RE: [SI-LIST] : Looking Inside IBIS Model

=?big5?B?VGluZywgU3RldmUgKKRCvW69ZCk=?= (TING.STEVE@inventec.com.tw)
Tue, 18 May 1999 09:32:36 +0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA0CE.55952F20
Content-Type: text/plain;
charset="big5"

Dear SI-List,
I'm sorry I sent something that most of you cannot read, here I post it
again (and made some modification)
with pure text format:

Abe,
I agree with you.
I believe that the test loading value specified in IBIS should be
consistent with datasheet.
If we can get Tco [clock to output] from driver's spec and Tsetup
(Thold) [setup time, hold time]
from receiver's spec ( and with clock's info. available), we can
determine the max. and min.
flight time for the data.

To determine the max. flight time (assume zero skew, jitter), I'll use
the formula:
Tflight_max = Tcycle - Tco_max -Tsetup
And to determine the min. flight time, I'll use:
Tflight_min = Thold - Tco_min

And in my opinion, I think the Tco can be decomposed as IC internal
delay plus
TIME_TO_VM, which depends on loading outside the driver. To avoid double
subtraction with the
TIME_TO_VM on the right side of above formula, the flight time obtained
from simulation (IDD file
generated by Quad's tool with VM correction DISABLED) should be
corrected by subtracting the TIME_TO_VM.

In many cases, where the TIME_TO_VM will be different for rising and
falling.
And sometimes, the asymmetry between rising and falling will be quite
significant, that will result in
some persecution. Because we'll have only one Tco in the spec.

For example, I have:
one driver A with Tco =2.5nS
one receiver B with Tsetup=2nS
running speed is 133MHz (Tcycle=7.5 nS).
TIME_TO_VM for the driver is 0.8nS on rising and 1.8nS on falling (1 nS
difference!).
According to above formula Tflight_max =7.5 - 2.5 - 2 = 3nS

What if my simulation result reports the Tflight_rise (rising) = 3.1nS
and Tflight_fall (falling) = 2.7nS for
some signal from layout database? (Not caused by ringback!)

It happened because the real loading in actual application won't
necessarily be the same as the test loading
used in datasheet. But how should I deal with it? If it is true that
there exist such asymmetry between rising and falling,

why doesn't the vendor privide more info on Tco?

Any comments will also be highly appreciated!

With best regards,

Steve Ting
EDA/CAE Engineer
INVENTEC CORPORATION

-----Original Message-----
From: Beal, Weston [ mailto:Weston.Beal@compaq.com
<mailto:Weston.Beal@compaq.com> ]
Sent: Monday, May 17, 1999 10:03 PM
To: 'si-list@silab.eng.sun.com'
Subject: RE: [SI-LIST] : Looking Inside IBIS Model

Dear IBIS people,

This message got cut off before it reached me. Did anyone get the whole

thing?

Anyway, I think a correction is important here. Steve wrote, "To avoid
double subtraction with the TIME_TO_VM on the right side of above
formula,
the flight time obtained from simulation (IDD file generated by Quad's
tool)
should be corrected by subtracting the TIME_TO_VM." BE CAREFUL with
this!
The TIME_TO_VM parameter should be included in the driver model and XNS
subtracts TIME_TO_VM from the simulated flight time by default. The
time
given in the IDD file is the corrected time that you should use in your
timing margin calculation. It is important to understand what you
actually
simulated and and calculated. The automatic TIME_TO_VM correction can
be
disabled or the TIME_TO_VM parameter might be missing from the model.
Check
these details! The difference between an ameteur and a professional is
in
the details.

Regards,
Weston Beal

-----Original Message-----
From: TING.STEVE@inventec.com.tw [ mailto:TING.STEVE@inventec.com.tw
<mailto:TING.STEVE@inventec.com.tw> ]
Sent: Monday, 17 May, 1999 6:07 AM
To: 'si-list@silab.eng.sun.com'
Subject: RE: [SI-LIST] : Looking Inside IBIS Model

Abe,
I agree with you.
I believe that t test loading value specified in IBIS should be
consistent
with datasheet.
If we can get Tco [clock to output] from driver's spec and Tsetup
(Thold)
[setup time, hold time]
from receiver's spec ( and with clock's info. available), we can
determine
the max. and min.
flight time for the data.

To determine the max. flight time (assume zero skew, jitter),
I'll
use the formula:
Tflight_max = Tcycle - Tco_max -Tsetup
And to determine the min. flight time, I'll use:
Tflight_min = Thold - Tco_min

And in my opinion, I think the Tco can be decomposed as IC
internal
delay plus
TIME_TO_VM, which depends on loading outside the driver. To avoid double

subtraction with the
TIME_TO_VM on the right side of above formula, the flight time obtained
from
simulation (IDD file
generated by Quad's tool) should be corrected by subtracting the
TIME_TO_VM.

In many cases, where the TIME_TO_VM will be different for rising
and
falling.
And sometimes, the asymmetry between rising and falling will be quite
significant, that will result in
some persecution. Because we'll have only one Tco in the spec.

For example, I have
one driver A with Tco =2.5nS
one receiver B with Tsetup=2nS
running speed is 133MHz (Tcycle=7.5 nS).
TIME_TO_VM for the driver is 0.8nS on rising and 1.8nS on falling.
According to above formula Tflight_max =7.5 - 2.5 - 2 = 3nS
What if my simulation result reports the Tflight_rise (rising) = 3.2nS
and
Tflight_fall (falling) = 2.8nS for

**** To unsubscribe from si-list: send e-mail to
majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE
si-list, for more help, put HELP. si-list archives are accessible at
http://www.qsl.net/wb6tpu/si-list <http://www.qsl.net/wb6tpu/si-list>
****

------_=_NextPart_001_01BEA0CE.55952F20
Content-Type: text/html;
charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: [SI-LIST] : Looking Inside IBIS Model

Dear SI-List,
I'm sorry I sent something that most of you cannot = read, here I post it again (and made some modification)
with pure text format:

Abe,
I agree with you.
I believe that the test loading value specified in = IBIS should be consistent with datasheet.
If we can get Tco [clock to output] from driver's = spec and Tsetup (Thold) [setup time, hold time]
from receiver's spec ( and with clock's info. = available), we can determine the max. and min.
flight time for the data.

To determine the max. flight time (assume zero skew, = jitter), I'll use the formula:
Tflight_max =3D Tcycle - Tco_max -Tsetup
And to determine the min. flight time, I'll use: =
Tflight_min =3D Thold - Tco_min

And in my opinion, I think the Tco can be decomposed = as IC internal delay plus
TIME_TO_VM, which depends on loading outside the = driver. To avoid double subtraction with the
TIME_TO_VM on the right side of above formula, the = flight time obtained from simulation (IDD file
generated by Quad's tool with VM correction = DISABLED) should be corrected by subtracting the TIME_TO_VM.

In many cases, where the TIME_TO_VM will be different = for rising and falling.
And sometimes, the asymmetry between rising and = falling will be quite significant, that will result in
some persecution. Because we'll have only one Tco in = the spec.

For example, I have:
one driver A with Tco =3D2.5nS
one receiver B with Tsetup=3D2nS
running speed is 133MHz (Tcycle=3D7.5 nS).
TIME_TO_VM for the driver is 0.8nS on rising and = 1.8nS on falling (1 nS difference!).
According to above formula Tflight_max =3D7.5 - 2.5 = - 2 =3D 3nS

What if my simulation result reports the Tflight_rise = (rising) =3D 3.1nS and Tflight_fall (falling) =3D 2.7nS for
some signal from layout database? (Not caused by = ringback!)

It happened because the real loading in actual = application won't necessarily be the same as the test loading
used in datasheet. But how should I deal with it? If = it is true that there exist such asymmetry between rising and = falling,

why  doesn't the vendor privide more info on = Tco?

Any comments will also be highly appreciated!

With best regards,

Steve Ting
EDA/CAE Engineer
INVENTEC CORPORATION




-----Original Message-----
From: Beal, Weston [mailto:Weston.Beal@compaq.com= ]
Sent: Monday, May 17, 1999 10:03 PM
To: 'si-list@silab.eng.sun.com'
Subject: RE: [SI-LIST] : Looking Inside IBIS = Model


Dear IBIS people,
 
This message got cut off before it reached me.  = Did anyone get the whole
thing?
 
Anyway, I think a correction is important = here.  Steve wrote, "To avoid
double subtraction with the TIME_TO_VM on the right = side of above formula,
the flight time obtained from simulation (IDD file = generated by Quad's tool)
should be corrected by subtracting the = TIME_TO_VM."  BE CAREFUL with this!
The TIME_TO_VM parameter should be included in the = driver model and XNS
subtracts TIME_TO_VM from the simulated flight time = by default.  The time
given in the IDD file is the corrected time that you = should use in your
timing margin calculation.  It is important to = understand what you actually
simulated and and calculated.  The automatic = TIME_TO_VM correction can be
disabled or the TIME_TO_VM parameter might be = missing from the model.  Check
these details!  The difference between an = ameteur and a professional is in
the details.
 
Regards,
Weston Beal
 

-----Original Message-----
From: TING.STEVE@inventec.com.tw [mailto:TING.STEVE@inventec.co= m.tw]
Sent: Monday, 17 May, 1999 6:07 AM
To: 'si-list@silab.eng.sun.com'
Subject: RE: [SI-LIST] : Looking Inside IBIS = Model



        Abe, =
I agree with you.
I believe that t test loading value specified in = IBIS should be consistent
with datasheet.
If we can get Tco [clock to output] from driver's = spec and Tsetup (Thold)
[setup time, hold time]
from receiver's spec ( and with clock's info. = available), we can determine
the max. and min.
flight time for the data.

        To = determine the max. flight time (assume zero skew, jitter), I'll
use the formula:
Tflight_max =3D Tcycle - Tco_max -Tsetup
And to determine the min. flight time, I'll use: =
Tflight_min =3D Thold - Tco_min

        And in my = opinion, I think the Tco can be decomposed as IC internal
delay plus
TIME_TO_VM, which depends on loading outside the = driver. To avoid double
subtraction with the
TIME_TO_VM on the right side of above formula, the = flight time obtained from
simulation (IDD file
generated by Quad's tool) should be corrected by = subtracting the TIME_TO_VM.


        In many = cases, where the TIME_TO_VM will be different for rising and
falling.
And sometimes, the asymmetry between rising and = falling will be quite
significant, that will result in
some persecution. Because we'll have only one Tco in = the spec.

        For = example, I have
one driver A with Tco =3D2.5nS
one receiver B with Tsetup=3D2nS
running speed is 133MHz (Tcycle=3D7.5 nS).
TIME_TO_VM for the driver is 0.8nS on rising and = 1.8nS on falling.
According to above formula Tflight_max =3D7.5 - 2.5 = - 2 =3D 3nS
What if my simulation result reports the = Tflight_rise (rising) =3D 3.2nS and
Tflight_fall (falling) =3D 2.8nS for



**** To unsubscribe from si-list: send e-mail to = majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE = si-list, for more help, put HELP.  si-list archives are accessible = at http://www.qsl.net/wb6tpu/si-list ****

------_=_NextPart_001_01BEA0CE.55952F20--

**** To unsubscribe from si-list: send e-mail to majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****