Minutes from the 09 August ibis-atm meeting are attached.
The following documents, which were discussed during the meeting, have been
posted to the work archive.
*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
09-AUG-2016 Bob Ross Teraspeed Pins With Same signal_name Must Have Same
model_name BIRD draft 3 (zip
<http://ibis.org/macromodel_wip/archive/20160809/bobross/Pins_With_Same_signal_name_Must_Have_Same_model_name_BIRD_draft_3.zip>
)(docx
<http://ibis.org/macromodel_wip/archive/20160809/bobross/Pins%20With%20Same%20signal_name%20Must%20Have%20Same%20model_name%20BIRD%20draft%203/BIRD181_draft3.docx>
)
09-AUG-2016 Mike LaBonte SiSoft IBIS 6.2 BIRD Candidates rev 3 (URL
<http://ibis.org/editorial_wip/IBIS6.2_BIRD_candidates_3.docx>)
09-AUG-2016 Mike LaBonte SiSoft I-V Table Clarifications BIRD draft 1 (zip
<http://ibis.org/macromodel_wip/archive/20160809/mikelabonte/I-V_Table_Clarifications_BIRD_draft_1.zip>
)(docx
<http://ibis.org/macromodel_wip/archive/20160809/mikelabonte/I-V%20Table%20Clarifications%20BIRD%20draft%201/BIRD_IV_Table_Clarifications_1.docx>
)
IBIS Macromodel Task Group
Meeting date: 09 August 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
* Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM * Luis Armenta
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Ambrish to check for collaborators' feedback on his nearly ready new version
of the Backchannel proposal.
- In progress. Ambrish said that he expects to be ready to discuss this next
week.
- Mike L. to post Radek's presentation and the IBIS 6.2 BIRD candidates list.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Pins with Same signal_name must have same model_name BIRD:
- Bob Ross: [Sharing presentation of BIRD draft 1]
[Note: draft 3, which contains some modifications suggested during this
meeting, is what was posted to the ATM archives]
- This BIRD starts by copying the BIRD 180 text, except that it removes the
change that demands uniqueness of pin names.
- The uniqueness of pin names change might cause issues with BIRD125, so it
was left out of this proposal so that BIRD180 can handle it independently.
- This proposal adds the restriction that two pins having the same
signal_name must use the same model_name.
- Original wording in draft 1:
- "If two pins have the same signal_name, they must have the same
model_name."
- In practice, for released commercial IBIS models, this would really apply
to all signal_names.
- For the purposes of the Interconnect BIRD proposal, the only signal_names
we are really worried about for this are those used by pins with POWER or
GND models. (e.g. you can't have a signal_name VCC3 and then have it used
by one pin that is a POWER pin and another pin that is a GND pin).
- Arpad: Do you want this in general, or just for POWER and GND pins?
- The sentence as it stands would apply to buffer I/O pins too.
- Bob: I would recommend restricting it to POWER and GND pins.
- Walter: I agree that it was originally written largely for POWER and GND pins.
- However, I would not like it changed (from the original wording seen above).
- signal_name is supposed to be a data book name. What is the meaning of
two I/O pins that have the same signal_name?
- Bob: The case would be for a non-commercial (non-shipping) IBIS file that is
used for prototyping and might violate this rule. The signal_name might
be a generic cut and paste in that case.
- The parser doesn't check for distinct signal_names in this way.
- Walter: IBIS is supposed to provide a component description.
- What you're describing isn't a component.
- Arpad: What about the case of ASICs?
- They're usually user-configured. So you might use a generic signal_name for
all pins, but they might use different models.
- Walter: When they have the same signal_name they usually have the same model.
- But I will not pursue this point because the Interconnect BIRD doesn't care
as long as this restriction is applied to all POWER and GND pins.
- I think it makes sense to apply the restriction to all pins, but I'll defer
to the rest of the group.
- Bob: I will draft a version with a modified statement that restricts it to
POWER and GND pins. [see the draft3 version posted to the ATM archives]
- Arpad: Who is the author of this BIRD?
- Discussion: Neither Bob nor Walter was concerned about who was the author
of record. The original text was from Walter, but Bob agreed to modify it
and be the author of record for this proposal.
- Mike L.: Mixing POWER and GND obviously seems wrong.
- What about NC? Would that be a problem?
- Walter: Yes. If a pin has a signal_name and is a POWER pin, then every other
pin with that signal_name must also be a POWER pin.
- Arpad: You could just change "they must have the same model_name" to
"they must have the same reserved model_name."
- Radek: We would need clearer wording than that.
- Walter's point is correct. In practice we would expect distinct signal
names.
I/V Table Clarifications BIRD:
- Mike LaBonte: [sharing draft 1 of the proposal]
- Four I/V table sections to be modified:
[Pullup], [Pulldown], [POWER Clamp], [GND Clamp].
- Want to clearly define both measurement points in the Vtable equations.
- Refer to actual nodes, not "voltage levels".
- Change the way the voltage equations are given.
- Someone suggested SPICE syntax: V(n1, n2).
- Provide the Vtable equations for all I/V tables.
- Provide the Pullup and Pulldown Vtable equations for the ECL special case.
- Discussion: Mike noted that the "PROPOSED CHANGES:" section simply contained
a wholesale replacement of several pages starting on page 53. The "before"
and "after" text is shown in two separate blocks, but no change tracking
information is included to highlight the modified portions. Arpad, Walter,
and Mike thought it might be better to include the change tracking in the
next version for reviewers to use. Radek noted that he had two questions.
First, is the term "Buffer_IO" (node name used in the Vtable equations)
properly defined somewhere? Second, is the direction of the currents
precisely defined? Radek noted that he felt existing statements on the
direction of the current were not as clear as they should be. Mike agreed
that it could be discussed and modified later (in the ATM group meeting).
List of IBIS BIRD Candidates from the Editorial Task Group:
- Mike LaBonte: [sharing IBIS 6.2 BIRD Candidates rev2]
[Note: rev3, which contains some modifications suggested during the
meeting, is what was posted to the ATM archives]
- This was updated in last week's Editorial meeting.
- A few more entries now have authors listed.
- From the Editorial discussions, item C will be merged into A.
- Item B is what I just discussed, I/V table changes.
- Item D is what Bob Ross discussed.
- Still looking for authors or action on some others.
- Discussion: Mike said he would make cleanup changes to his proposal
(item B) and bring the modified version back to ATM for review. Arpad
noted that the entry for D should be updated, since Bob's proposal is
separate and not folded into BIRD 180 [change made in rev3].
- Walter: Isn't item H just item A with regard to GND?
- Currently, on page 9 [section 3 GENERAL SYNTAX AND GUIDELINES], GND is
listed as one of the magic reserved names. It appears as a reserved model
name. I just want the spec to make it clear that the "must not be used"
restriction for GND does not apply to signal_names and pin names. Those
are "data book" names, and therefore we have to (and do) allow GND to be
used in those contexts.
- I just wanted that limited statement of clarification.
- Bob Ross wanted to generalize it.
- I think item A (Reserved name scoping rule clarifications) has to be written
by Bob because he objected to my limited statement.
- Radek: We could note H as likely to be folded into A.
- Mike L.: Those (H and A) I see as editorial.
- In ATM meetings we need to look at potential functional issues.
- e.g., B, D, J.
- Walter - Item I (C_comp reference in simulation clarifications) is related to
item F (Pin Reference).
- I had created [DUT_ref_term] and [Pin Reference] proposals.
- I ultimately moved to table discussion on them and withdrew my support of
the BIRD because I was stuck between two different interpretations of a
certain special case.
- I think Bob Ross and Radek have to agree on a way to resolve their
differences on this item.
- We need to get F resolved so item I can move ahead.
- Discussion: Radek noted that he had not seen the full details of the argument.
Radek noted that we could have that discussion in ATM, and Arpad suggested an
off line email discussion between Bob and Radek to prepare for it. Mike L.
noted that he would tentatively add Bob and Radek in the "requestor" column
for item F, and no one objected.
Cleanup of ATM agenda "tabled topics"
- Discussion: Arpad and Mike L. started a discussion about cleaning up the
"Tabled topics:" list that appears on the weekly ATM agenda.
Item 10: Enforcing LTI-ness of analog models for AMI simulations.
- Discussion: Arpad noted that this would be a nice thing to have, but that
making progress on such a goal was difficult. He noted that even if the
parser could flag something, it would be hard to force the model maker to do
anything about the issue. Walter moved to remove this item from the tabled
topics list. Curtis seconded. No one objected.
Item 12: BIRD 128 comments
- Discussion: Radek noted that he had already had the chance to give his
comments on BIRD 128. Radek moved to remove this item from the tabled topics
list. Walter seconded. No one objected.
Item 13: DLL trapping and return codes.
- Discussion: Mike noted that full functional testing of the .dll, particularly
with the intent of dealing with .dll crashes, is difficult. All the parser
could do is check some basic functionality, and it might crash itself if the
.dll had issues. Mike also noted that there are several free tools that will
perform a basic run time sanity check of an AMI .dll (some are on the ibis.org
website). Mike and Curtis also noted that the requestor of this item is no
longer subscribed to the IBIS mailing lists. Mike moved to remove this item
from the tabled topics list. Curtis seconded. No one objected.
- Arpad: Item 9 will remain. Items 10, 12, and 13 will be removed.
- Item 11 will now become item 10.
Item 9: How to handle missing min/max data?
- Discussion: Walter noted that Arpad is the owner of 9, and asked Arpad if he
felt it still needed to be on the list of tabled topics. Arpad said that he
had not yet drafted a BIRD to deal with the issue, but that he would like to
see it clarified and resolved eventually. He noted that some sections of the
spec say that if min/max data is missing then typ data should used. Other
sections do not make this statement, so we have a consistency issue. In
addition, the general assumption that typ should be used in lieu of min/max
data could cause inconsistency issues with related keyword. For example, if
v(t) tables were given for typ/min/max conditions, but I/V tables only
contained typ data, then inconsistencies could result. Radek agreed, noting
that if the typ/min/max v(t) tables had different endpoint values then they
could not possibly all agree with one typ set of static I/V tables. Radek
said he thought this was largely a model maker issue, but that we might be
able to clarify some limits on how data is handled. He suggested we should
leave this item available for further discussion. Walter agreed. Bob Miller
asked if this topic was a subset of a larger rule that separate but related
tables should be consistent.
Item 10 (formerly 11): BIRD 147.1 and co-optimization
- Discussion: Bob Miller moved to untable this item in anticipation of Ambrish
discussing it at the next meeting. Walter seconded. No one objected.
- Walter: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 16 August 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
