Fast LP Simulation

By Luke Lang
What are the most important features of a logic simulator?

I’m sure there have been lots of surveys done for this question. Unfortunately, I can’t find any results on Google. Nevertheless, I would be willing to bet that fast performance is at or near the top of every verification engineer’s wish list. For the low-power verification engineers, fast performance is also a key requirement.

It is not my intention to turn this blog into a marketing campaign for one simulator over another. However, it is also difficult to ignore our fascination with things that are fast. I remember having a Road & Track subscription and knowing the 0 – 60 mph acceleration time for all the fast cars. And that was before I got my driver’s license. Who doesn’t think the SR-71 Blackbird is the coolest plane ever built? To satisfy this craving for speed, let’s take a look at the similarities between getting from point A to point B quickly and speeding up LP simulation.

1) Drive a car instead of walking.
LP verification equivalent: Use an LP-enabled simulator. I have seen many, and even used one manual technique, to simulate a power shutoff (PSO) design. I used the testbench approach to simulate PSO. The testbench will monitor the shutoff control signal. When it is on, I force all flops in the shutoff domain to the X-state. (This is known as corruption.) When it is off, I release the force. The problem with this approach is that it took over a week just to get the first testbench written. Keeping up with the RTL changes became a recurring nightmare. All of the other manual methods, such as PLI model, power-aware gate-level model, etc., have similar problems. It is slow to set up a LP simulation.

With an LP-enabled simulator, one can code a power intent file and bring up an LP simulation in a matter of hours, instead of days or weeks.

Lessons learned: Use the right tool.

2) Drive on the shortest road between point A and B.
LP verification equivalent: Make sure the LP simulator does not waste time on operations that bring no benefit. One example of wasting time is modeling a level shifter and checking voltage levels during an LP simulation. It is important to make sure that level shifters are correctly inserted and powered, but this is something that only needs to be done once. During simulation, there is no need to check this for every data transition. If the design contains 1,000 level shifters and each level shifter sees 1 million toggles, then the inefficient approach will check these level shifters 1 billion times during a simulation. The efficient way is to treat the level shifters as simple buffers without any checking during simulation. Leave the verification of the level shifters to a LP structural verification tool.

Lessons learned: Don’t waste time.

3) When the car is not fast enough, take an airplane.
LP verification equivalent: Use hardware accelerators. Hardware accelerators can be more than 1,000 times faster than software-based logic simulators. This means that a simulation that takes a week to run could be done in 10 minutes on a hardware accelerator. When it comes to LP verification, one must use a hardware accelerator that supports PSO corruption. FPGA emulation is one example that cannot support LP verification. The flops in the FPGA are always on. Therefore, FPGA emulation cannot validate the full operation of the chip with LP modes.

The universal argument against hardware accelerators is that that they are expensive. Well, the cost of a re-spin and lost market window could be much, much more expensive than the cost of hardware accelerators.

Lessons learned: Don’t be penny wise, pound foolish.

A final thought: The absolutely worst thing that a verification engineer can do is to skip LP simulation for even one testbench. A person simply cannot know in advance which testbench will find LP error and which one will not. Don’t be the person that let the team down. Follow robust LP design methodology and enjoy the rewards of a successful tapeout.

–Luke Lang is a senior product engineering manager at Cadence.