[ibis-macro] Minutes from the 10 Nov 2009 ibis-atm meeting
- From: "Mike LaBonte (milabont)" <milabont@xxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 12 Nov 2009 10:46:31 -0600
Minutes from the 10 Nov 2009 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 10 November 2009
Members (asterisk for those attending):
Adge Hawes, IBM
Ambrish Varma, Cadence Design Systems
Anders Ekholm, Ericsson
* Arpad Muranyi, Mentor Graphics Corp.
Barry Katz, SiSoft
* Bob Ross, Teraspeed Consulting Group
* Brad Brim, Sigrity
Brad Griffin, Cadence Design Systems
Chris McGrath, Synopsys
* Danil Kirsanov, Ansoft
David Banas, Xilinx
Deepak Ramaswany, Ansoft
Donald Telian, consultant
Doug White, Cisco Systems
* Eckhard Lenski, Nokia-Siemens Networks
Eckhard Miersch, Sigrity
Essaid Bensoudane, ST Microelectronics
* Fangyi Rao, Agilent
Ganesh Narayanaswamy, ST Micro
Gang Kang, Sigrity
Hemant Shah, Cadence Design Systems
Ian Dodd, consultant
Jerry Chuang, Xilinx
Joe Abler, IBM
John Angulo, Mentor Graphics
John Shields, Mentor Graphics
Ken Willis, Cadence Design Systems
* Kumar Keshavan, Sigrity
Lance Wang, Cadence Design Systems
Luis Boluna, Cisco Systems
* Michael Mirmak, Intel Corp.
* Mike LaBonte, Cisco Systems
Mike Steinberger, SiSoft
Mustansir Fanaswalla, Xilinx
Patrick O'Halloran, Tiburon Design Automation
Paul Fernando, NCSU
Pavani Jella, TI
* Radek Biernacki, Agilent (EESof)
* Randy Wolff, Micron Technology
Ray Komow, Cadence Design Systems
Richard Mellitz, Intel
Richard Ward, Texas Instruments
Samuel Mertens, Ansoft
Sam Chitwood, Sigrity
Sanjeev Gupta, Agilent
Shangli Wu, Cadence Design Systems
Sid Singh, Extreme Networks
Stephen Scearce, Cisco Systems
Steve Kaufer, Mentor Graphics
Steve Pytel, Ansoft
Syed Huq, Cisco Systems
Syed Sadeghi, ST Micro
Ted Mido, Synopsys
Terry Jernberg, Cadence Design Systems
* Todd Westerhoff, SiSoft
Vladimir Dmitriev-Zdorov, Mentor Graphics
Vikas Gupta, Xilinx
Vuk Borich, Agilent
Walter Katz, SiSoft
Zhen Mu, Mentor Graphics
------------------------------------------------------------------------
Opens:
- None
--------------------------
Call for patent disclosure:
- No one declared a patent.
-------------
Review of ARs:
- Arpad modify 10/20/2009 flow to include Use_Init_Output boolean
- In progress
- Arpad Write a clarification BIRD to discuss accuracy issues related to the
various AMI clock_tick algorithms in an IBIS-AMI DLL
- TBD
- Todd: Update the BIRD for IBIS S-parameter box based on feedback from
discussion
- No update
- Arpad: Write parameter passing syntax proposal (BIRD draft)
for *-AMS models in IBIS that is consistent with the
parameter passing syntax of the AMI models
- TBD
- TBD: Propose a parameter passing syntax for the SPICE
- [External ...] also?
- TBD
- Arpad: Review the documentation (annotation) in the macro libraries.
- Deferred until a demand arises or we have nothing else to do
-------------
New Discussion:
Arpad showed the 10/20/2009 flow slide 1:
- In convolution 3 Use_Init_Output must be true if Tx GetWave_Exists is false
- This creates 3 different convolution cases
- It doesn't matter where the convolution 4 box is placed in the flow
- It is placed after convolution 3
- Arpad: Can Rx_Init 2nd expression work with the convolution 4 box?
- Walter: It would have to be deconvolved in that case
- If Use_Init_Output = true then Rx Init_Returns_Filter must be true
- Kumar: It can not return a filter
- Walter: Correct, but then Rx Init_Returns_Filter should be true
- We will have to live with that compromise
- We will use the term "preferable" for this
AR: Arpad update flow slides
Brad's connectivity proposal
- System models sometimes concatenate several connectors together
- Thousands of terminals
- Mistakes will be made if typing these
- How can model generation and EDA tools work together?
- Chip-package co-design simulates them together
- Sigrity adds comments to describe connections
- Working with EDA companies on this
- There should be one protocol
- Anyone interested in working on this?
- Arpad: This relates to the EMD proposal
- Walter: EMD is top down, Brad is looking bottom up
- With enough info the system could build an EMD
- Brad: We want something for a Q1 time frame
- What forum is best for this?
- Touchstone could have the same info
- Walter: The port information should be extensible
- We put port mapping info in side files
- Mike L: Side files are OK for resident project areas
- Single files are best for distribution to avoid confusion
- Brad: Are we nearly ready to take this on?
- Arpad: A few more meetings are needed for AMI
- It may take the rest of the year
- Walter: The Wed interconn group is about to turn to TS port mapping
- Arpad: Does this conflict with EMD?
- Walter: This is bottom up, EMD is top down
- They can co-exist
- Bob: Who else is involved?
- Brad: Can't say, under NDA
- Some of them can join meetings
- Bob: How far along is the proposal?
- Brad: We will deliver in Q1
- Bob: The other group is working on connectors
- Brad: A package is a connector
- When we refer to a chip the connector is included implicitly
- Bob: It would have to be made public
- Brad: This was done long ago
- Some may avoid it because it was created privately
- IBIS approval may help
- Sigrity will release documentation with our name stripped off
- Arpad: This will continue in the Wed meetings
Arpad showed some questions from Mentor developers:
- a) Require GetWave to contain fixed number of samples per bit?
- For example, each GetWave call might have 5, 10, 15, etc bits
- Mentor says yes
- Kumar: Should treat all GetWave calls as a continuous waveform
- This is a difficult problem
- Walter: Agree
- Arpad: It would make it easier for the model maker
- Walter: You can't assume there would always be the same number of samples
per bit
- Arpad: 5 is just an example
- Walter: What if it is not constant?
- Kumar: DCD for example
- They have to handle this with resampling
- b) Are 2^N samples per bit required?
- Kumar: It has to always be resampled
- Walter: Agree
- Bob: Do model developers have a choice in this?
- Arpad: Only if there is a way to tell the EDA tool
- Walter: Some algorithms work best with 16 samples per bit
- The input has to be converted to 16 samples per bit
- c) How many clock ticks can GetWave return?
- The EDA tool must allocate memory
- Kumar: It should be the same as the input waveform
- Arpad: If there are 300 samples I might have only 10 clock ticks
- It will run millions of bits
- Walter: You only handle thousands at a time
- Fangyi: There should be only one -1 at the end of the clock ticks
- Kumar: In the first spec we had one size for GetWave
- Walter: There has to be clarification on this
- d) Can GetWave size vary between calls?
- Walter: We should allow it
- It would be safer to not change the size
- Arpad: Init also allocates memory
- Walter: At Init we don't know how long the GetWave calls will be
- Only overlap-and-save memory must be allocated by Init
- GetWave is re-entrant
- Todd: Init also allocates internal state data
- Kumar: Memory is allocated by the EDA tool, not the model
- Arpad: We need to ask model developers
- e) Should clock ticks be aligned with sample times?
- It should not be
- Walter: Agree
Arpad: We will discuss our holiday schedule next time
Next meeting: 17 Nov 2009 12:00pm PT
--------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 10 Nov 2009 ibis-atm meeting - Mike LaBonte (milabont)
