Visibility into the FPGA.

Posts Tagged Design Flow

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

RTL or Netlist flow?

RTL or Netlist flow for FPGA debug?

RTL or Netlist flow?

EXOSTIV Dashboard ‘Core Inserter’ now proposes 2 alternate flows* for inserting EXOSTIV IP into the target design: the ‘RTL flow’ and the ‘Netlist flow’.

With the RTL flow, EXOSTIV IP is generated as a RTL (HDL) code ‘black box’, with a synthesized netlist underneath. EXOSTIV IP is inserted ‘manually’ by the designer into the target design by editing the RTL source code (VHDL or Verilog). Once inserted, the user manually runs the synthesis and implementation (place & route) of the instrumented code.

The Netlist flow lets the user pick the nodes to be observed from a synthesized design. EXOSTIV IP is then synthesized and automatically inserted into the target design netlist. The instrumented netlist can be placed and routed automatically too.

Which one is right for you?

You can choose the flow when creating a new project with EXOSTIV Dashboard software.

This choice has got consequences on the output files, on the results of the core insertion process and on the operations that you need to execute for obtaining an instrumented design.
See the table below:

RTL flow

  • Manual core insertion in RTL code
  • EXOSTIV IP is not linked to specific nodes
  • Nodes names are mapped during analysis
  • Requires synthesis, place & route and bitstream generation after insertion
  • Produces: a netlist of EXOSTIV IP, a RTL instantiation template and pinout / timing constraints

Netlist flow

  • Automatic core insertion in Netlist
  • EXOSTIV IP is linked to nodes selected from the design
  • Nodes names are mapped during EXOSTIV IP generation
  • Requires place & route and bitstream generation after insertion
  • Produces: an instrumented design netlist and optionally, a fully placed and routed design

The RTL flow…

…produces a generic debugging IP with the chosen resources and generic input port. The process of configuring EXOSTIV IP in EXOSTIV Dashboard is merely a matter of choosing the number of capture units in the IP and the width of them (see for instance an example of such IP component declaration in VHDL below). The generated modules will have ports numbered as: ‘cu0_Trig’ or ‘cu2_Data’.
Once generated, you can connect EXOSTIV IP to any RTL signal / wire from your RTL code.

Once the IP is connected in the target design RTL code and once the synthesis, P&R have run, the EXOSTIV IP inputs really have a functional meaning. It is then desirable to specify a logic name rather than an obscure ‘cu#_Trigger(0)’. It just eases analysis. So, this will be done in the analyzer, with the ‘Data Probes Remapping’ function (see screenshot below).

Typically, the RTL flow will be used when:

  • The same sets of nodes are observed for debugging. This would be the case for a AXI bus-based system, where debugging the system requires watching the AXI bus traffic.
    Typically, this supposes that there is little or no iteration for selecting the nodes observed during debug.
  • Interesting nodes are optimized, removed or renamed after synthesis, preventing from probing them. In such a case, the RTL flow gives a better ‘insurance’ to be able to watch interesting nodes. Using properties on signals such a ‘MARK_DEBUG’ for Xilinx Vivado or ‘SYN_KEEP’ for Synplify would, however, limit the risk of ‘loosing’ the interesting nets after synthesis.

The Netlist flow…

… uses a communication between the FPGA vendor tool and EXOSTIV Dashboard software to dig into the design hierarchy, extract nodes and clock information from the synthesized design (see the node selection window below).

Typically, the Netlist flow will be used when:

  • You want to save the time of design synthesis when a new EXOSTIV IP core is generated. This would be the case when successive core insertions must be run to track bugs.
  • You do not want to manually modify the RTL code – which can be time-consuming. Leaving the work of inserting and connecting EXOSTIV IP to EXOSTIV Dashboard software and the FPGA vendor tool suite proves extremely efficient.

Takeaways

EXOSTIV Dashboard flows are 2 alternate ways of generating and inserting EXOSTIV IP into your target design. Which one is right for you very much depends on your habits and the flow you are using for creating and debugging FPGA.

It would be too quick to dismiss the RTL flow because it is not fully automated – and requires editing the RTL code to bring the right ‘wire connections’ at the level where EXOSTIV IP is instantiated. The RTL flow fits well when the same specific nodes are systematically probed. Using scripts with conditional instantiation of IPs is a very efficient way to generate and debug designs based on a RTL approach. As we’ll explore in a future post, coding techniques exist for easing the work of wiring nodes across the hierarchy.

Similarly, you should think again before dismissing the Netlist flow because node names cannot be found after synthesis: some properties can be used for limiting this effect – and we’ll come back on this later. The integration of EXOSTIV with the FPGA vendor tool allows browsing the design hierarchy, selecting nodes to observe and then automatically generate an instrumented design. When available*, the Netlist flow can be a wonderfully productive approach for debug.

It will be also interesting to see how each flow make the most of a new feature (coming soon…):
a full scripting interface for using EXOSTIV Dashboard. We’ll come back on this too.

Thank you for reading.
– Frederic

*The Netlist flow is currently available for Xilinx FPGA only.

EXOSTIV is there – and it is not a monster

Happy Halloween

EXOSTIV is there – and it is not a monster

As you might have noticed, EXOSTIV for Xilinx is now released. With the launch, I have been on the roads to demonstrate the product.

The good thing about meeting FPGA engineers is the flurry of questions, ideas and suggestions received as I show the product. Your feedback helps us find new ideas, find where the most acute pains are and understand what you actually do. I would like to thank you, who have already dedicated some time from your supercharged week to see the product in action. (If you are interested to see the product, please contact me to check our scheduled events with me).

What is EXOSTIV?

Here is one of the slides I use to present EXOSTIV (click here for the complete presentation in PDF):

What is EXOSTIV

EXOSTIV is not an emulator.

Why is it important?

Well, because it is sometimes expected from EXOSTIV to be everything at once. Some examples:
– Can it partition design onto multiple FPGA?
(Nope, that’s the role of a partitioning tool. We have to define how our IP can be used with such tools, though).
– Can it implement this (specific) trigger condition?
(Well, some of them, some not. But with it capture capacity, you might not need such a complex trigger).
– Will it be able to replace a protocol analyzer?
(It depends on the protocol and where it is observed…).
– …

Of course, some of your suggested additional features are already in the development pipe at Exostiv Labs… But not all of them.

EXOSTIV’s main value is in the level of visibility it provides for systems running at speed.

New features will be built around this value

Ask yourself: what can you do with 8GB of captured data flowing out of your FPGA at multi-gigabit speed? Would it add something to the flow that your current tools cannot achieve?

At Exostiv Labs, we believe that a tool that tries to be everything at once would probably be very good at nothing, not well fitted to your flow and much too expensive for the value.

EXOSTIV is not such a monster.

Thank you for reading – and Happy Halloween to all!
– Frederic

STAY IN TOUCH

Sign in to our Newsletter