Minutes from the 11 October ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 11 October 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
Trevor Timpane
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:
- Bob Ross to send out an updated BIRD 147.2 proposal containing the changes
discussed.
- Done.
- Michael Mirmak to draft a clarification BIRD for AMI Output parameters.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Two sets of minutes needed review, as the September 27th minutes were not
prepared and posted in time for the October 4th meeting.
- September 27th minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]
- October 4th minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
- Bob R.: [sharing draft 6 of BIRD 147.2]
- This is the most recent draft.
- The main changes are what we discussed last meeting, plus one change that
was from an additional email discussion after the meeting.
- In table YY1, required column entries for secondary BCI parameters:
"No, Yes if BCI_Protocol is present."
- If BCI_Protocol is present, all of the secondary parameters are required.
- If BCI_Protocol is absent, all of the secondary parameters must be absent.
- BCI_GetWave_Block_UI is now required if BCI_Protocol is present. No
default value is provided [this is the change resulting from the email
discussion].
- Radek: In the email discussion about removing the default value for
BCI_GetWave_Block_UI, one important point was that there was really
nothing special about the default value 1000.
- Bob R.: So we've gone to an "all or nothing."
- If BCI_Protocol is present, all BCI parameters are required.
- If BCI_Protocol is absent, all BCI parameters must be absent.
- I've moved all of these statements to the Usage Rules: sections, so the
locations are now consistent.
- Ambrish: What's the default for BCI_Protocol?
- Bob R.: There is none.
- Radek: We've never had a default for BCI_Protocol in these discussions.
- Bob: All we are stating [from BCI_Protocol Usage Notes:] is:
- BCI_Protocol names beginning with IBIS are reserved for future protocols
adopted and published in this specification. Names for private and
independently-specified published protocols should contain character strings
sufficiently unique to avoid conflicts with other independently-named
protocols.
- Arpad: If the BCI_Protocol name does not start with "IBIS" is it automatically
considered private?
- Ambrish: Yes.
- Arpad: If two model makers independently choose the same private protocol
name, is that going to be a problem?
- Ambrish: We have the same problem with other names, AMI .dlls for example.
- There's nothing we can do about it.
- Bob R.: We can't really even enforce the rule that a private protocol can't
start with "IBIS".
- There's no way to check it with the parser, unless we have a table of
official "IBIS" protocols.
- Ambrish: Wouldn't there be such a list?
- Walter: I recall that one of the things you did not want to happen is BCI
protocols being tied to IBIS releases.
- Ambrish: Yes.
- Walter: There may be some sort of process for approving a BCI protocol named
IBIS_xyz, but unless it becomes part of the IBIS spec. there's nothing
the IBIS parser can check for.
- Since we wanted the BCI protocol approvals to be independent of IBIS
releases, there's nothing the IBIS parser can check.
- I mention this because Bob mentioned the idea of having a table of approved
names, and the parser could verify that IBIS_xyz is part of the table. But
that would mean it has to be part of the ibischk parser and therefore part
of the IBIS release. But we wanted to make protocol approval independent.
- I don't think we need to get hung up on this point.
- Ambrish: Agreed.
- Arpad: In the paragraph where we say private names should be "sufficiently
unique to avoid conflicts", should we make a suggestion or even a rule
that all private protocol names should start with a vendor or entity
name of the model maker's organization?
- This would help guarantee uniqueness, and within an organization they could
hopefully track their own protocol names.
- Ambrish: We didn't try to legislate that with other things like .dll names.
- We can, but there's only so far you can go with those recommendations.
- Bob R.: We have some general problems.
- One is that we are stating that official protocols should begin with "IBIS".
- Walter is suggesting that we are not going to officially document these
protocols in this specification. That would be contrary to the verbiage
"published in this specification".
- We may have a separate process for storing approved BCI protocol names, but
there would be no enforcement of that. There would also be no way to
enforce any restriction on someone having a private unapproved protocol
and starting the name with "IBIS".
- Arpad: I'm not trying to enforce the "IBIS" rule, I was just suggesting that
we could provide a suggestion to help model makers come up with unique
names for their private protocols.
- Radek: The problem is that "entities" change.
- What you're suggesting is doable, but I think what we have is sufficient.
- Clearly "my_bci_protocol" would not be sufficiently unique.
- What we really want to ensure is that if we have IBIS approved protocols,
and a Tx and Rx are using the same approved protocol, that they can talk
to each other.
- Otherwise, it's really up to the user to make sure the devices are using
the same protocol.
- Mike L.: I think the current "sufficiently unique" sentence is good enough.
- Arpad has proposed some more specific guidance.
- Walter: I agree with Mike.
- We certainly have the problem with IBIS filenames.
- Any naming you rule you come up with is going to fail in some scenario.
- I think what we have is sufficient.
- We haven't run into trouble with IBIS files. People have dealt with it.
- Ambrish: The example could be changed to say "vendor_name_private_1" or
something like that to give a hint to the model makers.
- Arpad: Okay, we don't have to change it. I just thought we could provide
additional suggestions.
- Mike L.: I think the example could help.
- Also, the first sentence about "IBIS" names being reserved for future
protocols is sufficient to implement a parser check that would currently
flag an error for any protocol name beginning with "IBIS".
- Bob R.: Okay, but we should delete the phrase that they are published
"in this specification."
- Ambrish: Would they be published in some other specification?
- Bob R.: There are two views. Do we want the list of protocols to change with
each version of the specification? If so, then we could have
something that ibischk can check. Otherwise we'd have no official
mechanism to check, so we might just abandon the idea of checking
the protocol names.
- Mike L.: We may never publish a list of approved protocols, but it doesn't
hurt to reserve the names that start with "IBIS" just in case.
- Walter: Let's strike the phrase "published in this specification" and replace
it with "published by IBIS."
- Bob R.: The first sentence [of Other Notes:] already says "by IBIS", so we can
just strike "in this specification".
- Mike L.: The first sentence should say "by IBIS Open Forum" otherwise there's
confusion about IBIS meaning the specification.
- Bob R.: Then if it's published by the IBIS Open Forum then we can include it
in ibischk.
- Walter: We don't want that check tied to IBIS releases, and it will be if it's
in the ibischk parser.
- Bob R.: BUG reports could allow us to change the parser without changing the
IBIS spec.
- Radek: I think a list of approved BCI protocols that is independent from the
IBIS spec. is in conflict with a stand-alone ibischk parser.
- If you want the parser to read the currently approved list, then it would
have to go to some location and read the latest file.
- For a standalone parser and the IBIS specification, we may not be able to
check the most updated list.
- I think it's okay to keep it "published by IBIS Open Forum," and we can
just leave the parser alone.
- Bob R.: A mechanism could be possible to get the parser to link to some
prescribed location in ibis.org to get the latest list.
- Radek: Yes, if we wanted to.
- Ambrish: Exactly, that's something we can resolve later. We could implement
something in the future if we want to, but we don't have to worry
about it now.
- All we have to do now is remove "in this specification."
- Bob R.: So the changes are:
- Remove "in this specification."
- In the first paragraph, approved by "the IBIS Open Forum."
- Ambrish: I would also change the example protocol name from "XYZ_Private_1"
to use vendor name or protocol name, just to give an idea to the
model maker.
- Bob M.: I think the word "vendor" would be okay.
- Bob R.: Okay, I'll make changes along those lines.
- Walter: Motion to submit this BIRD, with the changes discussed, to the Open
Forum for approval.
- Bob M.: Second.
- Arpad: Anyone opposed to submitting this to the Open Forum? [none]
Bob Ross and Radek's discussion of Editorial Task Group Issues:
- Bob R: [sharing notes from their most recent meeting]
- Per Radek's comments, we discussed common reference vs. topologies where
there are some elements in the reference path in n-ports.
- Example:
---|--R12--|--- ---|--R12--RSS--|---
| | | |
R11 R22 = R11 R22
| | | |
---|--RSS--|--- ---|------------|--- (common ref)
- The 2-port parameters (e.g., S parameters, Y parameters, Z parameters,
etc.) are identical for both topologies.
- The difference is that reference path impedance RSS is moved up into the
signal path.
- If there's physically, say a Z-RSS in the reference path, then one could
think that separate reference terminals must be used. This is not
necessary, as the 2-port parameters are identical for both cases and
both include the impact of Z-RSS. Furthermore, separating the reference
terminals leads to incomplete constitutive circuit relationships
(equations).
- For the above reasons we opt to have n-port topologies with one common
reference terminal, the n+1 terminal.
- If separating such terminals is needed then for the 4 terminals in the
left picture a 3-port, not a 2-port, data needs to be generated.
- Radek: We had some discussion related to the IBIS Interconnect draft proposal.
- We had a few discussions related to touchstone and unused terminals, and
that led to this discussion.
- It's relative to what we are doing here in terms of a reference rail.
- Bob R.: Yes, what we are calling the [Local Reference] rail.
- Bob R.: We also had a discussion that is for the Interconnect Task Group
meeting and relates to what the default termination should be for
unused ports of an n-port.
- Radek: We are both in favor of that being an open circuit.
- Bob R.: We've had that discussion in the past, but what we discussed might not
be in sync with what's in the current draft interconnect proposal.
- Bob: We've decided we want the name [Local Reference] for what we previously
called [GND Reference].
- I claim that we can support the concept of [Local Reference], but that we
should not change the various voltages in the model as we had previously
discussed. That is for discussion. There's no loss in generality because
of the other rule we stated that if the [Local Reference] corner values
were identical to some other [* Reference] corner values, then their
corresponding terminals are considered the same. So if that were [Pullup
Reference], as might be done for ECL, then the [Pullup Reference] voltage
and its corresponding terminal would be the default reference for C_comp,
C_pkg, return currents, etc. We don't need to shift voltages around
relative to that reference.
- Radek: We haven't arrived at the final common decision on that.
- Bob R.: If we declare a [Local Reference] as some other rail, what should the
I/O waveform be relative to? Should it be shown relative to the DUT
reference or the [Local Reference].
- Radek: How you display the values depends on how you set up the simulation.
- We haven't finished that discussion.
- Bob R.: Radek had noted an interesting observation. It's possible for a
Pin to have the same bus label for the pullup_ref and power_clamp_ref
(according to [Pin Mapping]), but for the [Model] associated with
that Pin to declare different values for [Pullup Reference] and
[POWER Clamp Reference]. This is a possible inconsistency that I
think the current parser would not catch.
- Radek: We could start checking for that or establishing precedence.
- Bob. R.: I think this should simply be an error, as there's no way to know
whether the model maker set up the [Pin Mapping] or the [Model]
incorrectly.
- Bob R.: We also continued our discussion on [Pin Reference] and whether there
are any conflicts with [Local Reference].
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Bob Ross to send out a BIRD 147.2 proposal containing the changes discussed.
AR: Mike LaBonte to submit that version of BIRD 147.2 to the Open Forum.
-------------
Next meeting: 18 October 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
