[ibis-macro] Minutes for January and February 2009 meetings

  • From: "Mike LaBonte (milabont)" <milabont@xxxxxxxxx>
  • To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 18 Feb 2009 11:17:04 -0500

Getting caught up; minutes for the last four ibis-atm meetings are
attached.

Mike
IBIS Macromodel Task Group

Meeting date: 17 February 2009

Members (asterisk for those attending):
  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
  David Banas, Xilinx
  Donald Telian, consultant
  Doug White, Cisco Systems
* Eckhard Lenski, Nokia-Siemens Networks
  Essaid Bensoudane, ST Microelectronics
  Fangyi Rao, Agilent
  Ganesh Narayanaswamy, ST Micro
  Gang Kang, Sigrity
  Hemant Shah, Cadence Design Systems
* Ian Dodd, Agilent
  Joe Abler, IBM
* John Angulo, Mentor Graphics
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
  Kumar
  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 Comeau, Cadence Design Systems
  Richard Mellitz, Intel
  Richard Ward, Texas Instruments
  Sam Chitwood, Sigrity
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence Design Systems
  Sid Singh, Extreme Networks
  Stephen Scearce, Cisco Systems
  Steve Pytel, Ansoft
* Syed Huq, Cisco Systems
  Syed Sadeghi, ST Micro
  Terry Jernberg, Cadence Design Systems
  Todd Westerhoff, SiSoft
  Vikas Gupta, Xilinx
  Vuk Borich, Agilent
* Walter Katz, SiSoft
  Zhen Mu, Cadence Design Systems

------------------------------------------------------------------------
Opens:

Arpad: Minutes for several meetings have not been posted.
- Mike: They were uploaded today but email has not been sent yet.

Walter: You can't measure DC with a TDR (related to last week)
- DC measurements should not be associated with s-params
- Arpad: Can DC numbers be added if measured by ohm meter?
  - Walter: Believe so

--------------------------
Call for patent disclosure:

- No one declared a patent.

-------------
Review of ARs:

- Walter: Invite IC vendors to meeting in 2 weeks using ibis-list
  - Not confirmed that Adge can join us.
  - Todd will send email once confirmation is received

- 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:

Review of IBIS Interconnect SPICE document:
- Shunt element:
  - Arpad: There is a .connect statement that equates nodes
  - This can not be used for current measurement
  - Other options:
    - V=0
    - R=0
    - R=small number
      - Arpad: This can cause errors
  - Arpad: We already have R, we don't need to repeat it here
  - Bob: Do we really need .connect?
  - Arpad: .coonect is consistent with the idea that we have no V sources
    - Maybe we should drop V
    - Walter: Many existing SPICE decks would fail
      - Bob: Agree
    - Arpad: But V is limited to 0 here, not a full V element
- Radek: Optional explicit parameter names are not good
  - If we have named parameters maybe they should be required
- Walter: We have a philosophical difference here
  - We are simply defining a subset of HSPICE for interconnect
- Michael M: The only question we had was over dependent sources
  - This is for interconnect only
- Arpad: Is the V=0 element a subset of HSPICE?
  - Michael M: We have trouble when we take away functionality
- Mike L: Do we specify what happens with "R1 1 2 R=5 6" ?
- Arpad: Do we explicitly exclude variable names for parameters?
  - Walter added a note about this

- T element:
  - Walter: Should we require that refin and refout nodes be 0?
    - Arpad: Sometimes the only requirement is same DC potential
    - Arpad: We have no voltage sources anyway
      - Walter: The nodes could be passed in
    - Radek: Why the limit on refnodes?
      - Arpad: All 4 nodes are there, but the refnodes have limited use
    - Mike L: All simulators should be able to handle arbitrary refnodes
      - Walter: Haven't seen any circuits using it
      - Arpad: The voltages can not differ in reality
  - Walter: Should we allow both Z0 and Zo? (oh)
    - Walter: Yes
    - Arpad: As long as HSPICE supports it
  - Walter: Td is actually time per meter, with separate L parameter
    - L defaults to 1 meter
    - We will not allow L=

- E, F, G, H
  - Walter: Every combination of V/I control/source
  - Behavior is basically the same
  - Variations on the simple elements:
    - DELAY
    - LAPLACE
    - POLE-ZERO
  - Arpad: HSPICE has a frequency table version of LAPLACE and POLE-ZERO
    - There are also s-param and W elements
    - Walter: Length seems meaningless on s-param
    - Do we need LAPLACE and POLE-ZERO?
  - Arpad: Only the E element is shown, is that all we have?
    - Walter: No we have all 4
    - Some parameters described do not apply to all 4
    - The full descriptions of all 4 will be selective
  - Frequency Response table is on the next page
    - This settles the previous question about s-param and W element
    - Bob: Usage of this table might not be standardized
  - Should we keep Foster Pole-Residue?
    - The usage is not well known
  - We decided to put Frequency Table and Foster Pole-Residue in "purgatory"

- S-element
  - We will pick up here next meeting

Next meeting: 24 February 2009 12:00pm PT

-----------

IBIS Macromodel Task Group

Meeting date: 10 February 2009

Members (asterisk for those attending):
  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
  David Banas, Xilinx
  Donald Telian, consultant
  Doug White, Cisco Systems
* Eckhard Lenski, Nokia-Siemens Networks
  Essaid Bensoudane, ST Microelectronics
  Fangyi Rao, Agilent
  Ganesh Narayanaswamy, ST Micro
  Gang Kang, Sigrity
  Hemant Shah, Cadence Design Systems
* Ian Dodd, Agilent
  Joe Abler, IBM
* John Angulo, Mentor Graphics
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
  Kumar
  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 Comeau, Cadence Design Systems
  Richard Mellitz, Intel
  Richard Ward, Texas Instruments
  Sam Chitwood, Sigrity
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence Design Systems
  Sid Singh, Extreme Networks
  Stephen Scearce, Cisco Systems
  Steve Pytel, Ansoft
  Syed Huq, Cisco Systems
  Syed Sadeghi, ST Micro
* Terry Jernberg, Cadence Design Systems
  Todd Westerhoff, SiSoft
  Vikas Gupta, Xilinx
  Vuk Borich, Agilent
* Walter Katz, SiSoft
  Zhen Mu, Cadence Design Systems

------------------------------------------------------------------------
Opens:

Walter reviewed the recent IBIS summit meeting:
- There were two papers on EMI
  - There is definitely a need to characterize the EMI radiation of an IBIS
    component.
  - But there is no clear definition of what exactly is need to characterize
    the EMI radiation.
- Mixed mode papers by Vladimir Dimitriev-Zdorov and Yuriy Shlepnev
  - One on the mathematics, and one on some measurement data.
  - It gets interesting around 10GHz
  - Nothing relates to modeling issues we may have
- One paper compared simulations based on EBD vs Board Layout extraction.
- There were two IBIS quality papers:
  - High correlation between perception and actual
  - Failures can be as simple as getting [File name] wrong.
  - The Xilinx paper was about how to improve quality
- Two papers on Broadband IBIS analog model:
  - One on various methods of capacitor compensation when used with IBIS
    "Driver Schedule" buffers
  - Another on using Touchstone between the AMI model and the channel 
interconnect.


--------------------------
Call for patent disclosure:

- No one declared a patent.

-------------
Review of ARs:

- 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:

Walter discussed Todd's IBIS summit presentation "Broadband Analog Models":
- Page 3:
  - Handling of impulse response not fully specified
  - Ian: Is there any documentation of need?
  - IBM co-authored the paper:
    - Would like to enhance IBIS to handle freq-dependent C
    - Ian: It was shown that correlation was good without this
- Page 6:
  - Cadence and Sisoft get the same answers as HSSCDR
- Page 7:
  - The S-param model shown includes the buffer
  - It is stored in s4p files
  - Radek: So then non-linear effects are neglected
    - Walter: This is an AMI assumption
  - Arpad: S-param data often does not go to DC, needed for time domain
    - Walter: IBIS AMI is primarily freq dependent
  - Arpad: Does touchstone include DC?
    - It can, but doesn't have to
    - It is difficult to measure
    - Walter: Good transistor models help
    - Bob: Some tools can produce Touchstone from time domain simulation
- Page 9:
  - There are different proposals for freq dependent C
- Page 10:
  - Touchstone 2 does not have port map data, need to have this in the call
- Page 12:
  - S-param buffer model is an alternative if IBIS does not implement C(f)

Bob: How is the s-param generated?
- Ian: A paper to demonstrate the need would help
- Walter: Adge could answer this
  - Maybe he could join one of our meetings
- Ian: Can other vendors speak about guaranteeing these models?
  - Randy: Micron does not deal with serdes, so no opinion

Arpad: How does this relate to our interconnect language effort?
- Walter: IBIS Interconnect SPICE could replace the need for a direct 
Touchstone call
- Arpad: We should avoid duplication of effort
  - Walter: Would prefer to use Final_Stage subckt
  - John: This could be in an IBIS 4.1 circuit call
    - Walter: That only supports Berkeley SPICE
    - John: But tools tend to go beyond that
- Ian: We are jumping ahead, and should invite IC companies
- Bob: This proposal is an alternative to Final_Stage subckt
  - This should be good for ISI, eye diagrams, etc.
  - Arpad: This makes a good companion to IBIS

Arpad: We should be more organized in going forward:
- Ian: Can we have a meeting with IC vendors?
- Bob: Is anyone experienced in getting s4p buffer models?
- There was some discussion of vendor people who might participate
- Arpad: Should it be next week?
  - Walter: We will have to ask some people to see who can make it
  - Ian: Maybe this discussion should be in 2 weeks

AR: Walter invite IC vendors to meeting in 2 weeks using ibis-list

Walter: Next week we should go through proposed elements in detail:
- People should read the document in advance
- There was some debate about voltage sources

Next meeting: 17 February 2009 12:00pm PT

-----------

IBIS Macromodel Task Group

Meeting date: 27 January 2009

Members (asterisk for those attending):
  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
* David Banas, Xilinx
  Donald Telian, consultant
  Doug White, Cisco Systems
  Eckhard Lenski, Nokia-Siemens Networks
  Essaid Bensoudane, ST Microelectronics
* Fangyi Rao, Agilent
  Ganesh Narayanaswamy, ST Micro
  Gang Kang, Sigrity
  Hemant Shah, Cadence Design Systems
* Ian Dodd, Agilent
  Joe Abler, IBM
* John Angulo, Mentor Graphics
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
  Kumar
  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 Comeau, Cadence Design Systems
  Richard Mellitz, Intel
  Richard Ward, Texas Instruments
  Sam Chitwood, Sigrity
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence Design Systems
  Sid Singh, Extreme Networks
  Stephen Scearce, Cisco Systems
  Steve Pytel, Ansoft
  Syed Huq, Cisco Systems
  Syed Sadeghi, ST Micro
  Terry Jernberg, Cadence Design Systems
* Todd Westerhoff, SiSoft
  Vikas Gupta, Xilinx
  Vuk Borich, Agilent
* Walter Katz, SiSoft
  Zhen Mu, Cadence Design Systems

------------------------------------------------------------------------
Opens:

--------------------------
Call for patent disclosure:

- No one declared a patent.

-------------
Review of ARs:

- Michael M send updated IBIS Interconnect SPICE syntax document to Mike L for 
posting
  - Done

- Walter: Draft BIRD proposal for new keywords
  - This is cancelled

- 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:

Walter lead a discussion of the new IBIS Interconnect SPICE document:
- We started with a high level overview.
  - The Goals and Scope section lists items that it will and will not cover.
  - Syntax Rules
  - Functions and Params
  - Node Naming
  - Element, Subckt Naming conventions
  - Elements:
    - HSPICE "R=" syntax might be dropped
  - Frequency Response Table
    - Not sure who will use it, but it is left in
  - Foster Pole-Residue Form:
    - This is not well understood
  - .SUBCKT
  - S-element:
    - There are lots of options in the HSPICE manual
    - We need to find out which are important
    - SPICE tends to not be forgiving:
      - Some simulators abort, given unrecognized parameters
      - Can people add other parameters for their simulators?
  - W-element:
    - This needs work on how to point to RLGC data

Arpad: Should we combine interconnect and buffers in the same specification?
- Walter: This is a straightforward document as it stands:
  - Adding behavioral models would open up a Pandora's Box of issues
- Arpad: The new features can be incremental, based on this specification
- Michael M: Lance had asked if we will scope out a connection between
  interconnect models and buffers
  - Walter: We could have parallel efforts
  - Randy: This started with EMD, which is separate
  - Bob: Agree, IBIS Interconnect SPICE should be a separate module
    - IBIS Interconnect SPICE, EMD, and buffers should all be separate
  - Arpad: IBIS Interconnect SPICE already has voltage sources
    - We don't want to duplicate
  - Mike L: The behavioral specification could ".include" IBIS Interconnect 
SPICE
- Bob: We should not create new syntax where it does not exist
  - We should stick with a subset of HSPICE and live with the limitations
  - Arpad: We still need to add details
    - These documents should not require looking up in the HSPICE manual
  - Arpad: We already have pole-zero, which HSPICE does not support
    - Bob: HSPICE does support that
    - Arpad: They have controlled sources for this, but not direct support
- Michael M: We should not "bless" the Synopsys format such that others
  become imitators
  - Walter: There is nothing new here, it is all old syntax
    - We are OK as long as this is limited to interconnect
  - Randy: We would only differ if we had impulse response
    - Walter: impulse is a form of transfer function
      - S-params can be generalized to do this
      - Bob: Agree
  - Arpad: Agree with Michael M, the idea is not to promote Synopsys
    - We should not be pressured to add in everything HSPICE has
    - Radek: We do not have to follow everything in HSPICE
    - Walter: HSPICE may even take ideas from IBIS Interconnect SPICE

Walter: What we have here is a good first step
- Todd: This syntax is no more than a donated starting point
- Walter: We don't have to be concerned until we have a new proposal
- Bob: We need to be smart about this
- Todd: We have to consider what Synopsys signed onto
  - Bob: They can shut off any deviation
  - Michael M: Disagree: They have no control

Arpad: What do we do next?
- Walter: We should go through each element
  - This may take 2 or 3 weeks if we prepare
- Ian: It would be good to note vendor support for these primitives as we go
- Walter: We should resolve the resistor today

Arpad: We should plan for the next meeting
- DesignCon is next week, there will be no ibis-atm meeting
- Bob: We might have an ad-hoc meeting at DesignCon

Walter: How should we treat "R=" in resistor?
- Arpad: It should be optional
- Mike L: Having variable numbers of positional nodes and params can get tricky
  - Requiring "=" for all params solves this
  - But staying faithful to the legacy language is still best
- We agreed to make no changes to R through K 
- Walter: Should we have a special shunt element?
  - Bob: Maybe it should not have the number
    - A regular voltage source would be best

Arpad: Should we modify copy and paste into this document or reference?
- Walter: We should review what we have first

Next meeting: 10 February 2009 12:00pm PT

-----------

IBIS Macromodel Task Group

Meeting date: 20 January 2009

Members (asterisk for those attending):
  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
* David Banas, Xilinx
  Donald Telian, consultant
  Doug White, Cisco Systems
* Eckhard Lenski, Nokia-Siemens Networks
  Essaid Bensoudane, ST Microelectronics
  Fangyi Rao, Agilent
  Ganesh Narayanaswamy, ST Micro
  Gang Kang, Sigrity
  Hemant Shah, Cadence Design Systems
  Ian Dodd, Agilent
  Joe Abler, IBM
* John Angulo, Mentor Graphics
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
  Kumar
  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 Comeau, Cadence Design Systems
  Richard Mellitz, Intel
  Richard Ward, Texas Instruments
  Sam Chitwood, Sigrity
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence Design Systems
  Sid Singh, Extreme Networks
  Stephen Scearce, Cisco Systems
  Steve Pytel, Ansoft
  Syed Huq, Cisco Systems
  Syed Sadeghi, ST Micro
* Terry Jernberg, Cadence Design Systems
* Todd Westerhoff, SiSoft
  Vikas Gupta, Xilinx
  Vuk Borich, Agilent
* Walter Katz, SiSoft
  Zhen Mu, Cadence Design Systems

------------------------------------------------------------------------
Opens:

--------------------------
Call for patent disclosure:

- No one declared a patent.

-------------
Review of ARs:

- Walter: Draft BIRD proposal for new keywords
  - No update

- Michael M:  Confirm with Synopsys whether "used by permission" can be used
              as the official indicator on relevant documents.
  - Done! We were given a copyright phrase to use.

- 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:

Michael M: The SPICE specification document is ready for posting

AR: Michael M send updated IBIS Interconnect SPICE syntax document to Mike L 
for posting

IBIS Interconnect SPICE:
- Walter's evaluation criteria:
  - Can vendors produce these models?
  - Can consumers use them?

Michael M has responded by email to Walter's proposal:
- Does IBIS Interconnect SPICE solve the packaging problem?
  - Walter: Mapping of circuits to pins is needed
- Michael M: Point 5 was written because we need to limit our scope to avoid
  making the project unachievable.
  - Starting with IBIS Interconnect SPICE might be OK as long as we don't try
    to solve every problem with it
- Arpad: Should we prioritize this list?
  - Final Stage subckt is important
  - Michael M: There was pushback on Touchstone for not having some features

Walter showed a presentation:
- The types of enhancements are:
  - SPICE based package model
  - Measurement rules
  - Things that affect simulations (eg. Final Stage subckt)
- Maybe we could discuss this at DesignCon
- Michael M: Will we discuss measurement next week?
  - Walter: How about now?

[Specification] keyword proposal
- File would have to exist on an IBIS website
- Randy had discuss JEDEC 79-2C previously
  - The specification is complex nd has to be shown with a picture
- IEEE 802.3ap
  - Polynomial based mask
  - Requires sequential operations
- John: Then we have to focus on the standard, not individual parts
  - Walter: Companies can use their own specifications
- David: Is this the first time we are requiring human interpretation?
  - That might not be a good direction
  - A new specification is needed each time a new value appears
- Arpad: Maybe a specification name should be used instead of a file name
- Walter: Sometimes the specification is a subset of a file
- Michael M: Object:
  - Proprietary specifications
  - Parts of specifications are difficult to control
  - Is partial compliance allowed?
  - It would be tough to validate compliance
- Michael M: options:
  - AMS coding
  - Specify individual measurements
- Walter: For example there are multiple meanings of Vinl_ac
- John: Defining the parts of specifications that apply could be tough
- Arpad: We could point to internal specifications to get around proprietary
  - Michael M: An AMI black box does not have to be disclosed
- Walter: An AMI RX can do this today
  - Arpad: But the output interpretation is not defined
  - Michael M: We see-saw between two concepts:
    - Writing code is demanding for model author
    - Data for existing structures loses flexibility
  - Walter: AMI can do both
- Bob: We should catalog code-based representations of specifications
  - An analogy to [Specification] is simply giving a part number, no pin list
- Todd: It may be difficult to reduce standards down to an implementation
- Arpad: Do we want specification names or file names?
  - Walter: It can be an indirect reference
  - John: The tools will have to interpret on the fly
  - Walter: The tools will have a table of existing implementations
  - Walter: It would help if JEDEC was more computer readable
- Mike L: JEDEC gives only envelope parameters:
  - Individual vendor parts deviate from JEDEC
  - Walter: Vendors must certify that it works on your system

Bob: Reminder: DesignCon summit attendees should register soon



Next meeting: 27 January 2009 12:00pm PT

-----------

Other related posts:

  • » [ibis-macro] Minutes for January and February 2009 meetings - Mike LaBonte (milabont)