Thanks to Arpad for noticing that I had posted the 16 Jul ATM minutes, but had not emailed them last week. Here they are.
Mike
IBIS Macromodel Task Group
Meeting date: 16 July 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:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Ambrish ask Ken Willis about reasons for jitter not being Usage Out
- Done
- Walter draft BIRD to allow Usage Out for jitter
- Done
- Fangyi discuss issues with Walter
- Done
-------------
New Discussion:
BIRD 162:
- Bob showed an email from Arpad
- Bob: The first paragraph says nothing about they types of parameters used.
- The second paragraph requires AMI_Init to return values.
- The third paragraph requires AMI_GetWave to return values.
- The tool shall not use returns for subsequent calls.
- Arpad: I have elaborated a bit more on this.
- It should not affect simulation results.
- Radek: It should state more explicitly that it can't be used.
- Walter: Why not let EDA tools use the jitter values as they wish?
- Fangyi: For TX GetWave is called in chunks.
- The result depends block size.
- Arpad: The spec would have to describe the expectation of the tool.
- Radek: It can't be left to the EDA tools.
- Bob: For each parameter?
- Arpad: Only if expectations differ by parameter.
- Walter: Why can't the tool resimulate with the new TX jitter value?
- Arpad: We just have to spell it out to avoid implementation differences.
- Radek: That is more involved than what we are trying to accomplish now.
- Bob: The issue is with Tx_DCD and Tx_Jitter?
- We should settle it and not go back and forth
- Walter: We could set a general policy and relax for specific params in the
future
- Radek: The wording should have "shall not be used".
- Bob: I will make that change.
- Bob: I don't understand the 2nd paragraph implication that it affects only TX
params.
- Walter: Noise is an RX parameter.
- Fangyi: TX jitter can't change once the simulation starts.
- The RX jitter can change, that is post-processing anyway.
- Walter: RX jitter and noise could be post-processed.
- But it could also be applied to clock_times, not statistically.
- Fangyi: Yes it could be applied on the fly.
- Bob: There will be a 162.1 ready for the Friday meeting.
- Walter motioned to recommend this BIRD with changes.
- Fangyi clarified the changes.
- Arpad: Outputs can only be used from Init.
- Fangyi seconded the motion.
- There was no objection, the motion carried.
AR: Bob update BIRD 162 and submit to open forum
BIRD 155.1
- Fangyi showed BIRD 155.1 draft 3.
- Fangyi: The model name is not passed to AMI_Init.
- We could require all Dep parameters to be passed to AMI_Init.
- Or we could allow a Model_Name parameter string to be passed to AMI_Init.
- This is similar to DLLpath and DLLid.
- Corner can be handled using a parameter with Format Corner.
- Ambrish: The model would expect the parameter?
- Radek: It is not required.
- Bob: Why is the corner Model_Specific?
- The model chooses the actual input value.
- Arpad: It automatically uses the GUI settings.
- Walter: The values could be integers, anything the model wants.
- Arpad: If string it should be consistent with words we already use like Min,
Max.
- We could have a Format for [Model Selector], similar to Corner.
- The list would have all available model name values.
- Fangyi: The AMI file could not be used for different releases.
- Only one parameter would ever use that Format.
- Arpad: True.
- Bob: It would be Usage In?
- Fangyi: Yes.
- Walter: There was a proposal to use AMI_Init for Resolve by setting the wave
pointer to NULL.
- Radek: There is also an issue of freeing the separate memory.
- The flow would have to be spelled out.
- Walter: AMI_Close would have to be called for each AMI_Init call.
- Walter: At step 9 we need to say that the same parameters should be passed to
AMI_Init and AMI_Resolve.
- Fangyi: OK.
- Arpad: If the resolver decides on a parameter how does Init know?
- Ambrish: What would happen if not?
- Walter: Bad things would not happen.
- Ambrish: That is redundant.
- Walter: Dep parameters are not passed to either Init or Resolve.
- Only In and InOut are passed.
- Ambrish: The is already covered in the spec, there is no confusion.
- Arpad: If it can be done it will be done.
- Arpad: AMI_Resolver should only get In parameters.
- Walter: IT should get InOut too.
- Fangyi: Init might modify those, then they are passed to Resolve.
- Ambrish: The logic can prevent that.
- Walter: Why would Resolve not get the same parameters as Init?
- Fangyi: Resolve and Init could both modify it.
- Ambrish: Resolve can not modify those.
- John: Originally the DLL was out of the picture.
- Now we are having complications.
- Walter: No secret memory is passed from Resolve to Init.
- John: Why not?
- Walter: The DLLs are re-entrant, there is no memory retention.
- Separate executables could be calling these.
- Fangyi: Do we want solution #1 or #2?
- The group agreed on solution #2.
-------------
Next meeting: 23 July 2013 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
