[ibis-macro] Minutes from the 18 Dec 2012 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 18 Dec 2012 16:36:43 -0500
Minutes from the 18 Dec 2012 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 18 Dec 2012
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:
- Arpad: This is the last meeting this year
- The next meeting will be 8 Jan 2013
- James: Is the recent email topic on the agenda?
- Arpad: It is not planned
- It might be brought up in interconnect tomorrow
- Fangyi: The recent topic is more urgent
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Walter send BIRD 150.1 draft 7 to list
- Done
- Mike post BIRD 150.1 draft 7 to web
- Done
- Walter define Usage of dependency table parameters
- Fangyi, Mahbubul, et. al., to discuss merging their "Redriver" proposal with
BIRD 131.
- No progress
-------------
New Discussion:
Interconnect task group report:
- Michael M: We focused on SI2, details will have to wait until next year
- We may need more people from this meeting to resolve some interconnect
issues
- We will be taking up both analog and digital interactions
Walter showed "Backchannel with Repeaters":
- slide 1:
- Walter: A repeater can be a retimer or just a redriver
- slide 3:
- Walter: Redrivers generally are non-LTI
- Retimers contain a CDR, maybe DFE, FFE, regenerate the stimulus
- Fangyi: Redrivers can have filters and an FFE too
- slide 4:
- Walter: The industry uses the term "training" for backchannel
- slide 5:
- Walter: With a redriver the backchannel connect RX directly to TX
- Michael M: It depends on what the redriver is capable of
- They are controlled different ways, but they may be backchannel capable
- slide 6:
- Walter: Redrivers are simple, low power.
- Retimers are more sophisticated
- The RX trains the retimer, which trains the TX
- slide 7:
- Walter: Redrivers here are defined as not able to be trained
- slide 8:
- Walter: This is how people think it works - FAMOUS LAST WORDS
- Walter: We need standardized terminology for the repeater pins
- Fangyi: We call them input and output pins
- With Walter's BIRD the output is associated with an input
- My plan calls for the user to set it up
- Ambrish: My BIRD has other useful features
- Arpad: Should the BIRDs be combined?
- Fangyi: The flows need to be different for redriver and retimer
- Ambrish: Redrivers do not necessarily have to use AMI models
- Fangyi: Then Walter's idea to have separate BIRDs is valid
- Walter: We never defined the output of an RX model
- On an [External Model] we do, but not legacy IBIS
- The AMI RX is defined
- Ambrish: We might work this into the BIRD
- Michael M: One question is if we need probes for an analog-only repeater
- Otherwise this can be a black box
- Walter: What language would the black box be written in?
- It is non-LTI so ISS can't be used, but BSS could
- Arpad: Wouldn't it have to be LTI, as AMI requires?
- Walter: Only the channel interaction is LTI
- Only the algorithmic part is non-LTI
- Michael M: AMS models could be used
- Walter: Fangyi and I need to work together on this
- We should have a report for the next meeting
- Michael M: This is high priority
- Fangyi: I don't agree that redrivers are not trainable
- Walter: If the redriver is trained it has to retrain the TX
- Arpad: Could the RX train both redriver and TX?
- Walter: Not by 803.2bj
- Michael M: The redriver is usually thought to be transparent
- Ambrish: Should the protocol be handled in our spec?
- Walter: The designer decides this in the BIOS setup
- EDA tool might help automate it
Analog models:
- Walter: In IBIS 5.1 no analog model is defined
- Michael M: You can have zeroed-out IV models
- Walter: An IBIS Input requires no IV curves at all
- In IBIS 5.1 the DLL can not affect impulse response creation
- Ambrish: Correct
- Walter: James proposed a way to have the DLL modify the channel response
- James: Two issues:
- What should models do in IBIS 5.1?
- The emails have clarified that
- The analog channel should have high Z input
- What if models do not follow the convention?
- Have seen models that do not, created by members of this group
- From one vendor one TX assumes 0 ohm, other assume 50 ohm
- Signals can only flow forward
- We could let model makers use any declared impedance
- If an s-param is used that impedance is always there
- Walter: Agree, we need a specified on-die s-param analog model
- It has to declare the termination parameters
- Ambrish: Analog models have been put in the DLL?
- Walter: No
- James: My point is that we do not have to force people to use 0 ohms
- Michael M: We are running into TX interoperability problems right now
- In some cases ramp and IV have been embedded in the DLL
- We must distinguish between analog info in DLL vs. AMI
- I don't think anyone wants it in the DLL
- Ambrish: Then the AMI model is not a legal IBIS model
- Michael M: Some problems are cause by assumptions about where the VT data is
- Embedding in the DLL may be bad for bandwidth reasons
- Arpad: Ramp is required in IBIS
- Fangyi: BIRD 116 might address the impedance issue
- Arpad: It replaces C_comp and IV with ISS
- Radek: We have had that discussion, we decided TX is a 0 ohm source
- Defining source impedance should be doable right away
- Walter: IBIS 5.1 says that
- Fangyi: It just says "high impedance interface"
- Arpad: It says "high impedance connection"
- That is even more vague
- Radek: There is no requirement that the input impedance is infinite
- James: We agree on interpretation of IBIS 5.1
- Arpad: IBIS 5.1 does not allow s-parameters
- James: If output is 0 ohms then the s-parameter is -1
- Michael M: There is no way to test this for current implementations
Arpad: We might continue this tomorrow
Arpad thanked all for their hard work during the year
-------------
Next meeting: 08 Jan 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 18 Dec 2012 ibis-atm meeting - Mike LaBonte
