Design Article
Using FPGAs in mission-critical systems
Adam Peter Taylor, Principal Engineer, EADS Astrium
12/6/2010 5:01 AM EST
Simulation and verification
Once you have designed the state machine, you will of course wish to simulate it to ensure it meets requirements. It is also possible during simulation to try to test how the machine will behave when subjected to an SEU (it is worth noting that this can take considerable time and effort to achieve in full). You can corrupt the state machine using the force option within the ModelSim utilities library from a test bench. When attempting to simulate the effects of SEUs, it is important to remember that they are asynchronous events that can occur at any point in time. There are also third-party tools available that can test designs for SEU performance. One free offering, which injects SEUs into the design, is the ESA Single Event Upsets Simulation Tool, available at http://www.nebrija.es/~jmaestro/esa/.
Designers can undertake a similar approach upon the post-route simulation. However, it’s a better idea to verify the correct performance of the RTL code with regard to functionality and SEU tolerance and then conduct a formal equivalence check between the RTL and the post-route simulation netlist to ensure that they both behave in the same manner.
FPGAs will continue to be used in an increasing number of mission-critical applications as the growth in capability and performance demanded of these systems increases. The techniques presented here will provide you with the methodology required to make such a design a success.
Related articles
Comparing FMCs with PMCs/XMCs for harsh environments
Understanding and mitigating tin whiskers
High-performance FPGAs take flight in microsatellites
Xilinx FPGAs beam up next-gen radio astronomy
Xilinx rad-hard FPGA reaches for the stars
When perfect is good enough
Single event effects (SEEs) in FPGAs ASICs and processors
Transfer from FPGAs for prototype to ASICs for production
Design security yields secure FPGAs for mil/aero applications
Once you have designed the state machine, you will of course wish to simulate it to ensure it meets requirements. It is also possible during simulation to try to test how the machine will behave when subjected to an SEU (it is worth noting that this can take considerable time and effort to achieve in full). You can corrupt the state machine using the force option within the ModelSim utilities library from a test bench. When attempting to simulate the effects of SEUs, it is important to remember that they are asynchronous events that can occur at any point in time. There are also third-party tools available that can test designs for SEU performance. One free offering, which injects SEUs into the design, is the ESA Single Event Upsets Simulation Tool, available at http://www.nebrija.es/~jmaestro/esa/.
Designers can undertake a similar approach upon the post-route simulation. However, it’s a better idea to verify the correct performance of the RTL code with regard to functionality and SEU tolerance and then conduct a formal equivalence check between the RTL and the post-route simulation netlist to ensure that they both behave in the same manner.
FPGAs will continue to be used in an increasing number of mission-critical applications as the growth in capability and performance demanded of these systems increases. The techniques presented here will provide you with the methodology required to make such a design a success.
Related articles
Comparing FMCs with PMCs/XMCs for harsh environments
Understanding and mitigating tin whiskers
High-performance FPGAs take flight in microsatellites
Xilinx FPGAs beam up next-gen radio astronomy
Xilinx rad-hard FPGA reaches for the stars
When perfect is good enough
Single event effects (SEEs) in FPGAs ASICs and processors
Transfer from FPGAs for prototype to ASICs for production
Design security yields secure FPGAs for mil/aero applications
|
|
|
|
|
Navigate to related information
Mario Blunk
12/8/2010 3:03 AM EST
Interesting work but the flow diagrams are hard to read. Please make them readable for the public. Thank you.
Sign in to Reply
Bob Lacovara
12/8/2010 1:35 PM EST
This is more than just good advice for mission critical implementations. Many of the suggestions would apply equally well to software. Of course, viewed from the hardware description language perspective, the hardware is software...not that I wish to start a philosophic discussion on that score. But state machines and software systems both feature the ability to find themselves at execution points or states unexpectedly, and can sport unreachable states, and so on. I was bemused to find that one-hot machines were in use: I wasn't aware that much use had been made of one-hot architectures. Interested readers might want to go to abebooks and find a copy of Hill and Peterson's "Digital Logic and State Machine Design" (even the 2nd edition will do) wherein they will find a pedagogical HDL that compiles into a one-hot model. Another interesting thing about one-hot designs is that parallel execution is possible under some circumstances by allowing more than one flop to be hot at once. Suitable precautions and procedures are required, though.
Sign in to Reply
karax
12/9/2010 5:18 AM EST
Talking about simulation and verification tool SST tool from nebrija uses built-in simulator commands, that is, to feed the simulator with the appropriate commands to control the simulation or inject faults (PERL/TCL). This method is easy to implement and does not require the modification of circuit models. On the contrary, the command parsing and the reaction times of the simulator present a performance reduction and make that unviable for big circuits. I know other advanced techniques to speed up the simulation process using FLI (Modelsim) and other emulation HW methods in FPGA.
Sign in to Reply
anne-francoise.pele
7/16/2012 11:25 AM EDT
Dear Mario,
I have made the diagrams more readable. Click on the images to enlarge them.
Best,
Anne-Francoise Pele
Sign in to Reply