cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
634 Views
Registered: ‎06-22-2017

DDR input constaints

Hi All,

I hope everyone to be fine in these difficult days!

I tried to find a solution for a while for that issue but so far no success.

I have a parallel port (10 inputs) connected in DDR on a Kintex Ultrascale FPGA. The Input are connected to IDDR primitives (DDR_CLK_EDGE => "OPPOSITE_EDGE")
The clock is connected to the IDDR but is first fed to a PLL primitive to suppress the delay using the clock phase parameter (no change in clock frequency). I use : CLKOUT0_PHASE => -45.000000

drawing.svg.png

The datasheets give me:

Ts (half clock cycle) = 5ns 

T: min 1.75 , max 3.25

Here are my constraints: 

set min_delay 1.5;
set max_delay 3.5;
create_clock -period 10.00 -name Virtual_Clock -waveform {0.000 5.00}
create_clock -period 10.00 -name Clock -waveform {0.000 5.00} [get_ports Clock]
set_input_delay -clock [get_clocks Virtual_Clock] -clock_fall -min -add_delay $min_delay [get_ports Data]
set_input_delay -clock [get_clocks Virtual_Clock] -clock_fall -max -add_delay $max_delay [get_ports Data]
set_input_delay -clock [get_clocks Virtual_Clock] -min -add_delay $min_delay [get_ports Data]
set_input_delay -clock [get_clocks Virtual_Clock] -max -add_delay $max_delay [get_ports Data]

The delays on the board are not significant as it is routed very close to the FPGA, but I added a small margin anyway.

By tweaking the phase in the PLL I can easily get the design to pass without violations, but when I have no violations if I send a fixed pattern on the data stream I often have incorrect data as if the timing was incorrect and I would be in the setup/hold window. I can tweak that phase to avoid having any incorrect data but in that case Vivado reports a timing violation.

Am I doing anything wrong here? Does anyone have a suggestion? Can I trust the timing that Vivado gives me, or is there a something weird by using the PLL's?

BTW I have to use the following constraint for the clock: set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets ....]

Details: Vivado 2017.3 on Ubuntu, xcku035-ffva1156-1-c

Any help appreciated, cheers

raph

0 Kudos
6 Replies
Highlighted
Observer
Observer
530 Views
Registered: ‎06-22-2017

Re: DDR input constaints

Any hints?

0 Kudos
Highlighted
506 Views
Registered: ‎01-22-2015

Re: DDR input constaints

@raphplair 

You’ve done a good job explaining your design!   Thank for that and for your well wishes.

Some thoughts:

  1. Remove -add_delay from your second set of set_input_delay constraints and the reorder them.  They should look like the following.
    set_input_delay -clock [get_clocks Virtual_Clock] -min $min_delay [get_ports Data]
    set_input_delay -clock [get_clocks Virtual_Clock] -max $max_delay [get_ports Data]
    set_input_delay -clock [get_clocks Virtual_Clock] -min $min_delay [get_ports Data] -clock_fall -add_delay
    set_input_delay -clock [get_clocks Virtual_Clock] -max $max_delay [get_ports Data] -clock_fall -add_delay
  2. It is not wrong to use a virtual clock when writing your constraints, but it is confusing for some.  Instead of Virtual_Clock, you could use the DDR_Clock sent to you by the external device.
    set DDR_Clock [get_clocks -of_objects [get_ports DDR_CLK_IN]]
  3. DDR_Clock should be coming from a clock-capable pin on the FPGA and then directly routed to the PLL.  If it is, then you don’t need  “CLOCK_DEDICATED_ROUTE BACKBONE”.  If it isn’t then timing of your interface will suffer and, for your UltraScale device, you should be using “CLOCK_DEDICATED_ROUTE SAME_CMT_COLUMN” (ref UG949).

  4. The PLL you are using to shift the clock should only be used for this purpose (and not for anything else – like generating other clocks).  Also, on this PLL you should place a “set_property PHASESHIFT_MODE LATENCY” constraint (ref UG906).

  5. When you setup the PLL with the Clocking Wizard, specify that the source of the input clock is a “clock capable pin” and place a check in the box beside “Phase Alignment”.

  6. The PLL should work fine for what you are doing.  However, you could try using an MMCM instead.

  7. Upgrade your version of Vivado.

Cheers,
Mark

Highlighted
336 Views
Registered: ‎01-22-2015

Re: DDR input constaints

Hi Raph,

By tweaking the phase in the PLL I can easily get the design to pass without violations, but when I have no violations if I send a fixed pattern on the data stream I often have incorrect data as if the timing was incorrect and I would be in the setup/hold window. I can tweak that phase to avoid having any incorrect data but in that case Vivado reports a timing violation.

I hope the interface is now working in a way that makes sense to you. 

If not, then review your instantiations for the IDDR.  You said that you are using (DDR_CLK_EDGE => "OPPOSITE_EDGE") .  Take a look at the other IDDR modes ("SAME_EDGE" and "SAME_EDGE_PIPELINED") as described on pages 157-159 of UG571(v1.12).  My personal preference is "SAME_EDGE_PIPELINED".

Cheers,
Mark

Highlighted
Observer
Observer
243 Views
Registered: ‎06-22-2017

Re: DDR input constaints

Hi Mark,

Thanks very much for your answers!!! 
I tried most of your suggestions, and now I get a synthesis that passes without showing violations and with which I don't get errors while checking with chipscope on fixed sequences. 

I am not completely trusting my results yet, as I am fearing that if I do a new synthesis I would end getting back the errors. But as I am still developing on that project, I will check it out after each synthesis.

So far I think (but I cannot be sure) that this change made the most difference:

> 1. Remove -add_delay from your second set of set_input_delay constraints and the reorder them. They should look like the following.

That or the upgrade of Vivado to 2019.2

 

If I can find a better explanation on the improvement I will post it.

 

Again many thanks for you help.

raph

 

 

0 Kudos
Highlighted
Observer
Observer
217 Views
Registered: ‎06-22-2017

Re: DDR input constaints

I wrote too fast.... the next synthesis has the same problems, and it still looks better when I tweak the phase of the PLL's, ending up in a setup violation window.

I have the impression that the phase shift of the PLL isn't calculated correctly.

 

Or I am missing something else.....

 

raph

0 Kudos
Highlighted
208 Views
Registered: ‎01-22-2015

Re: DDR input constaints

Can you do the following:

  1. Try using an MMCM instead of a PLL
  2. Tell us the manufacturer and part# for the external device that sends data to your FPGA.  
  3. Give us a rough estimate of length for circuit board traces that carry the clock and the data from the external device to the FPGA
  4. Show us your code for instantiating the IDDR.
  5. You say "it still looks better when I tweak the phase of the PLL's".  Please describe in detail what you mean by "it still looks better".  How much tweaking are you doing?
  6. After you tweak the design, you say that a path fails setup timing.  Please show us the timing report for this path.
0 Kudos