Minutes from the 4 Mar 2014 ibis-atm meeting are attached. On behalf of Arpad Muranyi and myself, thanks to Bob Ross for chairing the meeting and to Curtis Clark for taking minutes.
Mike
IBIS Macromodel Task Group
Meeting date: 04 March 2014
Members (asterisk for those attending):
Agilent: Fangyi Rao
* Radek Biernacki
Altera: David Banas
ANSYS: * Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
* Brad Brim
Kumar Keshavan
Ken Willis
Ericsson: Anders Ekholm
Intel: * Michael Mirmak
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
Teraspeed Consulting Group: Scott McMorrow
* Bob Ross
The meeting was led by Bob Ross.
------------------------------------------------------------------------
Opens:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Bob and Ambrish - BIRD 147 editorial work
- Bob - I'm late on this one. I don't have draft 7 available to review.
- Ambrish, could you send me draft 7?
- Ambrish - yes.
- Bob - Perhaps we will get some discussion on this later today.
- Walter to send package issues outline and example to the email list.
- Bob - Walter, is this AR closed?
- Walter - Yes, it is closed.
- Arpad to make a BIRD163 syntax version of Walter's example.
- Bob - I believe this is in progress, right?
- John - I believe so.
-------------
New Discussion:
BIRD 147 Back-channel:
- Bob - Ambrish, are you prepared to continue the back-channel discussion.
- Ambrish - I've received no feedback other than from Bob.
- Nothing has been updated yet.
- Nothing new at this time unless others have more comments.
- I know Walter had noted some concerns in the last meeting.
- Radek - Last time we delayed discussion on one issue.
- BIRD 147 explicitly uses the AMI_parameters_out change from BIRD 128.
- BIRD 128 will have to be discussed as well.
- If any changes are need, they need to be made to both BIRDs.
- Ambrish - What are your concerns for BIRD 128?
- Radek - In its present form, BIRD 147 depends 100 percent on BIRD 128.
- So we can not ratify BIRD 147 without discussion on BIRD 128.
- Ambrish - Agreed.
- Radek - Personally, I have doubts about whether the solution (BIRD 128) is
proper.
- BIRD 128 is kind of a hack, and we should avoid this type of solution.
- We should explore other options.
- Walter - One of the problems with alternatives is changing the C function
signature.
- Radek - Yes, I know.
- We added the resolve function and maybe we can add other functions.
- It is related to version number, so it shouldn't be an issue.
- There are better solutions to the problem.
- Walter - You understand the functionality we need (BIRD 128).
- Could you propose an alternative BIRD?
- Radek - If I could find the time.
- Walter - I understand, but I'm serious and want you to submit an alternative
solution.
- I think we should wait for discussion on BIRD 128 until Radek has a
proposal.
- Bob - I have one comment on BIRD 147.
- I'm concerned about the tap coefficient example.
- We already have a "tap" format, so can't we use that?
- Ambrish - Let me go over your email (it just arrived recently).
- Bob - I didn't mention this issue in the email.
- John - (BIRD 147 comment)
- Under LFSR format, one of the items is a comma separated list of values.
- Model makers may put whitespace next to commas. Could be an issue for
parsers.
- Walter - I have a question for clarification on this.
- In LFSR format, are there always 3 numbers to be comma separated?
- Ambrish - I think there can be more than three. Those are the taps for the...
- Walter - We need a detailed definition of what that field means.
- Ambrish- I agree.
- We are working on pseudo code for that.
- You're the second or third person asking for that clarification.
- We want pseudo code so that we know bit streams will be identical.
- Walter - Okay, so the document will detail that field.
- John - My point is that if we require that no space be there, people will
often do it.
- Ambrish - We can address that.
- Bob - Are these the same meanings as the taps used elsewhere?
- Ambrish - No, these are for the LFSR polynomial.
- Bob - We need to clarify that these taps mean something different than used
elsewhere.
- Ambrish - Okay.
Package Modeling Direction:
- Bob - Do we want to continue the discussion on package modeling direction?
- Walter - One of the things I've wanted to do for several weeks is go and
review all
the usage models in the IBIS file for the memory package.
- Only described the usage model for the first two.
- Want to go through the others and see if we all agree they should be there.
- Bob - Any comments related to the use model and Walter's questions, or should
we wait?
- Randy - Let him review it and see if we have questions.
- Walter - I think it would be useful if you made me presenter.
- Bob - Okay.
- Walter - [sharing the memory_package.ibs file]
- IO example, one terminal or port on pin and buffer side.
- Power delivery model.
- All ports or terminals for power and ground pins.
- One for each supply signal name (one for each on die voltage).
- Power deliver model - second method.
- One port for every power pin, one port for every power port on each
buffer.
- Other flavors of PDN modeling.
- Model with Die Supply pads.
- One model goes from all pins to all die pads.
- Another model goes from all die pads to all buffers.
- Splits to two models for PDN, one for package and one for die.
- EDA tool might end up combining them into one model (like the previous
example).
- John - I'm not objecting to either.
- But both are subject to the concern about a large number of nodes for the
subckt.
- Could affect performance on a simulation that doesn't require all of them.
- Walter - This is the way Randy wanted to be able to supply power for his
memory.
- A controller might have 50 times as many, and I agree with you.
- Walter - Another approach, one package model per buffer.
- One model per buffer/pin, or one per diff pin.
- Obvious we need to support this. (this particular example uses
s-parameters).
- John - If these aren't s-params, it could be useful to pass a parameter like
length.
- Walter - That is my next use case.
- Subckt instead of s-parameters with parameter passing.
- Walter - I think there is no controversy on the above.
- Walter - One way is to assign an interconnect model to a [Model].
- So it's a pre-layout solution.
- John - This is useful if packages are identical, or identical "enough" for
all DQs.
- Walter - Implies all package models are the same.
- One could put in typ, min, max to cover the range on that bus.
- John is right. Assumption is that all interconnect models on that bus are
the same.
- John - Sometimes that's true, sometimes it's not.
- Is the overhead of supporting a special case worth it?
- Walter - It is definitely worth it.
- Many vendors are already doing it.
- SERDES model example from an IBIS member vendor doing it this way.
- Bob - [Model] name could be [Model Selector] name for generality.
- Walter - Correct.
- Walter - One option is one package per [Model] type.
- This is the only one of interest (i.e., contentious).
- Example, package model for I/O, one for Differential_I/O, etc.
- Broadband default model and default differential model could be done with
this.
- Has the advantage of giving us this broadband default capability.
- One could have different defaults for Input, I/O, etc.
- Could have coupling or cross-talk, but only for pre-layout usage.
- For post layout, only uncoupled models.
- Radek - Do you have precedence rules for overlapping applications?
- Walter - Yes, they were outlined in the presentation at Design Con.
- Hierarchy - per pin name, per [Model] name, per [Model] type.
- Bob - How do we distinguish between differential vs. single-ended output?
- Walter - [Diff Pin] statement tells you what is differential.
- Here I'm using + and - to indicate which pin is non-inverting and inverting.
- Bob - We have a single ended I/O type and a differential I/O type?
- Walter - Yes, that's a syntax we can come up with.
- This example model (s4p) applies to diff pins.
- John - The answer to whether we can benefit from having broadband default
models is
that you have vendors who've found it useful?
- Walter - I hate the fact that all we do is default to lumped RLC now.
- John - Some of our reasons for precedence rules are historical. It adds
complexity.
- Brad - Quick question...
- I look back at what we've got now, RLC instead of broadband.
- Implicit hierarchy.
- You've done something analogous here, added hierarchy.
- All you've done is generalize from lumped RLC to touchstone or IBIS ISS.
- If it's good to have those levels of abstraction for broadband models, why
not have
it for lumped RLC too?
- Then you can specify the same format for all and just specify RLC, ISS,
touchstone.
- Walter - Yes, that's certainly an enhancement we can make.
- Brad - I'd just like to not have ten different ways to describe this.
- Walter - One thing could simplify it.
- Instead of saying something is per [Model] type, just make it "default."
- The reason I put the Input and Output there, it's really a pre-layout issue.
- It's what Scott wanted - big complex model, here are my near in and far end
ports.
- Could just say the Input and Output are limited to the pre-layout models
for Scott.
- Brad - I just wanted to comment on the generality.
- Walter - I totally agree.
- Walter - Lots of stuff in here is because others wanted it.
- Maybe use "default" and not "[Model] type" at all.
- Walter - We'd be able to parameterize by length.
- Here's another thing we kind of have and kind of don't have.
- We have typ, min, max for lumped RLC, but not for everything else.
- Here I'd like delay corner typ, fast, slow.
- I think this is a chance to come up with a nice format name.
- Several format ideas, delay corner, or cross talk, or list, pdf, etc.
- Need corners of packages for consistency with lumped RLC.
- Radek - Filename can be arbitrary, so those names aren't counted upon, right?
- Walter - Yes.
- Bob - Intent is still to provide typ, min(fast), max(slow)?
- Walter - Notice that I'm not using "corner" here.
- In AMI and IBIS corner means typ, smallest, largest (values).
- Package modeling is totally independent of that, so we have to be very
careful
syntactically when we name that.
- That should be our next step.
- Walter - It's my intention to go to our subcommittee (Randy, Mike, Arpad,
Walter).
- Say to them, "here's what we need to support" and let's work out the syntax.
- Any objections to that approach?
- Do we put this in an existing section?
- Bob - Are there any questions?
- Brad - On the delay corner stuff here...
- What you're talking about is implementing design variation.
- But is it some discrete or continuous variation?
- If it's discrete, how many do you allow?
- If it's continuous, how do you handle that?
- What you've done is list all the possibilities? Let the subcommittee
sort it out?
- Walter - I listed what I think are important...
- [sharing "Enhanced Parameter Formats" slide from presentation]
- Can consider supporting Gaussian, Integer Range, Real Range, pdf, list.
- If one had DOE experiment for manufacturing distribution, could use these
types.
- Anyone doing DOE and yield prediction would be able to do it with these.
- Brad - So basically the list you're talking about...
- Then "corner" is a special list with three values.
- Walter - It looks like the parameters in AMI trees.
- But with a more traditional way of describing the parameters.
- Brad - This is how you might represent what was in the last two lines of your
example?
- Walter - Yes, can't do range on s2p, but this could have been a list.
- Another example had a list that had nothing to do with speed.
- Walter - Traditional IBIS simulation has always had the concept of typ, min,
max.
- As soon as you put in list or Gaussian, that's going to put strain on EDA
tools.
- So, I made sure that for any value there's a way to know the typical value.
- I.e., for Gaussian it's the mean.
- Brad - One procedural question:
- Does this larger group want to consider the scope of the generality?
- Is the subcommittee of four going to make that decision?
- Walter - Subcommittee won't make that decision.
- We could have straw votes on each one if we wanted to.
- Bob - We might take it to this committee for the straw vote.
- But people can give the subcommittee some guidance.
- Rather than come up with defaults, our standard syntax has been that a
typical value
is provided for all cases.
- Bob - Six minutes to go. Any other comments on your presentation?
- Walter - I'd like to do one quick thing.
- Work on EMD was using parameter tree structure.
- One idea was to use it for package modeling, but that has gone by the
wayside.
- Went back and redid an example. Looks exactly like an EBD file.
- Added the ability to provide voltages to nets.
- Added the concept of connections.
- Instead of a path section in an EBD file, created a [spice description]
section.
- We may decide not to do EBD, EMD at all.
- Just say in EBD we can now have SPICE descriptions instead.
- Bob - You could just name the things that you need to route.
- Walter - Yes, that's exactly what I did.
- In the case of I/O, it specified a pull down and ground clamp reference.
- They were the same, so I only referenced one of the ports.
- You don't have to provide all 4 voltages to the buffer, maybe just two, for
example.
- Walter - In the pin list, is this a signal name or is it POWER and GND?
- EBD files just have power and ground.
- Memory chips have multiple power and grounds.
- Randy - EBD syntax doesn't let you provide signal name.
- Walter - This may mean we have to go to EMD.
- Bob - I have a hard cutoff at 4. Motion to adjourn the meeting. (motion and
seconded)
- Bob - Okay, thanks for joining.
AR: Ambrish to update BIRD 147 with Bob.
AR: Mike L. needs to upload versions of BIRD 147.
AR: Subcommittee will work on more package proposals.
-------------
Next meeting: 11 March 2014 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
