specific constraint during synthesis

[fragnen]

Inside asynchronous FIFO there are synchronizers present. What kind of constraint needs to be provided during rtl synthesis for those synchronizers which are present inside an asynchronous FIFO?

 

[kaz1]

there is a context here, which you might be missing. time and time again, the OP asks complicated questions without having the basic knowledge required to come anywhere near them. this is very frustrating for frequent posters of this forum.

Not at all. We have been diving in micro-discussions and the OP is well aware of basics of timing. You suddenly came dismissing all our discussions and advising him to read basics...

 

[fragnen]

FvM and Kaz1,

A summary of our discussion is drawn below. Please correct if anything is wrong or improper.

For the presence of multi stage synchronizers present in any design, we need to provide the set_max_delay for the red coloured path/paths of the diagram for a single bit signal or multibit bus crossing crossing from one clock domain to another clock domain through single stage synchronizer or multistage synchronizer while writing the SDC of the design.

 

[dpaul]

man, you need to read some textbook or tutorials on this timing stuff. start with some simple STA and SDC tutorial. clock domain crossing is a whole other beast which you are not ready to tame. IMO.

@kaz1
I have been seeing questions from fragnen for quite some time....

As far as most of his Qs are concerned, I think the Quote above is the correct answer from !Sam.

 

[kaz1]

FvM and Kaz1,

A summary of our discussion is drawn below. Please correct if anything is wrong or improper.

For the presence of multi stage synchronizers present in any design, we need to provide the set_max_delay for the red coloured path/paths of the diagram for a single bit signal or multibit bus crossing crossing from one clock domain to another clock domain through single stage synchronizer or multistage synchronizer while writing the SDC of the design.

The red path needs set false path(or set clock groups as asynchronous).
additionally for multibits it needs set_net_delay.

Here is an excerpt from Intel:
"The first requirement is that you do not have a set_false_path constraint between the two clock domains, if you don't want paths between them to be analyzed for setup and hold then you can use set_clock_groups which has a lower precedence.

Next, constrain the paths with set_net_delay to make them as short as possible and with set_max_skew. Set_max_skew does not constrain the fitter but you can analyse against this constraint in the Timing Analyzer. "

The green path needs nothing as it follows clock2 constraints but you might override that by tighter values for optimum slack. Optimum slack is said to help MTBF but I don't see fpga vendors applying that. so you can ignore it.

and here is sdc file from Quartus dc fifo ip: (Though I need somebody to explain it):

# convention for module sdc apply_sdc_<module_name>
proc apply_sdc_dcfifo {hier_path} {
# gray_rdptr
apply_sdc_dcfifo_rdptr $hier_path
# gray_wrptr
apply_sdc_dcfifo_wrptr $hier_path
}
#
# common constraint setting proc
proc apply_sdc_dcfifo_for_ptrs {from_node_list to_node_list} {
# control skew for bits
set_max_skew -from $from_node_list -to $to_node_list -get_skew_value_from_clock_period src_clock_period -skew_value_multiplier 0.8
# path delay (exception for net delay)
if { ![string equal "quartus_syn" $::TimeQuestInfo(nameofexecutable)] } {
set_net_delay -from $from_node_list -to $to_node_list -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8
}
#relax setup and hold calculation
set_max_delay -from $from_node_list -to $to_node_list 100
set_min_delay -from $from_node_list -to $to_node_list -100
}
#
# mstable propgation delay
proc apply_sdc_dcfifo_mstable_delay {from_node_list to_node_list} {
# mstable delay
if { ![string equal "quartus_syn" $::TimeQuestInfo(nameofexecutable)] } {
set_net_delay -from $from_node_list -to $to_node_list -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8
}
}
#
# rdptr constraints
proc apply_sdc_dcfifo_rdptr {hier_path} {
# get from and to list
set from_node_list [get_keepers $hier_path|dcfifo_component|auto_generated|*rdptr_g*]
set to_node_list [get_keepers $hier_path|dcfifo_component|auto_generated|ws_dgrp|dffpipe*|dffe*]
apply_sdc_dcfifo_for_ptrs $from_node_list $to_node_list
# mstable
set from_node_mstable_list [get_keepers $hier_path|dcfifo_component|auto_generated|ws_dgrp|dffpipe*|dffe*]
set to_node_mstable_list [get_keepers $hier_path|dcfifo_component|auto_generated|ws_dgrp|dffpipe*|dffe*]
apply_sdc_dcfifo_mstable_delay $from_node_mstable_list $to_node_mstable_list
}
#
# wrptr constraints
proc apply_sdc_dcfifo_wrptr {hier_path} {
# control skew for bits
set from_node_list [get_keepers $hier_path|dcfifo_component|auto_generated|delayed_wrptr_g*]
set to_node_list [get_keepers $hier_path|dcfifo_component|auto_generated|rs_dgwp|dffpipe*|dffe*]
apply_sdc_dcfifo_for_ptrs $from_node_list $to_node_list
# mstable
set from_node_mstable_list [get_keepers $hier_path|dcfifo_component|auto_generated|rs_dgwp|dffpipe*|dffe*]
set to_node_mstable_list [get_keepers $hier_path|dcfifo_component|auto_generated|rs_dgwp|dffpipe*|dffe*]
apply_sdc_dcfifo_mstable_delay $from_node_mstable_list $to_node_mstable_list
}

proc apply_sdc_pre_dcfifo {entity_name} {

set inst_list [get_entity_instances $entity_name]

foreach each_inst $inst_list {

apply_sdc_dcfifo ${each_inst}

}
}
apply_sdc_pre_dcfifo test_fifo_fifo_181_3hdmxdq

This link may help:

https://www.intel.com/content/www/us/en/docs/programmable/683082/21-3/dual-clock-fifo-timing-constraints.html

 

[fragnen]

Kaz1 and FvM,

The red path needs also to be constraint with set_net_delay/set_max_delay even if the red path is a single bit signal while writing the SDC for any design which has a single bit signal passing through a multistage synchronizer to take care of clock domain crossing. Please correct me if I am wrong.

 

[FvM]

No, in most cases single bit signals don't need xxx_delay constraints for the asynchronous transfer.

 

[fragnen]

No, in most cases single bit signals don't need xxx_delay constraints for the asynchronous transfer.

But even for a single bit it can happen that if the total skew exceeds the update period then at the receiving end which is under clk2 domain will receive corrupt data from clk1 instead of proper data from clk1. Is not it?

 

[FvM]

Skew is a delta quantity (delay1 - delay2). A single bit has no skew.

 

[fragnen]

Skew is a delta quantity (delay1 - delay2). A single bit has no skew.

Here by total skew for one bit signal at post # 27, the time taken by a bit to travel through the red path from L1 to L2 is being referred. May be it should have been called as delay instead of a total skew. So if the the red path is too long in length the delay of traversing through this red path of a single bit signal can be so high that even the new next changed data may not be captured at the receiving flop, L2 correctly and hence L2 receiving corrupt data for a single bit signal even. Hence even a single bit signal can be corrupted if not constraint by set_net_delay/set_max_delay while the single bit signal is travelling from clk1 to clk2 through the red path. Please comment.

 

[std_match]

Here by total skew for one bit signal at post # 27, the time taken by a bit to travel through the red path from L1 to L2 is being referred. May be it should have been called as delay instead of a total skew. So if the the red path is too long in length the delay of traversing through this red path of a single bit signal can be so high that even the new next changed data may not be captured at the receiving flop, L2 correctly and hence L2 receiving corrupt data for a single bit signal even. Hence even a single bit signal can be corrupted if not constraint by set_net_delay/set_max_delay while the single bit signal is travelling from clk1 to clk2 through the red path. Please comment.

No, the red path in post #8 only needs a set_false_path.
It is the green path that needs to be constrained to maximize the setup time for the possibly metastable signal captured by register L3.
With Xilinx Vivado, it is enough to set the attribute ASYNC_REG = true for register L3. The tools will then place it next to register L2, which should also have ASYNC_REG = true.

From UG901:
"The ASYNC_REG is an attribute that affects many processes in the Vivado tools flow. The purpose of this attribute is to inform the tool that a register is capable of receiving asynchronous data in the D input pin relative to the source clock, or that the register is a synchronizing register within a synchronization chain."

 

[fragnen]

No, the red path in post #8 only needs a set_false_path.
It is the green path that needs to be constrained to maximize the setup time for the possibly metastable signal captured by register L3.
With Xilinx Vivado, it is enough to set the attribute ASYNC_REG = true for register L3. The tools will then place it next to register L2, which should also have ASYNC_REG = true.

From UG901:
"The ASYNC_REG is an attribute that affects many processes in the Vivado tools flow. The purpose of this attribute is to inform the tool that a register is capable of receiving asynchronous data in the D input pin relative to the source clock, or that the register is a synchronizing register within a synchronization chain."

That means for ASIC for both single bit signal and multibit signals passing through multistage synchronizers, the following constraints should also be provided in SDC. Please correct if it is wrong.

1. The green path needs to be constraint by set_max_delay.
2. The red path needs to be also constraint by set_net_delay/set_max_delay.

 

[fragnen]

Hello FvM, std_match, kaz1,

Can you please add any correction if necessary to the summary of our discussion summarized at post number 31 in this thread?

 

[kaz1]

Hello FvM, std_match, kaz1,

Can you please add any correction if necessary to the summary of our discussion summarized at post number 31 in this thread?

I can speak for FPGA platform and speculate on ASIC platform.
The clock crossing bridge is the same concept in either case.

The red path needs to be excluded from timing (false path, async clock group)
If red path is multibits it additionally needs minimising skew (set net delay)
This applies to FPGA or ASIC but may be ASIC can control fitting in a different way.

The green path needs nothing (leave it to clock tSU/tH)
Though in theory MTBF can be improved if its timing is further constrained for optimum slack i.e. setup slack ~= hold slack (transition of data right in middle of timing window.)