Understanding AMD Timing Constraints Management

Cross-Domain Clocking (CDC)

Reading time 10 minutes

If data paths have a synchronous source clock that is not the same to the clock used at the endpoint cell, we talk about Cross Domain Clocking (CDC). RTL coding gives us a structure where the digital design is analyzed by the compiler and structured in timing-related data paths. A data path has a source synchronous cell and a destination synchronous cell, such as a D-flip-flop. These synchronous cells might exist in the FPGA fabric but could exist outside of the FPGA in an external device. As far as clock timing constraints are defined for the clocks, the database elaborates the clock edge event corresponding to any data change in the digital design. All synchronous pins of those endpoints have setup and hold timing requirements that must be fulfilled to achieve a reliable behavior for these cells. Examples of such pins include D, CE, and R pins of a D-flip-flop, address pins, WE pins for RAM cells, all input signals to DSP slices and many more. The hardware designer has to make sure to fulfill specifications like real-time requirements, specified with the period of the clock.

If the synthesized design can be linked with all HDL modules and constraints, these requirements can be analyzed. For a timing-driven compiler like the Vivado Synthesis compiler the Cross-Domain Clocking (CDC) paths are fully enclosed to achieve a timing estimation report, indicating whether timing closure is achieved or not. After synthesis, this report is based on estimations, and running place-and-route, we will get an objective statement of the timing results. For any timing path transitioning to a synchronous pin, the setup and hold checks need to be calculated during the compilation runs. This could also start an iterative process of gate-level restructuring to achieve the timing requirements. This approach is quite simple for the hardware designer, provided all the necessary information exists in the compilation database. It is achievable if we have a master clock and an individually derived launch event of a synchronous startpoint ( i.e. the clock input of a D-flip-flop), as well as the capture clock at the endpoint, which is a reference at this cell for synchronous input pins where setup and hold time requirements must be fulfilled. If we see negative values for a slack in a timing report, this is a timing violation. But the timing-driven compiler will iteratively run optimization processes to meet these requirements.
 

Timing path

A CDC timing path

If clock_1 is not the same signal as clock_2, the data path is a CDC data path. An exeption: only the clock phase differs and the clock skew can be resolved by the p&r tool.

 
What can we learn from this:
Cross domain clocking paths are as well fully covered in the clock period-based timing constraining, if the same clock or even a derived clock from the master clock is fully seen in the database. Even a trial-error approach is allowed.

Here is an example:

Our FPGA has a clock input with a 50 MHz crystal oscilator on the PCB. We use a PLL or MMCM with two different clock outputs, which utilize dedicated clock trees by using clock buffers. The two PLL output frequencies are set to 100 MHz and 125 MHz from this PLL/MMCM. We need some parameters from a controller module used as an input for a digital state machine. The controller design runs on the 100 MHz clock and provides these parameters as an output. The state machine runs on 125 MHz and we have some if-conditions using the parameter signals. The 50 MHz clock input is defined with a primary clock constraint.
 
What needs to be done?
Do we need to define timing constraints for these CDC paths? No! We give it a try as we have a synchronous system based on the master clock. We will run the synthesis process and see what we get. If there is no negative setup slack, this estimation result suggests a very high propability that the enclosed CDC path can be used. Perhaps we might observe a negative hold slack violation, but this issue will not be resolved from the synthesis run – it will be resolved later during the implementation run. And with a very high propability, we will achieve timing closure when running the following place-and-route implementaion. Therefore, for many CDC paths in FPGA designs, there is no need for user intervention, such as adding CDC timing constraints.

Also for other situations user CDC timing constraints are not needed:

 
 
When is additional management of CDC paths necessary using timing constraints?

01. We will get timing setup violation for a master clock-defined datapath, as described above, and we would like to improve or over-constrain these paths to get better results. A typical constraint which would be used here: set_max_delay

02. We decide to ignore a specific timing violation, i.e. as a parameter in the example above is quasi static and a parameter change could be allowed to cause a timing violation. Some clocks later we will get a valid value. But it require additional steps of code analysis as violations might also cause a dead-lock in recursive structures like a FSM. A typical constraint to ignore a timing requirement: set_false_path
 
03. The launch clock startpoint exists outside of the FPGA. A typical constraint need to be used here: set_input_delay
 
04. The capture clock endpoint exists outside of the FPGA. A typical constraint need to be used here: set_output_delay
 
05. There is no master clock in the FPGA for the launch and capture side, the clock phases are not known, or not determined. Here it needs synchronizer circuit, AMD recommendation: Uee XPM CDC template or dual ported BRAM or asynchronous FIFO.
 
06. Some ports are not fully digital while they have no discrete clock synchronisation, such as a manual switch. Here it needs synchronizer circuit, AMD recommendation: Uee XPM CDC template or dual ported BRAM or asynchronous FIFO.
 
07. If the compilation database sees clock phase relations, that are physically not fully determined, we can remove those associations by using timing constraint like set_clock groups or set_false_paths. No specific CDC constraints based on Synopsys rules exist here.
 
Constraints like set_false_paths or set_clock groups can remove constraints where this is physically not relavant or fully determined. Constraints like set_max_delay, set_min_delay can be used to improve, tune, and over-constrain specific segments of timing paths.
 

It is essential for the hardware designer to read and understand the timing reports to analyze the CDC path: