Clock Domain Crossing and Reset Domain Crossing Rules
Incorrectly crossing clock-domains can result in functional failures and can be difficult to trace and debug. Additionally, incorrectly setting constraints when crossing clock-domains can result in long run times and impossible timing results. The following CDC rules detect if the datapath signals are going through correct synchronization logic and are being properly constrained.
CDC-50001 – single-bit asynchronous transfer is not synchronized
This rule checks that a single-bit asynchronous transfer has the proper synchronization circuitry.
Figure 19. Unsynchronized 1-bit Asynchronous TransferTo prevent a CDC-50001 violation, the blue register in the following figure must be followed by at least one other register also latched by clkb.
In the example, the output of the blue register should feed another blue register to better protect against metastability.
CDC-50002 – single-bit asynchronous transfer is missing timing constraint
To prevent Quartus® Prime Pro Edition from analyzing the paths between clock domains, relax setup and hold requirements on this path. Use a set_false_path, set_clock_groups (asynchronous), or a large set_max_delay and a large negative set_min_delay.
CDC-50003 – CE-Type CDC Transfer with Insufficient Constraints
Violations of this rule identify a CDC transfer synchronized by DFFE (D Flip-Flop with enable) registers with insufficient timing constraints. Without proper constraints, all bits of such a topology may not latch on the same clock cycle.
Apply an instance assignment of Synchronization Register Chain Length = 1 on the head of a CE-type CDC to prevent downstream registers from being treated as a synchronizer chain. If the transfer forms a multibit bus, apply a set_max_skew constraint on the bits of the bus to ensure that all bits latch on the same clock cycle. The value of the skew constraint must be equal to or lower than either the source or destination clock period, whichever is lower, by setting the set_max_skew constraint.
Also, for all CDC widths, apply a set_net_delay constraint or a set_data_delay constraint on the bits of the transfer to limit their allowable delay. The value of the net delay constraint or data delay constraint must be equal to or lower than the destination clock period, by setting the set_net_delay constraint.
RES-50001 and RES-50002 Reset Synchronization Rules
Deassert asynchronous resets synchronously, to prevent metastability. The following reset domain crossing rules help detect improper reset synchronization.
- RES-50001 – asynchronous reset is not synchronized
- RES-50002 – asynchronous reset is insufficiently synchronized
Example code for a reset synchronizer:
module safe_reset_sync (input external_reset, input clock, output internal_reset); logic q1, q2; always@(posedge clock or negedge external_reset) begin if(external_reset == 1’b0) begin q1 <= 1’b0; q2 <= 1’b0; end else begin q1 <= 1’b1; q2 <= q1; end assign internal_error = q2; endmodule
The output of this module can drive the resets of registers. The design needs constraints to cut the timing path from the asynchronous reset to the synchronizer reset pins.
RES-50003 – asynchronous reset is missing timing constraint
Similar to rule CDC-50002, the reset synchronizer should have timing constraints to prevent Timing Analyzer from analyzing these paths. Use set_false_path, set_clock_groups (asynchronous), or a set_max_delay larger than the latch clock period on transfer from the asynchronous reset source to the registers’ async reset pins.
RES-50004 – multiple asynchronous resets within reset synchronizer chain
Ensure that all asynchronous resets in a reset synchronizer chain have a common source.