[ibis-macro] Terminology Change Request - RE: Re: [EXT] Re: [C Comp Model] BIRD Updated Draft
- From: "Bob Ross" <bob@xxxxxxxxxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 17 Jun 2019 15:49:29 -0700
Randy,
Because Subparameter_mode is used in V7.0, and "Mode" is not used by itself,
it would make sense to replace "Mode" with "C_comp_model_mode" or just
"C_comp_mode". While longer, the first choice has a clearer meaning.
That way we can use another "* _mode" for some future modal setting with
different arguments and rules.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Randy Wolff ;(Redacted
sender "rrwolff" for DMARC)
Sent: Monday, June 17, 2019 1:14 PM
To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: [EXT] Re: [C Comp Model] BIRD Updated Draft
Arpad,
In the attached draft, I moved that last sentence to its own paragraph. I
think it reads better that way, but open to other suggestions. I also
removed 'token' per Bob's request and fixed some space formatting in each of
the rules headers.
Thanks,
Randy
From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> On
Behalf Of Muranyi, Arpad
Sent: Sunday, June 16, 2019 11:35 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: [EXT] Re: [C Comp Model] BIRD Updated Draft
Randy,
Thanks for the update. I apologize for being so picky, but I don't like the
way
these two sentence follow each other:
"For example, if the C Comp Model mode is Non-Driving, then the C Comp Model
is used only in the high-Z state of a 3-state model. If the model type is
I/O or 3-state, and there is only one C Comp Model with Mode Driving or
Non-Driving, the EDA tool shall use the [C Comp Corner] values for the
undefined mode in the simulation."
because it gives me the impression as if the second sentence would be part
of the "for example" discussion. In reality the second sentence is a rule
definition, that is not part of the example preceding it.
I am not sure how we could correct this easily, but I would try to do
something
about it. Swapping the two sentences might be a way to do it, but that way
the example is too far away from the rule it wants to illustrate, because
there
is another rule between them.
Can you come up a clever solution?
Thanks,
Arpad
===============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Randy Wolff
Sent: Friday, June 14, 2019 9:39 AM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: [EXT] Re: [C Comp Model] BIRD Updated Draft
Arpad,
I used your suggested text in the attached BIRD draft. We can discuss
further on Tuesday to see if there is agreement on finalizing this to submit
to the Open Forum.
Thanks,
Randy
From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> On
Behalf Of Muranyi, Arpad
Sent: Wednesday, June 12, 2019 10:41 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: [EXT] Re: [C Comp Model] BIRD Updated Draft
Thanks Bob for checking all this. I think it is consistent with what pg.
95
says. If I would have found that material on pg. 61, I wouldn't have asked
all these questions. J
Arpad
=========================================================
From: Bob Ross [mailto:bob@xxxxxxxxxxxxxxxxx] ;
Sent: Tuesday, June 11, 2019 11:38 PM
To: Curtis.Clark@xxxxxxxxx; 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>; Muranyi,
Arpad <Arpad_Muranyi@xxxxxxxxxx>
Cc: bob@xxxxxxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: [EXT] Re: [C Comp Model] BIRD Updated Draft
Hi All,
Per the AR, I checked the syntax. There are no stated limits to the number
of submodel references under [Add Submodel].
It is possible uunder [Add Submodel] to add many [Submodel] references..
The I-V tables will simply add in parallel
For example,
[Add Submodel] mode
ODT100 All | 100 ohms always in place
for Driving and Non-Driving
ODT100 Non-Driving | parallel combination creates
effective 25 ohm ODT for Non-Driving
ODT100 Non-Driving
ODT100 Non-Driving
[C Comp Model] could work in the same way - just add all of the [C Comps
Model]s in parallel For example we could support for an I/O Model_type two
Non-Driving [C Comp Model]s and create a combined model.
However, as a practical matter, we are choosing to limit ourselves to up to
two choices. We do not expect to do more than two extractions.
So, we can add some rules and for allowable modes of the two models for a
given Model_type (and not overlap the C Comp Models.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Curtis Clark
Sent: Tuesday, June 11, 2019 6:01 PM
To: 'IBIS-ATM'; Arpad_Muranyi@xxxxxxxxxx
Subject: [ibis-macro] Re: [EXT] Re: [C Comp Model] BIRD Updated Draft
Hi Arpad,
Following up on today's discussion in ATM. I believe Bob was correct and
"submodel mode cannot conflict with top-level model type" is to be
interpreted more narrowly than you were in your email. It's only a
"conflict" if the mode is not possible for the top-level model, not if it is
a subset. So, it's not a conflict if an I/O model has a "driving" mode
submodel because that mode is a subset of what the top level model supports.
On page 95 of IBIS 7.0 we do state explicitly that multiple submodels can
appear under the same model:
When special-purpose functional detail is needed, the top-level model
can call one or more submodels.
So, I think it's already possible to have driving and non-driving mode
submodels under a single model (if it's I/O or 3-state).
I think Randy's approach with C Comp Model modes is consistent with
submodel.
Thanks,
Curtis
_____
From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> on
behalf of Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
Sent: Tuesday, June 11, 2019 1:45 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: [EXT] Re: [C Comp Model] BIRD Updated Draft
Randy,
I think you are making the rules more complicated than what they need to be.
The first two items in your list are really not requirements or rules.
Those are
just circumstances, in which case we (the EDA tool) know what to do. No
rule
is needed for them. The rule is only needed for the 3rd case when the new
cap model is not defined for all possible modes. So wouldn't it be enough
to
say in the BIRD what to do in that case? For example, something along these
lines:
"If the model type is I/O or 3-state, and there is only one [C Comp Model]
with Mode Driving or Non-Driving, the EDA tool shall use the [C Comp Corner]
values for the undefined mode in the simulation."
But, I just noticed something else. Currently we say that the Mode
subparameter
is required (for all model types). This is really not necessary either, and
it is
something that the parser will need to check (model type and mode). The
Mode information is really only needed/useful for I/O and 3-state model
types. Shouldn't we say that it is required only for I/O and 3-state and
illegal
for all other types?
But, I remember we wanted to make this BIRD consistent with how [Submodel]
works. So I looked it up (pg. 61):
I would summarize the above as follows:
- Mode is required (since the keyword is defined with two columns)
- Mode must match the model type (Input/Non-Driving,
Output/Driving)
- Mode "All" can be used for any model type
- I can't find anything on how many [Add Submodel] keywords are
allowed in one [Model]. Theoretically we could have more than one
(we don't seem to prohibit it), but the above rules wouldn't support
having one as Driving and another one as Non-Driving for an I/O model
type, because Mode has to match the model type... So the above rules
imply one [Add Submodel] per [Model].
So how consistent do we want to be with [Add Submodel]? Or, if we need
to deviate from it, shouldn't we "do it right"? Or should we "upgrade"
[Add Submodel] with another BIRD so that it could support two different
[Submodel] for the two Modes (Driving and Non-Driving), which it can't
do today?
Thanks,
Arpad
=============================================================
From: Randy Wolff (rrwolff) [mailto:rrwolff@xxxxxxxxxx] ;
Sent: Tuesday, June 11, 2019 11:32 AM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; 'IBIS-ATM'
<ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [EXT] [ibis-macro] Re: [C Comp Model] BIRD Updated Draft
Arpad,
Thanks for the feedback. I do want the statement to be unambiguous. Here's
another way of stating the requirement:
If the top-level model type is one of the I/O or 3-state models, the use of
[C Comp Model] must satisfy one of the following conditions:
1. Two C Comp Models are included, one defined for Driving Mode and one
for Non-Driving Mode
2. One C Comp Model is included with Mode set to All
3. One C Comp Model is included with Mode set to Driving or
Non-Driving. In this case, the EDA tool shall default to the [C Comp Corner]
values to model the undefined Mode.
Is this more clear? Should I try to word this without using a numbered list
format?
Thanks,
Randy
From: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
Sent: Monday, June 10, 2019 5:00 PM
To: Randy Wolff (rrwolff) <rrwolff@xxxxxxxxxx>; 'IBIS-ATM'
<ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [EXT] [ibis-macro] Re: [C Comp Model] BIRD Updated Draft
Randy,
I am sensing a conflict in the rules here. One rule says that for I/O and
3-state
model two are required, but the other rule allows only one model, in which
case
the legacy keyword shall be used. If the former is required, than the
latter will
never happen. Or, if you expect the latter to happen, than don't make the
former
a requirement.
Thanks,
Arpad
================================================================
From: Randy Wolff (rrwolff) [mailto:rrwolff@xxxxxxxxxx] ;
Sent: Monday, June 10, 2019 3:07 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; 'IBIS-ATM'
<ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [EXT] [ibis-macro] Re: [C Comp Model] BIRD Updated Draft
Arpad et al.,
Below in yellow highlight is my proposed change to the BIRD to clarify the
default of using [C Comp Corner] if a Mode is left undefined. I'm open to
suggestions for improvement from anyone. FYI, I will not be available to
attend the ATM meeting tomorrow to discuss changes.
Mode rules:
The subparameter Mode is required and may be either Driving, Non-Driving, or
All. If the top-level model type is one of the I/O or 3-state models, Mode
may be Driving, Non-Driving, or All, and up to two C Comp Models may be
defined, one for Driving mode and one for Non-Driving mode. For example, if
the C Comp Model mode is Non-Driving, then the C Comp Model is used only in
the high-Z state of a 3-state model. I/O and 3-state models require either
two C Comp Models, one defined for Driving and one for Non-Driving Mode, or
one C Comp Model with Mode set to All. Alternatively, for I/O and 3-state
models, if only one C Comp Model is defined for either Driving or
Non-Driving Mode, then the EDA tool shall default to the [C Comp Corner]
values to model the undefined Mode.
The Mode cannot conflict with the top-level model type. For example, if the
top-level model type is Open or Output, Mode cannot be set to Non-Driving.
Similarly, if the top-level model type is Input, Mode cannot be set to
Driving.
The C Comp Model mode can be set to All to cover all permitted modes for any
top-level model type including, for example, Input, Output, and I/O.
Example:
Mode Driving
I do not think a change to the rules of precedence statement in the BIRD is
required, but please re-read the statement below in light of the Mode rules
changes.
RULES OF PRECEDENCE
The EDA tool shall either use C_comp* or [C Comp Model], but not both. The
user and EDA tool may assume that [C Comp Model] is more accurate than
C_comp*. The EDA tool may use the [C Comp Corner] values for V-T curve
shaping during simulation.
Thanks,
Randy
From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> On
Behalf Of Muranyi, Arpad
Sent: Monday, June 03, 2019 6:54 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [EXT] [ibis-macro] Re: [C Comp Model] BIRD Updated Draft
Randy,
Thanks for the new draft, and the accompanying note. Yes that is something
we
should spell out in the BIRD. I would favor a rule that would make IBIS
models
unambiguous. I really don't like the idea of under defined models and then
having
to guess how to go about it.
I still have a draft BIRD on the subject of what to do when min/max data is
not
present in I-V and V-t tables. The spec says in several places to just use
the typ
data, but that can lead to serious I-V and V-t curve mismatch problems,
when,
for example, one set does have min/max and the other set doesn't. I don't
think we should add more such problems to the spec by not spelling out the
rules exactly.
So I would encourage you to consider adding something to your BIRD to define
all possible conditions.
Thanks,
Arpad
=================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Randy Wolff
Sent: Friday, May 31, 2019 2:51 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] [C Comp Model] BIRD Updated Draft
The attached [C Comp Model] BIRD draft includes changes from the draft shown
during the 5/28 ATM task group meeting.
Changes include:
1. Renaming the keyword to [C Comp Model]
2. Changing instances of "C_comp Model" to "C Comp Model" in the
PROPOSED CHANGES section
3. Updating the Examples section to show two examples illustrating use
of the Mode subparameter options
4. Adding Ext_ref to Figure X
5. Fixing typos related to the Number_of_terminals subparameter in
examples
I noticed one other area that I think needs further
discussion/clarification. There are no rules preventing an I/O or 3-state
[Model] from having only one [C Comp Model] with the Mode subparameter set
to Driving or Non-Driving. This creates an undefined condition for the EDA
tool to interpret. Would the one [C Comp Model] be used for both Driving
and Non-Driving states? The Rules of Precedence statement "The EDA tool
shall either use C_comp* or [C Comp Model], but not both." could be
interpreted to require this.
Fixes could include:
1. Allowing the EDA tool to use C_comp for the undefined condition.
(Requires changing the Rules of Precedence statement)
2. Add a rule that I/O and 3-state [Model]s must include either two [C
Comp Model] sections with Driving and Non-Driving modes defined or one [C
Comp Model] with Mode set to All.
Please send feedback by email or plan on further discussion at a future ATM
meeting.
Thanks,
Randy
- Follow-Ups:
Other related posts:
- » [ibis-macro] Terminology Change Request - RE: Re: [EXT] Re: [C Comp Model] BIRD Updated Draft - Bob Ross
- » [ibis-macro] Re: Terminology Change Request - RE: Re: [EXT] Re: [C Comp Model] BIRD Updated Draft- Randy Wolff
