cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Scholar
Scholar
673 Views
Registered: ‎11-21-2013

set_input_delay does not propagate through the MMCM/PLL

Jump to solution

Hi All,

In our design (KC705 with a bridge board on the HPC), we have a multi-lane LVDS DDR interface, with an LVDS clock of\ 288 MHz and data is valid around the clock edges with +/- 420 ps sampling margin on each edge, i.e. the data is valid 420 ps before each edge and after each edge at the output of the source, making it about 840 ps sampling window. In the context of this post, I would like to ignore things like skew, jitter, trace lengths etc.

The clock goes through the CC I/O, then PLL, which generates 3 clocks:

- CLK0 (renamed using create_generated_clock as lvds_serdes_clk) output generates 288 MHz phase 0 for ISERDESE2 CLK

- CLK1 (renamed using create_generated_clock as lvds_serdes_clkb) output generates 288 MHz phase 180 for ISERDESE2 CLKB

- CLK2 output generates 72 MHz, which goes to both ISERDESE2 CLKDIV to match the serialization ratio of 8, as well as the rest of the design (I want to use global clocking for now, I know it has its challenges with these clock rates)

The issue is that I am defining the set_input_delay constraints, but it seems that these constraints are not propagated through the PLL.

My constraints are (Vivado 2018.3):

set_input_delay -clock [get_clocks lvds_clk_clk_p] -min -1.316 [get_ports lvds_data*]

set_input_delay -clock [get_clocks lvds_clk_clk_p] -max -0.420 [get_ports lvds_data*]

set_input_delay -clock [get_clocks lvds_clk_clk_p] -clock_fall -add_delay -min -1.316 [get_ports lvds_data*]

set_input_delay -clock [get_clocks lvds_clk_clk_p] -clock_fall -add_delay -max -0.420 [get_ports lvds_data*]

I see nothing in the timing report on the corresponding sections of the lvds_clk_clk_p, or its derivatives (CLK0/1/2 outputs of the PLL), i.e. no input delay data at all.

Why is that?

Thank you very much

Vlad

Vladislav Muravin
0 Kudos
1 Solution

Accepted Solutions
Highlighted
283 Views
Registered: ‎01-22-2015

@muravin 

Still could not find any paths.

In the instantiation for ISERDESE2:

    ISERDESE2_inst : ISERDESE2
    generic map (
        DATA_RATE => "SDR", -- *DDR, SDR
        ...
        ...
        SRVAL_Q1 => '0',
        SRVAL_Q2 => '0',
        SRVAL_Q3 => '0',
        SRVAL_Q4 => '0'
        IOBDELAY => "BOTH",     -- NONE, BOTH, IBUF, IFD 
    )
    port map (
     ...

If you are using IDELAYE2 then set IOBDELAY => "BOTH"

If you are NOT using IDELAYE2 then set IOBDELAY => "NONE"

(ref UG471, Table 3-4)

A wrong setting for IOBDELAY can result in no timing paths into ISERDESE2.DDLY or into ISERDESE2.D.

 

 

View solution in original post

0 Kudos
16 Replies
Highlighted
Guide
Guide
654 Views
Registered: ‎01-23-2009

I don't have a complete answer for you - I don't know why you aren't seeing any timing reports associated with your clock/input; the constraint format looks correct...

But I have a couple of comments about the interface and the constraints.

First, for the constraints - they may be correct, but they aren't really "natural" - I would probably use -min 0.420 and -max 1.316. You may need to modify the timing edges of the interface (I actually don't think you do), but it is still more natural to do the constraints this way...

But more importantly, there is NO WAY this interface is going to work with static capture. Your data window is only 0.840ns wide, which is way too small to capture with even the best clocking architecture, which isn't even what you are using. Take a look at this post on input capture clocking structures; you will see that this structure (BUFG Capture with MMCM/PLL) is one of the slower ones, often needing data valid widths of 2ns+ or even 3ns+; you have 0.840. The best clocking structure (Direct Capture with BUFIO/BUFR) is significantly faster, but still requires somewhere around 1.5ns to 1.75ns of data window - again, significantly larger than what your device is providing you with.

So, there is no way to do static capture of this interface. If you really need to make this work you will need some kind of dynamic calibration mechanism. When you use dynamic calibration, static timing analysis (and hence constraints) are meaningless...

Avrum

Tags (1)
0 Kudos
Highlighted
Guide
Guide
650 Views
Registered: ‎01-23-2009

Oh, and by the way, I have had problems in the past with having an MMCM generate both the CLK and CLKB directly (180 degrees apart). Even though this is supposed to be the "best" way to do this, I had a system where I was pretty sure that the tool ended up "double inverting" the CLKB (ending up with CLK and CLKB effectively 0 degrees apart). There have been one or two other users that seem to have made a similar observation.

So while this clocking structure is "recommended", you should probably just use the CLKOUT0 for CLK and just invert the CLKOUT0 to drive it to CLKB; this will use the "local inverter" in the ISERDES.

Avrum

0 Kudos
Highlighted
Scholar
Scholar
644 Views
Registered: ‎11-21-2013

HI Avrum,

Thank for all your comments. Our final design, based on our custom board, it does use the source-synchronous capture.

This one (a transitional KC705-based) does not since I/Os are not in the same bank. Yes, we've done a couple of times the bit-level deskew on other designs, where timing is meaningless, and I am really reluctant to do that here... Might go to BUFMR+BUFR+BUFIOs.

On your other comments... I agree, the constraints are not natural, I am just used to take everything 1/2 a period back in time. Can try more natural, especially if this magically makes it to the timing report

Furthermore, we did use an inverter on OSERDES based designs all the time, I just went "large" on the clocking this time. It sounds strange that 180 phase is actually not 180 at the MMCM's output...

Most importantly, I wish someone from Xilinx explain to me why I don't see constraints are not propagating through the PLL. This is the first time I am using PLL with set_input_delay, in the past had no issues with that when there was no PLL.

Thanks again.

BR Vlad

Vladislav Muravin
0 Kudos
Highlighted
Guide
Guide
504 Views
Registered: ‎01-23-2009

Might go to BUFMR+BUFR+BUFIOs

Let me repeat - there is NO WAY you will meet timing with any clocking scheme with a valid window this small. Its not even close. Furthermore using the BUFMR results in terrible timing - it adds something like 1ns to the required valid window.

It sounds strange that 180 phase is actually not 180 at the MMCM's output...

It's not a problem with the MMCM, if it exists (and I never had time to conclusively prove that it did), it was a bug with the interaction between the CLK180 of the MMCM and the CLKB of the ISERDES. My suspicion is that the tool automatically enabled the local inverter on the CLKB input in spite of the fact that it shouldn't have, so I ended up using the inverted CLK180, which resulted in the two samples being taken at the same time instead of 180 degrees apart.

Avrum

0 Kudos
Highlighted
Scholar
Scholar
499 Views
Registered: ‎11-21-2013

Oh yes, I don't dispute what you are saying, i.e. I know that anything less than about 1.3-1.4 ns (assuming an exceptionally good hardware design otherwise it's higher) or so requires calibration with per-line deskew, which is why I mentioned (perhaps not clearly enough) that in the context of this post, I am ignoring all these. We have 4 designs with different data rates using our own, fancier than XAPP585, calibration and per-bit deskew. I just wanted to know why the constraint does not pass through the PLL/MMCM, that's all. It's been a long time since OFFSET IN BEFORE and OFFSET IN AFTER, which passed through the PLL/MMCM just fine... Thanks again. Cheers Vlad

Vladislav Muravin
0 Kudos
Highlighted
Guide
Guide
487 Views
Registered: ‎01-23-2009

I just wanted to know why the constraint does not pass through the PLL/MMCM,

It absolutely should, and it has always worked properly for me. So there is something specific about what you are doing that is causing this problem, but I can't tell what.

But my other point is that since you are using dynamic calibration, constraints are irrelevant.

Avrum

0 Kudos
Highlighted
Scholar
Scholar
483 Views
Registered: ‎11-21-2013

Indeed, constraints are irrelevant when you are "screwing" the clock/data arrival dynamically the serdes taps.

We are not doing anything special, i.e. there is a PLL on the canvas, I hit CTRL-T to make the clock external (pin location set to a CC I/O pair B25/C25 on KC705's HPC), BUFG on everything coming out of the PLL, and that's it. Clock constraints for CLK0/1/2 are auto-generated, but it's just that little problem of set_input_delay not passing through the PLL.

One thing I just though of as I finished reading your last reply is... if the clock somehow, without us knowing, does not go through the dedicated clock network (there is this DEDICATED_ROUTE constraint, which we don't even set in this project), this might be one reason.

BR Vlad

Vladislav Muravin
0 Kudos
Highlighted
443 Views
Registered: ‎01-22-2015

The issue is that I am defining the set_input_delay constraints, but it seems that these constraints are not propagated through the PLL.

The Vivado timing report below is for the data input to an ISERDESE2.  From this report, I understand that Vivado timing analysis places the value from set_input_delay on the data path (and not on the clock path).

SERDES_input_delay.jpg

0 Kudos
Highlighted
Scholar
Scholar
435 Views
Registered: ‎11-21-2013

The report you showed has a reasonable slack, i.e. there are paths returned by the timing analysis. I am getting an infinite slack in the report if I manually try to define this constraint in the open implementation, i.e. the paths to analyze against that set_input_delay constraint are not there.

Vladislav Muravin
0 Kudos
Highlighted
406 Views
Registered: ‎01-22-2015

@muravin 

Important parts of my design are shown below.

SERDES_circuit2.jpg

In my design, there is only one timing path thru the data input port, DATI_P, and it ends on ISERDESE2.DDLY.   Are you saying this timing path does not exist in your design?

Are you using IDELAYE2 in your design?

In your ISERDESE2 instantiation, what setting are you using for attribute IOBDELAY?

Mark

0 Kudos
Highlighted
Scholar
Scholar
366 Views
Registered: ‎11-21-2013

Initially no, I did not use IDELAYE2 in the design. There was just pad to SERDESE2, with clock being from differential pad + PLL. Still could not find any paths.

Vladislav Muravin
0 Kudos
Highlighted
Scholar
Scholar
308 Views
Registered: ‎11-21-2013

Hey Avrum,

I can confirm, at least for entertainment purposes, that I do have an instance where a PLL, whose CLK0 is 0-degree phase and CLK1 is a 180-degree phase DOES NOT work as expected. An inverter makes a difference. Will repeat the experiment, and also, did not try the MMCM, but will do it later. Here is the PLL instance for anyone from Xilinx who might be interested...

My intention was to have CLK0 and CLK1 outputs of the PLL 180 degrees apart, with CLK2 being CLKIN/4. In simulation everything is great.

V

 

PLLE2_ADV #(
.BANDWIDTH ("OPTIMIZED"),
.CLKFBOUT_MULT (3),
.CLKFBOUT_PHASE (0.0),
.CLKIN1_PERIOD (3.472),
.CLKIN2_PERIOD (10.000),
.CLKOUT0_DIVIDE (3),
.CLKOUT0_DUTY_CYCLE (0.5),
.CLKOUT0_PHASE (0.0),
.CLKOUT1_DIVIDE (3),
.CLKOUT1_DUTY_CYCLE (0.5),
.CLKOUT1_PHASE (180),
.CLKOUT2_DIVIDE (12),
.CLKOUT2_DUTY_CYCLE (0.5),
.CLKOUT2_PHASE (0.0),
.CLKOUT3_DIVIDE (7),
.CLKOUT3_DUTY_CYCLE (0.5),
.CLKOUT3_PHASE (0.0),
.CLKOUT4_DIVIDE (7),
.CLKOUT4_DUTY_CYCLE (0.5),
.CLKOUT4_PHASE (0.0),
.CLKOUT5_DIVIDE (7),
.CLKOUT5_DUTY_CYCLE (0.5),
.CLKOUT5_PHASE (0.0),
.COMPENSATION ("ZHOLD"),
.DIVCLK_DIVIDE (1),
.REF_JITTER1 (0.100))
inst_plle2_adv (.CLKOUT3 (),
.CLKOUT4 (),
.CLKOUT5 (),
.DO (),
.DRDY (),
.PWRDWN (1'b0),
.DADDR (7'h00),
.DCLK (1'b0),
.DEN (1'b0),
.DI (16'h0000),
.DWE (1'b0),
/*AUTOINST*/
// Outputs
.CLKFBOUT (mmcm_clkfbout), // Templated
.CLKOUT0 (mmcm_clkout0), // Templated
.CLKOUT1 (mmcm_clkout1), // Templated
.CLKOUT2 (mmcm_clkout2), // Templated
.LOCKED (mmcm_locked), // Templated
// Inputs
.CLKFBIN (mmcm_clkfbin), // Templated
.CLKIN1 (lvds_clk_pad_idelay_p), // Templated
.CLKIN2 (1'b0), // Templated
.CLKINSEL (1'b1), // Templated
.RST (mmcm_reset)); // Templated

Vladislav Muravin
0 Kudos
Highlighted
284 Views
Registered: ‎01-22-2015

@muravin 

Still could not find any paths.

In the instantiation for ISERDESE2:

    ISERDESE2_inst : ISERDESE2
    generic map (
        DATA_RATE => "SDR", -- *DDR, SDR
        ...
        ...
        SRVAL_Q1 => '0',
        SRVAL_Q2 => '0',
        SRVAL_Q3 => '0',
        SRVAL_Q4 => '0'
        IOBDELAY => "BOTH",     -- NONE, BOTH, IBUF, IFD 
    )
    port map (
     ...

If you are using IDELAYE2 then set IOBDELAY => "BOTH"

If you are NOT using IDELAYE2 then set IOBDELAY => "NONE"

(ref UG471, Table 3-4)

A wrong setting for IOBDELAY can result in no timing paths into ISERDESE2.DDLY or into ISERDESE2.D.

 

 

View solution in original post

0 Kudos
Highlighted
Scholar
Scholar
276 Views
Registered: ‎11-21-2013

I will definitely check that, thanks.

Vladislav Muravin
0 Kudos
Highlighted
Scholar
Scholar
219 Views
Registered: ‎11-21-2013

Hey Mark,

I did what you suggested, and got the result of the set_input_delay. Then I changed it back to IFD, and I got it again... Very weird but thanks. Now I can confirm that at least I am told how bad this constraint is.

BR Vlad

Vladislav Muravin
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
200 Views
Registered: ‎05-14-2008

Please choose the answer that resolves your issue as solution to close this thread.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos