Minutes from the 20 December ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has 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
20-DEC-2016 Arpad Muranyi Mentor Graphics BIRD 158 models with official
IBIS syntax (zip
<http://ibis.org/macromodel_wip/archive/20161220/arpadmuranyi/BIRD_158_models_with_official_IBIS_syntax.zip>
)(pdf
<http://ibis.org/macromodel_wip/archive/20161220/arpadmuranyi/BIRD%20158%20models%20with%20official%20IBIS%20syntax/BIRD158_with_Official_IBIS.pdf>
)
The following document, which was discussed during the meeting, has been
posted as a BIRD update.
187.1 Format and Usage Out Clarifications
<http://ibis.org/birds/bird187.1.docx> Michael Mirmak, Intel
Corporation December
13, 2016, December 16, 2016
IBIS Macromodel Task Group
Meeting date: 20 December 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:
- Reminder: The meeting on December 27th is cancelled.
- Arpad thanked the group for all the effort and accomplishments in 2016.
-------------
Review of ARs:
- Michael M. to submit the Deterministic Noise Support BIRD draft, with the
discussed changes, to the Open Forum.
- Done. Submitted as BIRD 188.
- Michael M. to submit the Format and Usage Out Clarifications BIRD draft, with
the discussed changes, to the Open Forum.
- Done. Submitted as BIRD 187.
- Arpad to email Vladimir and Fangyi to discuss moving forward with BIRD 166 or
their proposal.
- Done. (see below)
- Walter and Radek to review BIRD 158.3.
- Done. Walter noted that he and Radek had discussed it and come to a good
agreement on how to proceed. Walter said he had prepared an updated BIRD
that we could review. Radek noted that they agreed in principle, but would
also be interested in getting Fangyi's input.
- Arpad to produce some slides on converting between BIRD 158.3 syntax and
the equivalent [External Model] (BIRD 160) syntax.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Michael M.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Bob Ross and Radek's discussion of Editorial Task Group Issues:
- Bob: [sharing [Local Reference] keyword draft 6]
- Radek and I met yesterday.
- [Local Reference] keyword explicitly provides attachments to the various
capacitances, unless some other Sub-Param like C_comp_pullup overrides it.
- We discussed terminology and stuck with "node" here, although "terminal" is
used in BIRD 181.
- Default value is zero if not given.
- The associated Local_ref node defines a common reference.
- Certain blocks of text may be positioned elsewhere and referred to by other
reference keywords. Another BIRD could potentially add references to this
new text from other reference keyword sections.
- We have the "node collapse" rule, where if two [* Reference] keywords have
the same voltage values for all three corner cases then they can be
considered one rail.
- Arpad: I might prefer "merged nodes" or "shorted nodes" to "collapsed nodes."
- Bob: I like merged nodes.
- Radek: Agreed.
- Bob: However, we also might have to deal with a case where the [* Reference]
voltages are the same, but due to routing issues you might have separate
paths and unique nodes.
- If the [Pin Mapping] specifies different bus labels for two *_ref nodes that
would otherwise have been merged, then the nodes are not merged.
- Deciding which node would be the local reference node in such a case is
something we are considering.
- Radek: The point we got stuck on is whether we should allow the case in which
all of the [* Reference] keywords have non-zero values.
- This would be consistent with the current spec.
- This case is probably not practical.
- It could perhaps be handled with a parser warning.
- The model maker may have reasons for doing it.
- If the Local_ref we are adding here is not the same as one of the other
*_ref nodes, then we have that same situation.
- We may want to disallow it, but we don't have a solution at this point.
- Walter: As a solution, could we say that if this situation arises, then power-
aware simulations will require a ground based reference system, as
was proposed by Scott McMorrow?
- There's a legal way to do that with a ground based reference system.
- It's only an issue if you want to do power-aware simulations.
- Radek: Agreed, if you aren't concerned with power-aware simulations then it's
a no brainer and you bias the model as given in the [* Reference]
keywords and everything is fine.
- Bob: We can add something like Walter's statement.
- Radek: That statement effectively uses the GND (local reference) node as part
of the simulation model.
- The [Pin Reference] solution suggested in another proposal is the solution
for the power-aware case.
- Bob: That might be where we aren't in agreement.
- I don't think we should need [Pin Reference].
- This should be sufficient without it.
- We can avoid this pathological case where the Local_ref is different than
all the other *_ref nodes.
- Radek: The Local_ref is intended to provide a means for connecting the
C_comp, C_pin, C Package matrices. This is not really provided by the
current spec.
- Radek: That's a good summary of where we are, but we are not done.
BIRD 166:
- Arpad: [sharing Fangyi's email response regarding proceeding with BIRD 166]
- Arpad: Fangyi's email arrived recently. He states that BIRD 166 really only
covers one special case, and it does not work when cross talk is
present. He doesn't think moving forward with BIRD 166 by itself will
be sufficient. Fangyi hopes to work on his proposal and have an update
in January.
IBIS 6.2 discussion (what is needed to complete it?):
- Michael M: [sharing BIRD 187.1]
- This new update to BIRD 187 might be relevant to this topic.
- At the last Open Forum and ATM meetings, several people noted that there was
some additional text related to Usage Out parameters that occurred later on
in the specification, beyond the scope of the text originally considered in
BIRD 187.
- This new 187.1 adds a lot of additional text just to explicitly state and
clarify what is in the specification without changing it.
- There are some small enhancements to Increment, Step, and Corner rules.
- Arpad: I ask the entire group to take it as an AR to review 187.1.
BIRD 158 syntax vs. "official" BIRD 160 syntax.
- Arpad: [Sharing 'How to write BIRD 158 Models with "official" IBIS syntax']
- [Slides 1, 2, 3]
- Introduction and background on BIRD 158 vs. BIRD 160.
- [Slide 4] (see below)
- [Slide 5] BIRD 158 Tx .ami file excerpt and diagram
- Note: "Model Specific" would become "Reserved" if BIRD 158 were approved.
- Example uses Tx_V, Tx_R, Tstonefile parameters.
- [Slides 6-7] The same Tx model with BIRD 160 syntax
- IBIS_ISS language.
- ISS_wrapper.inc contains subcircuits.
- Unique subcircuit for each corner case.
- Three D_to_A converters for the corner cases of the Non-Inverting Pin.
- Three D_to_A converters for the corner cases of the Inverting Pin.
- Note that the [Ramp] keyword and trise/tfall contain identical slew rates.
- RefNode in the subcircuit could be the reference node for the D_to_As.
- This is just one example of a way to implement it. There are others.
Multiple individual subcircuits could probably be reduced to one
subcircuit if parameter passing were used.
- Discussion: Bob asked about the RefNode usage. Arpad said that the s4p
has five terminals when a common reference is used. Radek commented that
the [External Model]'s A_gnd port could serve this purpose. Bob noted
that BIRD 158 implicitly uses node 0 for this. Radek also noted that
BIRD 158 would dispense with the slew rate from the D_to_A or [Ramp]
and assume everything is in the S-parameter file and the step used to
calculate the impulse response should be "ideal".
- [Slide 8] BIRD 158 Rx .ami file excerpt and diagram
- Example uses Tstonefile and Rx_R.
- [Slides 9-10] The same Rx model with BIRD 160 syntax
- Again one subcircuit for each corner.
- Since we were just discussing referencing, note that the R is just
connected to node 0 in the subcircuit.
- This model uses an A_to_D.
- The IBIS spec allows you to connect the A_to_D so it probes at the pad or
the core side. In this example we are looking at the core side, so we
see the results after passing through the S-parameter block.
- [Slide 4] Comparing BIRD 158 and 160.
- BIRD 158 places the Tstonefile parameter in the .ami file.
- It is only available to AMI simulations.
- That may provide performance advantages. For example, it might
eliminate the need for a time domain channel characterization.
- BIRD 160 uses [External Model] to wrap the S-parameters.
- It is generally available to any IBIS simulation.
- Channel characterization would normally be done in time domain.
- This has performance and possibly accuracy issues.
- However, an EDA tool could detect when the Tx and Rx [External Model]s
were each simply wrappers for an .s4p, and in that case the EDA tool
could apply BIRD 158 simulation flow automatically. For example,
staying in frequency domain for channel characterization if possible.
- Discussion: Walter noted that while the last statement (the EDA tool could
detect when External Models were merely wrapping .s4p files) was possible
in principle, in practice it was onerous. The tool would have to parse
through both the [External Model] sections of the models and the included
subcircuits, all in the hope of discovering that it was as simple as the
special case shortcut provided by BIRD 158. Arpad noted that he sometimes
liked to run only the analog portions of an AMI model as a basic startup
step. BIRD 158 would push this processing into the AMI engine. Walter said
that BIRD 158 defined Usage Info parameters that were generally available to
the EDA tool for any simulation. Since none of the processing of the
interconnect model was pushed down into the AMI model (Usage In parameters),
there was no restriction on how the EDA tool could make use of the information
in the BIRD 158 parameters. Radek noted that it was really a question of what
the model maker wanted to do. Did they want the BIRD 158 shortcut, or the
perhaps more general BIRD 160. If both approaches were available to the model
makers, then there would be no need to translate between the two. Radek noted
that the BIRD 160 approach might contain a non-linear representation of the
IBIS buffer, and the AMI simulation only extracts some linear representation
of it for use in AMI. Bob noted that it could be done either way. If the
S-parameter data required a slew rate limited input, then the legacy approach
with [Ramp] could be used. If the S-parameter data contained the buffer
characterization, then the BIRD 158 ideal step approach should be used.
- Walter [referring back to slide 5 - BIRD 158 AMI Tx]
- In my current BIRD 158.4 I'm still using this picture (with two distinct
voltage sources).
- I think a simpler and more effective picture would be to consider a pure
differential source between the two pins, without a reference to local
ground.
- That would eliminate the local ground from the Tx. I'm not sure if it's
easy to eliminate it from the receiver.
- Originally I had two separate voltage values, Tx_Voh and Tx_Vol, for the
sources on each line to try to handle common mode. But that is what
caused some concern for Radek.
- Arpad: Going to differential would also simplify my D_to_A converter, and
port1 and port2 of the D_to_A could just be the inverting and
non-inverting terminals. We could eliminate the extra steps there
for the common reference.
- Radek: You do have the reference node for the S-parameters.
- This does not have to be GND. It can be a common node on the Tx and Rx
sides.
- Depending on the data in your S-parameters file, you should not ignore the
common mode. The sources and the output should be connected to the same
node as the reference node of the S-parameter data.
- Arpad/Radek: Yes, we can talk about it further.
- Bob: It sounds like we already have a solution with BIRD 160.
- Walter: We don't have a good solution for people who want to stay in the
frequency domain.
- We just described multiple ways of describing these depending on single-
ended or differential D_to_A, how you terminate the Touchstone circuit,
etc.
- For people who are doing frequency domain IR generation, we do not have
a very good way of conveying this information to the tool.
- Bob/Arpad: Yes, there are pluses and minuses to each.
- Walter: There is a common solution.
- We could make the BIRD 158 parameters Reserved (approve it).
- That provides the shortcut.
- You could also implement all those parameters using the BIRD 160 approach,
and then we have a solution for both ways.
- Bob: Motion to adjourn.
- Michael M.: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 03 January 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
