FPGA performance and design constraints

24 July 2008

After the HDL model function, design constraints have the next biggest influence over the performance of an FPGA design. However, many designers do not invest enough time to constrain a design

Instead, they attempt to close timing too late in the design flow by trying a variety of place and route tool options and handdirected placement. These methods are time consuming and may not work on the next revision of the design. Well-defined constraints will help the implementation tools optimise the design to meet its objectives, and will do so at the most appropriate stages of the design flow.

FPGA design constraints express design intent beyond the HDL model. The most common type is timing characteristics of the target device, but may also include directives for design optimisation, I/O programming or a physical floor plan.

Synthesis and data flow
The flowchart, right, illustrates an FPGA data flow using Synplicity Synplify and Lattice Semiconductor ispLEVER FPGA design tools, and special emphasis is given to the constraint flow. Such constraints originate from the graphical editors Scope and Design Planner, or from an HDL source embedded as VHDL attributes or Verilog comments. It is not uncommon to use a combination of both HDL and constraint editors to direct synthesis and place and route tools.

The first processing block reflects the Synplify compiler and synthesis algorithms. HDL-based constraints and the SDC (Synplicity Design Constraints) file are applied to direct the Synplify optimisation and synthesis engine. Timing constraints direct the embedded timing analysis and logic algorithms, while mapping control constraints direct the types of library cells that will be used in the target netlist.

After the synthesis step, design constraints for the back-end tools are captured. The ispLEVER Design Planner is used to express timing objectives as well as physical implementation details such as an I/O and floor plan. The Lattice LPF constraint file is applied at the map design stage, where both I/O programming and timing optimisation occur. Any ispLEVER constraints that originated in HDL are merged with the LPFbased constraints and written to a PRF (physical preference file). Any references to logic cells of the postsynthesis netlist are automatically translated into physical elements such as slices, DSP or the EBR blocks of the target FPGA. The physical preference file is then applied by the place and route and static timing analysis tools that are part of the FPGA implementation tools. After place and route results are available, it is typical to perform additional refinement runs with more accurate timing details back-annotated into the synthesis stage. Black-box IP timing and route delays improve the accuracy of synthesis timing analysis.

Synthesis constraints
The importance of synthesis constraints cannot be over-emphasised. Place and route tools can do little to improve or ‘fix’ the timing performance of RTL that is poorly designed for logic synthesis, or a design that has not been optimised for the I/O timing and clock frequencies required by the target system. Synthesis timing constraints have an influence over the quality of the FPGA implementation since this is where the algorithms are applied to minimise levels of logic between register stages of the design. Synplicity makes a distinction between directive versus attribute type constraints.

Directives influence compiler optimisation and must be HDL-based. Attributes influence mapping optimisation and may be HDL or SDC-based. Timing constraints are used to define clocks, I/O timing, multi-cycle relationships between clocks or a path, as well as timing exceptions. To make code as portable as possible, timing constraints are maintained in the SDC file. Timing constraints embedded in HDL are usually reserved for IP cores referenced as blackbox type modules, where details are not available to the synthesis timing analyser. In these cases, the IP vendor will often provide timing details for analysis. The graphical constraints editor Scope provides an easy way to initialise, browse design signals, and assign timing constraints. Output is stored in the ASCII SDC format.

Timing constraints should cover basic performance characteristics of the design; clocks, I/O delays and the point-to-point delays of asynchronous paths through the design. If there are situations where one clock domain passes data to another domain, the number of cycles required should be defined using a multi-cycle type preference. Several compiler optimisation constraints are available for Synplify. Popular types control state machine encoding, hierarchy retention, and memory technology targeting. To illustrate a compiler constraint, state machine encoding should be considered. The Synplify FSM Compiler feature makes assumptions about encoding style based on the number of machine states defined. If the machine has up to four states, sequential encoding is used for a compact implementation; whereas five to 40 states will produce OHE (one hot encoding), which tend to be high performance. Over 40 states will produce grey encoding. If there are special design requirements, FSM encoding can be controlled on a case-by-case
basis by using the syn_encoding directive that is added to the declaration of the state registers.

Place and route constraints
Constraints for the ispLEVER implementation tools cover timing performance as well as many aspects of the design implementation. As constraints through the design flow are managed, it is natural to shift perspective from higher levels of abstraction to lower ones. Initially, constraints will be written relative to registertransfer level elements or the gates, ports and nets inferred from RTL. Later constraints will be written relative to ‘physical’ FPGA elements like programmable function units, embedded ASIC blocks for memory or DSP, and programmable I/O cells. The semantics of the FPGA implementation tool constraint language accommodates both domains.

Back-end constraints are most commonly used to define I/O programming, I/O placement and timing objectives. They can also define parameters of programmable blocks such as memories or PLL/DLL circuits. Constraints can go so far as to direct the placement of logic onto the device’s floorplan and design partitions for a modular design flow. Like synthesis constraints, back-end constraints can be based in HDL or an ASCII text file.

In ispLEVER, the Design Planner application provides a graphical interface to browse the content of the post-synthesis netlist and write constraints in terms of the ports, nets, registers, and ASIC blocks.

Timing constraints should cover basic characteristics, as for logic synthesis and cover clocks, I/O delays, and point-to-point delays. It is not uncommon to over-constrain timing objectives. In practice, multiple versions of constraint files may be maintained, where one set is applied for logic optimisation and the other for static timing analysis using the ‘real’ sign-off timing.

Several attributes are available to guide the FPGA implementation from within HDL. Popular types control I/O location, logic ‘don't touch’ type directives, and logic grouping. To illustrate an HDL-based back-end constraint, consider HGROUP, the logic grouping attribute hierarchical group. HGROUP directs the placer algorithm to put members of the group in proximity on the device. This type of attribute can help improve timing and make the performance results of subsequent runs more consistent.

For example, in VHDL
attribute HGROUP: string
attribute BBOX: string
attribute HGROUP of struct: architecture
is “pgroup1”
attribute BBOX of struct: architecture is

The attributes define a tag “pgroup1” that will be associated with the architecture struct. All logic of struct will be constrained to a 5 row high by 15 column wide bounding box where the dimensions are in terms of row and column units of the target device.

Taking the example further and adding more detail about the placement in the LPF results in:

# Anchor pgroup1

This directs the placer to anchor the NW corner of the 5x15 bounding box at row 11, column two of the target device.

If the group contents were expressed in LPF in terms of post-synthesis elements, this list would need to be refreshed with each revision of the model. However, once embedded in source, the membership is ‘inferred’ after any change.

To begin defining achievable constraints, it is necessary to leverage the analysis reports produced by synthesis and the implementation back-end. The following reports will help speed the definition of key back-end constraints.

Timing constraints
A Synplify synthesis report can be used as a baseline target for clock and I/O timing. Depending on routing congestion, a degree of variation from the synthesis estimate may be identified. However, target speeds ±20% of synthesis reports can be expected.

Initially defining signal standards for I/O means that package assignments may be floated. Using automatic placement to find a legal placement takes into account signal standard support that can vary across banks of the device. Backing annotate assignments to the LPF preference file when the pin interface is stable is suggested.

Guiding the floor plan based on an initial, low-effort, ‘flat’ placement means that hierarchical branches can be highlighted to determine the consumption by branch. It is also necessary to account for PIO location and relative positions of regions based on data flow.

TROY SCOTT is product marketing engineer, Lattice Semiconductor

Contact Details and Archive...

Print this page | E-mail this page

This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.