[ibis-macro] Minutes from the 10 Apr 2012 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 11 Apr 2012 17:58:29 -0400
Minutes from the 10 Apr 2012 ibis-atm meeting are attached. Thanks to
Curtis Clark for taking minutes.
Mike
IBIS Macromodel Task Group
Meeting date: 10 Apr 2012
Members (asterisk for those attending):
Agilent: Fangyi Rao
* Radek Biernacki
Altera: David Banas
Ansys: Samuel Mertens
* Dan Dvorscak
* Curtis Clark
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
* Ambrish Varma
* Feras Al-Hawari
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: * Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
Maxim Integrated Products: * Mahbubul Bari
Mentor Graphics: * John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: Randy Wolff
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: * Eckhard Lenski
QLogic Corp. * James Zhou
Sigrity: Brad Brim
Kumar Keshavan
* Ken Willis
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
The meeting was lead by Arpad Muranyi
------------------------------------------------------------------------
Opens:
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad to propose IBIS spec changes to clarify ISS D2A & A2D interfaces
- no update
- Arpad to write a new revision of BIRD 117 and 118 to generalize references
to parameters in files (.ami or any)
- in progress on 117
Ambrish update BIRD 145 for pad to pin mapping and other clarifications
- in progress
-------------
New Discussion:
BIRD 144 discussion:
- Arpad: Last week we ended the meeting while discussing BIRD 144.3.
- Is this BIRD simplifying things?
- Boundary conditions were added. Did they make it too complicated?
- Are people ready to continue discussion of these questions?
- Ambrish: (summarizing the development path of the BIRD)
- Propose removing the new boundary conditions from the BIRD.
- Replace with a description of assumptions in certain cases.
- Will better serve the BIRD's goal of simplicity.
- Feras: Goal is ease of use.
- Point to a Touchstone file directly.
- Portable since you don't need any SPICE syntax wrapper.
- Termination was added at this committee's request.
- Instead, we might simply specify the EDA tool's expected behavior.
- Arpad: Define a general rule in the spec instead of rules for each model.
- Ambrish: User can still use another wrapper for more complex cases.
- Feras: Yes, [External Circuit] can easily handle a more complex case.
- It could cascade to another [External Circuit] for termination.
- Termination only an issue for [External Model].
- However, a termination scheme was proposed and it's not too complex.
- Arpad: Two questions for general rules:
- 1. Are reserved terminals connected directly to S-parameter blocks?
- 2. What to do if S-parameter has extra ports (dangling ports)?
- Feras: Direct connection between reserved terminals and Touchstone ports.
- floating ports -> high impedance.
- Radek: Port is two terminals. How is a port defined in this context?
- Feras: SPICE subcircuit has terminals, S-parameters have no such concept.
- Radek: Yes, an S-parameter port is + and - terminals.
- How is this defined in this BIRD?
- Arpad: Good point, IBIS is sometimes loose on this point of Ground ref.
- Radek: We follow HSPICE convention, but it's well defined.
- What is the reference node here?
- Feras: Ground is the common reference node.
- Radek: You must state this explicitly.
- Arpad: IBIS has [Pulldown Reference] defined, not simply ground.
- but there is a reserved analog "Port Name", A_gnd for analog ground
in the [External ***] section of IBIS which could be used for this.
- Feras: DC voltages might be entirely inside the model.
- Only 2 terminals for an S1, for example.
- Only 4 terminals for a differential buffer.
- 7 basic terminals in IBIS, among them are the 4 pwr/gnd refs.
- James: by definition S-parameters have no global ground.
- not a valid concept for S-parameters.
- Arpad: True.
- but that doesn't prevent user from connecting all refs to same point.
- Feras: BIRD currently assumes global ground is the common reference.
- James: We can define how terminals are connected if not to S-parameters.
- But, it would not affect the S-parameter block in any way.
- Feras: True.
- James: IBIS only provides framework/format. User can decide.
- Feras: BIRD now gives extra flexibility, but tradeoff is complexity.
- Ex. Simple general rule - any dangling terminal gets high impedance.
- James: So the BIRD gives a default behavior but with flexibility?
- Ambrish: No, one or the other.
- Arpad: If you stick an S-param block in a normal [External Model],
- Direct connections to reserved terminals, others dangling.
- [External Circuit] case is more flexible.
- It could use another [External Circuit] wrapper for termination.
- Burden for termination is on the model maker.
- Walter: Everything in this BIRD could be done with IBIS ISS (BIRD 116).
- This discussion is going into a rat hole.
- Propose a straw-man vote on whether to continue with this discussion.
- Feras: I agree that it can all be done with BIRD 116.
- However, this is a shortcut for S-parameter blocks.
- Walter: Shortcut is exactly what BIRD 122 proposed.
- You rejected BIRD 122 because you didn't want shortcuts.
- Feras: My problem with BIRD 122 was with the SPICE templates.
- Not as general as S-parameter blocks.
- Ambrish: We also had issues with the AMI specific nature of BIRD 122.
- Walter: I make a formal motion that we should vote on this.
- Now or next week.
- Ambrish: We have support for this BIRD from other users and EDA vendors.
- Feras: I agree with Walter. Let's decide on how to proceed now.
- Arpad: Do we have a second to Walter's motion. (silence)
- I think we should move on to other topics, so I will second the motion.
- Radek: I don't support voting today.
- We should make sure everyone knows we will be taking a vote.
- We should have a vote to show our group's opinion to the Open Forum.
- Arpad: I will send a notification of the upcoming vote to the reflector.
AR: Arpad send notification of upcoming vote to the reflector.
------------------
CTLE example email:
- Arpad: Walter, do you have anything to discuss?
- Arpad: (highlighting April 4th CTLE email on screen)
- Walter: Example in the current spec only has one set of poles and zeros.
- New example with 2 sets of poles and zeros.
- A two row table for poles.
- The first row has three poles.
- Second row has two poles, but since N/A isn't available 0,0 for third.
- Arpad: Could we have some background? Why?
- Walter: Existing example only allowed one transfer function.
- wanted to provide an example to define multiple.
- Feras: This is frequency domain. We usually work in time domain for this.
- Walter: All vendors describe their CTLEs with poles and zeros.
- Feras: The model consumes these values?
- Walter: The model uses them in Init(), GetWave(), etc.
- Radek: Is this just a selector, or could the user modify values?
- Could just use hard coded values inside the model and a pure selector.
- Walter: The model maker could choose to do either.
- Arpad: The entire table is passed into the model?
- The selector is then used to choose?
- Radek: (0,0) is a valid pole at the origin. It shouldn't mean no pole.
- (0,0) for pole and zero would be okay as a nothing.
- Walter: I would certainly prefer to say N/A, but it's not allowed.
- Ambrish: Where is the original example?
- Bob: It's a Table format example.
- James: This is a model specific parameter, the meaning could be anything.
- Ambrish: yes.
- James: Radek's question was about specific data.
- Spec shouldn't assign any meaning to data in a model specific param.
- Bob: data must be consistent with what the .dll wants.
- James: yes, but the spec should not define any model specific data.
- Bob: yes, as long as the data is formatted correctly.
- Ambrish: This looks more like a CTLE example than a Table example.
- Bob: model specific parameter is vendor specific.
- Could define any convention for this data.
- (0,0) could be okay as do-not-use.
- Or, for example, a positive pole could mean do-not-use.
- James: the tool need not understand this specific data.
- Arpad: yes, model specific implies what you just said.
- Bob: complex conjugate pairs are implied by this example.
- Arpad: So what? It's model specific.
- Feras: I agree, for physical systems we expect complex conjugate pairs.
- Arpad: That doesn't matter for this example.
- James: Agree, specification should not attempt to provide meaning.
- Radek: I have a question of a different sort.
- We have unfinished discussions on Out and InOut for model specific.
- Therefore, I think we should not use InOut in this example.
- Keep this example strictly In, until we can clarify InOut and Out.
- Ambrish: We have InOut in a BIRD.
- Walter: I have no objection to using In for this example.
- Would provide a nice segue to InOut for the Rx case though.
- Radek: yes, I understand your point 100 percent.
- Feras: I would prefer the example list the conjugates.
- Walter: None of the standards do it that way.
- Arpad: I want to get back to Radek's (0,0) question.
- Do we have a limitation we need to address?
- Is the fixed row length requirement a problem without N/A?
- Do we need a spec change?
- Walter: If CTLE were a reserved parameter, we'd have to address it.
- Arpad: We don't need to address it here?
- Radek: Just don't say it here.
- Since it's model specific, just don't provide the description.
- Bob: It's an application specific example.
- Arpad: Do we need to address a limitation and future problem?
- Bob: If we address it, I prefer another column entry instead of N/A.
- Another column entry could define the length of the row.
- Preferable to polluting syntax with N/A symbols.
- Ambrish: I would want an example of the param string itself.
- Arpad: Okay, any requests for this AR for Walter?
- 1. InOut -> In
- Ambrish:
- 2. Text explaining what the example does.
- 3. Show the parameter string.
- Radek: It is clear already.
- These rules are already in the Table BIRD (BIRD132).
- Ambrish: Examples in BIRD 132 all describe the param string.
- Arpad: Okay, I get it. (make it consistent with other examples)
- Arpad: (Final summary of the three items in the AR.)
- Ambrish: okay.
- Arpad: Walter, can you and Bob do it.
- Walter/Bob: yes, no problem.
AR: Walter/Bob prepare CTLE parameter string example
-------------
Next meeting: 17 Apr 2012 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 10 Apr 2012 ibis-atm meeting - Mike LaBonte
