FPGA Design Flow Summary

06/12/2018, hardwarebee

Are you going to make an FPGA design? Are you asking yourself where to start, how to continue, and finish?


These are the basic steps of an FPGA design flow:


Design Requirements


A High Level Description of the desired functionality.


Architecture Specification


In response to the Requirements, a High Level Design is produced. Normally this level of the design is done by experienced designers and/or system architects, who define things like which FPGA device to use, interfaces to other components in the board, associated external devices like host CPU and memories, etc.


Design Entry and Functional Verification


At this stage the model of the device functionality is defined using Hardware Description Languages like VHDL. The design functionality is verified (behavioral simulation).


Tools used in Altera environment: Quartus or external editor for HDL entry, Modelsim and Altera libraries for simulation


Synthesis and Timing verification


The Synthesis process is where the design is translated (mapped) to a HW implementation using the internal blocks of the FPGA and its interconnections. The FPGA internal blocks include LUTs, Flip Flops, memories, hard IPs, etc. Timing verification includes Static Timing Analysis and Gate Level Simulation


Tools used in Altera environment: Quartus for Synthesis, SDC files for timing constraints, TimeQuest for Static Timing Analysis. Modelsim and Altera libraries for Gate Level Simulation.


Target verification


The design is ‘programmed’ or loaded onto the FPGA in an evaluation board or in the real target device. The design is verified using a plethora of debugging tools and instruments: Signal generators, scope, spectrum and logic analyzers, etc.


Altera Tools for this stage: Programer, SignalTap Logic Analyzer (the latter is a ‘virtual’ logic analyzer that can be embedded on the design and provides real-time debugging information via the JTAG port).




In real life these steps are not always linear and it is not uncommon for designers to go back and forth the several stages of the Design Flow. However, a good design team will have much less ‘back-tracking’.


Signs of very bad design practice are, for example, functional bugs that are discovered only during timing verification, or worse, during target verification, or worst of all, in customer premises.




This is a guest post by FPGA’er

Recent Stories