Latency simulations are the sworn enemy of the verification schedule. A handful of tests add days to weeks for each regression cycle; and when you add in the fact that they can’t be parallelized like the shorter bandwidth simulations, it gets hard to manage an engineer’s time efficiently. But…
What if there was a better way?
Since the olden days of simulation, all of that was true. Bandwidth sims were—and still are—mostly needed in the middle of the project time, but when the latency simulations come around at the end of the project they begin to dominate the regression cycle. This meant that the project would bottleneck at the end, and engineers would be left twiddling their thumbs, waiting days or weeks for a handful of tests to complete.
All of this was due to the fact that latency sims couldn’t be effectively shortened. The tests were simply too large and complex for the simulator to automatically break into convenient parts so they could be run on multiple machines. It simply couldn’t be done.
But now, it can.
Xcelium Simulator brings a new simulation technology to the table: multi-core. Patented software allows Xcelium to find the parts of a long latency simulation that can be effectively parallelized, and it distributes the overall simulation across multiple cores, representing a testing speed-up of anywhere between 3X and 10X, depending on the system. Before Xcelium, when all tests were run in single-core, no amount of distributing the bandwidth-hungry tests over many single-core machines could save your overall project time. The latency simulation was just so much longer that the bandwidth sims that the extra resource consumed for bandwidth simulation was essentially wasted. There was no real reason to use all of the processing power at your disposal if it wasn’t actually going to make your regression any faster overall. Xcelium Simulator opens the bottleneck, and makes it advantageous to strategically match your total bandwidth tests to your new, shortened latency test, thereby making the most efficient use of your resources.
Figure A: A simulation needs change as the project progresses. In the middle, bandwidth simulation is the primary use of resources, but as the project reaches the end, latency simulations dominate. At that point, the only pragmatic way to address regression time is to apply multi-core simulation. Bandwidth simulation regression time can be lowered by the use of additional machines, but only a new engine can reduce the latency simulation times.
It boils down to this: originally, engineers had one knob with single-core processing power: number of machines. It was like a radio with only a volume knob: they could throw more and more machines at a project until it finished—but there was hard limit in place with the latency tests. The number of machines engineers have access to is a finite resource, as well—that volume knob doesn’t go to eleven. Now, with Xcelium Simulator, engineers have access to a second knob: multi-core. Engineers no longer have just a volume knob—they have bass and treble adjusters. Like any audiophile knows, control over the system is paramount—and that’s exactly what Xcelium Simulator gives them: control. Parallelizing the latency simulations drastically reduces overall regression time because engineers can tune their single-core machine use to match the reduced run time for the latency tests.
Xcelium Simulator is the next step in simulation technology—a true third-generation engine. With multi-core technology, Xcelium allows engineers to have unprecedented control over their tests which in turn allows them to further tailor their test sequencing to their specific hardware needs.