[ibis-macro] Minutes from the 25 Jun 2013 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 26 Jun 2013 11:05:28 -0400
Minutes from the 25 Jun 2013 ibis-atm meeting are attached. Thanks to
Curtis Clark for taking minutes.
Also, "Backchannel support BIRD 147 draft 4" has been posted to the
ATM work archive at
http://www.eda.org/ibis/macromodel_wip/archive-date.html
Mike
IBIS Macromodel Task Group
Meeting date: 25 June 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.
- Meeting will be held as scheduled on July 2, 2013.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Ambrish update BIRD 147
- Ambrish ready to present changes made in response to previous meeting.
-------------
New Discussion:
Interconnect update:
- Walter: I gave a presentation regarding EMD, package, On Die Interconnect.
- Do we handle On Die with BIRD 145 [Model Call] or new EMD methodology?
BIRD 155, New AMI API to Resolve Dependent Model Parameter:
- Fangyi: (presenting the latest BIRD draft)
- Radek and I modified this and included input from Walter.
- Shortened the name of one API function to AMI_Resolve().
- Added AMI_Resolve_Close(char * AMI_parameters_out);
- Purpose is resource cleanup.
- Previously, AMI_Init() was going to handle this cleanup.
- Walter suggested decoupling "Resolve" from other AMI functions.
- Arpad: That's a good idea [decoupling them]
- ex. With BIRD 160 you might have a .dll with only Resolve functionality.
- Kumar: You would then make AMI_Init() and AMI_Close() optional.
- Todd: What would we need this for without having an AMI_Init()?
- Arpad: With BIRD 160 you might have dependent analog parameters but no AMI.
- Radek: But we currently point to the .dll with the [Algorithmic Model] line.
- Todd: Resolve without Init is a solution in search of a problem.
- Fangyi: I agree, it is likely tied to AMI.
- Walter: One possibility - separate .dll for the Resolve functions.
- Radek: Todd is right, let's stick to AMI use of Resolve for now.
- Fangyi: (resuming review of BIRD draft)
- Resolve_Close() is required if the parameter Resolve_Exists is true.
- (described the usage flow of the Resolve API (steps 1 through 9))
- Todd: If Resolve_Exists is true, what do you pass in? The whole tree?
- Fangyi: No, only parameters of type "In" [step 4. in flow]
- Fangyi: We introduce a new usage "Dep".
- If a parameter is updated by AMI_Resolve(), its usage is "Dep".
- If a parameter is updated by AMI_Init(), its usage is "Out" or "InOut".
- A list of parameters that can not have usage "Dep" is provided.
- Kumar: I don't think we need Resolve_Exists. The tool can figure it out.
- Fangyi: Yes, the tool could look for the entry point.
- But this is consistent with GetWave_Exists.
- From past discussions, justifications include a model developer who wants
to include a function (debug) but doesn't want it used.
- Kumar: So the parameter has priority.
- The tool uses Resolve_Exists and ignores Resolve functions if it is false.
- Fangyi: Yes, it says that in the flow.
- Todd: Could I step back and look at the big picture?
- SiSoft approach was to handle these dependency issues without .dll change.
- This is effectively passing a table to a new entry point in the .dll.
- Fangyi: Yes, I think this approach is extremely flexible.
- Todd: You call AMI_Resolve() and then pass the entire reply to AMI_Init()?
- Fangyi: No "Dep" parameters don't go to AMI_Init().
- The purpose of AMI_Resolve() is to get the dependent parameters needed to
calculate the impulse response of your circuit.
- You need resolution of these before AMI_Init() because it's too late then.
- Todd: Ah, I understand.
- Walter: ex. Tstone_file becomes "Dep" not "Info"
- Jitter params in IBIS 6.0 are all "Info". Must they now become "Dep"?
- Fangyi: AMI_Init() could choose TxRj using the same method as AMI_Resolve().
- Walter: No, the .dll doesn't use TxRj.
- Fangyi: Oh, right. Yes, we have to allow TxRj to be "Dep" as well as "Info".
- Radek: If AMI_Init() needs a dependent value it can calculate it the same way.
- Walter: I sent an email today regarding a new leaf on usage.
- Fangyi: Can we finish this discussion first?
- John: Why do we need "Dep" at all?
- Fangyi: "Dep" prevents the possibility of something being updated twice.
- Radek: The old "Out" becomes complementary subsets "Out" and "Dep".
- John: The tool could detect that something had been updated twice.
- Radek: And then what...?
- Fangyi: It forces the model maker to specify.
- Kumar: I like "Dep" to make it clean.
- Radek: Table 17 lists the Usage type allowed for various Reserved parameters.
- Extend this table so "Dep" is an option.
- John: Were the original analog parameters (load, etc.) all "Info"?
- Arpad: They were Reserved parameters only.
- Tool wouldn't know what to do with Model Specific parameters.
- Now with BIRD 160, Model Specific Info params used by [External Model].
- Walter: The model user first has to make various parameter value selections.
- Input to Resolve function is "Info".
- Output of Resolve is classic "Info" parameters.
- We need to know which are "Dep-In" and which are "Dep-Out". Which are
which?
- Overloading Usage with "Dep" is a confusing way to handle it.
- Fangyi: You're moving on to your topic now...
- Ambrish: Could I suggest that we see some implementations of old examples?
- Fangyi: Okay, we will create one.
- Arpad: Is this BIRD to exist in parallel with BIRD 150 or to replace it?
- Ambrish: We should pick one or the other.
- Arpad: Yes, I would also prefer one or the other. Perhaps this one.
- Bob: I have some Table 17 comments.
- We've deprecated "Out" for some Reserved Parameters.
- Almost all Reserved Parameters are "Info".
- Radek: Reserved "Info" parameters can be returned by AMI_Init().
- Walter: There are plenty of BIRD 150 examples.
- In some of them the inputs to the AMI_Init() function are resolved.
- Fangyi: If you're using a dependency table to resolve an input, then the same
resolution could just be done inside the AMI_Init() call.
- Arpad: Looking at the clock, should we now move over to Ambrish's update?
Bird 147 - Back-channel Support:
- Ambrish: (showing latest changes based on the last meeting)
- Tree root name "BCI".
- States that the parameter string is constructed according to existing rules.
- States how to resolve Training Bits vs. Ignore bits values.
- Todd: BCI file defines allowed messages that can be passed from Tx to Rx?
- Bob: BCI root name is for protocol specific parameters only?
- Ambrish: Any InOut parameter in the BCI goes back and forth from Tx to Rx?
- Todd: Reiterate that this defines legal messages and values.
- Walter: Yes, in a separate tree.
- Ambrish: A separate "BCI" root.
- Bob: This is not a root, it's under "Protocol Specific".
- Arpad: Isn't "Protocol Specific" too generic?
- This is a training protocol? What if there are others?
- Ambrish: BCI is for training.
- Arpad: Now is a good time to stop. See you all next week.
-------------
Next meeting: 02 July 2013 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 25 Jun 2013 ibis-atm meeting - Mike LaBonte
