Bob,
I am basically going to repeat the idea I posted yesterday
to the IBIS-ATM email reflector, since it is closely related
to this thread.
I think we could take care of this min/max vs. slow/fast
problem in IBIS the following way.
Currently the 5.0 specification defines three valid corner
names ("Typ", "Min" and "Max") for the "Corner" subparameter
of [External Model] and [External Circuit] on pg. 107 and
pg. 125. These corner names are also used for the D_to_A
and A_to_D subparameters of the same keywords in the last
column, see pg. 108 and 127.
Section 9 explains that most min and max data does correspond
to slow and fast performance, but is also defines some
exceptions, most notably C_comp. The issue here is not that
we don't know that the min/max data for the I-V, V-t and
[Ramp] information means slow/fast performance. The problem
is that we don't know what the meaning of those min/max
values are which are the exception to this. In order to
bridge this gap, I would suggest to do the following.
Add corner names "Slow" and "Fast" to the [External Model]
and [External Circuit] "Corner" and "A_to_D" and "D_to_A"
subparameters. This would serve the purpose of defining
these corner names. In addition to this, we can start a
convention that for all those parameters which only have
typ/min/max, min means slow and max means fast. To address
the exceptions, we could add two mode data values to those
parameters which do have their own independent slow and fast
corners.
So, for C_comp would need to add two more values:
| variable typ min max slow fast
C_comp 7.0pF 5.0pF 9.0pF 9.0pF 5.0pF
(where the slow value doesn't have to be the same as the max value and
the fast value doesn't have to be the same as the min value, but neither
fast or slow can go outside the range defined by min and max).
For our AMI Format Corner, we could also add two more values:
Corner <typ value> <min value> <max value> <slow value> <fast value>
We could do this to all those parameters which do not track
min/max for slow/fast. The beauty of this is that we don't
have to do this for all parameters that need it all at once,
it can be done incrementally. We can do this for the ones we
can think of now (the most important ones, such as C_comp),
and we can add this to any other parameter at a later time
when we realize we have to do it.
This way we could have our cake and eat it too. Comments,
questions are welcome.
Thanks,
Arpad
=============================================================
-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Bob Ross
Sent: Wednesday, September 14, 2011 4:10 PM
To: ibis@eda.org
Subject: [IBIS] Model Corner C_comp BIRD Discussion
To IBIS Reflector
This note is to open for discussion and questions the pending
C_Comp BIRD133:
http://www.eda.org/pub/ibis/birds/bird133.txt
The proposal suggests an optional keyword syntax that allows specifying
the C_comp entries extracted from and aligned directly with PVT
(process/voltage/temperature) corners to be consistent with
the other [Model] electrical content (I-V and V-T tables).
Other alternatives, along with most other suggestions from a long e-mail
thread last September, 2010 are documented in the ANALYSIS and the OTHER
BACKGROUND INFORMATION sections.
Bob
-- Bob Ross Teraspeed Consulting Group, LCC http://www.teraspeed.com bob@teraspeeed.com Direct : 503-246-8048 Teraspeed Labs: 503-430-1065 Headquarters: 401-284-1827 Teraspeed is a registered service mark of Teraspeed Consulting Group LLC -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.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 e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.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 e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Thu Sep 15 16:58:42 2011
This archive was generated by hypermail 2.1.8 : Thu Sep 15 2011 - 16:59:11 PDT