FPGA back-end (place & route) flow

Whether or not the pre-synthesis or post-synthesis partitioning is used, the resultsare a mapped netlist ready for each FPGA, plus the associated constraints fortiming, pin-locations etc. At the end of the tool flow is a tool or rather a set of tools,provided by the FPGA vendors which can be considered the “back-end” of the flow,using common SoC terminology. These back-end tools take the netlist andconstraints provided by the synthesis tools and implement the logic into the desiredFPGAs.

A simplified flow diagram of the FPGA back-end is shown in Figure 33, where wesee that the first step is to re-map this netlist into the most appropriate FPGAresources as optimally as possible. If synthesis has been correctly constrained and itself has good knowledge of the target FPGA technology then the netlist will need little remapping in the back-end.

The mapped resources are then placed into available blocks in the FPGA and routed together. The place & route runtime and results will depend on many factors, but mostly the quality of the constraints and the utilization of the device.

Figure 33: Xilinx place & route tool flow

Xilinx place & route tool flow.png

The final step is to generate the bitstream which will be programmed into the FPGA devices themselves (with RAM-based FPGAs such as the Xilinx ® Virtex ® families, we call this configuration rather than programming).

Throughout the back-end we can control and analyze the results of the various steps including timing analysis, floorplanning and even estimate the final power consumption.

These tools are generally available through a graphical design environment such as the Xilinx ® Integrated Software Environment (ISE ® tools) which is shown in Figure 34. Here we see the summary for a small design targeted at a Xilinx ® Spartan ®- -3 device but the same approach is scalable up to the largest Xilinx ® Virtex-6 FPGA, although the platform upon which the tool is run, especially the place & route tool, must be very much more capable. For this reason, most large prototyping projects run their tools on Linux-based workstations with maximum ram resources, which are generally widely available within SoC development labs.

Many users will run each of the above steps in an automatic flow, started by clicking a single “button” in ISE. However, it is also common to find that each step is launched individually with the appropriate arguments in a scripted flow or through a command-line interface. This allows unsupervised implementation of the FPGA in a semi-automated fashion which is beneficial when the runtime is many hours.

In that case, conditional branching or termination tests would be inserted at various points of the script to ensure that time is not wasted running tools after earlier steps had failed for any reason.

Figure 34: Xilinx ® ISE ® tools screenshot

Xilinx ® ISE ® tools screenshot.png

A useful way to get started with place & route scripts is to use the “generate script” command in the ISE Project Navigator. This generates a tool control language (TCL) script that contains all the necessary commands to create, modify, and implement the single-FPGA project from a TCL command prompt.

Controlling the back-end

At the top of Figure 33, we see alongside the edif netlist (.edn) a file called .ucf. This is the user constraints file (UCF) format file which is generated by synthesis

The two most important parts of the UCF are the controls for constraining the timing and the placement of the back-end results. Here is where constraints such as clock periods, IO timing, RAM placement, logic grouping and even fine-grained logic placement can be enforced on the back-end. For a FPGA-based prototyping flow, the most useful part is the placement constraint for package pins. Figure 35 shows a short excerpt of a UCF which was automatically generated by a configuration tool for the HAPS ® FPGA boards, called Hapsmap. This UCF is controlling some pin locations for a Xilinx ® Virtex-5 FPGA on a HAPS-51 board and is setting their voltage levels to 3.3V. The UCF is also setting a control for one of the digital clock manager (DCM) blocks as well as defining some clock constraints using TIMESPEC commands understood by the Xilinx ® back-end tools. There is more information about UCF in the references and we shall take a closer look at constraining FPGA designs during chapter 7 and chapter 8.

and/or manually entered by the user and which is used to control the back-end flow.

Figure 35: Example lines extracted from typical user constraints file (UCF)

# Date: Tue Feb 17 16:02:12 2009

# Main board: haps-51

# Signal mapping for device A (FPGA A)

NET "CTI_HCLK_DBG" LOC="B29" | IOSTANDARD = LVDCI_33 ;

NET "BIO1_WRITEDATA" LOC="T36" | IOSTANDARD = LVDCI_33 ;

NET "BIO1_READ_SH" LOC="P35" | IOSTANDARD = LVDCI_33 ;

NET "BIO1_READDATA" LOC="T34" | IOSTANDARD = LVDCI_33 ;

NET "BIO1_CLK" LOC="U33" | IOSTANDARD = LVDCI_33 ;

NET "BIO1_WRITE_LD" LOC="R35" | IOSTANDARD = LVDCI_33 ;

NET "RESET_N" LOC="L14" ;

# DCM phase shift

INST "dcm_base_1" PHASE_SHIFT="-40";

#Begin clock constraints for 32 MHz input clock

NET "HCLK_BUFG" TNM_NET = "HCLK_intern";

TIMESPEC "TS_clk" = PERIOD "HCLK_intern" 31.000 ns HIGH 50.00%;

#End clock constraints

# Misc timing constraints

NET "CTI_HCLK_DBG_c" TNM = "cti_hclk";

NET "clk_fx" TNM = "fx_clk";

TIMESPEC "TS_01" = FROM "cti_hclk" TO "fx_clk" TIG;

TIMESPEC "TS_02" = FROM "fx_clk" TO "cti_hclk" TIG;

An important role for the UCF file is to act as a link between synthesis and the back-end in order to ensure that both tools are working towards the same goals. It is a common error amongst some FPGA designers to neglect the constraints for either part; for example, to provide only the most rudimentary clock constraints to the synthesis and but to then spend a great deal of time and effort tweaking controls for place & route in order to meet timing goals. Passing UCF forward from synthesis ensures that both synthesis and place & route play their part in optimizing the design and meeting design targets.

Additional back-end tools

Beyond the core flow outlined above, there are a number of other useful tools in the back-end suite which may increase our productivity during our prototyping projects. These additional tools include:

• Core generation: a tool which generates specially constructed and optimized design elements or IP cores. Such IP cores may be part of the original design or cores that may be used to replace special RTL structures with FPGA equivalent structures. Read in chapter 10 how we can use the Xilinx ® CORE Generator ™ to help with SoC IP prototyping.

• Floor planning: a tool that allows the user to create placement constraints to any design element. Typically used for IO placements but can also be used to place logic when performance is critical and the tools cannot meet performance requirements.

• Incremental implementation: tools that allow incremental design implementation only on parts of the design that were changed since the last run. Depending on the extent of changes, incremental implementation can significantly reduce the implementation time, compared to a complete re- implementation. Read more about incremental flows in chapter 11.

• FPGA editing: an editing tool that allows modification of the FPGA after place & route. Such tools (Xilinx ® FPGA Editor) allow engineers to perform low-level editing of the design (more detail in debugging tools section below).

• In-circuit debugging: tools that allow capturing and viewing of internal design nodes. Debugging tools will probably be used more than any other in the flow and so we will consider them in more detail next.

TABLE OF CONTENTS

Controlling the back-end

Additional back-end tools