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