[ibis-macro] Minutes from the 11 Jun 2013 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 11 Jun 2013 17:27:53 -0400
Minutes from the 11 Jun 2013 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 04 June 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:
- Walter: We should discuss open forum votes and editorial process
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Fangyi to get clarification of retimer flow ready for Friday.
- Done
-------------
New Discussion:
Interconnect update:
- Michael M: There was no meeting last week
- There will be a meeting this week
IBIS 6.0:
- Michael M showed a list of new BIRDs in IBIS 6.0
- Michael M: Currently it is being called IBIS 6.0 but we need to discuss
numbering strategy
- Walter: We need to start the editorial process
- Radek: I can help
- Bob: BIRD 156.2 should be upgraded to 156.3
- Michael M: That will happen shortly, with changes folded in
- Walter: BIRD 145 was discussed and tabled for the interconnect group to handle
- BIRD 158 was not voted at the last open forum
- Radek and I will work on that offline
- Ambrish had raised objections to the BIRD
- BIRD 161 will be discussed in interconnect
- BIRD 150 & 155 are two ways to handle dependencies
- We have to decide what to do about back channel BIRD 147, BIRD 128 is
related
- BIRD 125 needs to be discussed
- Michael M: A draft 6.0 is ready, can be posted in the minutes
- The draft was easy to assemble in the new format
- The IBIS Version Change Strategy document:
http://www.eda.org/ibis/docs/ibis-version-change-strategy-v3p0.pdf
(an XLSX is also available)
- The WIP IBIS Ver. 6.0 draft is available at
http://www.eda.org/ibis/ver6.0_wip/
- Arpad: Why is there a comment about IBIS 5.2?
- Michael M: It is a placeholder, will be deleted
- Walter: When will we have a 6.0 parser?
- Michael M: We need to start the bidding process
- Arpad: I am concerned about a new developer being unfamiliar with the code
- Bob: It probably will take months to get started and months to complete
- Michael M: The process can begin fairly soon
- Bob: We will need to assure funding
- Bob: One option is to suspend interconnect meetings and use the time slot
again
- Michael M: If there is no objection
- Ambrish: Are all of the changes folded in?
- Michael M: Yes but there are some outstanding issues
Backchannel:
- Arpad: Is there any news on BIRD 147?
- Ambrish: It was shared in March, not revisited since
- There will be an update next week
- We should all review the current BIRD
- Walter: BIRD 128 can be combined with BIRD 147
- Bob: BIRD 128 is just one page, that should be OK
- Both BIRDs are written against IBIS 5.0 though
- Arpad: They can be rewritten against 6.0
- Arpad: It is a problem that we are changing the in/out argument usage in BIRD
128
- It may be better to add a new argument
- Radek: Agree, we should work on this
- Arpad: There may be backward compatibility problems
- Radek: We have AMI_Version to handle that
- Arpad: We will discuss this next week
AR: Ambrish update BIRD 147
Dependency Tables:
- Walter: The BIRD 150 functionality is well understood
- BIRD 155 takes the idea that tables are not flexible enough
- There will be memory management issues, plus in/out issues
- Dependency table changes will require a new DLL, not just an AMI change
- We could implement either BIRD, or both
- Radek: BIRD 155 should be easily updated soon
- Arpad: BIRD 155 avoids having to explain BIRD 150 table operation
- Any new features required will not require a spec update
- Radek: Fangyi may not be available next week
- Walter: We should have model maker feedback
- David: Altera prefers the DLL approach
- It also helps protect IP
- Mike L: It is easy to determine every possible mapping by probing
- David: The logic behind the mapping can still be concealed
AR: Arpad contact Fangyi about BIRD 155 updates
Eye Mask Definition:
- Arpad: We need to resolve the timing side of this
- Michael M: There was a proposal in this from Japan
- Is this for pass/fail testing?
- Arpad: It is for BER
- Michael M: I wonder if a pass/fail spec is useful
- Arpad: We could have multiple eye masks, for different BER levels
- Rx_Receiver_Sensitivity is a poor man's eye mask, we need a full fledged one
- Ambrish: Rx_Receiver_Sensitivity is not an eye mask
- Arpad: It needs to have a timing component added
- Walter: That is handled by Clock_PDF
- Rx_Receiver_Sensitivity is like Vdiff
- This is an interesting topic, but it opens a Pandora's Box of issues
- Arpad: This is at the other side of the model
- Walter: Is this for legacy models?
- Arpad: They are not clocked
- Michael M: We may simply not be documenting the clocking, but it may still
exist
- Arpad: We can't deal with eye masks for legacy models
- Somehow we never introduced that concept
- Walter: DDR4 has eye mask rules
- There should be a BIRD for that
- An AMI model should be usable within any standard
- These rules should belong to the standard, not the model
- Arpad: Why is Rx_Receiver_Sensitivity in the spec?
- Walter: That is the silicon itself
- Ambrish: What does Rx_Receiver_Sensitivity do?
- Arpad showed that portion of the spec
- Arpad: Where is this measured?
- David: It has to be measured at the ball
- Walter: Some chips gives scope readings at the decision point
- David: The signal at the slicer is not part of the standard
- Ambrish: Rx_Receiver_Sensitivity only helps determine the BER
- Walter: In combination with Clock_PDF
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 11 Jun 2013 ibis-atm meeting - Mike LaBonte