RE: [IBIS] Model Corner C_comp BIRD Discussion

Arpad:

I read you proposal, but think we should defer adding new (slow, fast)
corners
to C_comp. The discussion is extensive, and I have concerns about some of
your
assumptions.

The IBIS model issue that we are addressing is to provide an "explicit"
alternative method for entering C_comp (1) to align with extracted measured
or SPICE based values, (2) perhaps to allow for some other correlated
extensions
aligned with PVT in the future, and (3) to give explicit model information
for
testing and correlation (as an alternative to the Section 9 rules for
C_comp).

Your added corner syntax proposal for C_comp might be considered as
as another choice only if we make the explicit definition that the 'slow'
entry
is the value for PVT min settings, and the 'fast' entry is the value for
PVT max
settings.

For [External Model], certain IBIS keywords and subparameters including
C_comp are optional and are overridden anyway by executable [External
Model]s.
The executable model (SPICE, *AMS, *A(MS) and pending IBIS-ISS) do not
any specified C_comp* (page 100). So the executable model should already
comply entirely with min=slow and max=fast.

The same applies for [External Circuit] (used as buffers or receivers) since
standard IBIS parameters including C_comp* are not permitted. So as a
driver
or receiver, the executable model should already comply with min=slow,
max=fast.

Any corner extension proposal including those that relate to IBIS-AMI and
possibly to any [External Model] and [External Circuit] syntax should be
considered
in a future release where all of the implications can be fully considered.

Bob

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi,
Arpad
Sent: Thursday, September 15, 2011 4:58 PM
To: ibis@eda.org
Subject: RE: [IBIS] Model Corner C_comp BIRD Discussion

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 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 1993