Tuesday 28 May 2013

FPGA Design Flow

Field-programmable gate array (FPGA) is a device that has numerous gate (switch) arrays and can be programmed on-board through dedicated Joint Test Action Group (JTAG) or on-board devices or using remote system through Peripheral Component Interconnect Express (PCIe), Ethernet, etc. FPGAs are based on static random-access memory (SRAM). The contents of the memory of an FPGA erase once the power is turned off. Usually, FPGAs can be programmed several thousands of times without the device getting faulty.

Fig. 1 shows the architecture of an FPGA. It includes logic blocks, input/output (I/O) cells, phase-locked loops/delay-locked loops (PLLs/DLLs), block RAM and interconnecting matrix. Nowadays, FPGAs are also coming up with several hard intellectual property (IP) blocks of PCIe, Ethernet, Rocket I/O, PHYs for DDR3 interfaces and processor cores (for example, PowerPC in Xilinx Virtex-5 FPGA and ARM cores in both Xilinx and Altera series FPGAs).

To level up with the new technology, both Xilinx and Altera have come up with new series of FPGAs (Virtex 7 from Xilinx and Stratix-V from Altera), which are manufactured with TSMC’s 28nm silicon technology. These FPGAs focus on a high speed with low power consumption using various parameters and bringing down the FPGA core voltage to as low as 0.9V. Along with the new FPGAs, Xilinx and Altera are also focused on improving their synthesis tools to meet the routing constraints and to analyse the timing and power consumption of the FPGA. 

Fig. 1: FPGA architecture (generic)
As the aim here is to learn the basic technique of FPGA design to work with both the tools and devices, let’s get back to the design flowthrough the steps.

Step 1: Requirement analysis and SRS preparation

Before starting work on the design, all requirements should be documented as system requirement specificatio (SRS) by designers and approved by various levels in the organisation, and most importantly, the client. During this phase, FPGA designers, along with the hardware team, should identify suitable FPGAs for the project. This is very important because designers need to know parameters such as the I/O voltage levels, operating frequency and external peripheral interfaces.

It is also important to determine which IP cores are available with the tools or FPGA family used for the project. Some IP cores are free, while others are licensed and paid for. This cost should be reviewed several times by the team before releasing it to the client and listed separately for approval from the client or management.

The SRS should contain the following (the list pertains to the FPGA only):
1. Aim of the project
2. Functionalities to be handled by the design, followed by a short description
3. A concept-level block diagram depicting the major internal peripherals/IPs of the FPGA
4. FPGA vendor, family, speed grade, package, core voltage, supported I/O levels, commercial/industrial type
5. List of blocks that will be used as IPs. Mention clearly what’s available for free with the vendor-provided IPs, hard IPs available within the FPGA and paid licensed IPs to be used
6. Type of processor interfaces used (soft processor or external processor interfaces)
7. Type of memory interfaces used
8. A section about the timing diagram of the major peripheral interfaces such as the processor interface and flash interfac
9. Type of FPGA configurationsto be used
10. Reset and clock interface planned
11. A brief summary of the estimated resources required for implementation of the logic and I/O pins to be used
12. HDL (VHDL, Verilog, ‘C’ or mixed) used for RTL coding, tools and version to be used for synthesis, implementation and simulation

Spartan-6 USB-FPGA module 1.11b
To calculate the approximate resources required, go through the IP datasheets for the resources used for each IP, and also calculate the resources used by custom RTL. There is no rule of thumb for calculating resources at this level. These can be calculated approximately based on experience, reviews or analysis. The most important thing is to get the resource requirement reviewed by the hardware team, software team and a third party several times before submitting it to the client.

Step 2: Detailed design document preparation

Once the SRS is approved by the client, the next phase is to make the detailed design document.

This document should consist of:
1. Brief introduction to the project
2. FPGA part details with proper specification
3. Detailed block diagram depicting the internal modules of the FPGA design
4. Top-level module block diagram showing input and output ports with their active levels and voltage levels which are connected to the external peripherals, connectors and debug points
5. Hierarchical tree of the modules
6. Each module should have:
   (i) Detailed explanation of the functionality
   (ii) Register information
   (iii) List of input and output ports with source and destination module name, and active level of the signal
  (iv) A block diagram/digital circuit diagram of finite-statemachines indicating how the RTL will be implemented
   (v) Clock frequency to be used, if a synchronous module is used
   (vi) Reset logic implementation
   (vii) File name which will be implemented
   (viii) Approximate FPGA resource utilisation
   (ix) Testbench for testing each module independently
7. Input system clock frequency and reset level
8. Explanation of how the internal clock frequencies are derived—using phase-locked loop (PLL) or delay-locked loop (DLL) with the input clock. Also, explain how the global clock buffers are used. Mention clock signals with their frequency and voltage levels that are driven out of the FPGA for external peripherals 
9. A simulation environment setup for the design (called ‘device under test’) with a top-level testbench. A block diagram indicating how the clock source, reset and pattern generators, and bus functional modes are connected to the top-level module under testing will be helpful here. Mention how log filesare used to register the activity of the required signal 
10. Make a page with the heading ‘FPGA Synthesis and Resource Utilisation.’ Keep it blank with a note that once the final implementation is done, this page will be updated
11. Under the heading ‘Timing Analysis,’ mention the major timing parameters of the control signals to be maintained, with a timing budget and waveform drawn manually or using timing analyser tool. Mention the major timing constraints that will be used in the UCF or QSF filesof the design 

As mentioned in Step 1, the FPGA team members, hardware and software team members and architects should review the document at several stages before releasing it to the client.

Step 3: Design entry and functional simulation
Each module owner should develop a testbench for his module, capture simulated waveforms or assertion-based log report, and get it reviewed by the team lead. Before going for synthesis, every module should be verifiedthoroughly for functionality using simulation. Regular code review will help to reduce errors and simulation time. Once the simulation of individual modules is done, the next step is to integrate the module and do full-system-level functional simulation with assertion-based log report.

Fig. 2: FPGA design flowchart

Step 4: Synthesis
If the functional simulation satisfie the requirement, the next phase is synthesis.

In this phase, the integrated project is synthesised using a vendor-specificsynthesis tool based on the optimisation settings. Whenever RTL is modifed, it is always good to complete Step 3 with unit-level and full-system functional simulation. Always follow vendor-specificcoding guidelines and library modules for better optimisation of the design. 

During this phase, synthesis tools verify the design for syntax errors and do block-level floor planning.

Step 5: Adding design constraints
Once synthesis is complete, constraints can be added to the design. These constraints are usually included in a separate fle where the designer lists out the signal with its corresponding FPGA pin number, I/O voltage levels, current-driving strength for output signals, input clock frequency, hard block or module location, timing paths to be ignored, false paths, other IP-specificconstraints recommended by the vendor, etc. This information is passed on to the placement phase.

Step 6: Placement and routing phase
Before routing, the synthesis tool maps the buffers, memory and clock buffers to the specificvendor libraries. That is, in this phase, logical blocks are translated into physical fileformat. Then, in the place-and-route process, the tool places and routes the design considering the user constraints and optimisation techniques. Timing simulation can be done at this stage to verify the functionality, so that the design meets all the functional and timing requirements.

Step 7: Programming file generation
After obtaining a satisfactory timing and functional behaviour of the design, it is time to generate the bit filethat is downloaded to the FPGA to test the functionality on the board with actual peripherals.

For each stage, the tool will provide the corresponding report files,using which the designer can analyse time delays, power, resource usage, unrouted signals and I/O pins list.

In short

To summarise the above points, the FPGA design flowis shown as a simple flow-chartin Fig. 2. There may be minor variations in the design fow during the requirement stage and the design and document preparation phase, from one organisation or project to another, but the overall FPGA design flow remains the same.

No comments:

Post a Comment