Emulators are becoming more important for chip verification. While they used to be valued for in-circuit emulation (ICE) – real-worldish implementations of pre-mask hardware, the driving force now is the ability to execute software on pre-mask SoCs.
But an emulator is a big beast of a machine, and, for two out of the three emulator players, doing an upgrade is an even bigger process because they have to design their own custom chip for the heart of the emulator. Mentor just announced such an upgrade, doubling the speed and capacity of their existing Veloce emulator.
They did a new version of their internal chip for Veloce2 as well. It’s mostly just a scaling up of the old version, but they did add a new kind of memory – XMEM – for more efficient implementation of small register-based memories.
One of the confusing aspects of this market is the distinction between emulators and FPGA prototype boards. You might think that the “FPGA” is what makes the obvious difference, except that EVE makes an emulator out of Xilinx FPGAs. And I’ve even heard reference to the custom Veloce chip as a “custom FPGA.” The big difference between the custom and off-the-shelf FPGAs seems to be debug access. While a commercial FPGA has some debug capability, if you design your own strictly for that purpose, then you can bulk up on the observability features.
FPGA prototype boards, by contrast, have historically been used differently from emulators. While designers need to be able to implement quick design turns in an emulator as they refine a design, prototype boards tend to be implemented after the design is stable, with lots of effort going into maximizing performance – which will typically be 5-10 times (or more) faster than what can be done in an emulator. These prototypes are then available to software programmers as development targets.
When Mentor makes comparisons in their announcement presentation, it is typically to Cadence. They perceive the EVE situation as fuzzier because of the FPGA positioning confusion and the fact that they find themselves competing with Cadence head-to-head more than with EVE (almost as if EVE had a different user base). I have no idea whether the Mentor/EVE lawsuit plays into this (the Mentor spokesperson stayed far away from that topic). In general, Mentor sees themselves with a particular advantage in design turn time and debug capabilities.
Along with Veloce2, they also announced VirtuaLAB, a general programmable peripheral that is intended to simplify the process of generating traffic or otherwise including a real-world peripheral in the emulation setup. In addition to their need to be physically found and plugged into the setup with each test configuration, real peripherals also need rate-matchers since emulators can’t keep up with the real-world speeds.
VirtuaLAB is a pizza box that can be installed along with the server farm for general use. It can implement one or more peripherals (Ethernet is used as an example of a complex peripheral). The question of how many peripherals can go in one box comes down to bandwidth – communication is streamed on a SCE-MI-2-over-PCIe link, with multiple peripherals being multiplexed across the link. You can do as many peripherals as you can stuff across that cable.
They’ve included a couple features intended to save time and increase system availability. One is save-and-restore: this captures system state for later use. It can take a while for an RTOS to boot (or up to 10 hours for a large OS). Rather than having to go through that for each run, you do it once, save after boot-up, and then you can start from that point (or any other saved point) for all future runs.
The other feature is the ability to work with CodeLink. An entire run can be captured, and then engineers can work offline to do analysis and debug rather than having to chew up emulator time doing that.
You can find more information in their release.
