[ibis-macro] Minutes from the 16 Apr 2013 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 16 Apr 2013 19:50:39 -0400
Minutes from the 16 Apr 2013 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 16 April 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 Raghat
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:
- Mike L: Will not be able to join Apr 30, possibly not Apr 23 either
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad update BIRD 160 draft with Bob's comments
- Done, there have been two revisions
- Arpad try to apply BIRD 158 shortcut language to his BIRDs 116-118
- In progress
- Walter write new BIRD for repeater/retimer pin keywords
- In progress
-------------
New Discussion:
Interconnect Task Group report:
- Michael M: Went over open EMD issues last week
- EMD draft 5 has been issued and will be discussed this week
Analog BIRDs:
- Arpad: We will schedule a vote for recommendation to open forum
- Walter: The labels BIRD should be ready for voting too, would like to discuss
- Arpad showed BIRD 160.1 draft 2
- Todd:
- There are multiple ways to draw a waveform with a given 20%-80% dv/dt,
even for an ideal 50 ohm output with no V-T data
- A perfectly trapezoidal ramp has very high harmonics
- With bandwidth limiting rolloff the results are very different
- The D_to_A has the same problem, wave shape is not specified
- Arpad: We don't know where to start filtering harmonics
- I always assumed perfect trapezoidal
- Todd: That is the intent but but not the letter of the law
- Michael M: Long ago there were discussions about [Ramp] with minimal V-T
tables
- This would avoid uncertainty
- Is there a minimum number of points for [Ramp]?
- Arpad: This is independent of BIRD 160
- There could be another BIRD for D_to_As
- Todd: Models written with this can work differently in two simulators
- Michael M: Let us say this would have to be closed in the next spec version
- Arpad: Even with a 4 point V-T table we can't be sure about wave shape
- Todd: The problem here is we place a passive circuit in place of the model,
and we don't know what the stimulus is
- A simple circuit demonstrates that eye margin is very different depending
on stimulus
- Bob: A sharp ramp stimulus and s-param can give desired results
- Trying to use ramp time for shaping is already an approximation
- Todd: It needs to be unambiguous
- Arpad: The language implies straight ramp edges
- Todd: There are tools implementing it in multiple ways
- Michael M: Maybe BIRD 160 should address [Ramp] specifically
- Todd: We need to close the [Ramp] and D_to_A issues the same way
- Meanwhile models should not be built with this
- Bob: How does this work with AMI?
- Todd: It's broken
- One suggestion is [Ramp] subparams to define rolloff
- The would provide continuity with what simulators already do
- One question is about the impact on existing models
- We should create a simple demonstration model and try to get consistent
results
- Arpad: How can [Ramp] be anything but a straight line?
- Todd: All real circuits are band limited
- Bob: I implemented [Ramp] with rounded upper and lower halves
- We should use some other technique to give driver frequency response
- Arpad showed a section of BIRD 160 defining D_to_A
- Arpad: For D_to_A it is defined as 0% and 100%
- Todd: Then regular [Ramp] is still broken
- Arpad: If trise/tfall is zero it amounts to one timestep
- Todd: What is the status of Parameter Trees?
- Bob: I would be in favor of delaying a vote on this until that is discussed
- Arpad showed BIRD 160 language regarding this
- Arpad: It references BIRD 153, the example is from that
- Maybe they should be voted together in open forum
- Bob: It is not clear what Usage In means here
- In AMI it is clear that it is with regard to the DLL
- It is not good to have double meanings
- Arpad: The only meaningful Usages are In and Info
- There should be a different Usage for parameters controlling dependency
tables
- Bob: How would the tool know what to do with it?
- Arpad: That is a good point
- Todd: There is value in parameterizing
- Without BIRD 153 we lose that
- Arpad: We would only lose having parameters in the IBIS file
- Todd: So an AMI file could have parameters and no DLL?
- Ambrish: It could be a TXT file
- Todd: Do the other AMI Reserved_Parameter and Model_Specific levels not apply?
- Ambrish: It says they are not required
- Todd: Something that is not an AMI parameter tree should not have an AMI
extension
- Arpad: References are required to show the path starting at root level
- Mike L: Are values given as Format Range, etc?
- Bob: This is not an AMI file, it does not conform to those rules
- Todd: Then it should not have the AMI extension
- Bob: There can be multiple trees in a file
- Todd: AMI can have only one tree
- Arpad: I will remove all references to BIRD 153, and assume it is approved
- Bob: We still have issues regarding BIRD 153
- Ambrish: If parameters are taken from other than an AMI file we have to
specify it
- Arpad: If we use AMI we have the Usage In problem
- Usage Info is for the simulator
- Todd: It is all for the simulator, there is no DLL to execute on it
- It has to be clear that this is something different
- Ambrish: We should be able to define it as AMI with exceptions
- BIRD a53 could be integrated with this
- Bob: BIRD 160 should not be approved until this is fixed
- Walter: The trise/tfall issue should be fixed too
- Arpad: We decided that that does not affect this BIRD
- Todd: That only affects [Ramp], not D_to_A
- Mike L: The examples here should have the Model_Specific tree level inserted
- Ambrish: That will not be required for these files
- Arpad: If nothing else we can support literal values specified in the file
- Bob: We could make it illegal to reference an AMI file
AR: Arpad update BIRD 160.1 draft to address parameter tree issues
-------------
Next meeting: 23 Apr 2013 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 16 Apr 2013 ibis-atm meeting - Mike LaBonte
