A "virtual lab" emulation environment can meet the challenges of complex SoC design verification, writes Richard Pugh of Mentor Graphics
If you are verifying an SoC, you generally have three options when logic simulation runs out of steam – all based on hardware-assistance or acceleration.
Yet these options have major implications for reliability and involve uncomfortable trade-offs Key issues are: who has access to the acceleration hardware, at what stage, and how stable is the process?
The three hardware options generally used are FPGA prototyping, accelerated simulation using verification IP, and in-circuit emulation (ICE).
These suit some scenarios but have significant downsides when you are working on a continually evolving multi-processor, multi-protocol, software-heavy SoC.
Fortunately, there is now a fourth option using a "virtual lab" emulation environment, which is better suited to the large team, multi-disciplinary rolling integration challenge of such a complex SoC.
FPGA prototyping is fine if you are just doing software spins on unchanged pre-existing hardware but it’s unsuited to SoCs where the hardware is also undergoing significant development – it offers no concurrency in the design process because the FPGA board isn’t usable by the software team until the hardware is finished, and every time there’s a problem the recompile times could be days rather than hours.
Plus trying to split a multi-million gate SoC across multiple FPGAs is asking for trouble.
FPGA prototyping looks like a cheap option but it’s a long, painful, risky way round for an SOC with hardware debug still in progress - which is why it is now a static market while the emulation market is growing at 20% a year.
Accelerated simulation suits hardware developers who need to verify that there are no bugs in a newly developed ASIC or piece of fundamental IP using deep test sequences, code coverage, assertion-based verification, error handling, protocol checking etc.
But when you want to verify an SoC, in which multiple existing hardware blocks must work together and be driven by software, you need a verification method accessible to the whole software team. Embedded processors require test to become a software-inclusive process.
Until 2012 in-circuit emulation (ICE) was the only option for concurrent software-hardware verification where the hardware is subject to change on a regular basis before prototype hardware is available.
ICE suits a relatively small project team based at a single site where that team has total, personal control over the lab and when the design does not involve many different hardware target interfaces.
But it has serious drawbacks in terms of flexibility, reliability and ROI because it requires models of your target peripheral or host to be running on external hardware cabled to your emulator in the lab.
Cables and external hardware devices introduce complexity and potential causes of unreliability but they also restrict emulation access – the lab becomes the bottleneck.
The only way for ICE to offer emulation access to multiple remote teams of hardware and software engineers on multiple projects simultaneously would be to run the same project set-up on multiple emulators. This would be expensive, power hungry and complex to manage.
Mentor Graphics customers working on SoC designs began asking if there was a way to make the lab virtual so that they could give flexible emulator access to all of their software engineers without lab cable spaghetti and at a lower cost than trying to run multiple ICE set-ups as if it were RAID.
It was clear that the solution would need more of the verification process to occur in software.
Mentor Graphics announced in 2012 an approach which would end the reliance on external hardware devices running models of your target peripherals and instead allow you to put the emulator in your general datacenter and treat it as just another computing resource.
This new emulation approach, or "virtual lab", lets you load your target protocol on the emulator alongside your design and drive the software side of the test process from a PC where your real target OS, drivers and applications run safely inside a virtual machine.
A virtual lab is better suited for SoC verification than other approaches when your hardware and software are in the early stages of development and subject to frequent changes.
For multi-million gate designs, with embedded processors, multiple peripherals and complex software tests, it offers a major step up in flexibility of use and productivity but it is evolution not revolution.
Functionally it’s the same as in-circuit emulation but more of the process happens in software. It’s controlled from your PC or workstation, the same hardware-accurate models used in ICE solutions are provided and the engineer uses properly pre-validated IP.
Protocol RTL models, software stacks and applications are simply downloaded onto the emulator (i.e. Veloce) which powers the SoC verification process. Like ICE, the virtual lab approach gives software engineers access to the hardware design while still in RTL but does it flexibly and without the need for multiple set-ups and emulator downtime.
We can now begin to think of the emulator as a server rather than something in a lab which is only available to a privileged few.
For hardware engineers, moving the emulator out of the lab into the datacenter puts an end to downtime caused by cable dislodgement, pin breakage, lack of available pins or overnight waits for remote lab staff to swap cables between external hardware targets. With a virtual lab you no longer have to depend on custom target boards (i.e. speed adaptors) to run tests.
And for software engineers it’s a more stable, resilient environment running the real target OS in a virtual machine – for example if your code addresses a piece of memory that isn’t yet there you don’t get a hardware crash, the PC keeps working and it’s just the virtual machine that gets rebooted.
The goal is to enable flexible, always-on access to emulation for all of the software, hardware and integration engineers on all of an organisation’s projects at the same time.
You shouldn’t have to worry about where the emulator is, whether you can gain access, how long the queue is ahead of you, whether a cable has been swapped or kicked. The ideal is for emulation to be an invisible and fully shareable resource which you don’t have to think about.
ROI rises the more people have access. Concurrent engineering has been a long time coming.
