------_=_NextPart_001_01BEA1CC.4DE43C9A
Content-Type: text/plain;
charset="big5"
Weston,
Thank you for your comment.
In my example, I try to express the idea:
The Tco_max was 2.5nS in my example, which was based on the same test
loading used to generate TIME_TO_VM.
And after Quad's mtest's calculation, I'll have TWO different values for
TIME_TO_VM: 0.8nS for rising and 1.8nS for falling.
I'll then think that the Tco_max must came from falling and the real Tco
for rising should be smaller than 2.5nS, maybe
around 1.5nS (I guess, because 1nS difference on TIME_TO_VM).
Then If I can have longer allowable flight time about 4nS
(7.5-1.5-2.0=4.0) purely for rising.
If it is true, the Tflight_rise of 3.1nS(<4.0nS) won't break my timing!
Am I totally wrong?
By the way, I assume zero skew and jitter in my formula just for
simplication, I didn't mean I can really do that in practical.
And I won't do the TIME_TO_VM correction manually in my simulation, I'll
enable the VM correction function in Quad if I have
reliable TIME_TO_VM values in XTK models.
RGS,
Steve Ting
-----Original Message-----
From: Beal, Weston [ mailto:[email protected]
<mailto:[email protected]> ]
Sent: Wednesday, May 19, 1999 12:21 AM
To: '[email protected]'
Subject: RE: [SI-LIST] : Looking Inside IBIS Model
Steve,
Almost all the datasheets I've seen provide minimum and maximum times
for
Tco. These should include all cases including rising and falling
waveforms.
I agree that TIME_TO_VM can be significantly differenct for rising and
falling edges. That's why the TIME_TO_VM parameter in the QUAD model
has
two different numbers for rising and falling. If you will calculate the
two
TIME_TO_VM parameters (or let mtest do it), put the TIME_TO_VM in the
QUAD
driver model, and enable VM correction in XNS, all your time deratings
will
come out correct.
On the other hand, as I stated in a previous email, the timing test load
should be placed at the pin. Including the TIME_TO_VM parameter in the
model with mtest puts the timing test load at the die. To be more
correct,
you might want to calculate TIME_TO_VM (rising and falling) to the pin
and
do your manual subtraction with the rising and falling cases seperately.
In your example, if 2.5ns is the Tco_max then your Tflight either rising
or
falling is 3.0ns and 3.1ns breaks your timing.
Regards,
Weston Beal
-----Original Message-----
From: [email protected] < mailto:[email protected]
<mailto:[email protected]> >
[ mailto:[email protected] <mailto:[email protected]>
]
<mailto:[ mailto:[email protected]
<mailto:[email protected]> ]>
Sent: Monday, 17 May, 1999 8:33 PM
To: '[email protected]'
Subject: 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 = Tcycle - Tco_max -Tsetup
And to determine the min. flight ti
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:[email protected]
<mailto:[email protected]>
< mailto:[email protected] <mailto:[email protected]> >
< mailto:[email protected] <mailto:[email protected]>
< mailto:[email protected] <mailto:[email protected]> > > ]
Sent: Monday, May 17, 1999 10:03 PM
To: '[email protected]'
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: [email protected] < mailto:[email protected]
<mailto:[email protected]> > [
mailto:[email protected] <mailto:[email protected]> <
mailto:[email protected] <mailto:[email protected]> >
< mailto:[email protected]
<mailto:[email protected]>
< mailto:[email protected] <mailto:[email protected]>
> > ]
Sent: Monday, 17 May, 1999 6:07 AM
To: '[email protected]'
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
**** To unsubscribe from si-list: send e-mail to
[email protected]. 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_01BEA1CC.4DE43C9A
Content-Type: text/html;
charset="big5"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Weston,
Thank you for your comment.
In my example, I try to express the idea:
The Tco_max was 2.5nS in my example, which was based =
on the same test loading used to generate TIME_TO_VM.
And after Quad's mtest's calculation, I'll have TWO =
different values for TIME_TO_VM: 0.8nS for rising and 1.8nS for =
falling.
I'll then think that the Tco_max must came from = falling and the real Tco for rising should be smaller than 2.5nS, maybe =
around 1.5nS (I guess, because 1nS difference on =
TIME_TO_VM).
Then If I can have longer allowable flight time =
about 4nS (7.5-1.5-2.0=3D4.0) purely for rising.
If it is true, the Tflight_rise of 3.1nS(<4.0nS) =
won't break my timing! Am I totally wrong?
By the way, I assume zero skew and jitter in my = formula just for simplication, I didn't mean I can really do that in = practical.
And I won't do the TIME_TO_VM correction manually in = my simulation, I'll enable the VM correction function in Quad if I have =
reliable TIME_TO_VM values in XTK models.
RGS,
Steve Ting
-----Original Message-----
From: Beal, Weston [mailto:[email protected]=
]
Sent: Wednesday, May 19, 1999 12:21 AM
To: '[email protected]'
Subject: RE: [SI-LIST] : Looking Inside IBIS =
Model
Steve,
Almost all the datasheets I've seen provide minimum =
and maximum times for
Tco. These should include all cases including =
rising and falling waveforms.
I agree that TIME_TO_VM can be significantly =
differenct for rising and
falling edges. That's why the TIME_TO_VM =
parameter in the QUAD model has
two different numbers for rising and falling. =
If you will calculate the two
TIME_TO_VM parameters (or let mtest do it), put the =
TIME_TO_VM in the QUAD
driver model, and enable VM correction in XNS, all =
your time deratings will
come out correct.
On the other hand, as I stated in a previous email, =
the timing test load
should be placed at the pin. Including the =
TIME_TO_VM parameter in the
model with mtest puts the timing test load at the =
die. To be more correct,
you might want to calculate TIME_TO_VM (rising and =
falling) to the pin and
do your manual subtraction with the rising and =
falling cases seperately.
In your example, if 2.5ns is the Tco_max then your =
Tflight either rising or
falling is 3.0ns and 3.1ns breaks your =
timing.
Regards,
Weston Beal
-----Original Message-----
From: [email protected] <mailto:[email protected]=
m.tw>
[mailto=
:[email protected]]
<mailto:[mailto:[email protected]=
m.tw]>
Sent: Monday, 17 May, 1999 8:33 =
PM
To: =
'[email protected]'
Subject: =
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 ti
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:[email protected]=
<mailto:[email protected]=
>
<mailto:[email protected]=
<mailto:[email protected]=
> > ]
Sent: Monday, May 17, 1999 10:03 PM =
To: =
'[email protected]'
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: [email protected] <mailto:[email protected]=
m.tw> [
mailto:[email protected]=
m.tw <mailto:[email protected]=
m.tw>
<mailto:[email protected]=
m.tw
<mailto:[email protected]=
m.tw> > ]
Sent: Monday, 17 May, 1999 6:07 AM =
To: =
'[email protected]'
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
**** To unsubscribe from si-list: send e-mail to = [email protected]. 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_01BEA1CC.4DE43C9A--
**** To unsubscribe from si-list: send e-mail to [email protected]. 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 ****