UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer ssneed
Observer
241 Views
Registered: ‎02-20-2019

DDR clock timing failure with other non-ddr logic

Jump to solution

Hello,

I have a Kintex 7 (-2) speed grade design with a source synchronous DDR input.  I have constrained the DDR input timing using the DDR Center Aligned Template.  However, I am also using the DDR clock to drive a test data generator that operates only on the clock rising edge.  It fails timing and the timing report shows that the Data Path starts on "(clock DDRC_CLOCK fall edge)".  Do I need to add constratints to direct Vivado to analyze the logic only with respect to the rising edge of the DDRC clock for my test data generator?

Thanks,  -Sean

Test Pat Gen Failure.JPG
Test Pat Gen Failure2.JPG
0 Kudos
1 Solution

Accepted Solutions
Observer ssneed
Observer
212 Views
Registered: ‎02-20-2019

Re: DDR clock timing failure with other non-ddr logic

Jump to solution

Ok.  I thought that the analysis for timing depends on the edges the flops.  Thanks for clarifying.

I made a mistake in my code.  The DSYNC input is actually a DDR input and so I have it constrained to drive an IDDR input (not shown in my diagram, by mistake).  In any case, that is he cause of the timing analysis being done on a falling edge.  Once I switched to using the output of the DSYNC IDDR block, timing then passed and the timing calc. worked out.

Much thanks.

-Sean

0 Kudos
2 Replies
Historian
Historian
230 Views
Registered: ‎01-23-2009

Re: DDR clock timing failure with other non-ddr logic

Jump to solution

The failing path you are showing starts at the DDR inputs of the FPGA - the analysis of the falling edge is coming from your set_input_delay constraints (which should have constraints with respect to the falling edge). So this path is not consistent with your description - this is not a path "inside" your Test Data Generator.

Each path in the design is timed using the edges of the clock it uses - there isn't inherently any concept of DDR clock vs SDR clock - the DDR paths exist since the IDDR uses both edges of the clock and your input constraints define timings with respect to both edges of the clock (which, again, is correct).

If a submodule only uses the rising edge of the clock, then paths within it will be rising edge to rising edge, and hence will be timed based on the full period (not half period). You don't need (nor are there any) different constraints for the tool to understand this.

Avrum

Observer ssneed
Observer
213 Views
Registered: ‎02-20-2019

Re: DDR clock timing failure with other non-ddr logic

Jump to solution

Ok.  I thought that the analysis for timing depends on the edges the flops.  Thanks for clarifying.

I made a mistake in my code.  The DSYNC input is actually a DDR input and so I have it constrained to drive an IDDR input (not shown in my diagram, by mistake).  In any case, that is he cause of the timing analysis being done on a falling edge.  Once I switched to using the output of the DSYNC IDDR block, timing then passed and the timing calc. worked out.

Much thanks.

-Sean

0 Kudos