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 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 hardware 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: Programmer, SignalTap Logic Analyzer (the latter is a ‘virtual’ logic analyzer that can be embedded in 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, on customer premises.
For more technical articles, insights, FPGA news, and VHDL projects, you are invited to visit my site.
