Tech Talk: FPGA RTL Checking

How to make sure the RTL in an FPGA matches what you developed.

popularity

Tobias Welp, software architect and engineering manager at OneSpin Solutions, explains how to ensure the RTL created by design engineers matches what shows up in an FPGA.



3 comments

Patrick Lehmann says:

Nice graphs, but this presentation misses one important issue. The faults are mostly not introduced by optimizers, placers and routers. These equivalence checks are already done better or worse by most tools and there development teams.

The real problem is that faults are introduced in RTL synthesis when it comes to translating HDL to a first netlist. And secondly, when this initial elaboration netlist is mapped (translated) to a device specify netlist. Until know I know only one bug done by a tool in the last 8 years that was introduced while optimizing a design. But I know a some bugs that exist in translating HDL to the appropriate RTL design.

Tobias Welp says:

Hi Patrick,

See our comment below—not sure if you were notified when we posted it, since it was not a direct reply.

Cheers,
Tobias

Tobias Welp says:

Hi Patrick,

The most frequent use case of OneSpin 360 EC-FPGA is to verify the equivalence between RTL and the final netlist. This includes the elaboration/compilation of the RTL to a first netlist, logic optimisations, and the technology mapping to a specific device. These are all complicated transformations and throughout the years, working with all major tool vendors and several third party customers, we have witnessed our customers uncovering many bugs in all these parts of the implementation flow using our tool.

I experience that quality assurance is an important aspect for the implementation tool vendors and the major players indeed use OneSpin 360 EC-FPGA for this purpose. However, it is important to keep in mind that these QA measures are only as good as the test sets of the tool vendors. If a customer design triggers an HDL feature or a specific transformation that is not covered and the triggered functionality happens to be defective, the implementation on the chip will not be functionally equivalent to the RTL. Especially in the context of safety critical designs, this typically represents a concern and suggests to apply the implementation verification on the specific customer design.

In the past, logic equivalence checking (LEC) has become an integral part of any ASIC sign-off. As FPGAs become large systems-on-chip (SOCs), we see this becoming a must-have in this space as well.

—Tobias Welp

Leave a Reply


(Note: This name will be displayed publicly)