Experts At The Table: Emulation
By Ed Sperling
System-Level Design sat down to discuss emulation technology and challenges with Narendra Konda, director of hardware engineering at Nvidia; Kasturi Rangam, director of engineering at Nethra; Jim Kenney, director of marketing for Mentor Graphics’ Emulation Division; Ran Avinun, marketing group director for system design and verification at Cadence; and Lauro Rizzatti, vice president of worldwide marketing and generation manager of Eve USA. What follows are excerpts of that conversation.
SLD: Where is emulation going to be applied going forward?
Rizzatti: Back in 2002 when we launched our first machine we did not have a compiler. We were telling the customer to buy it from Synplicity or somewhere else, but it was up to them. Today we have a compiler. We take half a billion gates and in eight hours we go from RTL to the bit stream. We put eight years into the compiler. Today the enhancements and improvements show up every three months. Those are known problems, but they can be fixed as long as you throw engineering resources. The same goes for debugging. It’s quite good today. It could be better and it will be better. As long as you invest engineering resources, everything can be fixed.
Kenney: To get to the question you just asked, we see emulation moving more toward simulation acceleration. Some customers would like to go completely away from dependence on custom external hardware. Ideally, if they could run their design and verify it on just the emulator, they could run this job on any of their emulators anywhere in the world. If a particular project requires ICE hardware, then it’s reliant on a machine configured just like that. If there are emulation resources available elsewhere that don’t have that hardware connected, you can’t use them. There are some real advantages to ICE, particularly for networking and many-port Ethernet controllers, but we hear customers saying it would be nice if they didn’t have that dependency. They ask whether we can engineer around that to be able to use emulators as general-purpose devices.
Konda: In our environment we have a place for both the acceleration and emulation. In the field of transaction-based acceleration, the kind of chips we are developing cannot be plugged into the final environment. It is the final environment. There’s no way to come up with the target system. We are employing the emulator for that particular task. We also use the same emulator for in-circuit because it’s a requirement. We have to run games and game traces. The same is true for processing images. We have to do it in real time because the amount of engineering and IP that goes into creating this little piece of hardware is equivalent in complexity to what’s being created in the software world. These two have to play with each other, and the only way we can make that happen is when we plug this chip into the final environment. That’s the only way we can run drivers of different kinds for different operating systems. We don’t see that going away.
Kenney: That’s for PCI Express?
Konda: Yes.
Kenney: That’s a great application for ICE. You have a device that’s going to plug into a PCI Express slot. You can plug that into your emulator and it’s a very good ICE application.
SLD: Let’s put this in perspective.
Avinun: I see three vectors here. One is traditional emulation, where the main purpose is to prepare the environment for post-silicon de-bug. It’s going to stay there. The second vector is to continue with hardware-software platforms. We start with virtual prototyping, simulation, emulation, as well as FPGA prototyping. People will need to use all four of these combinations. The third vector is taking regression testing—the advanced verification you do today in RTL simulation—and moving a lot of these to the hardware. We have sophisticated techniques, but the industry is struggling. It’s not an easy problem to solve. In addition, you start to look at architectural analysis. With high-level synthesis you can take C code, port it to RTL and plug it into your hardware system verification environment and do architectural analysis, with performance and power analysis in the future.
Konda: If we were to break this into numbers for transaction-based vs. in-circuit, about 10% is transaction-based and 90% is in-circuit.
Rangam: In the past this was all happening in serial fashion. People would build a chip, then they would build a board and put software on top of that. More and more they want to start building their systems and their software. We cannot get away from FPGAs because of that, but we cannot keep affording big systems. Ideally I would want one system. The software converts our design to FPGAs or Palladium or other areas. If you can separate the two, we can build our custom and commercial FPGAs and quickly map an existing design. That’s the ideal solution for small companies.
Avinun: So when you’re talking about one system you want to be able to port it to different situations, like virtual prototyping.
Rangam: Yes, exactly. We had to translate our RTL. All the I/Os, PLLs don’t go into FPGAs. When you build software that is not part of the system software, you’re focusing on the core logic.
Rizzatti: If you deploy 10% of the applications in transaction and 90% in ICE, we’d make a bold statement that there is one major advantage in transaction compared with ICE. In ICE, you have the real world running at real speed, the emulation is running at low speed, and a speed range in between that is breaking the timing relationship between the two. In transaction mode you preserve the timing between the two and you control the timing for the whole environment and you preserve the timing relationship between the testbench, the outside world and the design. In terms of debugging and tracing problems, because you maintain the timing relationship you have an edge over ICE.
Konda: Yes, you do have control and the debug is probably easier. The reason we go to in-circuit is what the system brings into the picture. In the transaction-based emulation, your testbench is architected by an engineer and it’s not close to the real system. When we bring the entire system, we have the CPU, the chip set—that is my testbench. Whatever this testbench throws at me, it has to work because it’s a real environment.
Rizzatti: I don’t want to downplay the role of the ICE environment, but it should be 50-50, not 10% and 90%. There is value in each.
Konda: This transaction-based 10% is relatively young. In-circuit emulation we’ve been doing for 15 years. But in the recent past we have started bringing up this transaction-based environment. In the future it may go to 30% or even 50%.
Avinun: There are two camps. One camp says they want to re-use the testbench. The other camp says they don’t want to re-use the testbench because then they can’t find other problems. It’s still based on the same mindset. In the end, you need both.
Konda: To come back to your larger question about where emulation is going to be used, the way I view it is, looking at the complexity of the chips and taking the past as guidance to the future, as we go to lower nodes we are able to cram more and more transistors onto silicon. More and more algorithms on software are being migrated into hardware. Even system-on-chips, the application processors being used today are the size of a GPU five years ago. Even the mobile chips are becoming bigger and bigger. That means verification is more complex, system-level integration is a huge challenge, and on top of all of this we have as much or more complexity in software—and that needs to be verified.
Tags: Cadence, Emulation, EVE, Mentor Graphics, Netrha, Nvidia