Minutes from the 11 July ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the ATM work archives.
*DATE* AUTHOR <http://ibis.org/atm_wip/archive-author.html> ORGANIZATION
<http://ibis.org/atm_wip/archive-org.html> TITLE
<http://ibis.org/atm_wip/archive-title.html> FORMATS
11-JUL-2017 Walter Katz SiSoft Electrical Module Description BIRD draft 1 (
zip
<http://ibis.org/atm_wip/archive/20170711/walterkatz/Electrical_Module_Description_BIRD_draft_1.zip>
)(docx
<http://ibis.org/atm_wip/archive/20170711/walterkatz/Electrical%20Module%20Description%20BIRD%20draft%201/BIRD_EMD_1.docx>
)
The following document, which was discussed during the meeting, has been
posted to the Editorial task group work archives.
Title <http://ibis.org/editorial_wip/index-bytitle.htm>FormatsAuthors
<http://ibis.org/editorial_wip/index-byauthor.htm>Organization
<http://ibis.org/editorial_wip/index-bycompany.htm>Date
<http://ibis.org/editorial_wip/index-bydate.htm>
BIRD 161.2 draft 1 .docx
<http://ibis.org/editorial_wip/bird161.2-draft1.docx> Michael Mirmak Intel
Corporation Jul 11 2017
IBIS Macromodel Task Group
Meeting date: 11 July 2017
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
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, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
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:
- Arpad: Walter has an EMD proposal to discuss.
- Ambrish: BIRD 190 should not appear under tabled topics. It was untabled at
the last meeting.
- Radek: The BIRD 158 agenda item (#8) is obsolete. I produced a new version,
and we discussed it last meeting.
- Arpad: I sent a private email to Radek because I have detailed feedback on the
updated version of BIRD 158.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
EMD BIRD draft introduction:
- Walter: BIRD draft emailed to ATM June 28.
- EMD is basically EBD using IBIS ISS subcircuits.
- Largely copy-and-paste from EBD section of IBIS and from BIRD 189.
- I think it's relatively straight forward, but needs thorough review.
- I think it's close to being finished, but I don't think it is for IBIS 7.0,
so there's no need to rush.
- There are a couple of issues that we need to think about:
- EBD only has one connector. Here there's a possibility of allowing
multiple connectors. I think people objected to multiple connectors for
EBD because it might step on EDA tools' turf. I've written EMD for a
single connector.
- How do we refer to the pins in the EMD [Pin List] itself. For the pins on
IBIS [Component]s we use the reference designator (e.g., u1.7), but how do
we do that for the EMD Pins? Perhaps .7, or j.7 (adopt j as the reference
designator for the EMD), or this.7?
- Rail terminals?
- We can use reference designators just like signal pins (e.g. u1.8).
- We will also want to use signal_name like GND.
- All pins on the module with that signal_name could be shorted.
- Or say all pins on a specific [Component] or in the [Pin List] with
that signal_name are shorted together. There are no bus labels in
EMD so we don't have that to consider.
- Ken: Do we still have fork, end fork, etc. describing the paths as in EBD?
- Walter: No the ISS subcircuit instance replaces the path descriptions.
- Bob R.: I suggest we introduce this at the Interconnect meeting before
uploading it. There might even be more changes in 189.
- Walter: I'm fine with that. I think we can hold off until 189 is approved.
- I think this is 98% done, but the last 2% will take time.
- Arpad: When you refer to "only one connector," are you saying traditional EBD
has a connector and then paths that dead-end at the chips, and that
you would like to have a through-type arrangement going from one
connector to another, as if between the pin and the pad?
- Walter: That's certainly an option we could adopt. I think this was brought
up the last time, and people objected to having multiple connectors.
They thought that would compete with EDA tools. I think we
will likely keep it to one connector with a single [Pin List].
- Arpad: One thing we might want to address here is the deliberate deficiency
we built into BIRD 189, where we disallowed the one-to-many and
many-to-one mappings for signals.
- Walter: That's not an issue here. That issue was inside the package. Here
you can have one pin go to multiple [Component]s or go to multiple
pins on a single [Component].
- Bob R.: In BIRD 189 we only have a one-to-one restriction for I/O pins.
- One-to-many and many-to-one exists for rails.
- Walter: Here in EMD, since we've eliminated the paths, it's just a subcircuit
with a bunch of terminals. Lots of the BIRD 189 complications just
don't exist for EMD.
BIRD 191:
- Arpad: What is the reason that we have to do BIRD 191?
- Up until now, we had "pin" or "die" (pad and buffer meant the same thing).
- Now with BIRD 189 we separate the buffer from the die-pad.
- But who is going to make SI simulations at the pad if the buffer terminal
is separate?
- If measurements at the buffer are more accurate or more important, do we
still need the "pad" location? Do we need both?
- Walter: Yes, compliance testing may be done at the pad.
- Michael M: We need to be very clear and careful with terminology.
- Meanings of terms have often changed since the original spec was written.
- What's easiest for various probing?
- Pin or ball is easiest. But with faster edge rates the package and on-die
interconnect are increasingly important, and probing there is less useful.
- If you have a die without a package, it's easy to probe "after" (Tx sense)
the on-die interconnect, what we call the die pad.
- I would argue the hardest thing to probe is the at the buffer.
- Bob R.: If doing it by simulation you'd have access to that point.
- But the purpose is not to defend the choice of locations.
- The purpose of this is for completeness and consistency of terminology.
- Remember that with an interconnect model you can now go directly from the
buffer to the pin, and you no longer have access to the "pad" location in
that case.
- Michael M.: What do Vref, Rref, etc., mean?
- Are they before or after the on-die interconnect, or at the pin?
- We need to be clear.
- Bob R.: That's why the Si_location is important. It gives the location where
they are specified.
- Ambrish/Arpad: This is also related to the A_to_D probing locations in
[External Model].
- Arpad: In the current spec, for a receiver model you can put the A_to_D at
the pad or at the core side of the receiver model.
- With BIRD 189 interconnect modeling separating pad and buffer, we would
probably also have to extend the A_to_D location to have a pad option, a
core side option, and a buffer terminal option.
- Arpad: This is why I'm concerned that we are opening a bigger can of worms.
- From an SI perspective we are probably more interested in the buffer
waveforms than the pad waveforms, now that they are separate. Wouldn't
it be easier to just make the "die" location now mean the buffer terminal?
Do we need to go from two choices to three? Instead of adding a third
option, just change the meaning of "die" to the buffer terminal.
- It seems like this will have a lot of ramifications.
- Bob R.: It will be introduced at the next Open Forum meeting.
- Something needs to be done because we use "die-pad" in BIRD 189.
- If we went with something like Arpad's suggestion (to change the meaning of
"die" for Si_location and Timing_location), we would then at least need a
statement that buffer location and "die" location are considered the same
even when using an interconnect model.
BIRD 158.6:
- Discussion: Arpad noted that he had a significant list of comments based on
BIRD 158.6 draft 1. Bob R. noted that the term "pad" was used in the draft
but not defined in any drawings or figures. He felt this should be clarified
to ensure there was no confusion with Interconnect Model "pad" terminology.
Arpad said he would send his comments to the ATM reflector so everyone could
review them. Radek said editorial changes could be made before the next
meeting, but since we had discussed technical issues at the last meeting he
preferred not to make any technical changes unless they were discussed during
a meeting first.
BIRD161.2 Supporting Incomplete and Buffer-only [Component] Descriptions:
- Michael M: If BIRD 191 is adopted, I believe BIRD 161 becomes less important
and can be deferred until after 7.0.
- First introduced in 2013.
- Tried to do some of the same things Bob R. is doing in BIRD 191.
- Address the fact that Timing_location and Si_location needed to be updated
in light of the new Interconnect rules.
- BIRD 161 contained some other interconnect related statements that BIRD 189
has now made obsolete.
- This new draft removes everything that is addressed in BIRD 189.
- It now focuses on adding two new Sub-Params to [Component].
- Scope
- Allowed values "Complete" or "Partial" (default "Complete").
- Specifies whether the [Component] describes a complete manufactured
device, or whether it's a partial description.
- "Partial" [Component] might only define one [Pin] and use one [Model].
- Ideally every .ibs file would a have full [Pin] list for an entire
component. This rarely happens, and it can be a pain at the beginning
of development. IBIS rules prevent me from just giving someone a
[Model], I'm forced to distribute a [Component].
- Scope Sub-Param allows the model maker to tell the recipient whether
the [Component] is meant to define a real component or not.
- This is a better approach than simply making it legal to not provide
a [Component] keyword.
- Pin_reference
- Related to Scope.
- Specifies whether [Pin] entries really mean pins, or just the buffer, or
buffer and on-die interconnect.
- Allowed values "Pin", "Die", "Buffer" (default "Pin").
- Pin_reference makes it easier to tell the user what is included. Many
keywords ([Pin], [Diff Pin], etc.) by their very name imply Pin,
which may not be correct for a "Partial" model.
- At the very least, we need "Scope" in order to support incomplete (e.g.,
buffer-only) descriptions.
- Bob R.: I think there's a lot of very complicated vetting for this.
- [Pin], [Diff Pin], [Pin Mapping], etc., there could be a lot of effects.
- I don't think we should consider it for 7.0.
- This Scope might be useful purely as information for the user, but I might
recommend EDA tools simply ignore it.
- The term "Partial" vs. "Complete" (or incomplete) has other connotations.
- Michael M: I agree with most of what you said, but let's not assume IBIS is
only for those who sell complete packaged parts.
- For example, an IP vendor may have a complete description of an IP buffer
set, and that should be legal to distribute to a package vendor.
- Bob R.: It is legal, you'd just put in a default zeroed out [Pkg], etc.
- All you need to have a "complete" IBIS model is that every pin in the [Pin]
list is associated with a model (including rails, NC, etc.).
- As a practical requirement we said the model "shall" document all the pins.
- We've reduced that to "should" or "recommend" it should.
- Language used in this BIRD may not be consistent with Interconnect parlance.
- Arpad: I reviewed it too.
- I do see the areas that could be removed from it, and I see the new text.
- We will need to review its verbiage very carefully, because after the
removal of some of the old text the verbiage becomes inconsistent and/or
confusing.
- Michael M: Agreed.
- Mike L.: Most of the models I see are buffer-only models.
- There are many of them out in the world.
- I do see some benefits from putting models in one category or another.
- EDA tools might be able to deal with them differently or offer only the
appropriate ones to the user.
- I do see an issue with terminology.
- There's a continuum. One file might only have one buffer and everything
else is invented overhead. The other extreme would be a fully complete
[Component] for an actual part.
- What's desired here is a binary flag to indicate when you have "buffers
only", but use of "Complete" or "Partial" implies something else.
- Maybe we could change the allowed values to "buffers-only" vs. something
else.
- Bob R.: As an example of Mike's point, it's real to offer an ASIC library
of various buffer models all packaged into one big [Pin] list, and
the intent is just to provide buffer models.
- Ken/Mike L. - FPGA models do that all the time.
- Michael M: Motion to table BIRD 161.
- Bob R.: Second. [no one opposed]
BIRD 190:
- Ambrish: I just wanted to revisit this quickly.
- I'm hoping everyone will agree that it's only a warning for the time domain
redriver flow.
- Someone who comes across the repeater section may not look back to the
warning in the single channel flow.
- Let's keep the flows simple.
- Arpad: Is this scheduled for a vote in the Open Forum?
- Walter: It is eligibile, but not scheduled.
- The repeater flow references doing things according to the normal single
channel flow. That section already has the warning words Ambrish wants.
- Passing this would reaffirm what I believe we know is an incorrect flow.
- Arpad: Do we need more discussion here, or do we go to the Open Forum?
- Ambrish: I would want to get consensus here in ATM before I would put it up
for a vote in the Open Forum.
- We haven't really specifically voted on this in the ATM strictly on the
merits of this BIRD. We had a straw poll that may have been under the
assumption that this affects the statistical flow too.
- Walter: Let's have a discussion next week, and then we can make a
recommendation to the Open Forum.
- Ambrish: Motion to adjourn.
- Mike L.: Second.
- Arpad: Thank you all for joining.
AR: Arpad to email his BIRD 158.6 draft 1 comments to the ATM reflector.
-------------
Next meeting: 18 July 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives