In the previous post in this series we talked about the process of creating an FPGA design. Once we have proven our design works, we then transfer the functional HDL code into an actual FPGA. We normally carry this out in three separate stages – synthesis, place and route and generation of the programming file. We discuss each of these processes in more detail in this post.
The first stage in building the FPGA is known as synthesis. This process transforms the functional RTL design into an array of gate level macros. This has the effect of creating a flat hierarchical circuit diagram which implements the RTL design. In this context, the macros are actually models of the internal FPGA cells. This can be any digital element in the FPGA such as flip-flops, RAM or combinatorial logic look up tables.
There are a number of different tools we can use to run the synthesis process. Both of the major FPGA vendors (Xilnix and Altera) offer free synthesis tools which are suitable for most projects. There are also paid tools which we can use for this process. The most well known of these are Synplify Pro from Synopsys and Leonardo Spectrum from Mentor Graphics. The paid tools are typically capable of delivering more optimised netlists than the free tools. We normally only need the paid tools for large or high speed designs.
The synthesis process requires at least two inputs. The first of these is the RTL source code. We also need a script or project file which defines the configuration of the synthesis tool. In addition to this, it is good practise to create a file which defines the timing constraints of the design
We use timing constraints to define details about the FPGA which can’t be specified in the source code. This includes information such as the clock frequency, the number of clock domains and the timing of external interfaces. These details determine how much effort the synthesiser puts into optimising timing within the FPGA.
We can also perform some analyses of our design as a part of the synthesis process. However, this information is typically more reliable after the place and route process. Despite this, capturing design issues earlier in the process can reduce development time.
The first of these analyses is the logic utilisation of the design. This analysis details how many of each of the different types of FPGA cells our design uses. The individual cells within a device vary from chip to chip, as well as between vendors. Almost all modern chips will include RAM, some form of combinatorial cell and registers. High end chips can also include dedicated DSP blocks, clock management blocks such as PLLs as well as other peripheral interfaces such as ADCs or dedicated high speed channels. After completing the synthesis process, we can generate a report which tells us the number of cells utilised. This is expressed both in absolute terms and as a percentage of all available cells in the device.
After running the synthesis process it is not uncommon to find that our design is too big for our device. There are a number of options available to us when this occurs. It is normally possible to reduce utilisation by changing the configuration of the synthesis tool. Examples of this could be changing state machine encoding or selecting a different synthesis algorithm. This reduction can be enough if our design is only slightly larger than our chosen FPGA. If this doesn’t sufficiently reduce utilisation then we must select a new FPGA or make our original code more efficient. It is also possible to reduce the logic utilisation simply by running multiple instances of the synthesis in many cases.
It is also common practise to analyse the timing of the design after completing the synthesis. This analysis indicates whether the FPGA is capable of running our design at the desired frequency. If the design can’t run at the desired frequency then we can cause timing violations on the internal flip flops. As a result of this, we can’t guarantee that our device will operate as expected. A more detailed discussion of timing analysis, including a definition of timing violations, is giving later in this post. We typically analyse the timing of a design in more detail following the place and route process. As the timing is dependent on the location of cells in the FPGA, results are more accurate following this process.
During the synthesis process, we can request that the tool generates a netlist in either VHDL or verilog. This process also generates a set of timing delays which model the propagation of signals through the FPGA. This allows us to run simulations using the previously developed tests for RTL verification. These post-synthesis simulations more closely mirror the behaviour of our final device. However, simulations using these net lists typically take considerably longer to simulate than pure RTL code.
When generating post-synthesis netlists, it is beneficial to use Verilog to generate these models. This is true regardless of the language we use to write our design and test bench. The reason for this is that Verilog based models tend to have faster simulation speeds than their VHDL equivalent. This is even more important for post-synthesis simulation due to the increased execution times of our simulations.
There are two main advantages to running post-synthesis simulations. Firstly, these simulations help to ensure that our generated netlist matches the behaviour of our original RTL model. Secondly, the timing of the chip can be more closely considered. This helps us to find bugs which may relate to timing based errors, such as race conditions or timing violations.
Although there are advantages to running post synthesis simulations, it is not necessarily wise to do so. The main disadvantage of this process is the time these simulations take to run. It is not uncommon for post-synthesis simulations to require several days to run a full set of tests. If it is necessary to run simulations for timing, the place and route tool can also generate the required netlists. These netlists also offer the advantage of being more representative of the final silicon solution. Therefore, it is preferable to carry out any timing simulations using this netlist instead.
Place and Route
After completing the synthesis, the next stage in the build process is mapping the netlist to the actual FPGA resources. Typically, the first stage of this process involves optimising the netlist. This removes or replaces any elements of the netlist which are redundant or duplicated. The optimised netlist is then mapped to the physical cells in the FPGA, which is commonly known as placement. The place and route process also defines the interconnection between the given FPGA cells. This part of the build is commonly known as routing. Normally we need several runs of this process in order to meet the timing requirements of our design. The place and route tool is responsible for scheduling these multiple runs based on our configuration. It is normal to increase the number and types of run we allow the tool to perform when our design doesn’t meet our timing requirements.
Place and Route Tools
Unlike with the synthesis process, no third party place and route tools are currently available. As a result of this, we must use a vendor specific tool for this process. These tools are freely available to download from the major vendors, although paid versions are also available. Depending on the size of the design, this process can take several hours to complete.
As with the synthesis process, the place and route tool requires a number of inputs to run correctly. The netlist we generated using the synthesis tool is the first of these inputs. This netlist is typically an .edf file, although this varies between vendors. The tool also requires a project file or script to determine the configuration of the tool. This defines the FPGA part number, including the package, as well as a number of specific options for the tool. These file is typically separate to the synthesis configuration file, despite the fact it performs the same function.
The place and route tool also needs a separate timing constraint. This serves the same purpose as the file generated for the synthesis process. We can use the same file in many instances, although this depends on the exact tools we are using. In addition to this, the place and route tool also needs a physical constraints file. This defines a number of physical attributes that we can’t describe in the RTL code. As a minimum this will include a mapping of the FPGA inputs and outputs to the devices’ physical pins. It is also possible to use these constraints to manually edit our netlist, by placing or moving cells for example.
Timing and Utilisation
As with the synthesis process, we can generate a number of reports after the place and route has finished. This allows us to further analyse our design to ensure it works correctly. One of these analyses is the utilisation report, which details the number of different cells used within the FPGA design. This report is exactly the same as the report which we can generate during the synthesis process. After completing the place and route process this report is more accurate however.
We should also analyse the timing of our device at this stage. The report we generate to do this at this point is known as Static Timing Analysis (STA). This process calculates the delay times through the various logic chains in the design. It then uses this information to determines whether the chip is capable of running at the specified clock frequency. The place and route tool performs this analysis with both the worst and best case timing conditions. However, it is more common for timing issues to arise with the worst case delays in the silicon. The STA report is crucial to the verification of our design as it proves the device functions correctly in the intended environment.
Programming File Generation
The final stage in the implementation of the FPGA design is the generation of the programming file. We normally use the place and route tool to generate our programming file. However, we typically run this as a separate process. This process can only be run once the place and route process has generated its outputs. We only need to tell the tool which file type we require in order to generate this output. Once this process has completed, we can use the generated file to program our FPGA.