Mentor Graphics has updated its Veloce emulator, using a newly developed chip to double capacity while, at the same time, developing new software to overcome the traditional handicaps of in-circuit emulation.
Even before its formal launch, Veloce2 is apparently doing well. Eric Selosse, vice president and general manager of Mentor’s emulation division, said it has sold more units in the pre-launch, beta-testing phase than its predecessor did in its lifetime. There are some Veloce I chips left but with no plans to make more of those on its old process technology, it has almost sold out.
“We have invested very significantly in the front-end software that allows us to prepare the design for the emulator,” said Selosse, combining that with the custom ASIC to bring down compile times.
“We are not using a commercial FPGA from Altera or Xilinx,” Selosse added. “By using our own ASIC, we have been able to significantly reduce compile times. FPGAs have different goals to emulators. The goal of the FPGA is to maximize the number of logic cells used. We made a clear architectural decision to optimize for routability. As a result, if an engineer makes a modification to the design, they can quickly get a new model compiled for the emulator. That process might take hours for an FPGA; it’s five minutes for Veloce.”
The new chip for Veloce II is based on a 65nm process, offering higher density than its predecessor but without the much higher development cost of a device aimed at a sub-30nm process.
Another change that Mentor has made is to help with globally distributed design. “The emulator is becoming a shared resource,” said Selosse.
Sitting in a data center, accessible to developers around the world, it becomes tricky to patch the peripherals for an in-circuit emulator to support different projects. So, the company has developed software modules that allow blade servers to be used as virtual peripherals that are switched in and out dynamically. The VirtuaLab modules use the standard SCE-MII protocol to communicate with the emulator.
To reduce the number of cycles that are ‘wasted’ by booting software on the virtual hardware, it is possible to store snapshots of the state of the emulator at any point and restore that at the start of a session. As a result, software testing can resume from a known point without having to wait for several hours for the boot sequence to complete – something that would otherwise be run many, many times.
The snapshots also make it possible for software developers to replay the sequence of events leading up to the expression of a bug, allowing the actual hardware to be used on another project or a new verification run.