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 Imaging; 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: What makes one company’s emulation different from another’s?
Rizzatti: We made a decision from day one to use commercial FPGAs. Back then, 10 years ago, we were too small to undertake the design of an ASIC. For us it was a mandatory choice, which was to select the best from the market, which is what we did. Ten years later, I think we did the right thing. Using the best you can get in the commercial world, you have a path into the future. To use commercial FPGAs, we had to invest heavily in software.
Avinun: We came from the same place originally. In the 1990s we used systems based on commercial FPGAs. We faced several challenges, mostly in debug and compile time. At a certain point we moved into custom FPGAs. At that times we had problems in scalability. We switched into custom ASICs as well as FPGAs. If you look at the market, we initially chose performance and in-circuit emulation. That was the right choice. This is an area many customers can get into quickly. However, in the last 5 to 10 years we have added other modes of operation, including simulation acceleration and transaction acceleration. We also are migrating to simulation.
Kenney: Mentor also has had offerings in both spaces. Based on experience we are now full custom-IC based because of fast and reliable compile and full-visibility debug.
Rizzatti: But in answer to your question, why Eve? Because we can bring higher speed and lower cost.
SLD: Let’s get a reality check from customers. What’s the criteria for end users?
Rangam: I work for a small company and cost is a big factor for us. Typically we use FPGA platforms to prototype our products. We have to prove our technology on FPGAs before we even sign up for a product. We have been using that for two years, but we also have seen the debugging and scalability isn’t there for FPGAs. We had to build a custom FPGA to debug our chip emulation. That was very expensive in terms of schedule for us. We looked at Cadence Palladium and Cadence Extreme. Palladium gave us the scalability and cut compile time. We were able to compile in a half hour. Simulation time was also key for us. We deal with high frame rate DDR applications. It used to take us 1 week for one frame of simulation to find out if the programming was correct. With Palladium we got it running in two minutes.
Konda: I’ve been a user of Mentor technology for a number of years. I’ve been a user of Cadence Quickturn—both custom FPGA and processor-based systems. And on the side we did use Eve, although it wasn’t in the production flow. In addition, we also have FPGA prototyping systems. Each of the systems has its own advantages and disadvantages, but they also have specific applications to a certain segment of chips and specific types of workloads we put on the emulator. When we go to systems on chip that are really small, which have different types of interfaces like PCI Express, USB connectivity, the SD card interface and camera interface, each interface has its own characteristics. Some interfaces have to run at specific speeds. When we have those constraints we have to use specialized solutions such as FPGA prototyping. There is a possibility to use either Eve or Mentor technology in that space, which we have explored. But how do you tune this technology to solve these problems? Doing prototyping is cost-effective, but the biggest issue we have is the time it takes to port the design from one environment to the FPGA. Technology mapping is the most time consuming.
SLD: How long does it take?
Konda: The very first time it could be two or three months. As the design matures it could be three weeks. At some point in time we do get to one week. That is a cost we pay, but we pay it to solve this tough problem. Current emulators run at 4MHz to 5MHz. Mentor and Cadence Palladium run at 1MHz to 5MHz. But that doesn’t cut it. It may have to run at 125MHz. The tool creators have to think how to implement these interfaces. I still believe the FPGA-based platforms can be modified to deal with these problems. The physical hardware is the same.
SLD: Let’s get back to the original question. Is one better than another?
Rangam: FPGAs are very good for prototyping, and we use that even with commercial emulators. We want to be able to be able to ship a board to our customers so they can physically look at the image quality from our algorithms. They don’t want a C model. They want to connect it to a sensor and see the output. We use Palladium for our verification because we need to catch all the bugs. You get 1MHz to 2MHz performance. It’s not enough, but it’s a lot better than 50KHz.
Avinun: When it comes to FPGA-based systems, the main issue is predictability of bring-up time. It could be a couple of weeks, in some cases it may be six months. It’s still not as predictable as other systems, and for customers schedules are important. The other thing is debug and turnaround time. If something doesn’t behave as you expect, you may not be able to find the problem. If you do find the problem you don’t have predictability for many cycles. If my design is stable and I know it’s stable, then FPGA-based prototyping is great. It can give you faster performance. But if you need to go back to the debug mode multiple times a day, you probably want to stay with the other platforms. That’s the difference between FPGA-based systems vs. others. When you look at our platform vs. Mentor’s, traditionally the difference was compile time, debug, and to some extent scalability. And in-circuit simulation has been an advantage for us.
Kenney: That is a differentiation, but I would soften it. Both our systems are full-custom IC-based. At Mentor we have focused very heavily on transaction-based capability in terms of performance and how fast you can take a transaction-based testbench from simulation to emulation. We’re stronger in transaction-based, Cadence is stronger at ICE (in-circuit emulator). But we do ICE, they do transaction-based, too.
Tags: Cadence, EVE, Mentor Graphics, Nethra, Nvidia
July 30th, 2010 at 8:00 pm
Thank you Ed for coordinating this discussion!
I am Thomas Huang and have devoted the last 20 years in ASIC Emulation and Rapid Prototyping since co-founding PIE Design Systems as CTO in 1990. I transitioned from emulation to programmable Rapid Prototyping with Aptix as CTO for 8 years, since 1995. The discussion here really summarizes that emulation is not a mainstream SOC validation vehicle and Rapid Prototyping is so difficult to scale up and debug. I applaud the experts’ opinions and would like to share my thoughts.
Emulation is necessary hardware for ASIC/ASSPs that can be validated in a controlled environment such as CPU, GPU, router, etc. Emulation’s challenge is to reduce ownership cost, so more people can afford it. Commercial FPGA capacity is growing faster than proprietary ASIC, thus area cost per gate is lower and scalability is better. Rapid Prototyping is a mainstream validation vehicle for consumer electronics that must validate in a compatible environment such as Smart Phone, PDA, Digital Camera, HDTV, etc. The key Rapid Prototyping challenges are with interconnects, RTL technology mapping and FPGA debugging. Unfortunately only the debugging area has been addressed slightly. Interconnects are a major problem to scale up the prototype and it requires some breakthrough technology. Today, most people use subsystem prototyping method to reduce interconnection requirements. As Konda pointed out, technology mapping consumes the most time since it includes a bring-up process that ensures the mapping correctness. With an emulator, co-emulation is performed before in-circuit to check the mapping results; however this process is not available in Rapid Prototyping flow.
Emulation runs slow but costs more due to excellent scalability and debugging capability.