[ibis-macro] Re: [EXT] Re: [C Comp Model] BIRD Updated Draft

  • From: "Randy Wolff" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "rrwolff" for DMARC)
  • To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 14 Jun 2019 14:38:37 +0000

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...  :)

Arpad
=========================================================

From: Bob Ross [mailto:bob@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, June 11, 2019 11:38 PM
To: Curtis.Clark@xxxxxxxxx<mailto:Curtis.Clark@xxxxxxxxx>; 'IBIS-ATM' 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>; Muranyi, Arpad 
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>
Cc: bob@xxxxxxxxxxxxxxxxx<mailto: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> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Curtis Clark
Sent: Tuesday, June 11, 2019 6:01 PM
To: 'IBIS-ATM'; Arpad_Muranyi@xxxxxxxxxx<mailto: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<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@01D5228C.80644B40]



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

PNG image

Attachment: C_comp_Model_Using_IBIS-ISS_BIRD_rev_6_14_2019.docx
Description: C_comp_Model_Using_IBIS-ISS_BIRD_rev_6_14_2019.docx

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 06-2019