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.
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.
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.
This website uses cookies to improve your experience while you navigate through the website. The cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. We do not sell any personal information.
By continuing to use our website, you consent to our Privacy Policy. If you access other websites using the links provided, please be aware they may have their own privacy policies, and we do not accept any responsibility or liability for these policies or for any personal data which may be collected through these sites. Please check these policies before you submit any personal information to these sites.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
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.
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
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