Lattice Blog

Share:

The Importance of Timing Constraints in FPGA Designs

The Importance of Timing Constraints in FPGA Designs
Posted 06/07/2021 by Eugen Krassin

Posted in

“The LEC2 Workbench” will be an ongoing series of technical blog posts focused on application development using Lattice products. The posts are authored by FPGA design experts from the Lattice Education Competence Center (LEC2), a complete training and education program designed in close cooperation with Lattice Semiconductor. The training program will include the entire Lattice Semiconductor FPGA and solution stack portfolio, including design tools and methods.

In the early days of chip design, the average low-power FPGA consisted of a few thousand look up tables (LUTs). However, with advances in deep sub-micron manufacturing technology, today’s low-power FPGAs can support 100K LUTS or more. These more complex FPGAs combine processors, memory blocks, and other IP (intellectual property) blocks. This added complexity requires a well-structured design flow that is scalable and provides enough flexibility for FPGA designers to define a seamless design methodology.

The primary goal of FPGA development is the design of safe and reliable circuits compliant with the application’s performance requirements. Accordingly, one of the most important steps in an FPGA’s design cycle is to properly specify and validate the design’s timing constraints to ensure they’re optimized for the timing and performance requirements for the module. This also applies to unconstrained paths, as a failure to validate them means not only will they not be optimized, they also won’t be reported. Fortunately, Lattice Radiant® design software includes the tools FPGA developers need to meet both of these requirements.

Timing Constraints

The basic path type for the specification and verification of timing parameters is the path starting and ending with a clocked element. This type of path can exist in different places in a typical FPGA design. Let’s take a look at some examples.

FPGA Input Path (Example 1)

FPGA Input Path (Example 1)

In the example above, the input signals for the FPGA are generated by an external component. In general, the CLKA and CLKB clocks are different.

FPGA Input Path (Example 1) Code Block

The Radiant timing constraints editor provides the user with suitable templates that significantly reduce the effort required to enter the parameters.

FPGA Internal Path (Example 2)

The general path type described above is visible in the picture below.

FPGA Internal Path (Example 2)

In contrast to Example 1, both the source and destination flip-flops are now inside the FPGA. The difference here is that, apart from the clock specification, no further timing parameters have to be specified, since the internal timing parameter values are already known by the Radiant software. The specification below is usually sufficient.

FPGA Internal Path (Example 2) Code Block 1

But there can be exceptions. In the simplest case, timing constraints define the operating frequency for the clock (or clocks) in the system to be developed. However, not all clocks in a design have a timing relationship that can be analyzed in more detail. Asynchronous clocks are an example of this, as it’s not possible to precisely determine their phase.

  • Synchronous clocks have a predictable timing/phase relationship. This is usually the case with a primary clock and its derivative clocks, since both are based on a common generation (root) and have a common period.
  • Asynchronous clocks have no predictable timing/phase relationship. This is often the case with different primary bars, and bars derived from them. Asynchronous clocks are based on different roots.

You can set up the relationships between the cycle paths with the help of a constraint file and the declaration of cycle groups. If, for example, two asynchronous clocks (CLKB1 and CKKB2) are used in the FPGA, the following specification could be used.

FPGA Internal Path (Example 2) Code Block 2

In a typical FPGA design, we also have to deal with the so-called timing exceptions (also known as a multicycle paths). A timing exception is a result that is only required every other clock cycle. For example, in the diagram below, the signal EN would only be present every second cycle

FPGA Internal Path (Example 2) Diagram 2

Another example of a timing exception is the data transfer from a slower to a faster clock system (or vice versa) when both clocks are synchronous. Finally, false paths can also be considered a type of timing exception.

FPGA Internal Path (Example 2) Code Block 3

By identifying timing exceptions in advance, the timing engine can focus its efforts on optimizing more critical paths to deliver higher quality results.

FPGA Output Path (Example 3)

FPGA Output Path (Example 3)

In the example above, the FPGA’s output signals receive additional processing from an external component. In general, the clocks CLKB and CLKC are different, but they can also be the same.

FPGA Output Path (Example 3) Code Block

In this example, the Radiant Timing Constraints Editor provides the user with suitable templates and significantly reduces the effort required to enter the parameters.

Analysis of timing constraints

Radiant software includes a timing analyzer to check the specified timing parameters. The analyzer can create a report showing results and analysis for all specified and unconstrained timing paths. The combination of the Timing Constraints Editor with the Timing Analyzer makes it much easier to optimize the FPGA.

Eugen Krassin is President and Founder of the Lattice Education Competence Center (LEC2)

Share: