Subject: RE: [IBIS] Time scale for VT plots on IBIS model.
From: Jeremy Plunkett (jeremy@serverworks.com)
Date: Wed Nov 20 2002 - 21:21:24 PST
Thanks for the info Lynne, I hadn't delved into version 4 yet but I am glad to know that this issue was fixed.
I have to respectfully disagree with Tom. It is my preference that SI tools use the VT curves as provided in the IBIS model, so that rising/falling relationships and absolute delay time are maintained. Some tools do this, which was the basis for my recommendation to Gerd. Other tools remove leading "blank space" in the interest of avoiding the "overlapping Vt curves" issue that Hspice is subject to. Some tools, such as a version of XTK that I tested a while ago, will strip leading "blank space" on rising and falling waveforms _independently_, such that the relative rise/fall delays of the buffer are not preserved and the duty cycle is distorted when the model is used. This is probably a minor effect at low frequencies where the rising/falling edge skew is small compared to the cycle time, but at "high" frequencies (in this context, busses where the bit cell width is less than 3-5ns) this is a serious issue since the duty cycle can affect many other measurements of the bus besides timing.
One possible workaround to this issue is to modify the Vt curves so that both rising and falling edges begin transitioning immediately at the beginning of the Vt curve. This sacrifices some accuracy in the curves (typically some of the "preshoot" is cut off), but guarantees that SI tools won't find any leading blank space to remove.
As long as
1) all time shifts of the VT curves use the same adjustment value for all curves of each process corner, and
2) total length of the VT curves remains less than the minimum time between transitions when the model is used,
I cannot think of a case where shifting the curves will result in innaccurate sim results. The only way this would be possible is if the model is used _without_ T2vm compensation, such that the delay in the IBIS model was treated as the actual buffer delay. Since this cannot be assumed for most IBIS models, and wouldn't match the specs even for models that did represent the true delay of the original spice netlist, there is no downside to removing this information and/or substituting relative delays that are more convenient to the model user.
regards,
Jeremy
-----Original Message-----
From: Lynne Green [mailto:lgreen@cadence.com]
Sent: Wednesday, November 20, 2002 10:24 AM
To: Jeremy Plunkett
Cc: ibis@eda.org
Subject: RE: [IBIS] Time scale for VT plots on IBIS model.
Jeremy,
The V-t "timing" issue was addressed in BIRD 68 and were incorporated in
IBIS 4.0. The
ability to use VMEAS corners is also included in IBIS 4.0:
| Examples from the IBIS 4.0 specification:
Vmeas 3.68 3.18 4.68 | A 5 volt PECL
Vmeas_rising 0.941 0.885 1.026 | vmeas =
0.285(vcc)
Vmeas_falling 2.0295 1.845 2.214 | vmeas =
0.615(vcc)
Buffer delay tables should "start" when the signal from the chip core to
the buffer toggles.
Tom Dagostino pointed out to me that any other "time" adjustment to the
V-t tables is at
best a waste of time, and at worst could produce inaccurate simulation
results in some SI
tools. (Thanks, Tom!)
Best regards,
Lynne
-----Original Message-----
From: Jeremy Plunkett [mailto:jeremy@serverworks.com]
Sent: Tuesday, November 19, 2002 11:40 PM
To: Lynne Green; Baumann, Hans-Gerhard; Beal, Weston; Muranyi, Arpad;
Ingraham, Andrew; Hazem Hegazy; Robert Haller
Cc: ibis@eda.org
Subject: RE: [IBIS] Time scale for VT plots on IBIS model.
Lynne,
That's an important correction, thanks for catching that. What you want
to do is set the relative delay of the TYP/MIN/MAX cases so that when
each case is driven into the reference load, the crossing of the timing
measurement threshold happens at the same time. There wouldn't be any
benefit to matching up the actual VT curves, except in the specific case
where the reference load is the same as the R_fixture/V_fixture used for
the VT curves. I was assuming 50% VDD for VMEAS based on Gerd's mail
below, but if that is not the case then the actual VMEAS should be used.
This brings up the issue that in order to get a VMEAS at 1/2VDD for
TYP/MIN/MAX cases extracted at different VDD values, you need to either:
a) use a [Model Spec] statement to specify the VMEAS value corresponding
to each VDD value, or
b) split the model into 3 models, with each one containing only one
corner case (or multiple corner cases all extracted at the same VDD
value). The VT curve adjustment I suggested is actually a handy
work-around to this oversight in the original IBIS spec, since if the
model users' SI tool doesn't recognize the [Model Spec] statement
(Hspice doesn't, although most other tools probably do by now), you are
saving the user from having to do a lengthy process of manually setting
up the T2VM testcases that would be required in order to use the correct
VMEAS value.
Since some SI tools strip leading "blank space" out of the VT curves
when converting IBIS models to their proprietary formats, users of those
tools will not be able to benefit from your thoughtfullness, but those
tools typically do all the work of T2VM adjustment for them anyway.
However, they may or may not use the [Model Spec] values, which is why
in cases like this I wouldn't include a VMEAS in the model except for
the 3 values in the [Model Spec] definition.
Regarding your question below about whether the delays in the VT tables
accurately represent the buffer delays; by default they will represent
the same delays as the spice model unless the model maker edits them
deliberately. However, they typically will not match the specs for the
part because there are other timing factors in the logic that add (or
subtract) from the circuit delays that are included in the IO buffer
model.
regards,
Jeremy
-----Original Message-----
From: owner-ibis@server.eda.org [mailto:owner-ibis@server.eda.org]On
Behalf Of Lynne Green
Sent: Friday, November 15, 2002 9:55 AM
To: Jeremy Plunkett; Baumann, Hans-Gerhard; Beal, Weston; Muranyi,
Arpad; Ingraham, Andrew; Hazem Hegazy; Robert Haller
Cc: ibis@server.eda.org
Subject: RE: [IBIS] Time scale for VT plots on IBIS model.
Interesting thread here.
In reply to previously posted thoughts:
Shouldn't one match the V-t waveforms at VMEAS, since this is the point
used for Time-to-Vm?
Different SI tools consider the time ahead of the transition
differently, since this is not specified in the IBIS specification. Some
consider the entire time from Time=0 to Time@VMEAS to be part of the
internal buffer delay, while others consider only the time after the
first V-t table point. In either case, adding an arbitrary lead-in time
ahead of the V-t transition to the V-t tables is likely to introduce
unexpected simulation artifacts.
Related questions:
In the V-t tables, does waveform alignment fully account for different
internal buffer delays at the different corners? Why don't more model
makers do this?
Best regards,
Lynne
-----Original Message-----
From: Jeremy Plunkett [mailto:jeremy@serverworks.com]
Sent: Friday, November 15, 2002 2:15 AM
To: Baumann, Hans-Gerhard; 'Beal, Weston'; 'Muranyi, Arpad'; 'Ingraham,
Andrew'; 'Hazem Hegazy'; 'Robert Haller'
Cc: ibis@eda.org
Subject: RE: [IBIS] Time scale for VT plots on IBIS model.
Gerd,
you might want to consider adjusting the Vt curve lead-in times so that
the 50% points of the TYP/MIN/MAX waveforms all occur at the same time.
This way users of the model will only need to do a single Time-to-Vm
compensation when using the model, rather than 3 (as long as their tool
recreates the Vt curves without modifying the delays). You could make
the delay a convenient value such as 1ns and make a note of it in the
model header information.
If you simply modify the Vt curves to have the shortest possible
lead-in, there is a potential for some users to attach significance to
the actual delay time in the IBIS model and not do any T2vm calibration.
Also, the "large" lead-in time in the normal buffer mode is OK as long
as the total duration of the Vt curve including lead-in delay is still
smaller than the minimum time between transitions when the model is used
(ie, Vt curve duration should be < 1/2 the period at the highest
frequency of operation, or smaller if you want to use other than a 50/50
duty cycle). This is a requirement for some simulators (ok, Hspice is
the only one I know of) to use the model without errors. The error is
that transitions after the 1st one in the simulation will have shifted
timing and possibly waveform errors as well (depends on details of the
Vt curve).
regards,
Jeremy
|>--/\/\/--((((((((()--|>
Jeremy Plunkett
Signal Integrity Engineer
Broadcom Corp.
www.serverworks.com
|>--/\/\/--((((((((()--|>
-----Original Message-----
From: owner-ibis@server.eda.org [mailto:owner-ibis@server.eda.org]On
Behalf Of Baumann, Hans-Gerhard
Sent: Friday, November 15, 2002 1:10 AM
To: 'Beal, Weston'; 'Muranyi, Arpad'; 'Ingraham, Andrew'; 'Hazem
Hegazy'; 'Robert Haller'
Cc: ibis@server.eda.org
Subject: RE: [IBIS] Time scale for VT plots on IBIS model.
All,
thanks for your helpful hints and recommendations to this subject.
My conclusion is not to use a negative delay.
Actually I came to this subject as I generated the IBIS model for a new
part which features to have a normal buffer (delay 2-4ns) or zero delay
buffer
(PLL) in its signal path. The zero delay in the PLL-mode of course only
looks like 0ns delay, but it behaves like this once the PLL is locked.
As I completed the VT-tables for the buffer (2-4ns delay on
WEAK,NOM,STRONG
columns) with its relation on time scale (strong model transition is
before weak model transition), I thought about how to setup the
VT-tables if the device works in the PLL-mode. Actually the process and
the VDD dependency for a zero delay buffer (PLL-mode) is significant
lower and I concluded to remove the time shift as it is shown for the
real buffer mode.
Next step was how to set the starting point for the transition, very
simple for the real buffer. 50% of swing at the output represents the
propagation delay (50% at input is set to 0ns). To set a 50% point at
the output to 0ns for the PLL mode buffer would require a start <0ns to
print the whole transition. That was my trigger to get your
recommendation.
I do not care too much about the "large" lead-in time (normal buffer),
since I think that most of all IBIS simulators provide the option to
strip (or
keep) non-switching time from the VT-tables if the delay of a buffer is
not of any interest.
Finally I set the delay for the PLL to the shortest value possible to
keep
>0ns. As I run the model I noticed of course that WEAK/STRONG variance
>in
delay still is larger than the PLL actually would have, but in fact that
is something what can not be modeled in IBIS at all. It is a result of
the function of the internal feedback, which compensates for process,
VDD and load. So the setting for the initial delay finally gets less
important too.
Thanks and Best Regards,
Gerd Baumann
------------------------------------------------------------------------
--- EUROPEAN HPA PRODUCT ENGINEERING Texas Instruments, Haggertystr. 1, D-85356 Freising, Germany E-mail: HGBaumann@ti.com Phone: +49 8161 804341 Fax: +49 8161 804909 ------------------------------------------------------------------------ --- ----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.org with the |appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or email a request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.org with the |appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or email a request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.org with the |appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or email a request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993
----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or email a request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Wed Nov 20 2002 - 21:30:28 PST