[ibis-macro] Re: Questions on CornerRange BIRD draft
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 14 Jun 2011 16:14:49 -0700
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:
