Minutes from the 1 Oct 2013 ibis-atm meeting are attached. Thanks to Curtis Clark for taking minutes.
Mike
IBIS Macromodel Task Group
Meeting date: 01 October 2013
Members (asterisk for those attending):
Agilent: * Fangyi Rao
Radek Biernacki
Altera: David Banas
Julia Liu
Hazlina Ramly
Andrew Joy Consulting: Andy Joy
ANSYS: Samuel Mertens
* Dan Dvorscak
* Curtis Clark
Steve Pytel
Luis Armenta
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
* Ambrish Varma
Feras Al-Hawari
* Brad Brim
Kumar Keshavan
Ken Willis
Cavium Networks: Johann Nittmann
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: * Michael Mirmak
Maxim Integrated Products: Mahbubul Bari
Hassan Rafat
Ron Olisar
Mentor Graphics: * John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: * Randy Wolff
* Justin Butterfield
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: Eckhard Lenski
QLogic Corp. James Zhou
SiSoft: * Walter Katz
* Todd Westerhoff
Doug Burns
Mike LaBonte
Snowbush IP: Marcus Van Ierssel
ST Micro: Syed Sadeghi
Teraspeed Consulting Group: Scott McMorrow
* Bob Ross
TI: Casey Morrison
Alfred Chong
Vitesse Semiconductor: Eric Sweetman
Xilinx: Mustansir Fanaswalla
Ray Anderson
The meeting was led by Arpad Muranyi
------------------------------------------------------------------------
Opens:
- Need a volunteer to take minutes, Curtis to take the minutes.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Walter - send last week's presentation to Mike LaBonte for posting - done.
- Arpad - duplicate Walter's examples using BIRD 125 - done (discuss today).
-------------
New Discussion:
New proposed topics/questions:
- Arpad - Michael Mirmak and Fangyi indicated they have new topics/questions:
- Fangyi - I have two questions related to AMI_GetWave().
- What is the expected size of the clock_times array?
- Model makers need to know this to avoid writing out of bounds.
- How can a model return a message to the EDA tool after AMI_GetWave()?
- There is no msg parameter like there is for AMI_Init().
- Arpad - I'd like to set aside a few minutes for Fangyi's questions.
- Please don't drag out the discussion. If it will be long, I may move on.
- Walter - I understand Fangyi's concerns.
- Second question - I think there's only one consistent way to do it.
- New Reserved AMI parameter called "message out" (or similar).
- Optional and Usage Out.
- Standardize a method for returning messages from AMI_GetWave().
- Could have reserved string indicators ("Error", etc.)
- Could perhaps allow different return values from AMI_GetWave().
- Arpad - The emphasis would be on "Reserved" parameter.
- Walter - We could do a BIRD for this.
- Fangyi - Can the model maker use the msg pointer allocated for AMI_Init()?
- AMI_GetWave() could update AMI_Init()'s msg string.
- Walter - I'm not sure off the top of my head, would have to think about it.
- Fangyi - My impression is that msg was intended to be used that way.
- Is that the intention of the spec?
- Arpad - I don't have it on top of my head either.
- I vaguely remember some of the discussions.
- Todd - I remember it as being for AMI_Init() only.
- Walter - To your first question, I vaguely remember discussions.
- Related to "EDA tool allocates the array and the model fills it up."
- EDA tool knows how much time in the last AMI_GetWave() call and the bit
rate.
- We should say something like:
- "EDA tool allocates the clock_times array size equal to the elapsed time
of the AMI_GetWave() call [its block of data] divided by the bit time
plus
some fudge factor."
- It would be dumb for the EDA tool to allocate less than that, but...
- The standard should be enhanced to say "allocate at least this much" plus.
- Should be a BIRD clarifying it for model makers.
- Could force the EDA tool to pass in an array of zeros with -1 as last entry.
- Arpad - We don't need a solution now, we can work on it.
- The spec is missing this information right now.
- Fangyi - Right.
- Arpad - Can we move on now?
- Fangyi - Do we agree that both need to be enhanced?
- Arpad - Yes, it would be useful to mention it in the spec. We can work on it.
- Fangyi - yes.
- Arpad - Michael [Mirmak], can you specify your new question?
- Michael - May be tricky to summarize the question and keep the discussion
short.
- Recently seen a significant split in where models put their analog info.
- Pre 6.0 models.
- Some models:
- All analog information in the traditional IBIS format.
- All algorithmic information in AMI files.
- Now, however, some other models:
- Traditional IBIS model is "worse than a dummy" (virtually empty).
- It's stated that all behavior is inside the .dll and .ami file.
- Specific tools are referred to...
- I think this [the latter] can't possibly be portable.
- Can EDA Vendors support both?
- Walter - Both SiSoft and ADS support Touchstone files, Tx_r, Rx_r, etc.
- For supporting on-die s-parameter models, and contained in the .ami file.
- These models could readily be converted to 6.0 [External Models] now.
- It would be nice to have a 6.0 parser to support that.
- However, some models now where analog info is claimed to be in the .dll
- I think that is fundamentally flawed.
- Return loss can't be handled in the .dll.
- I think the ADS and SiSoft touchstone support in .ami is valid.
- I think no one is logically supporting analog info in the .dll.
- Todd - More importantly, you can't do it!
- Arpad - Unless you pass the channel into the .dll...
- ... and the .dll is an analog simulator.
- Walter - You can't.
- Todd - You can do it, but it's not AMI.
- Arpad - Yes.
- Does that answer your question, Michael?
- Michael - Yes, I think so. I think these models are a problem.
Next Topic:
- Arpad - [presenting his AR for this week - examples in BIRD 125 syntax]
- Cyan section - IBIS file.
- Yellow section - subckt. using IBIS-ISS.
- Red section - how ISS circuit would be instantiated and connected:
- language, parameters, port names matched to [Pin Numbers] keyword.
- Walter - Could I ask a question when you're done?
- Arpad - Yes.
- Walter - Quick question, can parameters have corners?
- Arpad - If parameters come from .ami or params files:
- They could be a reference to a corner type.
- Walter - Bottom line, [Define Package Model] doesn't support typ/min/max.
- Arpad - It could be done simply. I didn't want to complicate the example.
- Walter - I mention an annoyance with IBIS.
- [Pin Names] are really pin numbers, and now [Pin Numbers] are names.
- Arpad - Yes, it goes back to the original Package Model stuff.
- Arpad - [continuing]
- SiSoft slide 8. Subcircuit with parameters framis, length reused.
- In 125, subckt is a blank holder for parameter passing.
- Walter - Same comment, no corner values for parameters.
- Arpad - I did consider this but didn't want to complicate BIRD 125 now.
- It could be done with a reference.
- Bob - Package corners would track [Model] corners.
- Is that the way it should work?
- Walter - No, [Model] is talking Silicon, Package is talking about package.
- Independent corners.
- Bob - It could refer to .ami file and use Corner or List there.
- Walter - Do we have [Pin Numbers] section with die ports?
- Arpad - It's not new, only the second column is new.
- Walter - [Package Circuit] is all new?
- Arpad - Yes.
- Walter - So it's all new, except for some basic boiler plate stuff.
- Bob - Sometimes people think building on old stuff is easier.
- It can be bad.
- Makes it harder to throw away old garbage.
- Arpad - I had a brand new idea no one has seen yet.
- It applies to the "sliding package models" concept.
- I realized there's a better way to solve this issue.
- Threw out the old way and the new idea is:
- Connection is basically made through the name of the [Model].
- New keyword instead of [Pin Numbers] is [Model Names].
- Indicating that the first column contains the [Model] name.
- From the IBIS file's [Pin] keyword (third column - model name).
- We need dummy names for that circuit (pin names, pad names).
- Are we supposed to make the model maker create these node names?
- Do we let the tool generate names for these locations?
- This wasn't quite clear to me in Walter's examples either.
- We need to know how the tool creates the names for the connections.
- Walter - No, in mine I have terminals.
- The info I have for differential terminals that are [Model] names
includes polarity (inverting or non-inverting).
- Arpad - You still don't name the pin or pad.
- Walter - In the DQ example it's the DQ pin or the DQ pad.
- Arpad - The point is we have pin and pad names and connect the subcircuit.
- s10p for DQ0 and Vdd.
- Notice the s10 doesn't get everything connected.
- Only the two are connected. The rest are dangling.
- I've created names for the NC's for the others.
- Walter - In what I'm doing we can tie directly to the s10p.
- If you want to connect to an sNp, there is no need for a wrapper.
- No wrapper subcircuits (yellow section).
- They are an unnecessary burden on using touchstone files.
- Arpad - In these examples I was making use of IBIS-ISS.
- Ambrish - There is precedent in BIRD 160.
- Arpad - [concludes examples]
- Walter - What you have in the [Define Package Model] is:
- pin numbers, model names, package subcircuits.
- Each of my examples is independent.
- If you tried to take all the examples and put them in one
"package file" and the let the user choose:
- I think it will be hard for you.
- You're customizing your pin and package model names for each one.
- I think your justification of BIRD 125 is reuse.
- But all you're reusing is a few boiler plate items like [Manufacturer].
- I think it's complicated.
- EDA tools will need new parsers for all this, regardless of our choice.
- Reuse isn't an argument. This group should decide on a path now.
- Does Ambrish still want to pursue BIRD 145 for on-die interconnect?
- Or does he want to use an extension of Arpad's or mine?
- Arpad - Thanks Walter. I'd like to hear from others too.
- I agree we will have to make a decision soon.
- We need to choose or implement both in the spec.
- Brad - We've had a lot of discussion.
- Both Walter and Arpad are talking about a decision on implementation.
- I approach this differently. I support a lot of post-layout verification.
- No good way for me to bring in a whole package model (s10p or s50p).
- Here we're talking about bringing in approximations or channel models.
- My customers can't use them.
- To one extent I like Walter's EMD.
- On the other hand I like Arpad's simple way to connect package models.
- I care about standardizing a package mode I can extract today, but my
customers can't use.
- John - It's telling that we don't have it figured out in either proposal.
- Brad - That's what I call part of the automating.
- John - A bunch of Monte-Carlo runs.
- Michael - Which features do you need the least?
- I'm sensing that aggressor definitions are less important.
- More important is just getting in a full package?
- Brad - Do we standardize the inputs to EDA tools?
- I'm sitting here with an s-parameter model and no way to hook it in.
- Arpad - Is this slide [today's presentation] what you're looking for?
- Brad - Yes, except I want multiple Vdd.
- Walter - There are many issues with the way people define package models.
- You need a complete package or a full quadrant.
- But there are other needs too.
- There are other ways other vendors deliver package models.
- I think we can't ignore the other vendors' approaches.
- Brad - I call a package model, "Here's a model of my package."
- Versus a channel model which is DQ0, etc.
- But it's a channel model that is assembled as a package model.
- I have a 50 port package model. We're trying to figure out how to use it.
- Walter - I understand.
- There are some package models.
- There are some who need channel models that are valid for that package.
- Brad - That's an approximation and the EDA tool has to assemble it.
- Arpad - I want to try to aim the discussion so that we can progress.
- Do we have to make a decision? Can we consider both?
- Walter - Is there anything you're proposing that mine can't do?
- Arpad - But I've been demonstrating that mine can do everything yours can.
- So that approach doesn't help.
- Arpad - It seems like we could implement 125/145 in less time than EMD.
- Seems like EMD might be longer term.
- Walter - EMD is done. It just needs some word-smithing.
- EMD for modules is straightforward, would just need the approval stage.
- I think implementing EMD is a lot simpler.
- No corners in yours.
- Arpad - We can do it with a reference.
- Walter - More gobbledygook now for corners.
- Haven't even looked at 145, which wants to use ISS for on-die modeling.
- Even more complicated.
- Arpad - BIRD 160, ISS is in 6.0.
- Walter - For buffer models.
- Arpad - [External Model] and [External Circuit] supported.
- Walter - Are there any IC vendor models that use [External Circuit]?
- Are anyone else's customers using them?
- There's something fundamentally wrong with them.
- Arpad - [External Circuit] was limited by the available language options.
- Now we have IBIS-ISS allowed.
- Walter - BIRD 145?
- Michael - Is it possible to get a side-by-side bullet point listing.
- Need to see a simple listing of the differences.
- That would get you a quick answer.
- Arpad - Walter tried something like that a few meetings ago.
- Michael - It would be helpful. Get a decision and move on...
- Arpad - Walter, can you and I try a few bullet points together?
- Walter - Sure, but I'm going out of town.
- Limited bandwidth before the next meeting.
- Arpad - I'll try it.
- Walter - Send me an email and I'll try to get to it.
- Arpad - Okay, thanks everyone. I think this is a good time to stop.
- See you all next week.
-------------
Next meeting: 8 October 2013 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
