Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] timing problem in doing CLOCK DOMAIN CROSSING

Status
Not open for further replies.

achaleus

Member level 5
Joined
Dec 21, 2012
Messages
85
Helped
5
Reputation
10
Reaction score
5
Trophy points
1,288
Location
Bangalore
Activity points
1,866
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

Advanced Member level 5
Joined
Jan 16, 2008
Messages
1,559
Helped
310
Reputation
620
Reaction score
310
Trophy points
1,373
Location
Germany
Activity points
11,556
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

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,860
Helped
1,817
Reputation
3,644
Reaction score
1,782
Trophy points
1,393
Location
USA
Activity points
59,414
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

Member level 5
Joined
Dec 21, 2012
Messages
85
Helped
5
Reputation
10
Reaction score
5
Trophy points
1,288
Location
Bangalore
Activity points
1,866
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

Advanced Member level 4
Joined
Feb 16, 2015
Messages
1,089
Helped
307
Reputation
614
Reaction score
303
Trophy points
83
Activity points
8,730
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

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,860
Helped
1,817
Reputation
3,644
Reaction score
1,782
Trophy points
1,393
Location
USA
Activity points
59,414
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.
 

vGoodtimes

Advanced Member level 4
Joined
Feb 16, 2015
Messages
1,089
Helped
307
Reputation
614
Reaction score
303
Trophy points
83
Activity points
8,730
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

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,860
Helped
1,817
Reputation
3,644
Reaction score
1,782
Trophy points
1,393
Location
USA
Activity points
59,414
(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).
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top