Is cycle-per-second ASIC simulation performance one of your concerns? If so, maybe you’re doing something wrong!

I can remember back in the early days of RTL languages (1990) when we needed to transition from using Verilog to VHDL as our tool of choice for developing ASICs for our new F-22 combat system. Uncle Sam was telling us that VHDL was going to be the new emerging standard.

We put together a list of features we needed to make the new simulator compatible with our planned environment and then we proceeded to call in the vendors. The main theme the vendors pushed was “Its all about performance”. Our response was “Wait Mr. Vendor, what good is performance if your simulator does not work with LSI Logic MDE tools, or with the old Logic Modeling Hardware Modeler, or the LM software models? What about your 1076 compliance? What does your roadmap look like?” It was clear that choosing a simulator because of a 10 or 20% performance advantage would be a disastrous decision if it did not easily fit in our environment.

Today it’s almost an entirely different picture. Simulators today have reached a mature status, so vendors are left with little but to still rant over their outstanding benchmark performance. I maintain that the importance (or lack of) of this remains the same. The word today is “Smart” Verification. Today it’s about using the simulation cycles you have wisely and not measuring your worth as a verification engineer by how many cycles you can throw at the device you are verifying. It’s about truly understanding the device you are trying to verify and writing structured constrained random stimulus to target all corner cases as efficiently as possible. It’s about using metrics to determine value of your tests with detailed functional coverage code, and using temporal declarative code to evaluate protocol behavior in an understandable fashion. This is “New Generation” testbench development and provides breakthroughs in verification quality and development cycle schedules regardless of simulator cycle per second performance.

Certainly better performance is nice and there are always exceptions that absolutely require the highest performance simulator and days worth of stimulus. On the other hand, with the maturity of simulators today, and the wealth of inexpensive Linux hardware coupled with transaction based HVL/simulator interfaces, in most situations isn’t your time better spent invested in your verification methodology rather than getting that last CPS from your simulator?

I am a strong advocate of using SystemC for “new generation” testbench development. My methodology stretches the OSCI simulator as far as it will go, uses PLI interfaces to stimulate and probe the device under test along with simulator specific kernel interfaces. My methodology involves running everything on Linux servers, and structuring my environments to gain portability by switching on and off vendor specific features such as assertions. We switch in vender tools as desired because they offer immediate value in accomplishing specific tasks, not because we are handcuffed to them for legacy reasons.

I for one am tired of listening to performance shootouts, performance pitches, benchmarks etc. My performance is measured by how fast and how well I can meet the project verification goals not how may cycles per second I can get out of my simulator. Or, maybe my tools of choice also just happen to be good performing tools.

Tom West

Cadence, Phoenix AZ

See more at www.openverificationfoundation.org