The Agony Of Choice

By Frank Schirrmeister
In my last post on “The Complexity of System Development and Verification” I outlined five main use models for verification at four levels of scope, enabled by seven execution engines. So how exactly do users choose between the different execution engines to run hardware and software together before the actual chip is available? It is far from trivial. The seven engines I identified are Software Development Kits, Virtual Prototypes, RTL Simulation, Acceleration, Emulation, FPGA Based Prototypes, and Development Kits that are based on the actual silicon samples once they are back from fabrication.

Two engines are used in pretty much every design flow I have seen – RTL Simulation and Development Kits. The choice whether or not to provide Software Development Kits (SDKs) and Virtual Platforms depends on how many independent software end users are expected to provide software. They are not part of the mainstream design flow to develop the actual hardware yet, but in an apps driven world at least SDKs have become a necessity for consumer devices like the Apple iPhone, the BlackBerry devices and others.

Which engines to use to execute RTL – RTL Simulation, Acceleration, Emulation or FPGA Based Prototyping – remains a matter of choice. Depending on project complexity, there may be a project phase of 6 to 12 months in which these engines are applicable before silicon. They can also be used  post-silicon to reproduce defects found during silicon bring-up. There is really no question on RTL Simulation; it is part of every mainstream design flow.

For acceleration let’s look at a couple of customer examples that were recently reported. At CDNLive Silicon Valley PMC Sierra reported on “Functional Verification of Next Generation IC’s with Next Generation Tools”. Their application is in high-speed, complex, multi-protocol routing with 100+ Million Gate SoC design. Their architecture contains 10 sub-systems, some of which could be classified as stand-alone chips! They run on a 18-month schedule. With simulation only it can take hours to send a single frame, and running the full regression suite can take more than a week. As a result interactive debug is difficult — it can take a long time to reproduce bugs and the team has to create simpler simulations to get reasonable simulation times.

Bottom line, longer simulation times mean a greater time lag between the release of RTL and subsequent verification before the next RTL release, which makes it challenging to complete a comprehensive verification plan while meeting time-to-market demands.  To address the speed challenges, PMC chose the Palladium XP Verification Computing Platform for both acceleration and emulation. In the case of acceleration they combined complex test benches using Specman with Palladium XP. They were able to execute simulations that would have taken one hour in 80 seconds, which meant effectively a 40x speedup with a 26 M gate DUT. PMC considers it straight-forward to migrate from simulation to simulation acceleration in their environment – major re-architecting of the test bench is not required and as a result simulation and simulation acceleration can co-exist as part of their overall verification strategy.

For PMC the main motivation to choose acceleration has been execution speed, and Cambridge Silicon Radio (CSR) reported on the same motivation during the recent CDNLive Israel earlier this year. Their presentation was called “NC compatible acceleration with Palladium XP” and it summarized their choice for HW assisted verification based on the need for a platform for SW development, accelerating RTL logic HW tests, short bring-up of new designs and debug capabilities. For CSR using an environment which runs at faster speed but really looks and feels like simulation was key. Using Acceleration they achieved in average about 500x speed improvement over RTL simulation (between 314x and 962x measured over nine test cases).

Speed is the main motivator for adding acceleration to RTL simulation.

The last remaining choice is between emulation and FPGA based prototyping. Let’s again look at users. A variety of users point out in John Cooley’s Deepchip.com in ESNUG 486 #1 the trade-offs they are going through in choosing hardware-assisted verification. It boils down to five considerations:

• “speed” – how fast does the engine execute
• “turn-times” – how long does it take to get up and running after new RTL is available
• “visibility” – how well can one debug the hardware and software running on it
• “connectivity to the real world” – how easy can a user connect to the interfaces the actual chip under development connects to
  • “multi-user” access – how easy can the system be made available to users, ideally remotely

This is also confirmed by Samsung and Altair as recently presented at CDNLive Israel (Slides 26 to 28 and 31 to 33). Their assessment was actually a little more intricate as outlined in the following table:

Example Selection Criteria for HW Assisted Verification

Altair is using a Verilog simulator combined with an Instruction Set Simulator (ISS) to create a debug environment for the SW engineers. They also build custom FPGA boards, for which they can be customize more components and lower bill of materials. As downside that requires a dedicated set of resources and long bring-up time for each design. In using rapid FPGA-based prototyping they use standard HW boards with software and an ASIC-like flow. For emulation they use Cadence Palladium and trade the lower speed than FPGA-based prototyping against very fast compile times, very good hardware debug capabilities and scalable capacity.

Samsung Israel needs to verify 5-32 Million Gate Image Signal Processing designs with infinite configurations and images. They use the Incisive Unified Simulator for scenario based verification at the block and integration level, which enables complex checkers for quick root-cause debugging. FPGA boards require design partitioning and longer ramp-up times, as well as longer turn-around times once new RTL is available, and longer debug times. Samsung is using Palladium emulation in synthesizable test bench and in circuit emulation mode, which can be used at early verification stages with end to end checkers.

As summarized in the table above, Altair and Samsung confirm the main issues described in in ESNUG 486 #1 influencing the choice for hardware assisted verification – speed, turn-times, visibility and multi-user access.

Where does all this leave us with respect to system design and verification? Choosing the right engine can be difficult at times. On the flip side we product managers in EDA need to make sure to define the requirements for these engines appropriately. There is always temptation to define a specific engine too broadly, which bears the risk to arrive at what we called where I grew up the “Eierlegende Wollmichsau” – the pig we can get our bacon from, that has wool we can shave off for clothing,  that can produce milk and lays eggs as shown below (I found the picture here). It would be nice, but does not exist — just like in system design and verification, where no single engine rules and all engines are needed in the flow and are best used in combination to make best use of their individual advantages.

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.