Lauro Rizzatti, Alex Starr, Guy Hutchison, and Rick Leatherman discuss the status quo of new emulation approaches and deployment modes
Source: EETimes
Editor’s Note: Dr. Lauro Rizzatti recently moderated a discussion on hardware emulation deployment modes with Alex Starr, AMD fellow at AMD; Guy Hutchison, Cavium’s associate vice president, Hardware Engineering, and Rick Leatherman, director Developer Tools from Imagination Technologies. What follows is a transcript of their conversation including a few questions from the audience at the end.
Rizzatti: The topic is deployment modes of an emulator. It is worth spending a few minutes on the history of the technology. The emulation technology has been around about 30 years, pioneered by Quickturn, IKOS Systems and Zycad. They were the first to come up with the idea of using the physical, real world to stimulate a design under test (DUT) mapped inside the emulator, and that was the mode that emulators were used for about 10 years. The mode was called in-circuit-emulation or ICE. No software tool would allow you to do that.
Then other companies, including Meta Systems that Mentor Graphics acquired in 1996 and Quickturn, developed the idea of connecting a software testbench executed by a simulator interfacing to the DUT mapped inside the emulator. They experimented with what became known as acceleration mode. The PLI interface of a simulator was later replaced with a transaction-based interface, which opened the door to a virtual environment where a physical testbench was replaced with a virtual testbench. Now, for maybe five years or so, many more use models have been brought to the market. Today, all the vendors are proposing these new models with some differences.
Alex Starr, Guy Hutchison and Rick Leatherman will discuss the status quo of these new approaches and deployment modes.
Starr: I work for AMD and we’ve been doing emulation for many years. During my time at AMD, it has been used intensively for about nine years. We started doing ICE mode emulation and we’ve been through the gamut of moving to transaction-based solution, IP level, hybrid models. Most of that was driven by two things. One: speed for software and two: verification acceleration and IP level testbenches.
Hutchison: I was the CEO of XPliant, which was acquired by Cavium in 2014. We have been using emulation for all of our designs for high-speed switching chip, in the range of 30 to 100 Gbps. We used it in the virtual mode with all drivers loaded in the emulated device. We used this as a replacement for full-chip simulation because we were running into capacity constraints, where we were no longer able to get useful simulation results at full chip.
Leatherman: We’ve been using emulators for a long time; something on the order of 15 years. Last time I checked, we had in the neighborhood of 17 hardware emulators in our lab, so we have a huge investment in emulation. I should mention that two of the big three emulator providers are well represented in our lab.
I came to IMG via the MIPS acquisition, so were primarily focused on CPU IP. I work in the tools area; we’re traditional users for the most part in terms of using in-circuit emulation mode. We have started to do transaction-based emulation work as well. I probably spend more time helping our core IP customers get their designs up and running on their emulation platforms then with actual in-house emulation use. I bring a different dimension to this discussion in that we’re an IP provider and a tools vender as well.
Rizzatti: Could you describe your verification flow, what it consists of, and how the various tools interact with each other.
Starr: We do, obviously, a lot of simulation. We have big simulation farms. They run full-chip simulations and at the IP level, maybe some at the sub-system level. We use it to generate high-coverage levels as part of a coverage-driven solution. We are doing more emulation work now around a platform-level workload, where we try and shift-left post-silicon work. We’re now at a point where we consider large chunks of that to be verification.
What we considered three years ago to be verification is now somewhat outdated. Today, we consider firmware and software as a part of the overall solution, including usual tape out gating kind of items. We use emulation also for IP-level verification.
For example, we use emulation for the recent “Zen” CPU cores at the IP level. We also started to use emulation for other IP and we’re going through that transition now, really picking up more speed for further IP using emulation. The software and firmware teams have been using emulation for a long time both in the ICE mode, traditionally, but also in this hybrid mode where we connect virtual platforms with the emulators. That lets the software team and the firmware teams really test out production-level code.
Hutchison: At Cavium, emulation was used only for full chip. Our device was broken up into sub chips. The sub chips used traditional simulation and then we used emulation when we got the full chip for performance verification. Our emulation use is broken down into three phases. The first one is performance simulation as we try to get the device up and get any full-chip architectural problems resolved. The second one is for software bring-up validation to get our software up and running pre-silicon so it’s ready for silicon debug. The third phase is for post-silicon validation. When we find problems in silicon, we go back into emulation and reproduce them in emulation so that we can track down the problem.
Leatherman: I’m approaching this from a CPU IP perspective as opposed to support for our customer base that also uses emulation. For our in-house work, a lot of simulation takes place and we try to get the design to emulation as quickly as possible. We look to get Linux booted as quickly as we can and get some level of soak test, for lack of a better term. Once we get that up and running, we try to reproduce that platform on large FPGAs. That way, we can get the software guys up and running. If any anomalies are uncovered on the FPGA platforms, we usually go back to the emulator and try to sort out where the issues are. We focus a lot of effort on maximizing performance. However, power is starting to become the dominant concern. The emerging IoT market is driving power.
Rizzatti: All three of you are using the emulator in ICE mode and in transaction mode. How do you compare the two modes?
Starr: I think they complement each other. If you have ICE target systems, for example, a hard disk drive, that hardware “is what it is.” What I mean by that is even if it’s out of spec, it is a real hard drive, and it will do whatever it’s going do. Your design is ultimately going to need to work with that. When you have real targets, real systems, it gives you that extra level of comfort to know that your design is going work with those devices. That being said, it comes with a bunch of challenges, such as you have cables that have to connect to those hard drives. If you have 50 hard drives, then you’ve got a lot of cables, and you have a lot of trip hazards in the lab and so on.
From a reliability and efficiency point of view, the transactional-based models or embedded models have definite advantages. Connecting virtual machines to hardware emulators gives you a lot more flexibility and more efficiency. You can prevent downtime. A good example of this is that you could easily have a disk go bad or a cable go bad over a weekend. Our team in China, on the other side of world from the labs, can do nothing about this. They have to wait until somebody physically comes in and fixes our system. If you have a transactor-based solution where you have a virtual disk image, you can just drag and drop an image and fix it right there and then.
Rizzatti: Regarding design debugging, do you see differences between the two approaches? Can you achieve the same results with both of them, or one is better than the other?
Starr: They are pretty much the same. But with a transactor-based solution, you can potentially get the save and restore capability that you cannot get in ICE mode. If you have a long workload that maybe includes an operating system boot, and then you want to do something interesting, you can save after that OS boot and restore both the virtual part and the emulation part and continue from there. From a debug point of view, that’s a huge benefit in terms of interactive debugging.
Hutchison: For our designs, we only use virtual. Part of that is due to the nature of our designs — there is nothing that is a real representative target for us that could generate 100 gigs’ worth of traffic. Even when we’re testing in a lab, we’re testing with an IXIA or a Spirent traffic generator. For us, there was no value to an in-circuit emulator approach, so we went with a full virtual approach for all of our simulation.
Leatherman: We use both ICE and transaction mode. A lot of the ICE work is similar to what Alex had alluded to earlier — it gets a little cumbersome if we’re trying to do remote work on the emulators and we have all kinds of cabling and set up. We go a step farther and plug our JTAG probes into the emulator to provide device run control and debug. The use of transaction mode is something that we’ve picked up on and in recent years and have started to use quite a bit. It doesn’t come across for free. There’s a little bit of a learning curve for doing that and I would caution folks to move into the transaction mode cautiously.
Rizzatti: Let’s talk about the new ways to deploy the emulator. Today, we can use an emulator to perform power analysis, low-power verification, software debugging, design for test (DFT), and others. Have you used or plan to use any of them?
Starr: We do quite a lot of DFT testing and doing that for quite a few years with JTAG patterns, memory BIST and so on. I think we can expand more in that area because DFT and design for diagnostics (DFD) is getting more complex. We want to test all of those chip features out and make sure they all work prior to silicon. Power analysis is something that is a growing area. I wouldn’t say just power analysis in the dynamic power sense, but more on the architectural-level power events, or how IP is sequencing through power states. The power intent angle using UPF connecting all of those together is becoming an interesting area.
Hutchison: We haven’t done any DFT work to date. We have started doing power analysis, particularly in terms of running at-speed patterns and then using those to feed into our IR-drop analysis, so that’s been useful. For our device, hardware/software debug has been invaluable. Our device is a software-defined networking chip. Essentially it doesn’t know how to do anything when it powers up. When the interaction between hardware and software kicks in, debugging and making sure the design intent was expressed correctly is critical.
Leatherman: Verification is our core use model. Embedded software development is probably the fastest growing use model for us at the moment. Looking forward, the new power profiling capabilities of emulation will get a lot of attention. We are focused on the IoT market right now and in that marketplace power is everything. We are looking at using emulation to identify early on where power issues are, not only at the CPU level but in system designs as well. We’re no longer able to go out there with a core that is fast and low power. We have to go out and deliver a core with known system operational characteristics and be able to guarantee it will integrate seamlessly with a plethora of peripheral devices. That said, power is the driving force right now.
Rizzatti: Is there anything you cannot do with an emulator?
Starr: Analog testing. It’s interesting, actually. Emulation presents this luxury of being able to do system-level workloads. Part of our system-level workloads with CPUs is running BIOS, doing memory training. Memory training has inherently got some analog portion to it — shifting edges, trying to find the eye of DRAM. For this we use transactor technology that we developed for our hybrid emulation models connecting to a virtual platform, but applied to simulation. In hybrid simulation-based solutions, the simulator can model the analog portions, whereas this analog modeling isn’t possible today in emulation.
Hutchison: I’ll reiterate — analog. We missed a bug in one of our prototype chips because all of the analog models are stubbed out. Because of that, when we did the chip initialization, we would have figured out that we were unable to do these things, but because the model did not exist, we couldn’t exercise them. It also results in changes to the software stack because now you have to work around devices which are not present when you’re doing emulation but are present in the final system. The other thing is design debugging. The debug ability in emulation is not as good as in simulation. It’s not something that it can’t do, but it is a cost benefit trade-off. You get a huge performance advantage in emulation, but there is a cost associated with it. It’s harder to track down a bug.
Leatherman: Faster… we always want it faster. With software, debug becoming a major use model, OS and RTOS boot times are critical. Device driver debug can consume a lot of emulator bandwidth as well as basic debug techniques like single step. For large SoCs, the amount of interactive emulator operation required to facilitate optimization of DUT speed and power consumption demands faster compile times. The key is the overall speed of operation.
The other wish list item is sharing the resource. Emulators are a limited resource and everybody’s clamoring for access. On my wish list are better methodologies for sharing the resource and remote DUT control.
Audience Member: How do you compare the emulation platforms of the big three (Cadence, Mentor and Synopsys)? What are the pros and cons of each of them, and which one should I select?
Leatherman: I’m not going to touch that. In all seriousness, when you do an evaluation on an emulator, it’s not something to be taken lightly. Obviously, they’re very expensive, so a lot of due diligence is in order. Make sure you have a clear understanding of your use model.
Interestingly, I’m starting to see startups calling out a hardware emulator as a line item in their capital equipment requirements for venture funding. Emulation used to be the domain of only the largest high tech companies — that is changing. With the level of integration we’re seeing in the current generation of SoC designs, many are starting to recognize emulation as a necessity.
Back to my earlier comment, you have to take a look at the nature of the designs you typically do and your planned use — will you use emulation strictly for validation or will embedded software debug be required as well? How many engineers will need access to the emulator and what will that topography look like? If you expect to do a lot of design iterations, things like compile time become important. The “ecosystem” is equally important for things like VIP, or verification IP. There’s an awful lot to take into consideration, and everybody has strengths and weaknesses, so it’s certainly not a one size fits all by any way, shape, or form.
Hutchison: I think that’s a fair statement that all the available platforms have some strengths and some weaknesses. We made our selection based off of what made the most sense for us. In particular, because of our usage model that is entirely virtual, the decision was heavily influenced by the availability of domain-specific verification IP for the platform.
Starr: You should develop methodologies that allow you to use any of the solutions so that you can make different choices down the road and keep your options open.
Audience Member: For your transactional models, is that exclusively for the VIP in the testbench, or are you transactionalizing some of the devices you use as well?
Starr: We’re using it for internal IP as well. We use it especially when there may be models that get delivered into an SoC on different schedules. Maybe you’ve got third-party IP coming in or some team is late, and if you have a virtual model of that IP, you can start your full-system emulation earlier.
Audience Member: And for your DFT, DFM type work, is that done at the register transfer level (RTL)? Or do you emulate the design at the gate level?
Starr: The answer is yes, we do both. Some features of DFT, DFD, are available in RTL, and so we’ll test all of those in RTL when we can. However, things like scan insertion are only happening during the netlist phase in certain flows and so we do put gate-level netlists onto our systems and test things like scan.
Audience Member: What kind of analog misses do you get? Some things you could do even if you have analog. For example, a lot of the analog issues are just connectivity inversing issues for simple logic. You could potentially download a simple Verilog netlist and get the whole thing in, and get a lot of issues caught that way.
Hutchison: If we had models that extracted the digital functionality with a lot of analog IP that was on the chip, the problems that we ran into in many of the software diagnostics and bring up issues could have been resolved in emulation. We’ve started asking for digital models of our analog IT.
Rizzatti: Some are automatically dumped by the tool. You don’t have to develop a model. It’s a bottom up. It extracts the Verilog down set and then that’s it, and we debug that way.
Hutchison: The models in question did not have analog only. We had functional simulation models, but we did not have any synthesizable model. We would write our own models, which defeats the point.
Starr: Then we reiterate that as well. We went through this phase of blocking out the entire analog models a few years ago. As more and more software teams and firmware teams want to run production code, then that software requires all of the analog IP registers to be defined and accessible. Now we get versions of the digital portion of the analog IP that we can use in emulation, so the programming model is intact.
Dr. Lauro Rizzatti is a verification consultant and industry expert on hardware emulation (www.rizzatti.com). Previously, Dr. Rizzatti held positions in management, product marketing, technical marketing, and engineering. He can be reached at lauro@rizzatti.com.