This document introduces the reader to our recommended FPGA design guidelines, which if followed enables the designer to produce a bug free design fit for release.
As designs get more and more complex, it is very important for RTL design engineers to follow a common set of rules which makes debugging easier and provide bug
The first things to finalize before starting a design are:
For FPGA designs, nowadays one can use:
The Choice between RTL languages such a VHDL, Verilog and the rest is based on how much control you want over a design. If design optimizations are not of concern then high level languages provide the fastest ”Design to Market” time. This document will not be focusing on these methodologies. Between VHDL and Verilog the following should be taken into consideration before finalizing a language.
Once an overall block diagram of your design is ready, you can have an estimate of the resource utilization. Always plan in such a way that the design never crosses 80 percent total resource consumption for your selected FPGA. This will drastically decrease the time required for timing closure for your design.
Following are the thumb rules for resource estimation:
Note: LUT example based on Xilinx Ultrascale Architecture
The UltraScale architecture LUTs can be configured as shown below
We will be discussing on two tools in this document:
This is a free simulator integrated with vivado. It is not the not robust simulator available. The ISIM is slower compared to Questa and is not suitable for long run simulations.
If you or your organization have the funds to purchase a simulator, then I will recommend Questa just because of the sheer amount of time you can save in simulations.
I understand that version control is not properly evolved for FPGA based designs, but it is imperative that you stick with a good VC such as GIT from the beginning of your project.
For Xilinx Vivado based designs, Xilinx provides very good documentation regarding integrating vivado designs with version control systems.
Correct understanding of ”UG1198-vivado-revision control- tutorial” will be a very good starting point for version control with xilinx designs
The below image represents a good folder structure for version control.
— bd : To store Block Design (.bd) files
— scripts : To store vivado run scripts and Makefiles
— hdl : To store VHDL/Verilog HDL including the top-level design
— ip : To store all XCI and XCIX files
— tb : To Store all testbench files .sv files should be wrapped in verilog files
— xdc : To store Xilinx Design Constraints (.xdc) for the top-level design
— hls : To sore all files related to C++ designs
— dsp : To store all Matlab SysGen design files
— work : Working directory for latest project to be committed to git
Coding standards are very important as they make your code clear and professional.
Before we get into coding standards, let us finalize on a text editor and documentation strategy for your design.
I personally recommend using EMACS as your default text editor for any and all design purposes. The next best option will be VIM.
These editors let you stick with the logic only while they have commands for all repetitive constructs in your code and believe me, your choice of text editor for your
design will determine the amount of effort you put into writing your code.
Documentation is left out by many engineers to be done at the end of your design.
It is a much easier method to use a system like doxygen to prepare your documentation. It will reduce a lot of hassle and along the way make your design a lot more professional.
Following are a couple of good coding standards to be used in a design:
Following are some points to keep in mind before starting your design:
In the scenario shown below:
I . DDR and MiG has a throughput capability of 100Gbps
II . DMA clocked at 200 Mhz with 64 bit bus can support only 200*64 Mbps => 12.5 Gbps which is a bottleneck in the design.
III. To circumvent this bottleneck increase the width of DMA to 512.
For example a scenario as shown should be avoided whenever possible: