cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
r1128689
Visitor
Visitor
1,368 Views
Registered: ‎07-10-2018

IDELAYE2

Jump to solution

I found out from simulation that IDELAYE2 has a data delay (from IDATAIN to DATAOUT) of 600ps when CNTVALUEOUT = 0 (i.e. tap = 0).  Is the 600ps delay min/nom/max?

0 Kudos
Reply
1 Solution

Accepted Solutions
avrumw
Guide
Guide
1,461 Views
Registered: ‎01-23-2009

Is the 600ps delay min/nom/max?

 

Neither...

 

The IDELAYE2 simulation model is a strange thing. It is intended to be used for RTL simulations, but in RTL simulations, the simulation is really "cycle accurate" not "time accurate" - no other cells (or statements) in your RTL attempt to model intra-clock time; LUTs take 0ns, flip-flops clock->q take 0ns, etc....

 

But the IDELAY is a cell specifically for inserting delay. So if you don't model intra-clock delay in the IDELAY model, the IDELAY model becomes nothing other than an assign statement.

 

So for this cell (and the MMCMs for different reasons), the RTL simulation model has to include some model of intra-cycle time - specifically, there needs to be a model for the delay increasing by TAP_DELAY for each tap used.

 

But the delay through the IDELAY is not just the TAP_DELAYs, there is also a real PVT variable (i.e. normal cell) delay. I guess the Xilinx designers didn't think it made sense to model the tap delay while intentionally ignoring the cell delay - so they put in this 600ps cell delay.

 

But its just a number. It happens to be in roughly the right ball park, but it is not intended to be an "accurate" representation of any specific device (and it varies a bit from family to family) nor any specific PVT point - its just a number.

 

The real timing, both for the cell delay and the tap delay portion of the IDELAY is only given during static timing analysis (STA). During STA, analysis is done at multiple timing corners and the "real" value for both components (cell and tap) are summed together at the appropriate PVT corner required for the analysis being done (setup vs. hold, fast process corner vs. slow process corner, source clock/data path delay vs. destination clock delay...)

 

Avrum

View solution in original post

1 Reply
avrumw
Guide
Guide
1,462 Views
Registered: ‎01-23-2009

Is the 600ps delay min/nom/max?

 

Neither...

 

The IDELAYE2 simulation model is a strange thing. It is intended to be used for RTL simulations, but in RTL simulations, the simulation is really "cycle accurate" not "time accurate" - no other cells (or statements) in your RTL attempt to model intra-clock time; LUTs take 0ns, flip-flops clock->q take 0ns, etc....

 

But the IDELAY is a cell specifically for inserting delay. So if you don't model intra-clock delay in the IDELAY model, the IDELAY model becomes nothing other than an assign statement.

 

So for this cell (and the MMCMs for different reasons), the RTL simulation model has to include some model of intra-cycle time - specifically, there needs to be a model for the delay increasing by TAP_DELAY for each tap used.

 

But the delay through the IDELAY is not just the TAP_DELAYs, there is also a real PVT variable (i.e. normal cell) delay. I guess the Xilinx designers didn't think it made sense to model the tap delay while intentionally ignoring the cell delay - so they put in this 600ps cell delay.

 

But its just a number. It happens to be in roughly the right ball park, but it is not intended to be an "accurate" representation of any specific device (and it varies a bit from family to family) nor any specific PVT point - its just a number.

 

The real timing, both for the cell delay and the tap delay portion of the IDELAY is only given during static timing analysis (STA). During STA, analysis is done at multiple timing corners and the "real" value for both components (cell and tap) are summed together at the appropriate PVT corner required for the analysis being done (setup vs. hold, fast process corner vs. slow process corner, source clock/data path delay vs. destination clock delay...)

 

Avrum

View solution in original post