Several methods for timing constraints

The more you understand how to implement your design, the timing requirements of your design, the resource distribution and structure of the target device, and the effect of EDA tools on executing constraints, the clearer the timing constraint goals for your design will be, and accordingly, the more controllable the timing convergence process of the design will be.

Based on the results of my recent work and study, I have summarized the following methods for timing constraints. They are arranged in order from easy to difficult:

0. Core frequency constraints

This is the most basic, so it is numbered 0.

1. Core frequency constraints + timing exception constraints

Timing exception constraints include FalsePath, MulticyclePath, MaxDelay, and MinDelay. However, these are not the most complete timing constraints. If there are only these constraints, it means that the designer's thinking is still limited to the FPGA chip.

2. Core frequency constraints + timing exception constraints + I/O constraints

I/O constraints include pin assignment location, idle pin driving mode, external routing delay (InputDelay, OutputDelay), pull-up and pull-down resistors, driving current intensity, etc. The timing constraints after adding I/O constraints are complete timing constraints. As a device on the PCB, FPGA is part of the timing convergence of the entire PCB system. As part of PCB design, FPGA requires PCB design engineers to read and analyze its I/O Timing Diagram like all COTS devices. What makes FPGA different from COTS devices is that its I/O Timing can be adjusted within a certain range in the later stage of design; however, it is best to give full consideration in the early stage of PCB design and include it in the design document.

Because the FPGA's I/O Timing will change during the design process, accurately constraining it is an important factor in ensuring a stable and controllable design. Many unstable issues with the FPGA's operation of external devices after the FPGA is recompiled may be caused by this.

3. Core frequency constraint + timing exception constraint + I/O constraint + Post-fit Netlist

The process of introducing Post-fit Netlist starts from a successful timing closure result, fixes the layout position and routing result (Netlist) of a specific set of logic (Design Partition) implemented on FPGA, and ensures that this layout and routing result can be reproduced in the new compilation. Correspondingly, the timing closure result of this set of logic is also guaranteed. This process of partially retaining the results of the previous compilation is Incremental Compilation. The type and degree of the retained netlist can be set, not just limited to Post-fit Netlist, so as to obtain the corresponding retention strength and optimization effect. With the strong support of EDA tools, although it is a fine-grained constraint accurate to the gate level, the designer only needs to perform a series of setting operations, and does not need to care about the specific information of layout and routing. Because the constraints accurate to the gate level are too numerous and cannot be saved in the qsf file, the retained netlist can be output to a separate file qxp in the form of Partial Netlist, and the incremental compilation is completed together with the rough configuration information in the qsf file.

4. Core frequency constraint + timing exception constraint + I/O constraint + LogicLock

LogicLock is a layout constraint performed at the bottom layer of the FPGA device. The constraints of LogicLock are coarse-grained, and only specify the layout position and size (LogicLock Regions) that can be adjusted for the top-level module or sub-module of the design. A successful LogicLock requires the designer to make an estimate of the possible timing convergence target, consider the impact of the position relationship between specific logic resources (pins, memory, DSP) and the LogicLock Region on the timing, and refer to the results of the last successful timing convergence. This process of weighing and planning the physical layout of the bottom layer of the FPGA is FloorPlanning. LogicLock gives designers more control over the layout position and range, and can effectively convey the designer's design intent to the EDA tool, avoiding the EDA tool from blindly optimizing non-critical paths due to the lack of layout priority information. Since the layout position changes of the module in each compilation are limited to the optimal fixed range, the reproducibility of the timing convergence results is higher. Due to its coarse-grained characteristics, LogicLock does not have much constraint information and can be retained in the qsf file.

It should be noted that methods 3 and 4 can often be used together, that is, for the LogicLock Region specified by FloorPlanning, it can be used as a Design Partition for Incremental Compilation. This is why the above two methods are easily confused.

5. Core frequency constraints + timing exception constraints + I/O constraints + register layout constraints

Register placement constraints are fine-grained placement constraints that are accurate to the register or LE level. Designers obtain reliable timing closure results by exerting precise control over the design. Manually placing position constraints on each register in the design and ensuring timing closure is a huge project, which means that the designer can fully control the physical implementation of the design. This is an ideal goal that cannot be achieved in a limited time. The usual practice is that designers place register placement constraints on parts of the design and obtain timing closure information by actually running the placement and routing tools, and approach the expected timing target through several iterations.

Not long ago, I saw a design like this: each register of a submodule was given a specific layout position constraint. The timing convergence of the module was accordingly guaranteed during each recompilation process. After analysis, the design and constraints of this submodule were initially made in the schematic diagram. After achieving the timing convergence target, the design was converted to HDL language description, and the corresponding constraints were also saved in the configuration file.

6. Core frequency constraint + timing exception constraint + I/O constraint + specific path delay constraint

Good timing constraints should be "guided" rather than "mandatory". By giving the timing delay range of the critical path in the design, the detailed work is left to the EDA tool to be freely implemented within the limited range of the constraint. This is also an ideal goal, which requires the designer to have a clear idea of ​​each timing path, and to distinguish which paths can be converged through core frequency and simple timing exception constraints, and which paths must have MaxDelay and MinDelay set. None can be missed, and the "understanding" strong support of the EDA tool is also required. Setting the path delay constraint is to indirectly set the layout and routing constraint, but it is more flexible than the above methods 3, 4, and 5, and does not lose its accuracy. The true meaning of timing constraints is to achieve timing convergence through timing constraints rather than explicit layout and netlist constraints.

I remember someone said, "Good timing is designed, not constrained." I have always used this sentence as a guide for my own logic design and timing constraints. Good constraints must be based on good design. Without a good design, it is meaningless to work hard on constraints. However, the quality of the design can be checked through correct constraints, and the timing analysis report can be used to check the places where the timing is not well considered in the design, so as to modify them. The goal of perfecting the design can also be achieved through several iterations of "analysis-modification-analysis". It should be said that design is the basis of constraints, and constraints are the guarantee of design. The two complement each other.