Minutes from the 04 October ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 04 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:
- Curtis to send out revised minutes from the September 20th meeting.
- Done.
- Bob Ross to send out a BIRD 147.2 proposal containing the changes discussed.
- Done.
- Arpad to send an email to the Open Forum with ATM's recommendation to reject
BIRD 128.2.
- Done.
- Michael Mirmak to draft a clarification BIRD for AMI Output parameters.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Minutes from the September 27th meeting had not yet been posted for review.
-------------
New Discussion:
- Arpad: I left the agenda the same as last week.
- I'm not sure if we have updates on any of our topics.
- Bob Ross did produce a draft of BIRD 147.2 and email it out.
- Bob R.: [sharing draft 3 of BIRD 147.2]
- BCI_Protocol rule: "BCI_Protocol must be present if the model supports any
BCI protocol."
- I moved this to the Usage Notes: section.
- Following Mike LaBonte's suggestion, we explicitly state that parameters
track BCI_Protocol.
- For example: "BCI_ID must be present if BCI_Protocol is present. BCI_ID
must be absent if BCI_Protocol is absent."
- I moved these rules to the Usage Notes: sections.
- In table YY1:
- For the parameters secondary to BCI_Protocol, under requirements:
"No, Yes if BCI_Protocol is present."
- Bob M.: BCI_GetWave_Block_UI is optional if BCI_Protocol is present.
- For the other secondary parameters, we now state that they must be absent if
BCI_Protocol is absent.
- Should we make that same statement for BCI_GetWave_Block_UI?
- Bob R.: Yes, I understand, it is optional, but illegal without BCI_Protocol.
- Bob M.: Yes, there's no practical use for BCI_GetWave_Block_UI if BCI_Protocol
is absent.
- Bob R.: Okay, I can add that.
- Arpad: I understand that for clutter purposes it's advisable not have the
secondary parameters there without BCI_Protocol. But, is it going to
hurt anything if they're there? Is it worth the trouble to explicitly
prohibit them if BCI_Protocol isn't there?
- Bob M.: I was just thinking of someone's comment that for the purposes of the
parser it's more convenient to explicitly disallow it.
- Curtis: I think it's worth the trouble to explicitly disallow it. We might as
well spell it out like the other three secondary parameters. There's
no good reason for it to be there without BCI_Protocol.
- Arpad: Okay, if it's easier to explicitly disallow it that's fine. I was
thinking it might be more work that way.
- Bob R.: Should we just make it a clean sweep and make it required if
BCI_Protocol exists, and illegal if BCI_Protocol doesn't exist (like
the other 3)? Or, should we leave it as it currently is, optional if
BCI_Protocol exists, and simply add that it is illegal if BCI_Protocol
doesn't exist.
- Radek: The latter sounds okay. We can keep it optional.
- Bob R.: I will email a draft 4 of BIRD 147.2.
Bob Ross and Radek's discussion of Editorial Task Group Issues:
- Bob Ross: We met yesterday [Monday, October 3, 2016].
- I can summarize.
- We looked at ECL, PECL, split PECL with respect to reference.
- Radek proposed a [GND Reference] keyword, which could be called a
[Local Reference].
- If this keyword is missing, the local reference is assumed to be 0.0V.
- If the value of [GND Reference] is non-zero, then all of the voltages
embedded in the IBIS model (with some exceptions) are now relative to this
local reference.
- All the v(t) tables, for example, get shifted.
- The Vinl, Vinh, thresholds get shifted.
- All the relevant [Model Spec] voltages get shifted.
- With respect to PECL, or ECL, all of the examples were the most positive
rail.
- For ECL, that's usually ground.
- For PECL, that might be 5V.
- If you put 5.0 in the new keyword for your PECL model, then for the rest
of your model you would basically reproduce the ECL tables.
- We still have to discuss things further.
- If that [GND Reference] happens to have the same value as one of the
existing [* Reference] keywords, then the corresponding rails are considered
the same (shorted).
- C_comp now gets connected to the [Local Reference].
- [Package Model] reference is the [Local Reference].
- Exceptions are:
- This is a new keyword within a [Model], so whatever is defined within the
[Model] as a reference voltage is still with respect to 0.0.
- The I/V tables don't shift. They're always relative to their
[* Reference] voltages, so they don't shift around.
- Anything that's differential does not shift.
- Radek and I haven't yet discussed an RS232 model that I sent him.
- We also discussed the [Pin Reference] keyword.
- Radek: The discussed examples show a likely assignment by the model maker.
- We are not imposing this on the model maker.
- We are giving them a way to clearly specify something they currently can't.
- This [GND Reference] in a way is an alternative to the [DUT Reference]
that we discussed earlier. It is probably slightly more flexible and
general than [DUT Reference] was.
- We still have to discuss any interrelationship between [Pin Reference] and
[GND Reference].
- Bob R.: We considered the case of a common mode voltage for a differential
application, where we might want C_comp to go to that common mode
voltage, which isn't currently defined anywhere. Maybe we don't want
to support this.
- Walter's hypothetical scenarios were discussed.
- Some with the reference in the [Model].
- Some with the reference Pin defined in the [Component].
- General answer is, "it depends on how the model was extracted."
- Radek: Once we finalize it we can broadcast it.
- Bob's summary notes show the outcome of some of the discussions, but not
the details and all the cases that were discussed.
- Bob: We are going to meet further, perhaps Friday.
- If we do introduce [Local Reference] in a manner that affects all voltages,
the impact to the parser is that we have to identify every affected voltage.
The parser would then shift the model values according to the value of
[Local Reference], so it's as though it were a current model relative to
0.0, and then check the model with the existing parser code.
- There could be major implications since the parser and EDA tools still have
to support existing models as is.
- We haven't fully examined this change from a parser or specification
language perspective.
- It could require the addition of multiple statements throughout the document
saying that everything is relative to the optional [Local Reference].
- Arpad: Does this discussion cover all the subtopics under this item on the
agenda? There are four subtopics 7a through 7d.
- Radek: 7b we have addressed. We said we prefer "model in simulation" to
DIA (device in action).
- 7a and 7c are covered in this discussion.
- We noted that any two [* Reference] entries for which all 3 corner case
values are identical will be considered to have their corresponding
terminals the same (shorted). That will clarify a number of things,
including which *_ref serves the reference. We won't have to speculate
anymore, it will be specified by the model maker.
- 7d. At the moment there is the implication of this [Local Reference] on
the [Receiver threshold] values. We still have to talk about [External
Reference], but that is not yet part of the discussion.
- Bob: As a reference, it could be the same as the [External Reference].
- However, that's not a valuable reference for output buffers because
[External Reference] was intended as a measurement reference for certain
types of buffers, DDR buffers in particular. It was intended as a reference
voltage that was not necessarily one of the rails.
- We can decide whether to allow it all or simply not recommend it.
- We sort of agree that we don't want to allow it.
- 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.
-------------
Next meeting: 11 October 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
