fragnen
Full Member level 4
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?
My recollection is that there are two constraints:It was being heard that a set_max_delay constraint is required for the double stage synchornizer. What can be that constraint?
I agree with your statement "The path between register 1 and 2 will be ruled by regular clock2 domain timing constraints". so yes set max delay is not right here.I fear we need a circuit sketch to clarify what we are talking about. I expect both registers clocked by clock2. false_path is in the asynchronous input path of register 1 (with the signal being originated in the clock1 domain). The path between register 1 and 2 will be ruled by regular clock2 domain timing constraints.
Additional max delay requirements may apply for asynchronous path if you either want to limit the delay skew of multiple asynchronous signals, e.g. a gray coded value. Or to limit the round trip delay of FIFO control.
What do you mean how to write?but how to write sdc constraints for both requirements?
How will it increase the MTBF if the two registers on either side of red arrow be placed too far apart?Let me explain my view based on below diagram
Red arrow is the bridging path. This should be false path as it will fail, otherwise it is burden on timing closure
additionally the two registers on either side of red arrow need not be placed apart too far to increase MTBF
but how to write sdc constraints for both requirements?
View attachment 179078
We are putting clk1 and clk2 under false paths with false_path command. We need to also use set_max_delay to put L1 and L2 as close as possible, but L1 runs at clk1 and L2 runs at clk2 and we already set clk1 to clk2 under false path and hence tool cannot do timing analysis for this set_max_delay between L1 and L2 . How to write the constraint then?What do you mean how to write?
One is a register placement constrain or rather attribute and the other is a timing constrain.
You define using TCL the connecting path (on either side of the read arrow) as false_path. You can put this command within your design constrain file.
As per the synthesis tool used, you need to tell the tool to put L1, L2 and L3 as close as possible and also not to be inferred them as redundant. You can use such a synthesis attribute (the DONT_TOUCH is very common) within the RTL file, where the sync is being done.
I fear we need a circuit sketch to clarify what we are talking about. I expect both registers clocked by clock2. false_path is in the asynchronous input path of register 1 (with the signal being originated in the clock1 domain). The path between register 1 and 2 will be ruled by regular clock2 domain timing constraints.
So here 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. Hence we need to constraint the red path using set_max_delay. This constraining of the red path with set_max_delay, does not have anything to do with MTBF. Am I correct?Delay in the asynchronous path doesn't affect MTBF at all. It comes into play if you want to capture multiple input signals, e.g. a gray counter value consistently and is related to the expected update rate. The total skew must not exceed the update period.
But the tool can use a long wire to connect L2 and L3 as the tool will find large positive slack in this register-register path between L2 and L3 and to avoid that we require to constrain this register-register path by set_max_delay also. Is not it?No, the green path delay doesn't modify the logic function as long as timing constraints are met. There's nothing specific to synchronizers in this question.
So here 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. Hence we need to constraint the red path using set_max_delay. This constraining of the red path with set_max_delay, does not have anything to do with MTBF. Am I correct?Delay in the asynchronous path doesn't affect MTBF at all. It comes into play if you want to capture multiple input signals, e.g. a gray counter value consistently and is related to the expected update rate. The total skew must not exceed the update period.
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.But the tool can use a long wire to connect L2 and L3 as the tool will find large positive slack in this register-register path between L2 and L3 and to avoid that we require to constrain this register-register path by set_max_delay also. Is not it?
Is this a contribution?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.
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.Is this a contribution?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?