102 Views

Best Practices and Guidelines for FPGA Designs

07/05/2020, hardwarebee

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.

 

FPGA Design Guidelines

 

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

free designs.

 

The first things to finalize before starting a design are:

  1. Language to be used.
  2. Estimate the resource utilization.
  3. Simulation tools to be used
  4. Version control tool to be used
  5. Using globally acceptable coding standards

 

A. Language to be used

For FPGA designs, nowadays one can use:

 

  1. VHDL
  2. Verilog
  3. High level languages (system C, Python, C++ etc)
  4. Generate RTL from tools such as MATLAB.

 

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.

 

VHDL

 

  1. Strict language, hence very low chance of design functioning in any unintended ways.
  2. Timing simulation is not possible, hence timing should be taken care of using STA.

 

Verilog

 

  1. There is a chance of design failing post-synthesis functional simulation because of the flexibility of the language.
  2. Timing simulation as well as functional simulation is possible.

 

 

B. Estimate the resource utilization

 

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:

 

  1. Understand the architecture of the FPGA platform being used correctly.
  2. Draw a block diagram for each module of your design and estimate the LUT,FF,DSP Slice and BRAM/URAM required for that RTL module for the architecture you have chosen.
  3. For IP’s being used in your design, Refer to the data-sheet for the resource consumption or you can perform an OOC build to get the utilization.
  4. Estimate the resources for synchronizers being used in your design.
  5. Lay a 10 percent leeway to the 80 percent utilization mark.

 

Note: LUT example based on Xilinx Ultrascale Architecture

 

The UltraScale architecture LUTs can be configured as shown below

 

  1. One 6-input LUT with one output.
  2. Two 5-input LUTs with separate outputs but common addresses or logic inputs.

 

C. Simulation tools to be used

 

We will be discussing on two tools in this document:

 

  1. Vivado Isim
  2. Questa Sim

 

Vivado Isim

 

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.

 

Questa Sim

 

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.

 

D. Version control tool to be used

 

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.

 

 

Where:

 

— 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

 

 

E. Using globally acceptable coding standards

 

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:

 

  1. Clocks should be named as (clk_<FREQ>).  Eg clk_122m88
  2. Signal should start with ”s”
  3. Inputs should start with ”i”
  4. Resets should indicate clock domain and polarity. Eg rst_n_122m88
  5. Outputs should start with ”o”
  6. AXI naming conventions should be followed.
  7. One VHDL file should contain only one Entity and one Architecture
  8. Make sure each RTL file is synthesized independently and a post synthesis functional/timing simulation is performed.

 

F. Miscellaneous guidelines

 

Following are some points to keep in mind before starting your design:

 

  1. You should have a clear outline of clock domains as well as CDC techniques to be used for the design.
  2. In vivado use clock network analyzer to find possible CDC issues
  3. SSO Analysis is always performed.
  4. DataFlow analysis should be done prior to finalizing design so as to prevent any bottlenecks.

 

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.

  1. Define the clocking and reset strategy early in the design.
  2. Make use of primitives whenever possible.
  3. Use safe state machines.
  4. Handling of all FPGA Mode/Control pins (e.g. pullup/pull-downs) should be reviewed
  5. Minimize the use of asynchronous logic in your design
  6. Make sure that LUT’s are not driving clock pins unnecessarily.

 

For example a scenario as shown should be avoided whenever possible:

  1. If timing is not met at the end of the design try changing the implementation strategy to ”Performance-Retiming” in Xilinx devices.
  2. Validate each RTL using TB and store the simulation reports for each RTL. This should always be included in your documentation.

Recent Stories