Timing failure in DDR3 Design

[rahdirs]

Hi,

I have a design which uses MIG ip.I added some user modules & i could get it to implement successfully.But in that design,i had differential system clock & reference clock.(4 diff sys clk + 1 diff ref clock.)

Earlier all these diff. clock inputs were inputs to my top module,now i wanted to generate those clocks internally by using clocking wizard.

I changed settings in MIG GUI to NO BUFFER option & am using a cascade of MMCM's to generate these clocks.

Now i am able to implement it successfully,but it is saying -

CRITICAL WARNING: [Timing 38-282] The design failed to meet the timing requirements.

Earlier without any MMCMs & option selected as differential in my MIG ip core,the design wasn't facing any such issues.I am getting this timing issue only after adding MMCMs to my design.

i've seen the timing report & as expected it is coming from the cascade of MMCMs that i have added recently to my design.

clock_gen_1 is a MMCM which takes a input clock of 337.5 & gives 200 MHz(clocK_out1) & 168.75 MHz (at clock_out2 & clock_out3).
clock_gen_2 is a MMCM which takes a input from output clock of clcok_gen_1.

Timing Report :
Inter clock table:
From - clk_out1_clock_gen2_1
To - clk_out2_clock_gen1

Setup :
WNS -> -5.693 ns;TNS -> -666.413 ns; TNS failing end points -> 130;Total end points -> 152
Hold:
WNS -> 0.916 ns, TNS -> 0 ns;TNS failing end points -> 0;Total end points -> 130

What could be the problem for this ?
Do i need to add any additional constraints in my xdc/ucf?

 

[ads-ee]

Look at the source and destination clock paths.
1. are they supposed to be synchronous (i.e. one clock is an integer multiple of the other clock)?
2. is there skew in the clocks (likely as they are from cascaded MMCM)
3. if they are not synchronous and you've got a synchronizer you need to false path the signal that passes between the clock domains. it's also advisable to place a maximum delay constraint on those paths too.

Cascading MMCMs is not recommended (Xilinx even mentions that in their documentation). The reason being the jitter becomes additive, so the clocks on the cascaded MMCM have very poor jitter.

I think you are not generating the correct clocking. Go back to the example design, I'm pretty sure it generates all the clocks from one MMCM 337.5 MHz is not the frequency the example design uses to generate the clocks, I think it's generated off of something like 100 or 100 MHz.

 

[rahdirs]

337.5 MHz is not the frequency the example design uses to generate the clocks, I think it's generated off of something like 100 or 100 MHz.

Unlike his case i am generating from 337.5 MHz because i have that clock on my board(comes from ADC).

I saw the signals for which he was showing negative slack & it was on the signal with two modules having different clocks(not multiples of each other).

So i was thinking synchronizing the signal with the clock of other domain.Will adding synchronizer in anyway affect(negatively) slack more ?

Should i just false-path it or add a multipath constraint.

 

[ads-ee]

I saw the signals for which he was showing negative slack & it was on the signal with two modules having different clocks(not multiples of each other).

This probably means you didn't include the constraints for the DDR3 core in your design or they didn't get applied properly as the hierarchy was different than expected by the constraint. ISE's MIG always produces a constraint file with the clock domain crossings false pathed.

So i was thinking synchronizing the signal with the clock of other domain.Will adding synchronizer in anyway affect(negatively) slack more ?

No, it won't. You have to add the constraint to cut the timing between the two clock domains.