Xcelium: Parallel Simulation for the Next Decade

This morning, Cadence announced two new products in the verification space: Xcelium, and Protium S1. The Cadence implementation and signoff products now all end in "US" (well, you have to squint to make Joules work, because the "U" and the "S" separated). In the same way, the verification products end in "UM": Xcelium, Protium, and Palladium. Okay, and Jasper. There have actually been discussions about finding a "UM" name for the formal verification products (Jasperium, anyone?) but there is so much brand equity in Jasper and JasperGold that it would be foolish to squander it.

The picture above shows the big picture view of Cadence's verification products. There are four engines: JasperGold, Xcelium, Palladium and Protium. JasperGold and Palladium have been refreshed recently. Today is the turn of Xcelium (previously Incisive) and Protium. These are all best-in-class engines. The blue bars that cut across all the engines are common attributes, but there are also common tools that cut across all four engines and either allow the same interface to be used with each or tie results from different engines together.

I will talk about the Protium S1 FPGA prototyping platform later in the week; it is deserving of its own post. Today's post will focus on the Xcelium Parallel Simulator. This is the industry's first production-proven parallel simulator. When Cadence acquired RocketSim, I wrote about how there were three ages of simulation (Omnia Simulation in Tres Partes Divisa Est). These three ages were interpreted RTL simulation, natively compiled simulation and now, the third age, parallel simulation.

Tell me if you've read this before, but design size and complexity are growing. One result is that verification is growing. But it isn't just growing in line with design size---it is growing even faster. A greater and greater percentage of the manpower of creating an SoC is going on verification. Groups are spending more and more on tools for verification, running them on larger and larger farms (100,000 server farms and more). However, the spend on verification tools is actually much smaller than it should be based on the percentage. Groups are spending too much on verification engineers and not enough on tools to make them more productive.

At one level, Xcelium consists of a tight integration between Incisive and Rocketick, what we call direct kernel integration (when RocketSim was a separate company, it communicated with Incisive through an API and it has continued to do that until now). But there are other improvements, too:

• Multi-core engine improvement
• 2X single core speedup
• New randomization engine
• Agile release process for quality

The biggest change is that the RocketSim is now fully integrated as a first-class citizen. The unique compile/elaboration process analyzes each designs dependency graph (see the example above) and then maps it onto cores to maximize speed. The number of cores can be changed without requiring a recompile. The approach has been proven to be scalable beyond a billion gates.

The speedup depends on the design because it depends on exploiting parallelism in the design (different clock domains for example). But the image below shows some actual performance data from real engagements with early customers. Some are named, some are just identified by the type of chip being designed.

The rule of thumb is 3X+ speedup for RTL, 5X+ speedup for gate-level, and 10X+ for DFT (fault simulation).

The multi-core architecture allows for a more concurrent test methodology, testing different parts of the chip at the same time, rather than narrowing tests to smaller areas one at a time. Perspec can be used to create these scenarios since it pretty much creates scenarios like that (unless you constrain it not to). Multi-core is more effective with a high event density since different parts of the chip can, to some extent, be simulated independently since different parts of the chip have a lot of locality. With a single core, that is not the case. Events in one part of the chip slow down simulation of other parts just because all the events have to be handled at once.

New features in Xcelium include:

• Code coverage for SystemVerilog/UVM, improving testbench quality by validating that all testbench code is executed in regression
• Simulation save and restore: in particular, you can perform the boot sequence and then save the state, and then restore and run the different functional tests
• Incremental elaboration automation: parallel elaboration of design and testbench into objects that can be linked based on test configuration speeding overall regression
• Intelligently exclude related coverage entities using single action to speed closure of comprehensive IP verification

So faster single core, multi-core for fast SoC simulation, and a number of new productivity features on top as the icing on the cake.