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?

 

[FvM]

set_false_path for the domain crossing data.

 

[dpaul]

You can generate a FIFO IP core from any FPGA vendor and look inside that IP core directory. It will have a constraints file where the TCL commands would be listed.

Remember the old adage - Self help is the best help!

 

[fragnen]

It was being heard that a set_max_delay constraint is required for the double stage synchornizer. What can be that constraint?

 

[kaz1]

It was being heard that a set_max_delay constraint is required for the double stage synchornizer. What can be that constraint?

My recollection is that there are two constraints:
- set false path on clock1 register to clock2 register (this path will fail)
- set max delay on clock2 dual synchronisers so that the two registers are not put too far apart, in order to achieve optimum tSU and tH

 

[FvM]

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.

 

[kaz1]

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.

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 guess you are saying the path from clock1 to clock2 (the asynchronous path) needs to be false path but also be allowed set max delay. is that doable?

 

[kaz1]

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?

Green arrow is constrained by clk2 tSU&tH
additionally it has to be optimised for balanced slack rather than just pass timing to improve MTBF
but how to write sdc constraints? I guess set max/min delay can override tSU/tH for that purpose.

I hear that the all the fanout paths from L3 to L4 should be direct without comb logic, but why?

 

[dpaul]

but how to write sdc constraints for both requirements?

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.

 

[fragnen]

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

How will it increase the MTBF if the two registers on either side of red arrow be placed too far apart?

--- Updated Oct 14, 2022 ---

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.

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?

 

[FvM]

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.

 

[fragnen]

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.

Tool will close timing between L2 and L3 with clk2 clock frequency and since there is no combinational logic between L2 and L3 the time will be easily met. But tool can insert some buffers in the green path and also make the green path longer causing longer wire delay of the green path as the green path between L2 and L3 can meet the timing easily. Does not it mean we need to constrain the green path with set_max_delay?

--- Updated Oct 14, 2022 ---

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.

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?

 

[FvM]

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.

 

[fragnen]

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.

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?

 

[FvM]

You don't need max_delay constraints for synchronous logic inside a clock domain, neither of synchronizers nor elsewhere.

 

[fragnen]

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.

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?

 

[FvM]

Yes. The update period scenario is one possible situation where delay constraints may be required. As written in post #11, maximal skew (max_delay - min_delay) is the critical vale in this case.

 

[ThisIsNotSam]

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?

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]

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.

Is this a contribution?

 

[ThisIsNotSam]

Is this a contribution?

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.