Visibility into the FPGA.

Posts Tagged analysis

Exostiv boosts RTL simulation

Exostiv boosts RTL simulation

It is essential to reduce the wasted machine cycles used for simulation workloads.

Simulation dominates ASIC/SoC/FPGA verification process

‘The 2018 Wilson Research Group ASIC and FPGA Functional Verification Study’ (you may have to register for free to watch this) reports that an ASIC, SoC or FPGA designer can spend up to 40% of the total verification time on creating testbenches, writing tests or running simulation. In addition up to 44% of the time spent on debug – and this involves running simulation too.
It is safe to say that simulation is the most dominant technique in the overall verification effort.

Simulation speed is losing the race against FPGA complexity.

Over the last decade, simulation software has improved at many levels. Simulation software needed these improvements so they would be able to cope with the increasing complexity of designing FPGAs and chips with hundreds of millions gates.

Simulation software now supports more languages, assertions, and verification methodologies such as Accellera UVM. Code coverage now includes testbench coverage – in order to keep track of whether a team has exercised specific test stimuli.

Interestingly, these efforts have improved the test coverage, provided metrics for signoff and standardized verification approaches based on simulation, but did not accelerate simulation that much. Even the most recent claims from simulation software vendors show RTL simulation acceleration by 4x or maybe 5x thanks to the execution of the simulation on multi-core servers… whereas the complexity of FPGA has been multiplied by 100 in the same period of time!

In 2018, 84% of FPGA designs had at least 1 non-trivial bug escape to production (source: The Wilson Research Group)

How to make the most of the simulation time

In the study mentioned above, The Wilson Research Group reports that a staggering 84% (!) of the FPGA designs have had at least 1 non-trivial bug escape to production – and that: 65% of the typical simulation times exceed 5 hours.

That is why it has become critical to make the most of the time spent in simulation, and limit – as much as it is possible – the wasted machine cycles. Otherwise, our verification techniques are at risk of becoming irrelevant.

In our experience, the following approaches have proven to be successful:
– Performing ‘per IP’ simulations to verify them helps spread the effort on multiple engineers in parallel and run shorter simulations;
– Make use of ‘snapshot’ simulation features – which consists in saving the state of a simulation and re-start from there to run specific simulations.

In the illustration below, two frequent snapshots are saved – after the boot of the processor and after the DUT is initialized respectively. This conveniently helps running combinations of initialization sequences and test stimuli without having to simulate the boot sequence over and over again.

Simulation shnapshot technique

Full system bugs can require multiple days of simulation.

As demonstrated in this presentation from Cadence on simulation tools, full-chip bugs, which occur when the full system is put together, can require days of simulation. A ballpark estimate is up to 54 hours of simulation for 43 milliseconds of SoC HW runtime! For these kinds of bugs, it has become equally crucial to:
– Speed up simulation; (that’s the job of simulation software vendors)
– Make sure that the simulated models are accurate; (EXOSTIV can definitely help !)
– Provide additional visibility from the real system to converge faster on finding the bug; (EXOSTIV can definitely help!)

What EXOSTIV can do to BOOST simulation.

Exostiv lets you record very long data sets from inside FPGAs running at full speed of operation.
Typical probing scenarios with their most common usages are summarized in the two tables below:
The first table lists common usages that boost simulation – illustrated below the table:

What is probedTarget usage
Specific IP inputs
(or group of IPs)
- Overcome modelling issues;
- Make test case match reality.
Specific IP outputs
(or group of IPs)
- Reference response database;
- See the effects of non- or hardly simulable elements,
(such as CDC or metastability).

Exostiv lets you record input vectors from reality for IPs and full systems

Other Exostiv usages that complement simulation:
What is probedTarget usage
A full system bus
- Verify / develop software;
- Evaluate system overall efficiency / performance over large - and real - data;
- Check system behaviour;
Specific nodes
- Functional verification and debug.

Conclusion

Exostiv complements simulation by providing a source of real-world stimulus for IPs, groups of IPs and full systems. It therefore helps overcome modelling problems that are the most common source of FPGA bugs escaping to production. Coupling simulation with the huge recording capability of Exostiv means you avoid wasting your quota of machine cycles dedicated to simulation and improves the quality of FPGA system sign-off.

When 84% of the FPGA designs report at least 1 non-trivial bug escaping to production, and 65% of the typical simulation times exceed 5 hours (source: The 2018 Wilson Research Group ASIC and FPGA functional verification study), boosting simulation is an absolute necessity.

As always, thank you for reading.
– Frederic

Record FPGA data during 1 hour – really

Record data from FPGA over long total times - deep capture

Record FPGA data during 1 hour – really.

As ASIC, SoC and FPGA engineers, we are used to watching the operation of our designs based on single limited snapshots. RTL simulations, for instance, provide bit-level details during execution times that span over a few (milli)seconds at best. Consequently, it may not be possible to see events that happen over long times as a single coherent capture.

In this blog post, I have wanted to show what can be done in a real case with EXOSTIV. The design that runs from a FPGA board is a full system on-chip that features a Gbit Ethernet connection. The board is connected to our company network – and I have set up EXOSTIV to trigger and record the Ethernet traffic during 1 full hour. Yes, we used EXOSTIV as an Ethernet sniffer, that works from inside the FPGA – providing a ‘decoded view’ of the traffic after it has entered the FPGA Gbit Ethernet IP. Check the video below. We have accelerated it but the stop watch shows the real elapsed time.

Like it is shown on the video, we have set up EXOSTIV to record a chunk of data (256 samples) every time ‘something’ is seen on the Ethernet interface: there is an event trigger when a wide variety of events (note the ‘OR’ equation trigger definition) marking the detection of traffic happen on the Ethernet connection. Each sample is 1,248 bits wide.. This gives a quite good insight of what is ‘after’ the Gbit Ethernet IP in the FPGA. Each burst records 256 x 1,248 bits = 319,488 bits of data – and there are 30,000 such bursts collected over a total time of about 1 hour.
In total, EXOSTIV has collected a little less than 1.2 Gigabyte during this run – which is just about 15% of the total memory provided by an EXOSTIV probe.

Practically, it means that we could collect roughly 6.6 times as much data… (> 6 hours) with this single capture unit.

You can see that the bursts are recorded rather randomly, as the occurrence of a trigger depends on the actual load of our company network. (Click on pictures below to enlarge and zoom on the data)

Exostiv Dashboard after capturing 1 hour of the Ethernet traffic

Exostiv Dashboard after capturing 1 hour of the Ethernet traffic - full capture
Exostiv Dashboard after capturing 1 hour of the Ethernet traffic - detail on the deep capture

As always, thank you for reading (and watching).
– Frederic

STAY IN TOUCH

Sign in to our Newsletter