Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎06-11-2015

source sync Bus Hold time violation

I'm getting a hold time violation for a input source syncronous Bus in my Artix design that I need to fix.


I have a single ended CMOS18 “pini_clk” input an 13 pini_din[12:0] lines that termiante at clock Artix DDR registers.


So my Verilog looks like


//Put clock input on a Global Buffer


    .O(gclk),    // Clock buffer output

    .I(pini_clk) // Clock buffer input


//and 13 of these IDDR to capture the Data




.Q1(din_A[12]),         .Q2(din_B[12]),

 .CE(1'b1),                   .R(grst),     .S(1'b0));



Now the pini_din[] and pini_clk are all in the same bank and the pini_clk is on a "MRCC" pin.


The deliver device of this source synchronous Bus provide just 1.37 nSec of hold time on either edge...

The CL to data valid MAX is 6 nSec. and the clock period is 16.276 (8.138 for each phase)

So constraints set are like:

create_clock -period 16.276 -name pini_clk -waveform {0.000 8.138} [get_ports pini_clk]

set_input_delay -clock [get_clocks pini_clk] -clock_fall -min -add_delay 1.370 [get_ports pini_din[12]]

set_input_delay -clock [get_clocks pini_clk] -clock_fall -max -add_delay 6.000 [get_ports pini_din[12]]

set_input_delay -clock [get_clocks pini_clk] -min -add_delay 1.370 [get_ports pini_din[12]]

set_input_delay -clock [get_clocks pini_clk] -max -add_delay 6.000 [get_ports pini_din[12]]


Vivado reports 2.77 negateive slack, so looks like it is closer to 4nSec hold time needed the way I designed this,


So how to fix this?

There is some IDELAY thing I've never used, is that appropriate to delay the signal before the IDDR?

Or is a DCM on this CLK a way to fix it to move the sampling point.

The Bus that delivers the pini_din and pini_clk when Idle produces no clock.

But it can be OK to have some DCM delay from Clock valid to the Data running.


Any thoughts?


0 Kudos
2 Replies
Registered: ‎01-23-2009

OK - you have a whole bunch of problems...


First, an IBUFG is not a global buffer, it is an input buffer. As you have coded it you are not using a clock buffer at all - you are using a locally routed clock from the IBUFG to the IDDR (unless the tool is autoinserting a global buffer for you - I am not sure if it will or not).


Second, using a global buffer is going to give terrible timing results - the clock insertion of the buffer is long and variable. Trying to capture an input with this interface will require a huge data eye. If I understand your timing, the device is supplying valid data for 3.5ns.


You don't tell us which device and speed grade you are using. The clocking you are proposing (global buffer only) need a huge data window. This is Tpsfd/Tphfd from the datasheet (U6181, v1.17,  table 44). For the slowest/largest device this is 3.79/-0.36 for a required data eye of 3.43ns - so only 70ps smaller than what you are providing, and this is before we take into account things like jitter, duty cycle imbalance, routing differences on the board...


This is not how you want to capture your data. At very least you want to use an MMCM to complensate for your clock insertion (there are no DCMs in 7 series devices). Using an MMCM - the data eye becomes Tpsmmcmcc/Tphmmcmcc (Table 45), which is 3.52/-0.62 for a somewhat more reasonable window requirement of 2.9ns.


Even better would be to use "Chip Sync" clocking - using the BUFIO - this would be Tpscs/Tphcs (table 47) which is -0.38/1.76 for a required window of 1.38, which makes this interface much more reliable - but, you need to architect your system around this clocking scheme...


Once you have worked all of this out, we can then look at the constraints. A link to the datasheet of the transmitting device would be helpful for that.



0 Kudos
Registered: ‎01-23-2009

Oh - and once you have figured out how you are going to clock it, you will need to adjust the clock/data phase relationship. To do this you will either need to use the phase shift of the MMCM (if you are using an MMCM) or delays on clock and data using the IDELAY cells.



0 Kudos