[ibis-macro] Minutes from the 21 Jan 2014 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: ibis-macro@xxxxxxxxxxxxx
- Date: Tue, 21 Jan 2014 16:22:23 -0500
Minutes from the 21 Jan 2014 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 21 January 2014
Members (asterisk for those attending):
Agilent: Fangyi Rao
* Radek Biernacki
Altera: * David Banas
Julia Liu
Hazlina Ramly
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
Andy Joy
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:
- Arpad: No meeting next week, we will be at DesignCon.
- The next meeting will be Feb 4
- Michael M: Reminder to send presentations for the IBIS summit ASAP.
- The deadline is today.
- Please print 50 copies.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- None
-------------
New Discussion:
BIRDs 163, 164, 165:
- Arpad showed an update to figure 29 of BIRD 163.
- Two changes suggested in the last meeting have been made.
- Walter: What is the model name of the buffer in section D?
- Arpad: It is an [External Circuit] so it has no model name.
- Walter: This violates our "one pin, one buffer" rule?
- Arpad: It has only one buffer.
- Walter: To find the buffer for pin 4 you have to look up the circuit?
- Arpad: Yes.
- John: This show all uses of [External Circuit]?
- It is just an update of an existing figure.
- Walter: Will anyone use Verilog or VHDL for interconnect?
- Arpad: Not many may want to, but it can be done.
- Walter: Only Mentor and Cadence have these simulators?
- Arpad: Most vendors support Verilog-A using HSPICE.
- Michael M: Would it be a problem to rule those out for interconnect?
- Arpad: Maybe not.
- Walter: This might effectively exclude some EDA vendors.
- Arpad: We have no desire to promote AMS languages for packages.
- Walter: We could have [External Package] that supports only IBIS-ISS.
- Arpad: No objection, but I don't see the need.
- This proposal came up last week.
- Radek: It is a valid concern.
- There is no need for AMS in on-die interconnect.
- Ambrish: This has existed for 5 years.
- Walter: It was a mistake then to add AMS.
- Arpad: We to either:
- Add a subparameter to say if it is for package or on-die.
- Add a new keyword that only deals with interconnect.
- Bob: No one uses [External Circuit] with AMS for interconnect.
- Arpad: There is an issue with the legacy package part of the figure.
- Both legacy and new circuit might be combined, unintended.
- We might have one part of the package connected to legacy, another to
external.
- Randy: It should be one or the other, not both.
- Bob: In some cases it might be the only way to model the device.
- Walter: There might be one power delivery model, and one or more signal
models.
- There would be no coupling between power and signals.
- Alternatively there might be one signal model (with one or more I/O) and
also power and ground.
- In any case power and ground would be in one model.
- Arpad: The issue is where one pin connects to two package models.
- Walter: It will not be a problem for power and ground pins.
- It might be confusing for those writing models.
- Arpad: We need to show cookbook examples.
- Walter: Doing it with [External Circuit] makes that difficult.
- [External Package] would be easier.
- We need to show examples of our syntaxes reflective of what IC vendors can
deliver today.
- Bob: Imagine you have:
- 1 on-die interconnect with a standard package.
- 2 [External Model] driving on-die interconnect.
- Why do we need the colon syntax for [Model] but not [External Circuit]?
- Arpad: To help us find the terminals of a specific buffer.
- John: How would we use ideal supplies?
- Arpad: Section A shows that.
- IBIS is vague on how to connect this.
- John: It is not a real PDN model, no RLC.
- Bob: A [Circuit Call] could use those reserved colon names.
- They are defined for only [External Circuit] and [External Model].
- Bob: Calling an [External Circuit] there are no model names.
- John: No one has ever used it for that.
- Arpad: [External Circuit] should be only for the interconnect part.
- John: The key here is to combine [Model] with [External Circuit] for package.
- Michael M: Will there be mixing of legacy package styles and new?
- That would affect the style we use.
- We might not spend much time on pathological cases.
- We will not be combining both styles within packages.
- Arpad: Some might want to use legacy for just the "boring" signals.
- Michael M: Anything that is not traditional [Model] is legacy.
- John: What if [External Model] is used?
- Michael M: We have seen little use of that.
- There can be simple buffers with complex packages that IBIS can't handle.
- Walter: With SerDes we certainly want good package model, usually s-param.
- Around 3GHz lumped RLC might do.
- Michael M: There is simply no interest in legacy IBIS package models.
- Walter: Is there an IBIS file illustrating the need for mixed package model
types?
- Arpad: Will there be a need to probe internal pad nodes?
- We probably want just the model terminal, not the pad.
- Walter: We traditionally have assumed these were effectively the same.
- It should be at the buffer.
- That should be an additional probe point for timing specs.
- Arpad: Do we need 3 probe points?
- Bob: We need the pads.
- Buffer terminals are only available by simulation.
- Walter: It makes a difference above 10G.
- Arpad: The IBIS spec does say something about probe points.
- Walter: It does not distinguish between pad and buffer.
- Arpad: It might have something.
- Bob: The model is hooked up to the pad.
- There should be no limit here because the nodes exist.
- Walter: It matters where we say how timing is done.
- At 56G the important point is the latch after the buffer.
- Timing specs currently will be at the pad, but that is not for SerDes.
- Radek: If the spec says nothing we do not need to add anything.
- Arpad showed Timing_Location and Si_Location in the IBIS 6.0 spec.
- It says "Die", which could be either pad or buffer.
- Walter: We could add "Pad" and "Buffer".
-------------
Next meeting: 4 February 2014 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 21 Jan 2014 ibis-atm meeting - Mike LaBonte
