FPGA Basics

This document introduces the reader to one of the articles we have created to help with FPGA Basics. This article will enables FPGA designers to get through the first basics steps of FPGA programming.

FPGA Basics

As FPGA designs get more and more complex, therefore it is very important for FPGA design engineers to follow a common set of rules and guidelines which make both design and debugging easier and generate bug free designs.

The first things to consider before starting an FPGA design are:

1. FPGA programming language selection
2. Estimate the FPGA resource utilization
3. Simulation tools to be used
4. Version control tool to be used
5. Using globally acceptable coding standards
6. Miscellaneous FPGA Programming Guidelines

1. FPGA Programming Language

For FPGA designs, nowadays one can use the following programming languages:

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.

2. Estimate FPGA 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.

3. FPGA Simulation Selection

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.

4. Version Control Tool Selection

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

5. Using Globally Acceptable FPGA 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.

6. Miscellaneous FPGA Programming 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.