In the first major emulator news since Synopsys gobbled up EVE, Synopsys announced the next generation of the EVE platform, ZeBu 3. And, as with pretty much any emulator story, the top line has to do with capacity and performance: how much design can I cram in there and how fast will it go?
They claim industry-leading 3 MHz (with one example going as high as 3.5 MHz), as compared to what they say is a competition range more around 1-1.5 MHz (I’ll let the comps comment on whether or not that’s a representative number). As to capacity, you can stitch up to 10 of their boxes together for a total of 3 billion gates.
They also mention a number of different use modes for emulation, which are morphing as capabilities both inside and outside the emulator evolve. One in particular caught my eye because of how it contrasts with past usage.
Once upon a time, a significant use model for an emulator was to accelerate simulation. If there was a piece of the hardware that was taking too long to simulate – and in particular if it didn’t need simulator-level observability (remember: in a simulator, you can theoretically access every node; in actual hardware, you can only access those nodes that have been provisioned for access) – then you could implement that function in hardware and have the simulator call it as needed.
That ended up shining the spotlight on a significant bottleneck: handing off the function to the emulator, which required specifying pin-level signals across the interface. This led to the development of the transaction-based SCE-MI 2 interface, which abstracted away the detailed pin-level interface, making it all go so much faster.
That’s all old news. As emulator capacity and speed have improved, the focus has moved more to acceleration of software execution in SoCs. Not only does the emulator execute the software more quickly than a simulator can, features like save and restore can allow you to capture the state, say, after boot-up, and start there rather than having to go through the entire boot sequence every time. Yes ,you could theoretically do this with simulation as well, but simulating software just takes too long.
So we’ve gone from mostly verifying by simulation (on a PC) to doing much more of the verification on an emulator, now that it’s big enough. But you know… we’re never satisfied, are we? Give us an inch, and we want another inch. Yes, we can run software fast, but we don’t care about all of the software, or perhaps we don’t care about all of it in as much debug detail. Believe it or not, this software is taking too long to run on the emulator.
So what to do? How about running it on a virtual platform? Virtual platforms abstract away the low-level execution details, and so they can run much faster. So now, in a complete role reversal, the emulator can offload software execution to a PC running a virtual platform, which acts as an accelerator for the emulator – the very same emulator (or a bigger, faster version) that used to be an accelerator for the PC doing simulation. Synopsys refers to this as “hybrid mode,” one of the various use modes that ZeBu 3 supports.
What goes around…
You can get more details on all of those modes as well as the other speeds and feeds in their release.
