[ibis-macro] Minutes from the 15 Jan 2013 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 18 Jan 2013 10:20:24 -0500
Minutes from the 15 Jan 2013 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 15 Jan 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:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- None
-------------
New Discussion:
Interconnect Task Group report:
- Michael M:
- Discussion of [Model] inputs were continued from the previous ATM meeting.
- Other EDA vendors again asked to present their views on the [Model] keyword.
Arpad: Should we continue the discussion from last week?
- Fangyi: We discussed where inputs are analog or digital
- This problem is not limited to the alternate flow
- The spec does not spell out the input at all
- Arpad: Agree the presentation was confusing, linking the problems together
- But there is no problem in the existing flow
- Fangyi: Why is it only a problem in the alternate flow?
- Arpad: That waveform has amplitude variations
- Radek: Fangyi is right that the spec does not say what the signal is
- The original flow has never been clarified
- Arpad: We thought there could be vendor differentiation on that
- Radek: The point of a spec is to avoid differences
- James: I have seen differences in how EDA tools interpret amplitude
- This is not how tools should distinguish themselves
- Arpad: The issue is about where the boundaries are drawn
- James: This is a different issue
- Walter: We have to be clear
- IBIS 5.1 has only one standard definition
- In time domain the input is a derivative of the step response
- It is not specified whether rising or falling step, but they should work
the same
- In 6.0 we have to say what to do when rise and fall do not match
- David: IBIS models don't make digital transitions
- Walter: The stimulus does, we assume only low-high and high-low transitions
- How the impulse response is generated can lead to numerical issues
- That was not put in the standard
- There can be artifacts when the response goes through an s-param
- James: We just need to say the stimulus is interpreted as a unit amplitude
- Walter: When an IBIS model is the analog model the voltage is not 1V
- David: James is saying only the input is 1V
- Michael M: Digital stimuli in SPICE models are voltage only because that's
all they have
- Walter: The HSPICE B element does that, but that is not what James is talking
about
- If the differentiation produces a 3V swing that is a problem
- Does it have to be normalized to 1V
- Radek: The output doesn't matter, the input does, and there is a voltage
divider effect
- Arpad: We are using "input" in different ways here
- It is the stimulus for this discussion, just a selector, not analog
- James: It is just logic, amplitude doesn't matter
- That can't be used with AMI_GetWave() where everything is analog
- Arpad: Our flow can't give it an analog input
- We should decide how to fill this gap and start a BIRD
- Michael M: Maybe a new keyword like [Analog AMI Model] would help
- Vendors can do something to maintain compatibility with existing models
- Fangyi: The only thing different would be a scaling factor
- Walter: IC vendors want:
- For TX an s4p with series termination value and voltage swing
- Or series impedance, c_comp, and voltage swing
- For RX an s4p with termination value to ground
- Or c_comp and termination value to ground
- Arpad: Why not [External Model]?
- Walter: The D-to-A converters are not needed
Arpad showed a slide about modified [External Model]
- Walter: This requires an external subckt, more complicated than needed
- A mechanism to specify the analog model from AMI or the DLL is needed
- Michael M: This is about whether the structure of [External Circuit] works
for AMI
- Arpad: One problem is that [Model] is single ended
- [External Model] should be an easy way to get where we want
- Fangyi: The content of [External Model] needs to be addressed
- Arpad: This shows a way to connect any analog voltage, it can be completely
analog
- Radek: Whether we use [External Model] or direct s4p call we have to clarify
voltage
- Arpad: A TOUCHSTONE parameter inside a [Model] is a problem because it is
single ended
- Radek: [External Model] has the same problem
- Mike L: If two diff pins call different models we might have the same problem
already
- Walter: EDA vendors are already doing this, but it needs to be documented
- Not many models out there have [External Model]
- We should not complicate things by using it
- Radek: We may want to consider more comprehensive solutions
- Walter: [External Model] still makes no sense
- Michael M: We must have a solution so that no one is left behind
- Arpad: We need a list of what we want in the model, to decide how we are
going to do it
- Then we can start writing BIRDs
- Michael M: David sent a survey question asking about how GetWave is used and
a 5.10 flow question
- Walter: That is unrelated to this
- We need a clear way to allow IC vendors to generate broadband models
- David: I have not heard any IC vendors confirm how it works
- Walter: There will be presentations at DesignCon to clarify it
Arpad: Our next meeting will be Feb 5, after DesignCon
-------------
Next meeting: 2 Feb 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 15 Jan 2013 ibis-atm meeting - Mike LaBonte
