Thomas Delaye, director of technical marketing in the Emulation Division at Mentor, a Siemens Business, recently studied how data could be used more effectively in chip design verification tools, such as hardware emulation. A big challenge, he discovered, because hardware emulation has a data problem, notably the large amount it generates. What follows is Lauro Rizzatti’s interview of Delaye where they discuss whether AI can manage data for SoC Verification.
Lauro Rizzatti (LR): Thanks for joining me today, Thomas. I heard you did an analysis on big data. Maybe you can talk about the criteria for the analysis and the results you have so far.
Thomas Delaye (TD): Well, it wasn’t really an analysis on big data. It was more of a project to look at data for engineering, which is different than big data. For me, big data is about the challenge of creating huge amounts of information, and the ability to process it efficiently for a specific purpose.
LR: You were looking at how data could be used to enhance or to be more effective in the verification of SoC designs. In particular, hardware emulation.
TD: Yes, that’s correct. The data problem for hardware emulation has two specific causes. The first one is very simple. Hardware emulation generates too much data. Imagine you have a billion-gate design and you do a verification run of a billion cycles. The amount of data you capture is too large to be processed or even recorded in some cases. Conventional techniques like waveforms, which everybody has been using for a long time, are of no help because just getting waveforms for one-million clocks can be mindboggling. In addition to the large dataset, there is the entire infrastructure to get that data out of the emulator and store it. As you can imagine that is not an easy task.
What do you? That’s where we move to the second problem, which is, we don’t want to gather more data than is needed. By managing data collection, we capture a meaningful amount of information to use in verifying designs. It is in this more complex area where AI can play a role.
Deep learning techniques and machine learning algorithms can be used to investigate the design based on verification results or design behavior. AI can help determine the amount and type of data to review to help understand what is happening. From that point, a verification engineer can identify what to explore further. Maybe to initiate a follow-up run or dig deeper in the current run by looking at a specific block and only that block, not the entire design. Suddenly, this huge amount of data becomes a much more reasonable amount of data.
This path of going from enormous data sets to capturing only a usable amount of data is something that is key for a next-generation verification platform. That way, verification engineers can deal with growing design size and complexity and increasing software content in a more precise way.
LR: What are you looking at to move emulation to this next generation verification platform?
TD: In emulation, we have the ability to run for a very long time, and the ability to “process” the entire design. With Veloce Strato from Mentor, for example, you have visibility to everything whenever needed. While it is easy to capture everything you want, not many people want to do that. What is needed is a mechanism that gives guidance to the user about when and what to capture.
This is where it becomes a bit harder because there are many types of data an emulator can provide. Things like basic information from a run where the information has nothing to do with the design itself. For example, the number of clock cycles run, type of transactions executed. All this data I would call generic detail. You just get access to it by having a fast platform with full visibility that can run the full design.
The other type of basic information is an understanding of the design behavior. For example, this information lets you know that the design is now in reset, and you don’t need to capture anything because the reset sequence is just resetting everything. You just want to wait until the next phase.
This type of data gathering requires a “brain” that shows a reset or when a particular memory is accessed, or a particular clocking structure is being activated. All those things require design knowledge. Making this happen is very complex because the emulator has to look at what is happening in the design and apply intelligence to the process. And that’s not usually what emulators do. Simulation engines and emulation engines are just pure engines. They’re taking data in, processing that data, and getting data out. In Veloce Strato, though, we create environments that take the data and analyze it for a specific purpose. The next step is to expand this type of capability and ease the pain of verification of large designs with large amounts of data at the full-system level. That’s the challenge.
LR: Can you give me a specific example of how these two aspects of the data problem play out in real life?
TD: Yes. Here is a very simple example. Imagine a very long verification run in a transaction-based environment. You pull a report that tells you when some DPI calls or transaction calls are being fired. Based on the time stamp, you attempt to correlate that event with the software running on the processor embedded in the design. Eventually, you would like to determine that at this time I was running this piece of code.
The user based on reports is making this conclusion, but the emulation environment provides no real correlation information. Only that the transaction is happening at a given time. Then you may say, at this time I was running and exercising this particular block –– my DDR, for example. Maybe I should look at my DDR to understand why I am sending this transaction at this time.
Users are asking us to build in pointers and information on what is happening in the design so they can go back and find it based on what they know and what they know to look for. And then because they know where to look, they know which design team they should work with to resolve it. Sometimes the verification problem is simply a matter of not knowing where look or which designer team should be consulted. Maybe the sequence is incorrect or maybe some code loading is incorrect or maybe something else. What and where to look first in my 10-billion gate design? That’s the first problem.
Next, they’re looking for some help as to what data can be provided that would help them focus on one specific issue. We don’t need to tell them what the problem is. Of course, that would be even better. When we could provide narrowly focused data based on all the data collected, it would make the correlation between the various logs provided easier.
The other aspect is that we could also imagine having some kind of verification methodology that would create a standard interface or centered way of providing data to tools that would identify the most common problematic blocks, or the type of signals or type of behavior that should be investigated. All of these things could be provided as needed to the emulator, as if you provide assertions, but vaguer so that you don’t want to spend too much time on that. Just say, if you see something on the power line that is not following the right sequence, you should flag it. We could provide data to narrow down the analysis.
LR: In this process of thinking and searching, have you run into any piece of literature, articles, blogs, and the like that you would consider an important data point?
TD: Not that I can think of. I don’t think anybody has approached this problem from an academic or even a public standpoint. I think this problem is the next step for verification. It certainly is a global problem that doesn’t have a good answer at the moment. Everybody is pointing to AI for help.
Also, AI is raising a particular concern to all of our users in that we’re going to be able to almost reverse engineer their code if we do AI efficiently. And I’m pretty sure that many companies would not be willing to provide us with any detail or provide us any design or provide logs because of secrecy and security. I think security is going to be difficult for this verification approach. When that is the case, we will have to find something other than AI that is a much more meaningful approach than just delivering waveforms.
Thank you again for the intriguing conversation and insights, Thomas. Maybe we can follow up in the future to see how this work is coming along.