In this post we talk about the FPGA implementation process. This process involves taking an existing HDL based design and creating a programming file for our target FPGA. In this post we cover the three major steps involved in this process - synthesis, place and route and finally programming file generation.

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 steps in more detail in the rest of this post.

Synthesis

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 look up tables (LUT). 

Synthesis Tools

There are a number of different tools we can use to run the synthesis process.

Both of the major FPGA vendors (Xilinx and Intel) offer free synthesis tools which are suitable for most projects.

In addition to this, there are also a number of open source synthesis tools which we can use. The most popular of these tools is yosys which is frequently used with Lattice FPGAs.

There are also paid tools which we can use for this pirpose. The most well known of these tools 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 source code for our design.

We also need a script or project file which defines the configuration of the synthesis tool. This script typically tells the tool which FPGA to target, the pinout of the design and which strategy to use when running the synthesis.

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.

Logic Utilisation

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.

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 LUT and flip flops.

High end chips can also include dedicated DSP core, clock management blocks such as PLLs as well as other peripheral interfaces such as ADCs or dedicated high speed interfaces.

After completing the synthesis process, we can generate a report which tells us how many cells are used in our design 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 FSM 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.

Timing Analysis

We can also analyse the timing of our FPGA after we have run the synthesus.

We use this analysis to determine whether the FPGA can run our design at the required frequency.

When our design can't be run at the desired frequency then we can not be sure that there will will be no timing violations on the internal flip flops. As a result of this, we can't guarantee that our device will operate as expected.

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. 

Post-Synthesis Simulation

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.

We can then use this information to run simulations of our synthesized netlist.

As these simulations also model the timing of our design, they give a more accurate model of the behavior of our final device.

We typically generate the post-synthesis simulation model using verilog, regardless fo the language we used in our design.

The reason for this is that verilog based models are faster to simulate than their VHDL equivalent. This is especially important for post-synthesis simulations as they typically have long execution times.

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, we normally won't do this as part of our design flow.

One reason for this is that these simulations require a long time to run. It is not uncommon for post-synthesis simulations to require several days to run a full set of tests.

Another reason is that we can also run simulations on the netlist which is generated by our place and route tool.

As these netlists as more representative of the final silicon solutio, it is preferable to carry out any timing simulations using this netlist instead.

Place and Route

After completing the synthesis, we then need to map the netlist to actual resources in our FPGA. This process is known as place and route and it actually consists of a few different steps.

Typically, the first stage of this process involves optimising the netlist. We use this process to remove or replace 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.

After we have completed the placement process, we then then run a process known as routing.

We use this part of the build process to define the interconnection between the different cells in our chosen FPGA.

We will often to perform several runs of this process in order to meet the timing requirements of our design. However, the place and route tool is responsible for scheduling these multiple runs based on our configuration.

When we are having difficulties getting our design to meet with our timing requirements, it is common to increase the number and types of run which we allow the tool to perform.

Place and Route Tools

There are no third party place and route tools for Xilinx or Intel parts, meaning we must use the vendor specific tools. These are freely available for download, although paid versions are also available.

There are also paid versions of these tools which are available, although they are normally only required for designs which target high end FPGAs.

For Lattice FPGAs, the open source nextpnr software is a popular place and route tool.

Depending on the size of our design, the place and route 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 which we generated using the synthesis tool is the most important input. This netlist is typically an .edf file, although this varies between tools.

We typically also use a project file or script to determine the configuration of our place and route tools.

We use this to define important information, such as the FPGA part number and package. In addition to this, we use this script to define the configuration of our place and route tool.

We also need to provide a constraint file to the tool which defines the timing characteristics of our design. This is often the same file as we use in the synthesis process which defines information about the clock frequencies and domains.

We also use a constraint file to define physical characteristics of our design which we can't describe in our HDL code. As a minimum this will include the mapping of the inputs and outputs to the physical pins of the device.

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. 

We usually run a utiliyation report after completing the place and route process.

This report details the number of the number of different cells which we have used to implement our design with the FPGA.

This report is exactly the same as the report which we can generate during the synthesis process. However, this report is more accurate when we generate it after completing the place and route process.

Another analysis which we typically perform after completing the place and route process is the Static Timing Analysis (STA).

We use this process to calculate the delay times through all of the logic chains in our design. By calculating this information, the place and route tool can determine 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.

We typically use the STA report as a crucial part of our design verification.

If our design fails the STA then we can't guarantee that our FPGA will work reliably. When this happens we either have to run the implementation process again with different settings or we must change our design.

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.

In this post we talk about the FPGA design process in more detail. This includes a discussion of all of the main stages of the design process - architecting the design, modelling the FPGA design and testing our design. We also look at the differences between the two major hardware description languages (HDL) - verilog and VHDL.

In the previous post in this series, we saw an overview of the entire FPGA development process.

We saw from this how there are three main processes involved in an FPGA project - design, verification and implementation.

In the rest of this post we talk about the tasks which form the design process.

Whilst the main task here is writing code to create a model, there are other important aspects of this process. This includes architecting our chip and testing our model.

We talk about the FPGA implementation process and FPGA verification in more detail in separate posts.

Architecting the Design

The first stage of the design process is architecting the our design.

This involves breaking the design into a number of smaller blocks in order to simplify the VHDL coding process.

For large designs, this is especially beneficial as it allows engineers to work in parallel.

In this case, we should consider this an integral part of the process.

For smaller projects, we don't need to formally carry out this step. However, it is always worth considering the architecture closely before starting detailed design work.

Design Modelling

The next stage in the process is the creation of a model of the design. We use this model to simulate the behaviour of our design and to build a programming file for our FPGA.

We typically use one of the two major Hardware Description Languages (HDL) – verilog or VHDL - to write this model.

There are two main styles of modelling which we use for this process. These are commonly referred to as Register Transfer Level (RTL) and Gate Level.

Let's look at both of these in more detail.

RTL Coding Style

Designs which use the RTL approach consist of code which describes the flow of data between registers within the FPGA.

This means that we write code which explicitly describes the behaviour of the FPGA in terms of flip flops, logic gates, finite state machines and RAM.

Let's consider the example circuit below to demonstrate this concept.

In an RTL model of this circuit, we would write code which describes the behaviour of the two D type flip flops and the not gate.

The code shown below gives the VHDL implementation of this circuit. Don't worry if the syntax is unfamiliar at this point as it is not important.

dff1_d <= not dff2_q;

dff1:
process (clock) is
begin
  if rising_edge(clock) then
    dff1_q <= dff1_d;
  end if;
end process dff1;

dff2:
process (clock) is
begin
  if rising_edge(clock) then
    dff2_q <= dff1_q;
  end ill
end process dff2;

In this code, the first line models the behaviour of the not gate.

The flip flops, labelled as dff1 and dff2, are modelled using VHDL processes.

These processes latch the value of the input whenever there is a rising edge on the clock. This matches the expected behaviour of a D type flip flop.

We can see from this example how we are describing the behavior of the components in our design, as well as the interconnections between them.

This is the defining feature of RTL modeling in comparison to other types of modeling which simply define the connections between components.

Gate Level Modelling

Gate level modelling consists of code which defines the interconnection of different pre-existing components.

These components are instances of integrated FPGA elements, such as PLLs, look-up-tables (LUT) or register cells.

The code shown below is an example of gate level modelling. This implements the same double flip flop circuit we previously considered.

inverter : component not_gate
  port map (
    inv_in  => dff2_q,
    inv_out => dff1_d
  );

dff1 : component dff
  port map (
    clock => clock,
    D     => dff1_d,
    Q     => dff1_q,
    Q_bar => open
  );

dff2 : component dff
  port map (
    clock => clock,
    D     => dff1_q,
    Q     => dff2_q,
    Q_bar => open
  );

We can see that there are three separate components in this example model.

There are two instances of the dff component, which is an implementation of a D type flip flop.

In addition, there is a single instance of a not gate component.

We use signals to wire the IO of these components one another. This results in a physical implementation of the circuit we saw above.

It is rare that we will ever want to create a gate level model.

However, synthesis or place and route tools often create such models.

We discuss both of these processes in more detail in the post on the FPGA build process.

However, it is common to use RTL models which we have previously written as components in a similar manner.

The syntax for instantiating the components and wiring them up is the same as that used in gate level modelling.

Although this is similar to gate level modelling, the difference is that we don't directly use cells in the FPGA. This approach is known as structural RTL modelling.

HDL Programming

Although HDL languages are commonly referred to as programming languages, they have little in common with traditional languages.

When working with languages such as C or Java, we are writing an abstract algorithm or describing program behaviour.

The way the CPU actually implement this program is unlikely to be of any real interest to us.

In contrast, when we write HDL code we are describing the behaviour of a digital circuit.

It is important to remember this different approach when designing FPGAs.

In fact, we have already seen this process in the simple example we used for RTL modelling. We started with a basic circuit and then wrote some VHDL which describes the behaviour of the circuit.

As this is an introductory post, we don't fully consider the details of verilog and VHDL in this post.

However, there are a series of VHDL tutorials and verilog tutorials available on this site which give an introduction to these languages.

Alternatively, you may wish to take one of these VHDL or verilog courses which also include hands-on, practical examples.

After reading these introductory posts, learning one of these languages should be the next step towards learning FPGA design.

Verilog vs VHDL

One of the first questions many people have when learning FPGA design is whether they should learn VHDL or Verilog.

For anyone with ambitions of becoming a professional FPGA designer, it will be beneficial to learn both of these languages. So a more important question in this case is which language to learn first. 

Whilst the two languages do have a number of differences, these are probably too subtle for beginners to fully appreciate.

In fact, even for professional engineers, a lot of the time it will come down to either personal preference or a pre-existing policy within a company.

When it comes to RTL modelling, geography is usually the main deciding factor in the choice of language to learn.

Verilog is the most used language by the big tech companies in California. Therefore, it makes sense to learn Verilog first for anyone hoping to work there.

In Europe, VHDL is more widely used and it makes sense to start with this language.

For hobbyists, verilog is also a good choice as it is generally less verbose.

For gate level modelling, Verilog is more popular than VHDL.

This is mainly due to the fact that it has an inherent ability to define the behavior of primitives. This means that we can define the behaviour of the cells within the FPGA using a language feature known as user defined primitives.

This is particularly useful for chip vendors who must develop libraries which define the behavior of cells in their chips.

Simulations which use verilog based models also tend to have faster execution times than VHDL equivalents.

Testing the Design

After architecting and coding our FPGA design, we then need to test our model.

This is essential for identifying bugs and proving that our model functions as expected.

Although we often have a separate verification teams for larger designs, some tests should be conducted by the designer.

This will eliminate the most obvious and easy to find bugs before verification begins.

As a result, the verification team can focus on more thoroughly testing the design, identifying more subtle bugs.

Typically, our testing will consist of 2 parts - fixing compilation errors and functional simulations.

Let's look at both of these in more detail.

Compilation Warnings

As a first step in simulating a design, we must compile the code.

This process turns the functional HDL code into a model or executable file. This file is then used by the simulation tool to emulate the behaviour of the design.

During this process, the compilation tool will create a number of warnings. These are issues with the code which won't prevent compilation but may lead to simulation errors.

Some examples of this include deprecated code constructs, non-synthesizable code or errors in vector sizing.

One example common example of a warning is attempting to assign an 8 bit signal with 9 bits of data. 

It is normal for the designer to correct these warnings before running any simulations.

For large designs, this can be a time consuming task and it is likely that not all warnings are fixable.

It is also common for the solution to the warnings to alter the behaviour of our model.

If using a formal process, we should at least fix the warnings before beginning the verification process.

When a separate verification process isn't required, we should fix these warnings before beginning the implementation stage.

Functional Simulations

Even when working with a formal verification process, the FPGA designer is normally expected to carry out basic functional testing.

This is where the lines between verification and design can start to become quite blurred, particularly for small chips.

Functional simulations in this context involve creating tests which emulate the normal operating conditions of the circuit.

This allows the designer to fix the most obvious functional bugs before verification begins.

This means the verification team can utilise their time developing more sophisticated tests. This is likely to lead to the verification process discovering more subtle bugs.

For hobbyists, there is no need to go any further than this level of simulation. There is also no need to do any more testing than this for small projects.

The exception to this is for projects where we are following a formal process such as DO-254.

When we are working on large projects then verification is going to be much more comprehensive than this.

This is also the case when we are following a formal design process.

In these cases, we should treat the verification of our FPGA as a separate, formal process. 

In this post we give a broad overview of the FPGA development Process. This includes an introduction to the design, verification and implementation (synthesis and place and route) processes.

In the following posts in this series we talk about the FPGA design process, verification and the build process (i.e synthesis and place and route) in more detail.

We don't specifically discuss the details of any of the languages used to program an FPGA in this post.

Instead, the information here is intended to provide important background knowledge which will help when learning how to program an FPGA.

There are detailed VHDL tutorials, Verilog tutorials and SystemVerilog tutorials available elsewhere on this site which can be used to learn these languages.

Alternatively, you may wish to take one of these VHDL or verilog courses which also include hands-on, practical examples.

What is an FPGA

We can think of an FPGA as if it were a massive collection of unconnected digital components.

This includes basic components such as multiplexors and logic gates as well as more complex components like DSP cores.

When we program an FPGA, we are actually creating connections between these different components to create a complex system.

All of this means that we are fundamentally designing hardware when we create an FPGA based design.

As a result of this, we can design a number of circuits which run in parallel to each other.

This means that FPGAs are capable of performing a large number of different operations at the same time. This is a major advantage over software approaches, which must be run sequentially by a CPU.

In addition, we also have much more control over the timing of our design in an FPGA. We can estimate to within a few nanoseconds how long operations will take to complete in an FPGA. Again, we could not do this if we used a CPU to implement our design.

As a result of these features, FPGA designs can be much quicker than the equivalent implementation in a microcontroller.

The drawback is that they tend to be more difficult to work with.

As we will come to see, this is not because designing FPGAs is inherently more difficult.

The major difference is that there is a much smaller community of people who develop FPGAs. As a result, we have much less libraries and open source code available to us.

Structure of an FPGA

Although it is simple to think of an FPGA as an array of unconnected digital components, in reality FPGAs still have a fixed structure.

A basic FPGA consists of a number of configurable logic blocks (CLB), input/output (IO) blocks and a network which provides interconnection between them.

We also normally find embedded RAM memory and specialized components, such as DSP cores and PLLs, in modern FPGAs.

Configurable Logic Blocks

The configurable logic blocks are the main building block of an FPGA. We can think of CLBs as if they were a reconfigurable logic gate which we can configure to perform different logical functions in our design.

A typical CLB consist of a few inputs, look-up tables (LUT), multiplexors and some RAM. LUTs are simply small blocks of memory which are programmed to implement a given logical function.

The exact structure of a CLB depends on the actual chip vendor. More information about the structure of the CLB in a Xilinx FPGA is available here while the structure for an Intel FPGA is available here.

IO Blocks

In an FPGA, the IO blocks provide an connection to circuits which are external to the FPGA. They are connected directly to the physical pins of an FPGA.

We can program the IO blocks in an FPGA so that they function as inputs, outputs or a mixture of both. We can also select different logic standards to apply to our IO, such as 3V3 or 1V8 LVCMOS or LVDS.

In modern FPGAs it is also common for us to have dedicated pins for special functions, such as high speed data transfers.

The exact structure of an IO block in an FPGA varies slightly between different vendors.

However, they typically always include simple registers, such as D type flip flops, and tri-state buffers.

FPGA Program Memory

Once we have finished with our FPGA design, we create a programming file which tells the FPGA how it should be configured.

The FPGA uses this to configure the internal LUTs and interconnections, as well as other internal components such as PLLs and DSP cores.

Most modern devices use SRAM type memory to store this information due to its speed.

One downside of this is that we need an external memory chip to store our program. This is because SRAM is volatile memory, meaning it can't retain its state when it is powered off.

Some vendors offer FPGAs which use flash memory instead of SRAM, as this memory type is non-volatile. However, SRAM based FPGAs can typically run with higher clock speeds which is why they are more popular.

FPGA Development Process

We can broadly divide the FPGA development process into three different stages – design, verification and implementation.  

In the design phase, we focus on transferring our initial concept or idea into an actual FPGA device. This normally involves architecting the chip, or breaking it down into smaller blocks to form a complete design. We then implement each of these smaller blocks using a HDL language, or some other approach.

The implementation stage takes our HDL design and converts this into a programming file for our FPGA.

The verification process feeds into both of these processes. This involves testing and analysing our design and implementation to ensure that it functions correctly.

The image below shows the stages in the development life cycle and how they are interlinked.

FPGA Design Process

The first stage in the development of an FPGA is the design.

We normally start this by architecting the chip in some way. This involves breaking the design into a number of smaller blocks to simplify the coding.

This may be a formal process involving block diagrams and discussions with other engineers. This is especially likely if we are working on a complex design in a professional capacity.

Similarly, we may just use pseudo code to create a basic idea of how our design will look if we are working on a small project.

The next stage is the creation of a function model of our design. We normally use one of the major HDL languages for this purpose.

There are two main styles of modelling which we use for this process. These are commonly referred to as Register Transfer Level (RTL) and Gate Level.

When we use the RTL approach we are describing how data flows between flip flops in the FPGA.

This means that we are writing code to explicitly describe the behaviour of our FPGA in terms of logic, RAM and state machines.

We use gate level modelling to define the interconnection of different pre-existing components. These components are instances of integrated FPGA elements, such as PLLs, LUTs or register cells.

Although we use RTL for the majority of our FPGA design work, most projects feature a mixture of both approaches.

FPGA Verification Process

After writing a model of our design, we then need to prove that it works. The process which we use for this is known as verification.

The first stage of this simulation of our design. For this purpose, we create a test bench which generates a number of inputs to our design.

We then check that the FPGA outputs are what we expect them to be, either through manual inspection or through self checking code.

We can repeat this process on our functional code and on our post place and route netlists. This is a model of the FPGA which is created by our software tools when we implement the FPGA. This model includes information about the internal timing of our FPGA and so is more representative of the final implementation.

Typically, simulation is the main process that is involved the verification of our design. We also normally complement this with hardware testing to ensure that the FPGA interfaces as expected with all external circuity.

However, as FPGA designs have become more complex, other techniques have become popular.

More modern verification activities include hardware in the loop (HiL) and emulation.

In both cases, this involves running code on our target device and feeding back data to simulation software. This allows us to run specific, structured tests on our device in near real time.

This is an advantage as post place and route netlists are extremely slow to simulate in comparison to function code. A simulation which takes an hour to run with functional code can easily take a day or more to run with a post place and route netlist.

FPGA Implementation Process

Once we have written our code and proved that it works, we then need to program this design on our FPGA.

There are actually three stages involved in this process - synthesis, place and route and programming file generation.

The synthesis process transforms our functional code into a number of interconnected gate level macros. These are models of the internal FPGA cells.

This process creates a netlist which describes what the contents of the programmed FPGA should be. We can think of this as being equivalent to a circuit diagram in traditional circuit design.

After we synthesise our design, we then map the netlist to the actual FPGA resources.

The first part of this is mapping the macros to the physical cells in the FPGA using a process known as placement. We can think of this as being equivalent to placing components on a circuit board when we design PCBs in traditional electronic design.

The second stage involves routing the interconnections between the different cells in a process known as routing. This process is equivalent to routing traces in a PCB.

It is normally necessary to run the place and route process several times 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.

We also perform a static timing analysis (STA) as part of the place and route process. This analysis calculates the delays for all of the timing paths in our FPGA and ensures that our design meets with our timing requirements.

If our design fails the STA then we can't guarantee that our FPGA will work reliably. When this happens we either have to run the implementation process again with different settings or we must change our design.

The final stage in implementation process is generating the programming file which configures the FPGA.

The block diagram below gives an overview of the entire FPGA implementation flow.

Synthesis and Place and Route Software Tools

There are a number of different software tools which we can use to implement our design.

Both of the major FPGA vendors (Xilnix and Intel) offer free synthesis tools which are suitable for most projects.

In addition to this, there are also a number of open source synthesis tools which we can use. The most popular of these tools is yosys which is frequently used with Lattice FPGAs.

We can also use paid tools such as Synplify Pro which typically deliver more optimized netlists.

There are no third party place and route tools for Xilinx or Intel parts, meaning we must use the vendor specific tools. These are freely available for download, although paid versions are also available.

For Lattice FPGAs, the open source nextpnr software is a popular place and route tool.

What Next

This post has given a brief introduction to the topic of FPGAs and the FPGA development process.

There are further three posts in this series which give more detailed information about FPGA design, FPGA verification and the FPGA build process.

Although we can start designing FPGAs without any additional knowledge of these processes, it is important to have a good understanding of these fundamental stages in FPGA design.

Additionally, there are detailed VHDL tutorials, verilog tutorials and SystemVerilog tutorials available elsewhere on this site which are a resource for getting started with FPGA design. These posts introduce all of the main features of these languages and include a number exercises and examples.

Alternatively, you may wish to take one of these VHDL or verilog courses which also include hands-on, practical examples.