Minutes from the 23 June 2015 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 23 June 2015
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Avago (LSI) Xingdong Dai
Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC * David Banas
Marc Kowalski
Ericsson: Anders Ekholm
IBM Steve Parker
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
Radek Biernacki
* Nicholas Tzou
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
(Note: Agilent has changed to Keysight)
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- Arpad: Walter is not here today.
- Topic was to be GND cleanup in the IBIS spec.
- Walter did send us a draft last Friday.
- We could discuss, but if that doesn't go far we may have a short meeting.
- Bob: I don't recall receiving the draft. Was it private?
- Arpad: [Reviewing email distribution list]
- It was sent to Mike LaBonte, Radek, Fangyi, Michael Mirmak, Todd and me.
- I guess it was semi-private.
- I would have forwarded it to the group if I had noticed.
- Arpad: Does anyone have any discussion topics that aren't on the agenda?
- Michael M: If we run out of topics, I'd like to suggest we go through the
existing list of open BIRDs from the Open Forum list.
- See how they're being disposed of.
- Some are being handled through the interconnect improvements.
- If any are pending that should be dealt with here, perhaps we should add
them to your list.
- Arpad: That's a good suggestion. We could do that.
- Any other Opens for today's meeting? [none]
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- None.
- Curtis: We did not record any ARs last week.
- One thing to mention.
- Walter replied with two minor corrections to make sure the spirit of his
comments were properly reflected in the minutes.
- I sent an update with Walter's corrections to Mike LaBonte.
- The original minutes and the modified version are both posted.
- Arpad:
- This reminds me of a conversation Curtis and I had after the last meeting.
- Curtis asked me if I wanted to review minutes before he posted them.
- I replied that I had read all the minutes he had taken previously, and I
trust his notes because they have been really good.
- I didn't think it was necessary for me to approve every set of minutes.
- But that raised the question, should we do it more formally and have the
minutes approved here in this meeting, like we do in the Open Forum?
- Michael M., would you have a suggestion on that?
- Michael M.: It probably would be the right thing to do, not just for this
meeting but for all of the meetings.
- It would be good to have a formal flow for this.
- I'd like to suggest we adopt an Open Forum like minutes flow.
- Michael L.: I've seen some different practices for that.
- Some meetings will literally read the last meeting's minutes verbatim.
- Another practice is to have one attending member asked to review them.
- Arpad: To have a designated person to do that approval?
- Michael L: Advantage to that is one person to do it and it takes up less time.
- Arpad: I'm worried about that approach.
- If just one person reviews them then it might not serve the intended
purposes
of preventing accidental or deliberate misstatements.
- Bob: I like the idea of putting them out for everybody.
- Encourage people to review them and submit corrections via email.
- Michael L: Another approach is what we do in Open Forum meetings.
- Topic is on the agenda.
- Ask if anyone has comments or corrections on the previous meeting's minutes.
- Then a motion to approve.
- Arpad: I agree with that. Just like we do it in the Open Forum.
- Michael L: Gives everyone an opportunity, but doesn't take much time.
- Arpad: If no one reads the minutes then it's our own problem ;-)
- I don't think we will run into malicious intent with any of our groups.
- Arpad: I would like to formalize this.
- Do we have a motion to instate this extra step in our meetings?
- Michael M.: I so move.
- Michael L.: I so second.
- Arpad: Anyone opposed to reviewing minutes each meeting? [none]
-------------
New Discussion:
- Arpad: Walter sent out a draft GND document.
- I didn't notice that it was not sent to everyone.
- Most people here today did not see it yet.
- I suggest we postpone this topic.
- Bob: I suggest we postpone it until next meeting, though I won't be here.
- I don't know what has changed.
- I reviewed draft 2, and there were substantial changes like changing
everything to A_puref and A_gcref.
- Arpad: [sharing Walter's email]
- Says it documents what needs to be looked at.
- Many of the changes can go away if we say GND is not simulator reference
node, nor is it node zero, but it's a local rail such as the model terminal
connected to the pull down or ground rail...
- Unfortunately, much of the buffer graphics is related to derivation
techniques, not how buffers are used.
- Further complicated by using a model where rail voltages are fixed to the
data derivation voltages as opposed to the rail voltages supplied during a
power aware simulation.
- Arpad: His email doesn't say too much about the actual changes.
- Bob: That's a controversial item, because the derivation methods are based on
fixed voltages.
- Without seeing what he did, that statement itself is controversial.
- Arpad: I agree that we should wait until Walter comes and we all review it.
- Michael L., could you post it on the ATM site?
- Michael L: Should I put that up dated today?
- Arpad: Use the date the mail was sent out, since we didn't discuss it today.
- Anything else on this topic? [none]
- Arpad: Walter also mentioned Fangyi could perhaps talk about IR some more.
- Fangyi: Not really, I think it's under control from the last meeting.
- Arpad: Scott McMorrow read the minutes and would like to continue the topic.
- He couldn't make it today, but is planning on joining next Tuesday.
- Fangyi: I didn't see Scott's comments on the reflector.
- Arpad: I'm not sure if it was private or public.
- He definitely wants to continue the discussion.
- It's an important topic to him.
- Bob, any comments on this? Did you talk to him?
- Bob: No, I don't.
- We had some private emails.
- It's best to make this a public topic next time.
- Arpad: This topic is tabled for today.
- Arpad: We could go with Michael M.'s suggestion and open up the IBIS website
and review the list of open BIRDs.
- Michael L: I'd compiled a spreadsheet with that info for the Open Forum.
- We could use that. It might be a bit out of date.
- Michael M: We now have two other BIRDS, 177 and 178.
- BIRD 178.2 Specifying Buffer Directionality for AMI.
- Bob: A potential new one is the interconnect proposal.
- Michael M: That's not submitted yet, it will probably be at least a few weeks.
- Michael L: That is definitely active in the interconnect meeting.
- When I created this spreadsheet the goals were:
- List the open BIRDs.
- Figure out when they were last actively discussed in a group.
- Just a few notes.
- BIRD 128, was tabled in ATM.
- BIRD 145, rejection had been discussed at one point.
- BIRD 161.1, seems like it was last discussed in interconnect in
2013.
- Michael M: BIRD 161 was mine.
- That was tabled because it would potentially be handled as part of
the interconnect proposal.
- Currently interconnect does not have language addressing it.
- So it may come back to life.
- We can't really untable it until the interconnect proposal is done.
- Arpad: This is a good list.
- Bob: Some of these we will probably reject.
- That was Michael's question. What do we plan to do?
- Michael M: Quite a few will be addressed by the interconnect BIRD.
- Those will probably be rejected once interconnect is approved.
- Others still floating around and may need to be addressed.
- Bob: We can start at the top of the list and work down.
- Arpad: BIRD 125.1, I wrote that a long time ago.
- Surprised interconnect was discussing it.
- Michael L: That's just mentioned because I searched through meeting minutes
and found it.
- Arpad: Yes, it might have been mentioned but no real discussion.
- Michael M: Its content would be entirely subsumed in the interconnect BIRD?
- Arpad: Yes, and the expectation is it would be rejected at that point.
- Michael L: Should we wait for the interconnect BIRD?
- Or entertain motions to reject?
- Arpad: I think we should wait.
- Not sure the new interconnect BIRD will be accepted.
- Probability is low that it won't be accepted, but simpler to wait.
- Arpad: Next one is BIRD 128.
- Michael L: Probably necessary for cooptimization.
- Bob: Probably will be approved in some form.
- Arpad: Turns the input parameter into an i/o parameter.
- Arpad: Next is BIRD 145.3.
- That was Cadence's to allow [External Circuit] and legacy models to be
cascaded so we could have interconnect models in the [External Circuit]
driven by a legacy model behind them, which is currently not allowed.
- I think the new interconnect model would probably make this irrelevant.
- New interconnect BIRD allows us to call ISS subcircuits for interconnect.
- This might get rejected if the new one passes.
- Bob: The issue was it also makes the multi-lingual approach more complicated.
- Piling on complications on top of complications.
- However, if the interconnect proposal gets too complicated and has too much
thrown in then I may switch hats and reject it and go with this one.
- Arpad: Row 5 and Row 13 (Backchannel and Cooptimization).
- These are either one and the same or close relatives.
- Perhaps we should put them next to each other.
- Bob: We can cross reference them.
- Arpad: We might get some answers to this when Ambrish comes back with
Cadence's response to Walter's presentation.
- Arpad: Next, BIRD 157 - Parameterize [Driver Schedule].
- That was mine, based on the suggestion of Romi Mayder.
- It is a useful BIRD for [Driver Schedule] if people are using it.
- [Driver Schedule] currently has fixed delay values.
- If you use the same buffer model at different frequencies, you have to
rewrite all the delays in the hard coded format.
- Would be nice to parameterize those for use with multiple frequencies.
- But [Driver Schedule] is not a very hot item these days.
- I haven't heard from Romi asking about it.
- Michael L: You might want to contact him.
- This might be a candidate for untabling.
- Arpad: I should contact him.
- This BIRD doesn't depend on any other BIRDs.
- It gets rejected or approved on its own merits.
- Bob: I'm probably not in favor of it.
- There's still no way to bring in the clock, which may be a dependency.
- Just fixed parameters.
- I don't like bringing in the parameter method from multi-lingual.
- Arpad: The main question now is how useful is [Driver Schedule] anyway.
- [Driver Schedule] is basically a poor man's multi tap.
- We can do a lot better now with AMI.
- Arpad: Next, BIRD 158.3 - AMI Touchstone Analog Models
- That was SiSoft's BIRD to provide a totally LTI analog buffer model using
touchstone.
- Scott might be interested in this given the recent discussions.
- Bob: Yes, we might resurrect it.
- Scott was opposed to it at first.
- It is a fixed topology. That was the issue.
- Arpad: I tend to have second thoughts about it, too.
- Fixed topology, lacks flexibility.
- Also goes against the grain of power integrity simulations since power and
ground referencing is somewhat limited.
- Might be useful for LTI requirements of AMI, but not for non-LTI analog
model simulations.
- Could stand on its own.
- Arpad: Next, BIRD 161.1 - Supporting Incomplete and Buffer-only [Component]
Descriptions.
- Michael L: Is that in the interconnect proposal?
- Michael M: It is not.
- There is some handling of package and interconnect descriptions that are
incomplete, and there are some implied interactions.
- But this BIRD was intended to identify to the user and tool the intent of
the model author to model the entire component or not.
- This BIRD can wait until after the interconnect BIRD is complete.
- Michael L: Does the interconnect group think this is in their domain?
- Bob: I don't think it's in the interconnect domain.
- My concern is that it has gotten complicated with subparameters.
- All you want to convey is "yes" or "no" is the model a complete model?
- Michael L: Like the touchstone analog buffer model BIRD, this one has a lot of
models out there doing this already.
- Bob: Yes, there's nothing that prevents you from creating a 1 Pin [Component].
- Michael L: Should this be in ATM?
- Bob: I don't know when to bring it up.
- If we want to add a new informational subparameter in 7.0, so be it.
- But we support legacy IBIS without them, and there's nothing that prevents
us from issuing partial models.
- Arpad - This is vaguely related to recent discussion about the completeness of
[Pin] and [Pin Number] lists between the package and the IBIS file.
- This is also dealing with incomplete models.
- Michael M: You're right.
- The key difference is there we have an identified [Pin] list we can compare
against the identified interconnect models.
- That's separate from this informational keyword identifying to the user
that the model you're working with is not intended to describe the entire
[Component].
- Useful because there's no automated way to otherwise know you have gotten
everything.
- Bob: That's the valid point.
- One application might be a large device and you only model one quadrant.
- Michael M: I think this can stay tabled until interconnect is done.
- Michael L: I'd just feel better if we kept a list of tabled topics like
Arpad has on his agenda.
- I don't see BIRD 161 on any of those lists.
- Arpad: That tabled list wasn't purposeful on my part.
- I just put the topics on the agenda, and then once tabled they move down to
the tabled section.
- I vaguely remember discussing BIRD 161 once in ATM.
- I'm not sure why it didn't make it to my tabled list.
- Michael M: Do we need to maintain an overall tabled list in this meeting?
- I'm willing to make that motion.
- Bob: I make a motion that we complete the tabled list with the BIRDs under
consideration at this point.
- Arpad: The motion is to complete my tabled BIRD list with all these BIRDs.
- So we have a complete list?
- Bob: Yes.
- Arpad: Do we have a second?
- Michael M: Second.
- Arpad: Anyone opposed [none].
- Michael L., please send me the spreadsheet.
- Arpad: BIRDs 163 and 164 (also 125) all competing with interconnect.
- These are all addressing the same feature set.
- I would expect one winner. Is that correct?
- Bob: Interconnect would be the alternative approach.
- The last three are multi-lingual approaches to the same problem.
- Arpad: BIRDs 163 and 164 are using [External Circuit] for packaging or on
die interconnect.
- Bob: It has architectural implications.
- [External Circuit] is that on die or outside the die?
- Arpad: Yes, that's the debate.
- Bob: Depends on interconnect whether we resurrect them or not.
- Arpad: Expect these might be rejected then since interconnect is a superset.
- Possibility of rejection is high.
- Bob: Because we don't want to do the same thing two different ways.
- Michael L: That comment applies to 125, 163, 164?
- Bob/Arpad: Yes.
- Arpad: Next, BIRD 165 - Parameter passing improvements.
- I wrote this.
- Currently parameter passing is done on the [External Circuit] or
[External Model] keyword level.
- But the [Circuit Call] is actually what instantiates the external
circuits.
- Having the parameter passing on the [External Circuit] level means
every single instance gets the same value.
- This BIRD is independent.
- Its fate might depend on how much effort we want to put into continuing
the use of these [External Model] and [External Circuit] keywords.
- Arpad: Next, BIRD 166 - Redriver Flow.
- Walter and Fangyi's solution.
- Independent BIRD, will need to be discussed on its own.
- Fangyi: Last time we decided to table it.
- Walter and I will have more discussions.
- Arpad: Yes, it can become active on its own at any time.
- Arpad: I think we are done with this list.
- Thanks for that suggested discussion.
- Arpad: What was the intent of my "complete" list of tabled topics?
- Just the ones that aren't being discussed elsewhere, for example in the
interconnect meetings?
- Arpad/Bob/Michael M./Michael L.: - [decided Arpad should list them all].
- Arpad: I'll keep a complete list in the agenda.
- Any other questions before we hang up?
- Next week I expect to discuss GND.
- If Scott can make it we will also discuss the LTI modeling for AMI.
- Thank you all for joining.
AR: Mike LaBonte to post Walter's draft GND document.
AR: Mike LaBonte to send his BIRD spreadsheet to Arpad.
AR: Arpad to add review of minutes to the ATM agenda each week.
AR: Arpad to add all BIRDs from the spreadsheet to the ATM agenda's tabled list.
AR: Arpad to contact Romi Mayder regarding BIRD 157.
-------------
Next meeting: 30 June 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
