Curtis,
Thanks for your comments. I didn't remember that section you are quoting...
I just searched for the [Add Submodel] keyword, and after I found it on pg. 61
I didn't look further. It is kind of interesting that the keyword is described
in
more detail 34 pages later...
Based on all that, I agree that Randy's proposal is consistent with [Add
Submodel].
Please ignore everything I wrote beginning "But, I just noticed something else".
The only comment that is still valid in my previous email is what I wrote in my
first paragraph with the suggested text in the second paragraph. I think that
would simplify the text a little without changing the intended rules.
Thanks,
Arpad
===============================================================
From: Curtis Clark [mailto:Curtis.Clark@xxxxxxxxx]
Sent: Tuesday, June 11, 2019 8:01 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>; Muranyi, Arpad
<Arpad_Muranyi@xxxxxxxxxx>
Subject: Re: [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<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> on
behalf of Muranyi, Arpad
<Arpad_Muranyi@xxxxxxxxxx<mailto: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):
[cid:image001.png@01D52175.37B8DD10]
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<mailto:Arpad_Muranyi@xxxxxxxxxx>>;
'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto: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<mailto:Arpad_Muranyi@xxxxxxxxxx>>
Sent: Monday, June 10, 2019 5:00 PM
To: Randy Wolff (rrwolff) <rrwolff@xxxxxxxxxx<mailto:rrwolff@xxxxxxxxxx>>;
'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto: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<mailto:Arpad_Muranyi@xxxxxxxxxx>>;
'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto: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<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On
Behalf Of Muranyi, Arpad
Sent: Monday, June 03, 2019 6:54 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto: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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Randy Wolff
Sent: Friday, May 31, 2019 2:51 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto: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