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>
[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
