[SOLVED] timing problem in doing CLOCK DOMAIN CROSSING

[achaleus]

While doing CDC, I am using 3 flop synchronizer from slow clock(100MHz) to fast clock(250MHz).
It is reporting timing not met as (I am using xilinx 14.7 for synthesis)

Source Clock: clk_100 rising at 10.000ns
Destination Clock: user_clk rising at 12.000ns

but actually it should report

Source Clock: clk_125 rising at 10.000ns
Destination Clock: user_clk rising at 4.000ns

so, what thing do I need to modify in UCF.

Vinay

 

[dpaul]

I don't understand your description below.

Source Clock: clk_100 rising at 10.000ns
Destination Clock: user_clk rising at 12.000ns

but actually it should report

Source Clock: clk_125 rising at 10.000ns
Destination Clock: user_clk rising at 4.000ns

Considering data travel path from the left to the right, data is passing from 100MHz to 250MHz domains. For a 3 flop sync stage, the 1st flop will be clocked at 100MHz and the next 2 flops at 250MHz. This is what I know is the std procedure.

so, what thing do I need to modify in UCF.

More details are required including the UCF.

 

[ads-ee]

It's showing 12 instead of 4 because the edge at 3*4 (12) is the worst edge (draw it out to scale).

With ucf there isn't a nice clock is async command like SDCso you will have to resort to using TIG (timing ignore group) between the clocks.

 

[achaleus]

with TIG, it simply ignores the timing for all those paths with cdc even if it is not meeting (considering all those paths which are failing), so I don't know whether that is an efficient way. I didn't get why you have written 3*4

 

[vGoodtimes]

the 100 MHz clock has rising edges at 10ns, 20ns, 30ns ...
the 250 MHz clock has rising edges at 4ns, 8ns, 12ns, 16ns, 20ns ...

the 12ns edge of the 250 MHz clock is 2 ns after the 10 ns edge of the 100 MHz clock.

 

[ads-ee]

with TIG, it simply ignores the timing for all those paths with cdc even if it is not meeting (considering all those paths which are failing)

That is the point of using it, you can't reliably time the CDC as it won't meet setup/hold at every clock edge relationship.

And why do you think you have to meet timing in a CDC path? The whole point of a CDC is the clocks are not synchronous and therefore there is no assumed timing relationship between the clocks.

 

[achaleus]

Thanks asd-ee that helped

Vinay

 

[vGoodtimes]

And why do you think you have to meet timing in a CDC path? The whole point of a CDC is the clocks are not synchronous and therefore there is no assumed timing relationship between the clocks.

The constraint that is desired is "max skew". For fifos, the address is gray coded (in most implementations). TIG literally means you could delay bit 0 by 1 microsecond, bit 1 by 2 microsecond, etc... Very absurd. But it could easily violate the gray code "one bit changes on increment" property.

There is also an assumed max delay constraint. For example, delay should not be more than one day. (again absurd, but TIG allows it).

(This is nothing against ads_ee, I just feel that Xilinx's support of TIG and wildcard names was lazy "wonderfullness" that should have never been a thing.)

 

[ads-ee]

(This is nothing against ads_ee, I just feel that Xilinx's support of TIG and wildcard names was lazy "wonderfullness" that should have never been a thing.)

Yeah, couldn't agree more. TIG IMO was the wrong way to constrain a CDC, I came from an ASIC background with SDC and did manual placement and routing for FPGAs with RLOC constraints on the CDC FFs (due to poor performance ofthe automated P&R, but you use what they give you).