[IBIS] BIRD 140 and Model Corner C_comp BIRD Discussion

Hello everyone,

I changed the subject line a little bit to reflect the content
of this thread a little more accurately.

We have three BIRDs slated for IBIS 5.1 which still need to be
voted on, and BIRD 140 is one of them. I would like to keep
the discussion going in email in hope to speed up our process.

The latest version of the BORD 140.1 draft has been uploaded to
the ATM web site some time ago:

http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20110906/arpadmuranyi/BIRD%20140.1%20Format%20Corner%20and%20Range%20Clarification%20for%20IBIS-AMI%20draft/BIRD140_1.pdf

This BIRD contains some clarifications on the various Formats
which are listed on pg. 140 of our current 5.0 specification
and attempts to define what "align implicitly to slow and fast
corners" in the existing specification actually means.

One comment I keep hearing from some of our participants is
that this BIRD is not needed at all, the specification is
good the way it is. I tend to disagree with that whole
heartedly because my company had to learn the hard way how
this was supposed to be implemented due to the poor language
in the existing specification. My firm belief is that the
specification MUST have a better language to describe how
the selection of one of the three values in a Format Corner
parameter is done.

This BIRD draft makes use of the already existing Corner
names in IBIS and defines that for AMI purposes "Min"
describes "Slow" or weak performance, and "Max" describes
the fast or strong performance. I believe this is in agreement
with what Walter was suggesting before, and this seems to be
the simplest way of addressing this issue.

In an email response to Bob's C_comp BIRD draft, I made a
suggestion to add corner names "Slow" and "Fast" to the
existing IBIS specification to address any potential concerns
that associating the IBIS_min with AMI_slow and IBIS_max with
AMI_fast would not be acceptable for some reason. This idea
is a more complicated solution (and hasn't been written up in
a BIRD format yet), but would introduce support for five
corners in legacy IBIS as well as in IBIS-AMI.

I would like to solicit comments and questions on this topic
from everyone so we could make a decision on BIRD 140.1, and
possibly vote to submit it to the IBIS Open Forum.

Thanks,

Arpad
================================================================

-----Original Message-----
From: Bob Ross [mailto:bob@teraspeed.com]
Sent: Thursday, September 15, 2011 10:47 PM
To: Muranyi, Arpad; ibis@eda.org
Subject: 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 have 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.
-- 
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