Design Article
When perfect is good enough
Angela Sutton, staff product marketing manager, FPGA Implementation, Synopsys, Inc.
1/4/2011 7:46 AM EST
Designs must be developed using techniques that will specifically enable mission- and safety-critical operation of the design after it is deployed. For example, EDA tools must allow engineers to build and retain redundancy in the design, as well as custom error detection and mitigation logic that automatically resolves errors such as those due to radiation effects. This logic can quickly return the system to a known safe state of operation ensuring high system availability in the field with correct and reliable operation and minimal downtime.
The design itself should be fully checked prior to deployment. Formal verification equivalence checking, virtual prototyping and software simulation are techniques that assist designers in verifying functional correctness and verifying that performance and power needs are being met.
EDA tools can also provide a valuable means to track and trace requirements from specification to completion of a project, while still achieving the required design performance on schedule. Project managers, system architects and design and verification engineers can now track requirements electronically from specification to completion. This allows design teams to develop processes that ensure their projects are in compliance with, for example, DO-254 requirements.
This article considers the various elements and methodologies noted above that are associated with the creation of high-reliability and high-availability FPGA designs.
We’ve all been there. The pre-flight announcements during which your fellow passengers are settling in, squeezing out a few more emails, greeting their neighbor – basically doing anything but listening to the safety instructions required by the FAA. And yet, we all take safety seriously. We know that at every step in the mil/aero design chain, safety matters. And, that includes those of us down to the level of the FPGA designs at the heart of so many mission-critical and safety-critical electronic systems. With an increasing number of specification requirements, tougher standards and very complex verification challenges, perfection is hard to achieve. But striving for perfection is exactly what we need to do.
So, how can designers live up to such high standards? Today, the focus for designs at 28nm and below is on the high reliability and high availability of systems designed using FPGAs. FPGA design tools and methodologies should include techniques for tracking and tracing requirements from specification to completion while meeting schedule goals, features to build redundancy logic into the design for custom error detection and mitigation, and options for system validation to verify functional correctness and quality of results. Figure 1 below shows an optimized flow for high-reliability and high-availability FPGA designs.

Figure 1: Optimized flow for high-reliability and high-availability designs
(Click on image to enlarge)
Next: -
The design itself should be fully checked prior to deployment. Formal verification equivalence checking, virtual prototyping and software simulation are techniques that assist designers in verifying functional correctness and verifying that performance and power needs are being met.
EDA tools can also provide a valuable means to track and trace requirements from specification to completion of a project, while still achieving the required design performance on schedule. Project managers, system architects and design and verification engineers can now track requirements electronically from specification to completion. This allows design teams to develop processes that ensure their projects are in compliance with, for example, DO-254 requirements.
This article considers the various elements and methodologies noted above that are associated with the creation of high-reliability and high-availability FPGA designs.
_______________________________________
We’ve all been there. The pre-flight announcements during which your fellow passengers are settling in, squeezing out a few more emails, greeting their neighbor – basically doing anything but listening to the safety instructions required by the FAA. And yet, we all take safety seriously. We know that at every step in the mil/aero design chain, safety matters. And, that includes those of us down to the level of the FPGA designs at the heart of so many mission-critical and safety-critical electronic systems. With an increasing number of specification requirements, tougher standards and very complex verification challenges, perfection is hard to achieve. But striving for perfection is exactly what we need to do.
So, how can designers live up to such high standards? Today, the focus for designs at 28nm and below is on the high reliability and high availability of systems designed using FPGAs. FPGA design tools and methodologies should include techniques for tracking and tracing requirements from specification to completion while meeting schedule goals, features to build redundancy logic into the design for custom error detection and mitigation, and options for system validation to verify functional correctness and quality of results. Figure 1 below shows an optimized flow for high-reliability and high-availability FPGA designs.

Figure 1: Optimized flow for high-reliability and high-availability designs
(Click on image to enlarge)
Next: -
Navigate to related information


KarlS
1/4/2011 5:11 PM EST
This looks fine for designing from scratch. My focus is on SOC, and want to connect IP blocks by function rather than RTL which is almost the reverse flow. It involves taking the verified HDL, say from the above flow, and parse it to extract the control and data flow logic then personalize a class that is instantiated along with the system application code(not a SystemC class). The application code then uses the object methods to interface with the hardware functions. In figure 1 there would be a path into the virtual prototype from a collection of verified HDL without all the overhead of RTL simulation.
Sign in to Reply