Is there a bug for timings w/o DCM in Virtex-5 Datasheet?

[gothard]

Hello.

My partner was wandering about some timing things and we've discovered smth interesting.

To point my finger onto spot i'll give example:

- In table 91 "Global Clock Setup and Hold Without DCM or PLL" of DS202 (DC and Switching Virtex-5 Datasheet) specified that for XC5VSX50T-1 Setup/Holds are 1.93/-0.31

- In table 92 "Global Clock Setup and Hold With DCM in System-Synchronous Mode" of same datasheet specified that for XC5VSX50T-1 Setup/Holds are 1.95/-0.37

 well... not much difference which is very suspucious since DCM is used only in second case (specialy suspicious taking into account specs of previous generations of Virtex)... ok going further

We've made a "probe" project and checked timings without and with DCM (in both cases pads were on same places and also I've checked that everything were made right via FpgaEditor after PAR).

Timings reports (Analyzing after PAR against autogenerated constraints) showing that:

- without DCM setup/hold times were 3.043/-0.342 (which seems more close to real-life than data from table 91)

- with DCM in use setup/hold times were 1.932/-0.433 which is almost same as specified in datasheet in table 92

It seems that there is VERY BIG BUG in table 91 of DS202. Please - check this out ASAP.

P.S. I've got fresh version of datasheet.

P.P.S: conditions for "probe" project were same as specified in tables 91-92. e.g. LVCMOS25, data captured into IFF. I've double cheked this via FpgaEditor.

[gothard]

P.P.S.:

Version of ISE is 10.1 with SP3

[jprovidenza]

Note that there are actually 2 differences between tables 91 and 92 in the data sheet:

  DCM on/off

  iff delay on/off

So, when you look at the actual timing results produced by the tools, check that the

iff input  delay settings are the same for the signals you are comparing.

John Providenza

[gothard]

> Note that there are actually 2 differences between tables 91 and 92 in the data sheet:

>   DCM on/off

>   iff delay on/off

Yeah, thanks, for a note.

But things getting more interesting now :)

I've chceked for delay in probe designs:

- IOBDelay on input FF is activated automaticly (turned on if DCM is not used / turned off if DCM is in use) which is logicaly correct

- IOBDelay on clock input path is always turned off.

Since text "Full Delay (Legacy Delay or Default Delay) Global Clock and IFF without DCM or PLL" is ambigous - just for experiment I've forced Default Delay on clock input path for that case (adding "NET clk IOBDELAY = IBUF;" in UCF file)

NOTE: But actualy it's incorrect since Default IOBDelay is intended to compensate clock path delay and allow zero hold times - meaning that IOBDelay should't be used in clock path.

What we got now:

- FPGAEditor shows that there is Defalut IDelay before IFF and IBUFG (ok - we wanted this)

- Timing analyzer gives following setup/hold times: -0.774/2.681. That's not what we want but he is right - 'cause we just added delay into clock path.

Difference from datasheet is bigger than it was before (w/o default delay in clock path).

You could also note another BUG here (about which I wrote before but didn't get answer):

- w/o delay in clock path required "window" for data was 2.701ns

- with delay required "window" for data is 1.907ns

("Window" is absolute of [Setup-Hold])

That's impossible, since introducing delay into any path should increase uncertainity and required window should grow, but we are observing opposite.

For XILINX: please comment this, since it's realy serious.

[ywu]

Please take a look at this AR (http://www.xilinx.com/support/answers/19257.htm) and see if it clears things.

Cheers,

Jim

[gothard]

Thanx, but I've already had those things (described in AR) in mind.

As I wrote above - I've checked (using FPGA editor) that all conditions in probe projects coresponds to those in datasheet but still after implementation setup/hold timings FOR CASE w/o DCM are much worser than in datasheet (actualy SETUP time is around 3ns instead of 2ns).

First thing I can't understand - why timings in Datahseet for case W/O DCM and for system-synchronous case WITH DCM are SO CLOSE? (for XC5VSX50T-1we are looking at -  there is 20ps differnece for setup and 60ps difference for hold. required "window" width difference is only 40ps).

Well - that could be if a skew in clk path for border condtions (low temperature, high voltage, good crystall/process, light load  vs  high temp, low voltage, weak crystall/process) nearly equal to [jitter+phase error] of DCM. Is that so? For previous families setup times were significantly different for cases with and w/o DCM - for example difference is around 400ps for Virtex II.

Ok then. If data in datasheet is correct, then how to achive correct timings?

Probe project we used to check is simple - just ibufg-bufg in clock path, and chain of IFD-FD-OFD for data path. FPGA editor checks shows that all required conditions are met (e.g. IOB Delay used, IFF placed in correctly, clock route is sane).

I could send you ngc/ngd file to check it.

[gothard]

P.S.:

Also could you check second bug I wrote about in my third post on that thread.

(e.g. introducing input delay into clock path shortened required data "window" on IFF by 800ps which is ridiculous)

Message Edited by gothard on 04-29-2009 11:55 PM