Minutes from the 27 June 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
27-JUN-2017 Radek Biernacki Keysight Technologies BIRD 158.6 draft 2 (zip
<http://ibis.org/atm_wip/archive/20170627/radekbiernacki/BIRD_158_6_draft_2.zip>
)(docx
<http://ibis.org/atm_wip/archive/20170627/radekbiernacki/BIRD%20158.6%20draft%202/BIRD_158.6_draft2.docx>
)
IBIS Macromodel Task Group
Meeting date: 27 June 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: The meeting next week (July 4th) is cancelled. We will meet again in
two weeks.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Bob M.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD 158.6:
- Arpad: Radek has a new draft of BIRD 158.6 to discuss.
- Radek: I would like to introduce it here, and then we can post it.
- [sharing the new draft]
- This incorporates comments from the discussions that started after Michael
Mirmak's comments on 158.5.
- We waited for BIRD 186 to be finalized so we could apply the same language
related to file references.
- "Step response" was not mentioned elsewhere in the spec, so we removed it.
- Incorporated discussion related to how much the Ts4file describes (buffer,
buffer plus on die, buffer plus on die plus package).
- New Section: 10.x ALTERNATIVE AMI ANALOG BUFFER MODELING
- Tx and Rx circuit diagrams unchanged, but their titles are changed.
- Discussion of package:
- Tx and Rx diagram indicate "buffer terminals".
- The overall circuit diagram is consistent with that. It shows the
"package" block in the user setup portion of the figure.
- The following paragraph explains, "...package model is added to the
channel by the user... In any case the package and possibly the on-die
interconnect data associated with the IBIS Model...shall not be
automatically incorporated into the above schematic by the EDA tool."
- Arpad: I understand that what the Ts4file includes will be defined by
Ts4file_Boundary.
- But I was expecting that the package information provided by the IBIS
file, particularly if it's BIRD 189, could be applied by the tool.
- Is this BIRD saying the user will always have to add the package
manually?
- Radek: This language has to specify what the default intent is.
- The intent is as described here, because if the EDA tool automatically
includes something from the IBIS model then you may deprive the user of
the chance to add their own separate package.
- We do have cases where model makers distribute separate (external to IBIS)
package model files.
- It is still possible for the EDA tool to add the package information, if
it first offers that choice to the user.
- "...shall not be automatically..." - Automatically means without user
interaction.
- Michael M.: Does that mean we don't need to set a hierarchy assumption for
traditional IBIS package vs. BIRD 189 [Interconnect Model Set
Selector] vs. Ts4file_Boundary?
- Radek: We don't specify that here. We leave the freedom to the user.
- The EDA tool may find a way to free the user of having to manually add the
package information, but we want the user to have the choice.
- As default behavior we don't want the EDA tool automatically adding any
package information without the user's input.
- Walter: In our tool, we give the user options: no package at all, legacy RLC
lumped, legacy [Package Model] (coupled matrix or path type), and we
also have our own scheme similar to BIRD 189.
- Whatever the user chooses, this 4-port gets hooked up to that.
- This would be exactly the same if you replaced these Ts4files with
[External Model]s.
- Arpad: Should we have an optional parameter to specify whether a legacy IBIS
package or BIRD 189 package should be used automatically, so the user
doesn't have to do it manually all the time?
- Walter: The tool could simply follow the Ts4file_Boundary parameter and decide
what to include based on that.
- Arpad: No, because what Radek is saying has merit. What if the IBIS [Model]
just includes useless old RLC package values and the user wants to
override that. Today the user might zero it out, or comment it out,
and then place their own package model on the schematic. But that
might require modifying the IBIS file.
- Why can't we just have a parameter that does the same thing and gives
the choice of using IBIS keywords or having the user do things manually.
- Walter: That's not a boundary on the Ts4file, it's a [Model] boundary.
- Arpad: Yes, it's a separate parameter.
- Radek: That would be defining the boundary on the "User Setup" portion of the
schematic diagram.
- We could add a parameter like that and the EDA tool could choose to use it.
- But Walter described a tool that already gives the user the choice, and
that's a good way to do it. We just don't want the tool to put something in
automatically and keep the user in the dark and end up double counting.
- Walter: Since Ts4file_Boundary defaults to "pad", and since for legacy models
pad = buffer, I think we are okay.
- Since the legacy package model keywords hook up to the buffer, and the
default of Ts4file_Boundary is legacy buffer, then you can just use whatever
you are using today in IBIS to determine your package model.
- Arpad: The current wording explicitly says the EDA tool should not do that.
- Radek: The EDA tool should not do it automatically.
- Walter: I'm fine with the current wording. I think it allows tools to give
the user the choice of what to do.
- Mike L.: What is the meaning when Ts4file_Boundary is "buffer".
- [looking at the Rx diagram] - 2 and 4 are already at the buffer?
- Radek: 2 and 4 are at the decision point.
- Mike L.: I see, so if it's "buffer" then the Ts4file contains just the
analog portion of the buffer (no on-die interconnect).
- Radek: I will send this out.
- I think we are fine with this language. We are not imposing any replacement
of the package, it just has to be left to the user to choose.
- Walter: Are we ready to recommend BIRD 158 to the Open Forum?
- Arpad: I hate to delay another two weeks, but we should get it posted and give
everyone a chance to carefully review it.
- BIRD 190:
- Ambrish: Motion to untable BIRD 190.
- Radek: Second. [none opposed]
- Ambrish: This was introduced and discussed at the Open Forum meeting along
with a presentation from Walter.
- Walter's objections were based on statistical flow.
- BIRD 190 doesn't mention anything about statistical simulation. It's in the
time domain section.
- Therefore, I'd like to discuss it again.
- The reasons are the same ones we brought forth when the BIRD was introduced.
- This is a restatement of a warning from the single channel flow.
- Walter: I object. I think BIRD 190 should not be considered until we fix the
flow with BIRD 166 or Fangyi's proposal.
- Ambrish pointed out that BIRD 190's comments are in the time domain section.
- I think the flow is wrong in both statistical and time domains.
- [sharing email exchange with Ambrish]
- I agree it applies to time domain.
- But if any of the models has GetWave_Exists = false, then the output of
Rx AMI_Init() is used in time domain.
- If all of the models are Init Only, then the output of Rx2's AMI_Init()
is used for time domain simulations.
- Opening sentence of BIRD 190 text:
- "The Rx2 executable model file writer for the downstream channels with
Redrivers..."
- But the model maker may have no idea if there's a redriver or retimer in
front of their model.
- Normally the model maker creates it for a single channel, and if the
channel gets too long, noisy, etc., the system designer might add in a
redriver.
- Bob M.: I would just note that some model makers probably know there will not
be a redriver in front of them. For example, high performance ASIC
channels where the use of a redriver is fundamentally impossible.
- I mention this just in terms of the difference between a necessary condition
or a sufficient condition for the warning prescribed in BIRD 190.
- Walter: My experience with 802.3 channels is that a design starts without a
redriver and then later it gets added.
- [continuing review of BIRD 190]
- The person designing the model already assumes the input to the model is
valid.
- The model maker already has to assume the IR input to Init() isn't complete.
- So the model has to handle manual settings (optimization off), and that's
true for a redriver or a normal channel case.
- The time domain flow for redrivers just refers back to the single channel
flow. That single channel flow already contains this warning paragraph.
- Adding it here, the "does not include the effects..." is just repeating
the fundamental problem for why 6.1 gives the wrong answer.
- Ambrish: This is not about statistical analysis.
- Walter: If all of the models are Init Only, the standard says to convolve the
output of Rx2 Init() with the digital stimulus to Tx1.
- Fangyi/Ambrish: No.
- Ambrish: The output of channel 1 is used as the input to channel 2.
- Discussion: Fangyi/Ambrish and Walter continued to disagree with certain
assumptions and interpretations in each other's arguments and counter
examples with respect to BIRD 166. Arpad asked if Fangyi had an update
on his proposal, which last week's straw poll had shown support for pursuing.
Arpad asked if Fangyi's proposal could be made to address legacy IBIS models,
perhaps by way of the multiple-calls-to-Init() suggestion Arpad had made.
Fangyi said his proposal did not address legacy models. Fangyi and Walter
said they had thought about the multiple-calls-to-Init() approach and didn't
think it could solve the legacy model issue. Walter asserted that BIRD 166
and Fangyi's proposal were orthogonal in the sense that BIRD 166 changed a
flow that Fangyi's BIRD didn't address. Arpad noted that Fangyi had presented
an example in which BIRD 166 made things worse. Walter said he felt that
example was specious and based on incorrect assumptions. Arpad asked the
various parties to work out these differences of opinion, and said he hoped it
was just a miscommunication. Walter suggested there were actual disagreements
about the underlying math.
- Michael M.: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
AR: Radek to send BIRD 158.6 draft 2 to Mike L. for posting to the ATM work
archive.
-------------
Next meeting: 11 July 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
