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: 
Highlighted
Visitor antg0l
Visitor
6,689 Views
Registered: ‎01-31-2014

Pls check my timing constraints for source-sync ddr

Jump to solution

Hello!

 

I have a working interface with ADC AD 9255 which is source-synchronous LVDS DDR on zync 7030. The architecture is shown in the attached picture, the frequency is 100 MHz. I set timing constraints the following way:


create_clock -name Clk_ADC0 -period 10 [get_ports ADC0_DCO_p]
set_input_delay -clock Clk_ADC0 -max 5.4 [get_ports ADC0_D_* -filter {direction==in}];
set_input_delay -clock Clk_ADC0 -min 4.6 [get_ports ADC0_D_* -filter {direction==in}];
set_input_delay -clock Clk_ADC0 -max 5.4 [get_ports ADC0_D_* -filter {direction==in}] -clock_fall -add_delay;
set_input_delay -clock Clk_ADC0 -min 4.6 [get_ports ADC0_D_* -filter {direction==in}] -clock_fall -add_delay;

 

But the future design will have to deal with frequency around 180 MHz instead of 100. So I am trying to tighten constraints. Tightening to 125 MHz is OK, 153 MHz is OK, but 166 MHz fails timing. Here are the constraints:

 

create_clock -name Clk_ADC0 -period 6 [get_ports ADC0_DCO_p]
set_input_delay -clock Clk_ADC0 -max 3.4 [get_ports ADC0_D_* -filter {direction==in}];
set_input_delay -clock Clk_ADC0 -min 2.6 [get_ports ADC0_D_* -filter {direction==in}];
set_input_delay -clock Clk_ADC0 -max 3.4 [get_ports ADC0_D_* -filter {direction==in}] -clock_fall -add_delay;
set_input_delay -clock Clk_ADC0 -min 2.6 [get_ports ADC0_D_* -filter {direction==in}] -clock_fall -add_delay;

 

Max delay path is ok, but min delay is not ok (see attached report).

 

So I wonder - is it really the limit? Seems too small - only around 150 MHz. So the problems must be caused by incorrect timing constraints or architecture. Any suggestions are welcome.

 

Anton

 

--

Min Delay Paths
--------------------------------------------------------------------------------------
Slack (VIOLATED) :        -0.157ns  (arrival time - required time)
  Source:                 ADC0_D_p[4]
                            (input port clocked by Clk_ADC0  {rise@0.000ns fall@3.000ns period=6.000ns})
  Destination:            design_1_i/adc_mux_0/U0/adc_ddr_regs[4].adc_da_ddr_reg/D
                            (rising edge-triggered cell IDDR clocked by Clk_ADC0  {rise@0.000ns fall@3.000ns period=6.000ns})
  Path Group:             Clk_ADC0
  Path Type:              Hold (Min at Slow Process Corner)
  Requirement:            0.000ns  (Clk_ADC0 rise@0.000ns - Clk_ADC0 rise@0.000ns)
  Data Path Delay:        0.674ns  (logic 0.674ns (100.000%)  route 0.000ns (0.000%))
  Logic Levels:           1  (IBUFDS=1)
  Input Delay:            2.600ns
  Clock Path Skew:        3.259ns (DCD - SCD - CPR)
    Destination Clock Delay (DCD):    3.259ns
    Source Clock Delay      (SCD):    0.000ns
    Clock Pessimism Removal (CPR):    -0.000ns
  Clock Uncertainty:      0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock Clk_ADC0 rise edge)
                                                      0.000     0.000 r  
                         input delay                  2.600     2.600    
    N20                                               0.000     2.600 r  ADC0_D_p[4]
                         net (fo=0)                   0.000     2.600    design_1_i/adc_mux_0/ADC_D_p[4]
    N20                  IBUFDS (Prop_ibufds_I_O)     0.674     3.274 r  design_1_i/adc_mux_0/U0/adc_d_ibufs[4].adc_d_ibuf/O
                         net (fo=1, routed)           0.000     3.274    design_1_i/adc_mux_0/U0/D5_in
    ILOGIC_X0Y68         IDDR                                         r  design_1_i/adc_mux_0/U0/adc_ddr_regs[4].adc_da_ddr_reg/D
  -------------------------------------------------------------------    -------------------

                         (clock Clk_ADC0 rise edge)
                                                      0.000     0.000 r  
    R19                                               0.000     0.000 r  ADC0_DCO_p
                         net (fo=0)                   0.000     0.000    design_1_i/adc_mux_0/ADC_CLKOUT_p
    R19                  IBUFDS (Prop_ibufds_I_O)     0.752     0.752 r  design_1_i/adc_mux_0/U0/adc_clk_ibufg/O
                         net (fo=1, routed)           0.000     0.752    design_1_i/adc_mux_0/U0/IDATAIN
    IDELAY_X0Y76         IDELAYE2 (Prop_idelaye2_IDATAIN_DATAOUT)
                                                      0.666     1.418 r  design_1_i/adc_mux_0/U0/IDELAYE2_inst/DATAOUT
                         net (fo=2, routed)           0.362     1.780    design_1_i/adc_mux_0/U0/I
    BUFIO_X0Y6           BUFIO (Prop_bufio_I_O)       1.140     2.920 r  design_1_i/adc_mux_0/U0/BUFIO_inst/O
                         net (fo=7, routed)           0.339     3.259    design_1_i/adc_mux_0/U0/C
    ILOGIC_X0Y68                                                      r  design_1_i/adc_mux_0/U0/adc_ddr_regs[4].adc_da_ddr_reg/C
                         clock pessimism              0.000     3.259    
                         clock uncertainty            0.035     3.294    
    ILOGIC_X0Y68         IDDR (Hold_iddr_C_D)         0.137     3.431    design_1_i/adc_mux_0/U0/adc_ddr_regs[4].adc_da_ddr_reg
  -------------------------------------------------------------------
                         required time                         -3.431    
                         arrival time                           3.274    
  -------------------------------------------------------------------
                         slack                                 -0.157  

Tags (1)
adc_interface.jpg
0 Kudos
1 Solution

Accepted Solutions
Instructor
Instructor
12,257 Views
Registered: ‎08-14-2007

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Austin,

 The "fine print" I mentioned is at the bottom of the block diagram image in the first post.  It read "Variable delay.  It is set during calibration..."  However it is described better in the most recent post.

 

As for timing constraints, you should look at the structures involved in meeting these constraints.  Assuming the clock is using dedicated routing paths, the tools really have no way to affect input setup and hold timing.  That's because there is no general fabric routing involved in the connections you're trying to constrain.  Also the tools do not make changes to fixed IDELAY values or to MMCM or PLL output phases.  So basically your constraints are just there to see if the design meets timing as you specified it, not to allow the tools to force it to meet timing.  Again this is only checked for the starting IDELAY tap, so in a dynamically calibrated design it is not necessary and you could just as easily remove the associated constraints.  Vivado does much better on other timing when there are no failing constraints.

 

As for using the clocking structures instead of IDELAYE2, this is a matter of precision.  An MMCM can provide a variable output phase with hundreds of steps per clock cycle.  It is also fairly easy to use since the phase wraps when you continue to increment it, so you can actually scan the phase through two full clock periods to make it easier to find the longest data eye in the case where the eye spans the start of a clock period.  This would not require you to program the clock polarity of the ADC, so it further simplifies calibration.  On the other hand, if the current design works well with the IDELAYE2, then you can certainly stick with it.

-- Gabor

View solution in original post

10 Replies
Scholar austin
Scholar
6,678 Views
Registered: ‎02-27-2008

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Almost always this is an architecture problem,

 

Too many levels of logic with too few registers (not enough pipe-lining).  You may first try different implementation stategies (min area, min power, etc.).  Look online for meeting timing for yout device:  there are many tutorials on what to do.

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor antg0l
Visitor
6,655 Views
Registered: ‎01-31-2014

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Austin, I described the problem in details, it seems not about meeting timing requirments inside FPGA, it is about interface timing. I know about levels of logic, using additional pipe-linening and such things. There is no logic here, only FPGA primitives that are needed to receive lvds ddr signal. It is not possible to, e.g. set additional register between IBUFDS and IDELAYE2. If you think that the architecture is not optimal, could you please be more specific? The problem path is from the input port to IDDR as you can see.

 

0 Kudos
Instructor
Instructor
6,633 Views
Registered: ‎08-14-2007

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

In the small print under the IDELAYE2, it suggests you are dynamically varying the clock input delay in order to center the capture clock in the data valid window.  If this is the case, then the slack violation you see from the tools is not real, since the static timing analysis (STA) does not understand that the input delay will be changed to compensate for variations in timing.  If you meet the input timing specs during STA, it really means that your design should run even without dynamically varying the input delay.  For a design with a calibration loop to dynamically set the clock phase, it is not necessary to meet setup and hold times in STA.  Failing the input setup and hold checks only means that you definitely need the dynamic calibration in order to run reliably.

-- Gabor
0 Kudos
Scholar austin
Scholar
6,627 Views
Registered: ‎02-27-2008

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Gabor,

 

"Fine print?"  I see the count value for control, is that what gives this away as dynamically cenetering?

 

Just curious.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Scholar watari
Scholar
6,612 Views
Registered: ‎06-16-2013

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Hi antg0l

 

I mention to you about other way to resolve this issue.

 

Why do you use DLL to generate 1/4*T (shift clock phase and use shifted clock to capture DDR data) ?

This method is useful for like your situation.

And it is used to read access of DDRx SDRAM.

 

Thank you.

Best regards,

 

0 Kudos
Visitor antg0l
Visitor
6,600 Views
Registered: ‎01-31-2014

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Watari, I think, that IDELAYE2 does the same job as DLL here, but with more dynamical flexibility. Having Ref clock 200 MHz, IDELAYE2 can give delays from 78 ps to 2496 ps (so it includes 1/4*T) with 32 steps. And this delay can be loaded right during the work, which is what I do.

 

Actually at first I was not going to make a variable delay. I made IDELAYE2 with a fixed delay of 1/4T - I think, it is the same as using a phase delay in DLL. But the design was not stable from power-up to power-up (STA showed no errors). Most of the times the interface worked fine, but sometimes after power-up it seemed that rising-edge and falling-edge data were switched (or, which is much worse, instead of data_i lsb and data_i msb I got data_i msb and data_i+1 lsb, I can draw a picture if it is not clear), so the data from ADC was all wrong. I could not find the reason for that behavior, so I came with the only solution to make a calibration.

 

The calibration procedure takes place each time after power up.The ADC is set into a state, when it generates known pn sequence ignoring input analog data. Then we try to receive this sequence 64 times - for each of 32 steps of variable delay in IDELAYE * 2 (2 is because we can ask ADC to invert its output clock, it is set via SPI register, so I check with normal and inverted clock) and I make an array of result (correct or incorrect). Then I find the middle of the longest correct segment and proceed with its settings (e.g. ADC_CLKOCK - inverted, IDELAYE2 step = 17). ADC is set to normal mode, the calibration is over.

 

It may seem a bit complicated, but it works.

 

Anyway. Going back to my question.


@gszakacs wrote:
For a design with a calibration loop to dynamically set the clock phase, it is not necessary to meet setup and hold times in STA.


So, what constraints should I use in my case? Maybe I can loosen them somehow (how?) so that the tool does not try so hard to meet them? And when implementation finishes each time with "timing failed!" it does not seem ok. I can delete all set_input_delay on ADC data but is it a good way to do?

0 Kudos
Instructor
Instructor
12,258 Views
Registered: ‎08-14-2007

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Austin,

 The "fine print" I mentioned is at the bottom of the block diagram image in the first post.  It read "Variable delay.  It is set during calibration..."  However it is described better in the most recent post.

 

As for timing constraints, you should look at the structures involved in meeting these constraints.  Assuming the clock is using dedicated routing paths, the tools really have no way to affect input setup and hold timing.  That's because there is no general fabric routing involved in the connections you're trying to constrain.  Also the tools do not make changes to fixed IDELAY values or to MMCM or PLL output phases.  So basically your constraints are just there to see if the design meets timing as you specified it, not to allow the tools to force it to meet timing.  Again this is only checked for the starting IDELAY tap, so in a dynamically calibrated design it is not necessary and you could just as easily remove the associated constraints.  Vivado does much better on other timing when there are no failing constraints.

 

As for using the clocking structures instead of IDELAYE2, this is a matter of precision.  An MMCM can provide a variable output phase with hundreds of steps per clock cycle.  It is also fairly easy to use since the phase wraps when you continue to increment it, so you can actually scan the phase through two full clock periods to make it easier to find the longest data eye in the case where the eye spans the start of a clock period.  This would not require you to program the clock polarity of the ADC, so it further simplifies calibration.  On the other hand, if the current design works well with the IDELAYE2, then you can certainly stick with it.

-- Gabor

View solution in original post

Scholar austin
Scholar
6,582 Views
Registered: ‎02-27-2008

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Thank you,

 

Austin

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Scholar watari
Scholar
6,571 Views
Registered: ‎06-16-2013

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

Hi antg01

 

I almost agree your explanation.

But I think that you use DLL or PLL to generate a phase delay as 1/4T (not TAP delay like use IDELAY).

I suspect that IDELAY rarely malfunctions.

If you accept my solution, DLL or PLL generates a correct phase delay which is base on rising edge of input clock.

Especially, if you choose PLL, PLL tracks rising edge of input clock and PLL generate correct phase delay.

 

It means that (I think) the purpose of IDELAY is only for additional delay by delay TAP, not  generate correct phase delay like 1/4T.

Because of the base clock of IDELAY is not related with input clock.

 

So, could you change the architecture from your idea to use DLL/PLL idea ?

 

Thank you.

Best regards,

 

Visitor antg0l
Visitor
4,491 Views
Registered: ‎01-31-2014

Re: Pls check my timing constraints for source-sync ddr

Jump to solution

gszakacs, thanks for your answer, I think I will remove constraints on ADC DATA. Using MMCM for dynamical phase correction is a good option, I will keep it in mind.