[ibis-macro] Re: Questions on CornerRange BIRD draft; Questions on section 9
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 20 Jun 2011 15:22:47 +0000
Bob,
Thanks for helping in with explaining the spec...
Walter,
I want to make a few general comments. In the early days, when
we wrote the first version of the spec, we had a debate on this
whole topic. The question was whether we should give meanings
like fast/slow or best/worst case to the data in the model. So
we talked a lot about the meaning of these words. The problem
is that these words can mean different things depending on whether
we view things from the perspective of the device or the system
that they are used in. Just one example is the C_comp. It is
true that a large C_comp (often considered as the slow case, in
terms of the device) in a receiver can slow down the edge rate
seen by the input, but it can also reduce reflections and/or
ringing. In the days when the flight time often depended on how
long it took for the signal to settle (stop ringing), a larger
C_comp might have meant a shorter flight time, which might have
been interpreted as "best case" or "fast case" in terms of the
system.
These were also the days when the usage of Monte Carlo analysis
and parameter sweeps were becoming popular for finding a solution
space for the design, and we started to discover that the working
solution was not always composed of the selection of a certain
corner for everything in the design. So we started to promote
the use of "try every possible combination" approach.
These are the kinds of thoughts which influenced us to write the
specification the way it was written. But the problem was that
in this early stage of the specification we didn't see all the
complications arising from the various new keywords that were
added in later versions, and we weren't very good in writing
the words of the spec so that no matter how many decades later
you read them, or how you twist them, you would still get the
same understanding from them. The [Pulldown Reference] is just
one example to illustrate these complications. Before we added
these [*** Reference] keywords, we only had [Voltage Range].
Typ/min/max made perfect sense for [Voltage Range], but as
you pointed out, typ/min/max can be interpreted in various
ways for the [*** Reference] keywords. Having a strong memory
of [Voltage Range] in our minds, we didn't think about these
interpretations, because it was "obvious" to us what typ/min/max
meant. But for those who weren't there when this happened,
things look differently. They read the spec by what the
letters say, not by remembering history. This is why we are
continually discovering so may ambiguities in the spec.
I must say that this also applies to the much more recent AMI
portions of the spec. The authors had a lot of stuff in their
head which made what they wrote "obvious" to them, but even now,
just a couple of years later we are discovering a bunch of stuff
that simply doesn't make sense as written...
This shows how hard it is to write a spec.
Regarding the main topic of this thread, AMI Corner, I understand
why you are pushing for having fast/slow (or even more than just
the three) corners, but the fundamental problem is that in reality
IBIS doesn't have corners. You are trying to introduce something
in the AMI portions of the spec that doesn't exist in the legacy
portions, and you want to make associations between the fast/slow
concept in the AMI portions of the spec with the non existent
fast/slow concept in the legacy portion. I really don't know how
this could be achieved without introducing the same concepts in
the legacy portions of the spec.
I am not proposing to fix this entire topic in the legacy portions
of the spec now, but dealing with C_comp (either with Bob's BIRD,
or my suggestion of an additional qualifier subparameter called
C_comp_corner) we could at least get the minimum that we need for
this concept in AMI.
Thanks,
Arpad
=================================================================
From: Bob Ross [mailto:bob@xxxxxxxxxxxxx]
Sent: Monday, June 20, 2011 9:26 AM
To: wkatz@xxxxxxxxxx; Muranyi, Arpad; 'IBIS-ATM'
Cc: bob@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft; Questions on
section 9
Walter:
Comments to your questions are in your e-mail.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Monday, June 20, 2011 6:34 AM
To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft; Questions on
section 9
Arpad,
In section 9 of IBIS has the following setnences:
| The required "typ" column for all data represents typical operating
| conditions. For most [Model] keyword data, the "min" column describes slow,
| weak performance, and the "max" column describes the fast, strong
| performance. It is permissible to use slow, weak components or models to
| derive the data for the "min" column, and to use fast, strong components or
| models to derive the data in the "max" columns under the corresponding
| voltage and temperature derating conditions for these columns. It is also
| permissible to use typical components or models derated by voltage and
| temperature and optionally apply proprietary "X%" and "Y%" factors described
| later for further derating. This methodology has the nice feature that the
| data can be derived either from semiconductor vendor proprietary models, or
| typical component measurement over temperature/voltage.
| The voltage keywords that control the voltage conditions are [Voltage
| Range], [Pulldown Reference], [Pullup Reference], [GND Clamp Reference], and
| [POWER Clamp Reference]. The entries in the "min" columns contain the
| smallest magnitude voltages, and the entries in the "max" columns contain
| the largest magnitude voltages.
|
| The optional [Temperature Range] keyword will contain the temperature which
| causes or amplifies the slow, weak conditions in the "min" column and the
| temperature which causes or amplifies the fast, strong conditions in the
| "max" column. Therefore, the "min" column for [Temperature Range] will
| contain the lowest value for bipolar models (TTL and ECL) and the highest
| value for CMOS models. Default values described later are assumed if
| temperature is not specified.
|
| The "min" and "max" columns for all remaining keywords and subparameters
| will contain the smallest and largest magnitude values. This applies to the
| [Model] subparameter C_comp as well even if the correlation to the voltage,
| temperature, and process variations are known because information about such
| correlation is not available in all cases.
|
| C_comp is considered an independent variable. This is because C_comp
| includes bonding pad capacitance, which does not necessarily track
| fabrication process variations. The conservative approach to using IBIS
| data will associate large C_comp values with slow, weak models, and the
| small C_comp values with fast, strong models.
Question #1:
Re
| For most [Model] keyword data, the "min" column describes slow,
| weak performance, and the "max" column describes the fast, strong
| performance.
Does "most" mean
"All [Model] keyword data, with the exception of the specific parameters
mentioned in this section, min values should be used for slow/weak components
and max values should be used for fast/weak components."
Or
"Most [Model] keyword data, with the exception of the specific parameters
mentioned in this section, min values should be used for slow/weak components
and max values should be used for fast/weak components."
"Most" can mean both cases. C_comp currently is a significant exception for
the first statement
(there may be one or two other minor ones). For the second case, a terminator
based on [Rpower]
and [Rgnd], or [Rac], [Cac] could be extracted according to PVT (process,
temperature, voltage) and
be positioned such that the values creating the fastest responses are in the
min column. Similarly
the series element extractions according to PVT may have the opposite effects
including whether
it is configured as in series with the signal or as a shunt to the signal.
Also it is possible for voltage
or temperature compensated devices to have entries correctly positioned
according to PVT, but
their compensated effects and values cause the min entries to perform the
fastest. So in the
second case, there are device-specific, circuit-specific or even
extraction-specific situations
where the typ, min, max entries are not always the typ, slow, fast entries.
Question #2:
Re
| The entries in the "min" columns contain the
| smallest magnitude voltages, and the entries in the "max" columns contain
| the largest magnitude voltages.
Which of the following is correct?
[Pulldown Reference] 0 -.02 .01
Or
[Pulldown Reference] 0 .01 -.02
Good catch on ambiguity and incompleteness of the verbage for "0" volts.
The [Pulldown Reference] 0 .01 -.02 would be the correct entry. The
intent is to set up the rails to create the minimum voltage drop across
the device (with respect to both the [Pullup Reference] and [Pulldown
Reference] for all of the min entries, and max voltage across the device
for the max entries.
I also agree that C_comp requires a BIRD so that a [Model] can have define
values of C_comp for components that have a fast C_comp that has a smaller
magnitude that a slow C_comp.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Sunday, June 19, 2011 12:08 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft
Walter,
Regarding: "Values of tap coefficients, strength, CTLE settings are clearly
independent of process corner. The AMI language makes this perfectly clear
to the model maker and the EDA tool." I would like you to show me
where in the spec this is made clear with page numbers, etc...
As far as I understand, this is not clear at all which is
the very reason that we are working on this BIRD draft.
Also, regarding the first sentence of the above quote, my
reading of the spec and from all the conversations that took
place on this topic gives me the opposite impression. This
sentence on pg. 141:
| Note that in the context of Algorithmic Model for type 'Corner', <slow
| value> and <fast value> align implicitly to slow and fast corners...
seems to be trying to do exactly the opposite, to "align"
certain AMI settings with the process corner of the analog
IBIS model.
Aside from that, your suggested text:
"The model maker expects the EDA Tool to use <typ value> for nominal
conditions, <slow value> for slow/weak process corners and <fast value> for
fast/strong corners."
unfortunately doesn't solve our problem, because "slow/weak
process corners" and "for fast/strong corners" are not defined
in the IBIS specification for analog models. I can hear you
responding with pg. 174 to this, but please remember the word
"most" in the 2nd sentence of the 2nd paragraph and the next to
the last paragraph on the bottom of that page, which is the
reason for the problem. While we may know what slow and fast
is for the I-V and V-t curves, we do not know what those are
for C_comp.
I am still on the opinion that the only way we can solve this
would be with another BIRD that introduces a subparameter or
keyword for C_comp to allow the model maker to give fast/slow
meaning to the min/max C_comp values. Once we did this, the
fast and slow conditions for the analog model would be known
and the issue with Format Corner would resolve itself almost
automatically.
So I would recommend that we look at Bob's C_comp BIRD, or
add another subparameter immediately before or after C_comp
to allow the model maker to "label" its min/max columns with
"fast" and "slow" as they see fit, something like this:
C_comp_corner typ slow fast
C_comp 7.0pF 5.0pF 9.0pF
We could make this additional subparameter required ONLY when
the [Algorithmic Model] keyword is present, and optional for
all other cases. This would keep existing models working
but would allow us to move forward with the Format Corner
AMI model parameters unambiguously.
Thanks,
Arpad
================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 14, 2011 10:11 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft
Arpad,
The AMI language, and explicitly the format Corner were originally designed to
avoid the confusion in IBIS of the meaning of "most". Values of tap
coefficients, strength, CTLE settings are clearly independent of process
corner. The AMI language makes this perfectly clear to the model maker and the
EDA tool.
To me "align implicitly to slow and fast corners" means that the model maker
expects the EDA Tool to use <slow value> for slow/weak process corners and
<fast value> for fast/strong corners. I do not think it is necessary, but it
might make it clearer by adding a sentence like:
"The model maker expects the EDA Tool to use <typ value> for nominal
conditions, <slow value> for slow/weak process corners and <fast value> for
fast/strong corners."
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 14, 2011 8:50 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft
Walter,
The AMI section of the current 5.0 spec says:
| Note that in the context of Algorithmic Model for type 'Corner', <slow
| value> and <fast value> align implicitly to slow and fast corners, and
| <slow value> does not have to be less than <fast value>.
What does "align implicitly to slow and fast corners"
mean exactly? Slow and fast corners where? If I
remember correctly, we established verbally in this
discussion that this refers to the corner setting of
the EDA tool, selecting a certain corner for the analog
IBIS [Model]. Whatever corner the user selects in whatever
GUI the EDA tool has for the legacy analog IBIS model is
the corner that we are trying to use for selecting the
corresponding AMI parameters value from a parameter of
Format Corner.
But what are the slow and fast corners in the legacy IBIS
[Model]'s terminology?
Well, most min data corresponds to slow and most max data
corresponds to fast, according to:
"For most [Model] keyword data, the "min" column describes slow,
weak performance, and the "max" column describes the fast, strong
performance."
But C_comp is not part of that, according to what the bottom
of pg. 174 says:
| The "min" and "max" columns for all remaining keywords and subparameters
| will contain the smallest and largest magnitude values. This applies to the
| [Model] subparameter C_comp as well ...
|
| C_comp is considered an independent variable...
So based on all this, please explain to me what is the
exact meaning of "align implicitly to slow and fast
corners" in our current spec. Based on reading the
spec I have no idea...
Thanks,
Arpad
=========================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 14, 2011 6:54 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft
Arpad,
These words are for AMI parameters of format Corner. What does that have to do
with C_comp?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 14, 2011 7:51 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft
What is "slow and fast corner" for the C_comp values
according to the IBIS specification?
The reason we need to fix IBIS here is because the
AMI parameters Format Corner are associated with the
"slow and fast corners" of IBIS. If we don't know
what they mean, we can't make that association...
Thanks,
Arpad
=====================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 14, 2011 6:46 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft
Arpad,
What is not clear about the following words?
| Note that in the context of Algorithmic Model for type 'Corner', <slow
| value> and <fast value> align implicitly to slow and fast corners, and
| <slow value> does not have to be less than <fast value>.
I agree that IBIS [Model] parameters are not clear, but we are not going to
solve that here. We are charted to fix AMI not fix IBIS.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 14, 2011 7:33 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft
Forgot to finish my thought:
And since AMI parameters Format Corner supposed to be
associated with the IBIS corner problem, it seems
that we need to solve the IBIS corner problem also,
or define an independent classification for that from
the AMI portion of the spec.
Arpad
========================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 14, 2011 6:30 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft
Walter,
This BIRD draft is dealing with AMI parameters Format Corner
(which is not in your list below). That's what is not clear
for me in the spec...
Arpad
==============================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 14, 2011 6:26 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft
Arpad,
Please note that it is for "most [Model] keyword data". This is the IBIS
problem. We are talking about AMI Parameters. For AMI Parameters we already say
"For type 'Range' and 'Increment', <min value>, <max value> does not imply slow
and fast corners".
What is not clear about this?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 14, 2011 7:15 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft
Walter,
I totally disagree with you...
"Why do we need to add anything else?"
Exactly because of the word "most" on pg. 174:
"For most [Model] keyword data, the "min" column describes slow,
weak performance, and the "max" column describes the fast, strong
performance."
Note that towards the bottom of pg. 174 the spec says:
| The "min" and "max" columns for all remaining keywords and subparameters
| will contain the smallest and largest magnitude values. This applies to the
| [Model] subparameter C_comp as well ...
|
| C_comp is considered an independent variable...
This is the reason I disagree with you. C_comp is a pretty important
part of the analog model and its corner conditions. If we don't know
what its min/max values mean in terms of slow/fast, how are you going
to make an association between the AMI slow/fast corners and the analog
models' slow/fast corners?
Sincerely,
Arpad
==========================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 14, 2011 5:56 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Questions on CornerRange BIRD draft
Arpad,
This is the current wording in 5.0:
|
| Note that in the context of Algorithmic Model for type 'Corner', <slow
| value> and <fast value> align implicitly to slow and fast corners, and
| <slow value> does not have to be less than <fast value>. For type 'Range'
| and 'Increment', <min value>, <max value> does not imply slow and fast
| corners.
Why do we need to add anything else? I think the above words are clear and
Unambiguous. These words mean that the "Model Maker expects the EDA tool
to use <typ value> for typical performance, <slow value> for slow weak
performance, and <fast value> for fast, strong performance".
AMI models do not suffer the consequences of the word "most" in the following
Sentence in the IBIS 5.0 specification on page 174:
For most [Model] keyword data, the "min" column describes slow,
weak performance, and the "max" column describes the fast, strong
performance.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, June 14, 2011 6:29 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Questions on CornerRange BIRD draft
Hello,
Since our discussion in the ATM teleconference today
did not reach a conclusion on what the text should say,
I would like to continue with this topic in email, so
that we could hopefully find a solution by next Tuesday.
Here is the debated text for your convenience:
| Note that for Format Corner AMI parameters, the selection of one of the
| three possible values (<typ value>, <slow value>, <fast value>) is done
| by the EDA tool based on its internal IBIS [Model] corner setting.
| Since the IBIS specification does not define how exactly an EDA tool
| should pick from the various types of min. and max. data in the .ibs
| file to achieve slow and fast simulation results, the exact method of
| how <typ value>, <slow value> and <fast value> from Format Corner AMI
| parameters should be associated with the EDA tool's corner setting
| cannot be defined here. However, it is recommended that the typ., min.,
| max. (or similar) IBIS [Model] corner settings should be associated with
| the <typ value>, <slow value>, <fast value> in Format Corner AMI
| parameters, respectively. For AMI parameters <slow value> does not have
| to be less than <fast value>. For type 'Range' and 'Increment', <min
| value>, <max value> does not imply slow and fast corners.
Summary:
1) The main motivation for this BIRD was to state in the spec
that the Format Corner parameter gets its control input from
the EDA tool automatically and a GUI for user selection is not
necessary for these types of variables.
2) Another goal was to define that the AMI corner and the analog
model's corner settings are linked together
Problem:
In IBIS we (deliberately) left C_comp independent from the I-V and
V-t curves, because we thought that its variations were not related
to silicon. As a result, EDA vendors implemented their own methods
for how the user combines the C_comp with the I-V and V-t curves.
Some vendors have five corners (typ/min/max/slow/fast), other
vendors may have different user options.
Question:
How do we associate the AMI slow/fast corners with the IBIS analog
model's min/max corners?
Options:
1) Leave it open in the spec and let the EDA tool vendor do
what they think works best with their products.
- the problem is that if EDA tools have different associations
the results will be different, or the model files might have
to be edited "tailored" manually for each tool
2) Introduce another subparameter for C_comp to define the meaning
of its min/max corners
- this would also solve some issues in legacy IBIS
3) Define in the AMI portions of the specification that for [Model]s
which have [Algorithmic Model] keywords, the min/max corners of
C_comp have a specific meaning (slow/fast), which doesn't apply
to legacy IBIS modeling
This BIRD draft does #1, but we really don't seem to like it.
Bob already started a C_comp BIRD draft, and it seems that we like the
ideas Bob wrote down, but we were wondering about the syntax approach
Bob proposed. This would go with option #2 pretty well, but may take
a little more time to finish Bob's BIRD draft.
Option #3 is fairly inconsistent, and as a consequence I think it will
confuse a lot of model makers and users, and therefore it is error prone.
But this may be the simplest and fastest solution to have something well
defined.
I personally think that #2 would be the most robust solution because
it would solve the IBIS problem as well as the AMI problem. It is not
challenging from a technical perspective, so I would think that we
should be able to finish Bob's BIRD draft in a short time.
I would simply add a new subparameter to the spec under or above C_comp
to specify the meaning of its columns:
C_comp_corner typ slow fast
C_comp 7.0pF 5.0pF 9.0pF
where slow/fast can be in either order, while the numerical entries
for the 2nd and 3rd columns will have to be in increasing order (to
go with the old rule: min < max). Once we have this, the AMI Corner
association would solve itself by using this new subparameter. The
C_comp_corner subparameter would be required when {Algorithmic Model]
exists in [Model], but optional in all other cases.
I am open for comments and suggestions.
Thanks,
Arpad
======================================================================
Other related posts:
