Minutes from the 24 May 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
24-MAY-2016 Fangyi Rao Keysight Technologies AMI Simulation Flow Round 3 v5
(zip
<http://ibis.org/macromodel_wip/archive/20160524/fangyirao/AMI_Simulation_Flow_Round_3_v5.zip>
)(pptx
<http://ibis.org/macromodel_wip/archive/20160524/fangyirao/AMI%20Simulation%20Flow%20Round%203%20v5/AMI_flow_round3_v5.pptx>
)
IBIS Macromodel Task Group
Meeting date: 24 May 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
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
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Luis had joined the ATM meetings previously when he was with ANSYS. Arpad
asked him to briefly reintroduce himself in his new role with IBM. Luis said
he is working with the signal integrity team for the OpenPOWER Consortium, and
that they will be producing IBIS-AMI models for their customers.
-------------
Review of ARs:
- Ambrish to send the latest BIRD 147 draft to Bob and Walter, as requested.
- Done.
- Ambrish to check for a collaborator's feedback on his nearly ready new
version of the Backchannel proposal.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Dan: Motion to approve the minutes.
- Ambrish: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
[Pin Reference] BIRD Draft:
- Arpad: We did discuss this last week in Walter's absence.
- Were you able to follow that discussion in the minutes, Walter?
- Walter: Yes, I kept up with the minutes.
- My response to last week's discussion is that there are two distinct issues.
- 1. There's just a shift in voltage for a device under test.
- What's connected to the gc_ref is not 0V, but some non-zero voltage
relative to the simulator's node 0.
- How do you adjust the value of the voltage at the I/O pad in order to
compare that correctly with thresholds in the IBIS file (e.g. Vinl)?
- This would be the oft discussed case of VSS=1000V and VDD=1005V and
the buffer should still work fine and the threshold should be 1002.5V.
- 2. A device under test has 0V for its [GND Clamp Reference] and 5V for its
[POWER Clamp Reference], but at simulation time the device in action
sees a 6V difference between pc_ref and gc_ref. How should the
thresholds be adjusted in that scenario?
- [Receiver Thresholds] offered one way to deal with that.
- Bob added a bunch of stuff to draft 3 of the BIRD to deal with this
second issue, but it's a separate issue.
- I think the way to deal with this would be to add a "technology"
keyword with values like CMOS, TTL, ECL, PECL, etc.
- We could add rules for each technology that specify how thresholds
change.
- Arpad: I think the original purpose of this BIRD draft was to help the Friday
editorial meetings with their "ground" problems.
- I understand this second issue seems like mission creep.
- I would suggest a minimalist approach. Let us only cover what is needed for
the editorial task group, but do it in such a way that we can expand upon it
at a later time.
- Walter: I don't think editorial is waiting on it.
- I think they are expecting something like this [Pin Reference] BIRD to deal
with these issues.
- I would like to defer to the editorial group and see what they need.
- Mike L.: This is a new keyword.
- It would not have wide spread impact.
- It won't hurt the editorial group if it doesn't come along until later.
- Arpad: If the editorial work has this BIRD as a dependency, can they move
forward?
- What if this BIRD fails to be approved later?
- Bob: I have a slightly different view than was presented here.
- This group might be the better group to resolve some technical issues we
haven't really resolved.
- But I don't think this is holding up editorial.
- Walter: Motion to table this BIRD here.
- Dan: Second.
- Arpad: Anyone opposed? [none]
SPI 2016 report: [Walter asked to talk about SPI briefly]
- Walter:
- About 110 registered participants.
- Mostly from Europe, perhaps 15 or 20 from Asia.
- Several interesting papers related to IBIS I/O methodology.
- Interesting and different approaches to our current I/V and v(t) Models.
- One with v(t) tables but using 3 columns per corner.
- One that was not table driven at all.
- Some were admittedly science projects not ready for prime time.
- My response to everyone was that they were all interesting approaches, but
it is going to be very hard to get something through IBIS if EDA vendors
will have to adopt something different than the existing K(t) methodology.
- My suggestion to them was that rather than come up with a different table
driven scheme where the EDA tools have to figure it out, perhaps we should
come up with a .dll interface with the [External Model]. The .dll could
even read tables, but I was just imagining how tough it would be to get
some of these new methodologies through IBIS.
- I also had conversations with a number of people on package models and their
particular methods for doing power integrity.
- There was certainly no consensus on one right way to do it.
- I did come away convinced that the approach we are taking with the
interconnect task group would satisfy the needs of all of their different
power integrity methodologies.
- Bob: Could you elaborate on the different power integrity approaches?
- Walter: It's not uncommon that they would have separate power and data models.
- The most complicated models lumped all of the grounds at the IC together
and all the Pins together. So you could not have nodes per pin, it was
nodes per each of what we call signal_name.
- Some used SPICE models for the power and SPICE models for the interconnect
and a totally different methodology for coupling the two.
- Some approaches said, "it's just an impedance problem, you find out the
impedance of the board and that's the impedance requirement for the
package."
- Some simulations took days. Some used noise budgets. There were lots of
research projects.
- Bob: Many of these are PhD students presenting, and we've kept in touch with
many of them over many years.
- Walter: Some given by PhD students, some by professors, one by Intel.
- It was varied, not all academic.
- Keysight gave a nice boot camp on power and signal integrity.
- All the papers are published and one can read them.
- Arpad: Walter, you mentioned something about Touchstone v2.0 in one of your
email reports. Can you elaborate?
- Walter: I am on the IEEE SA - P370 group, which is dealing with standards for
s-parameter data measurements.
- Several people on that committee happened to be at SPI.
- When I mentioned Touchstone v2.0 I got some sour responses from people.
- I suggested that we document some of the things they were doing with respect
to quality of s-parameter data and gather some of them into an enhanced
Touchstone v2.0, and they said, "Don't even bother, no one wants to touch
Touchstone v2.0 with a ten-foot pole."
- They said that "no tools read it and no tools write it." Obviously "no"
is an overstatement, but there are so many internal, non-commercial tools
people use that parse Touchstone files but don't support v2.0 that it is
just unacceptable to the industry.
- The only thing Touchstone v2.0 has that addressed a real need for people
was per port impedance. If that was all that had been added it might have
been adopted more widely.
- But something as simple as removing the requirement for .sNp as the file
extension was a deal breaker because so many tools relied on it.
- Feedback I got was that they would like IBIS to do something, but don't
change the Touchstone format. Leave Touchstone v1.0 as it is. Perhaps
add one change for impedance per port. Perhaps define a side file that
will define the near end, far end, and differential pairs without
complicating the Touchstone file.
- I have heard about, but not personally seen, the existence of one
Touchstone v2.0 file.
- Arpad: If Touchstone v2.0 does more than they want, why can't they just use
part of it?
- Walter: It's the whole structure. To use it at all you need to add in a bunch
of new parts that break existing readers.
C_Comp Improvements:
- Discussion: Randy said he had recently reviewed the most recent draft, which
was almost a year old. He said he needed to make some updates based on new
decisions that had been made for the interconnect BIRD. He said he would
update it and present it to the group at a future meeting.
- New Redriver Flow:
- Fangyi: [sharing his updated "AMI Simulation Flow Round 3" version 5]
- I've updated the parameters according to the discussion we had in the
meeting two weeks ago.
- [Slide 12 - New Reserved Parameters]
- Last time we talked about changing back to a two parameter approach
because people didn't like the bi-directional parameter approach.
- Two parameters:
- Support_Proposed_Flow
- Rx parameter, Info, Boolean, default=false
- This parameter tells the simulator whether the Rx model supports the
proposed flow.
- Use_Proposed_Flow
- Rx parameter, In, Boolean, default=false.
- This parameter tells the model if the EDA tool is using the 6.1
flow or the new proposed flow.
- These parameter names are not finalized.
- [Slide 13 - contains a truth table for Parameter settings]
- If Support_Proposed_Flow is false:
- Tool and model must use 6.1 flow.
- Tool cannot set Use_Proposed_Flow to true (illegal).
- If Support_Proposed_Flow is true:
- Simulator can still set Use_Proposed_Flow to false to use the old 6.1
flow.
- Simulator can set Use_Proposed_Flow to true and then the tool and model
will use the new proposed flow.
- Discussion: Fangyi asked the group if we should require a model that supports
the new flow to also support the old flow. Mike suggested that the question
amounted to weighing the work imposed on the model maker for mandatory support
of the old flow vs. the potential reputation issues for IBIS-AMI if we allowed
a new class of models (new proposed flow only) that simply wouldn't work with
any older tools. Walter said that he was fine with going to a two parameter
approach, but that we should require models to support the old flow. He said
that it should be easy for a model maker supporting the new flow to also
support the old flow. Fangyi agreed that it should not be a big deal for a
model that will support the new flow to also support the old flow. Arpad
said that if that were true then we should make support for the old flow
mandatory. No one in the group disagreed with the decision to keep support
for the old flow mandatory. Arpad did raise the question of how long the spec
would make support for the old flow mandatory. Curtis said that since we have
the AMI_version parameter, we could wait until a future revision and decide to
deprecate it then. Fangyi agreed. Walter said he thought we probably never
would or should deprecate it. Bob suggested that we should come up with
better
names than "new" (proposed) and "old" (6.1) flow. Mike agreed that the sooner
we came up with the final names the better. Mike noted that we had previously
discussed this in the context of DFE, and he had wondered if we could come up
with a more general category. He suggested we might use terms like a "one
impulse response" flow and a "two impulse response" flow.
- Michael M.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 31 May 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives