[ibis-macro] Minutes from the 30 Apr 2013 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 2 May 2013 16:46:31 -0400
Minutes from the 30 Apr 2013 ibis-atm meeting are attached. Thanks to
Curtis Clark for taking minutes and Arpad for editing.
Mike
IBIS Macromodel Task Group
Meeting date: 30 Apr 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 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:
- Curtis to take the minutes.
A Cut & Paste error was noticed by Arpad and described in an email:
- Arpad: GetWave_Exists and Use_Init_Output have identical definitions.
- This is on page 185.
- Do we need a BIRD to fix it?
- Walter: Bob pointed out that it is a typo correction.
- The Editorial Committee can handle it.
- Arpad: Do we need to tell them what to write?
- Walter: We can trust them to fix it.
- Michael: There is a "known issues" text file.
- It is in the same directory as the 5.1 spec.
- We can update the text in that file.
- There is no need for a BIRD.
- Changes are noted for editorial revision.
- Bob: I agree with Michael
- I don't agree with Ambrish's proposed change.
- Arpad: What is it? (recent reply to Arpad's email)
- Michael: Page 177, <value>
- "Single value data. The user may assign any value..."
- Not sure of Ambrish's objection.
- Ambrish: The description is inaccurate.
- Who is the "user"?
- Michael: Oh, user vs. model maker?
- Ambrish: It's not clear.
- Bob: It was a cleanup of the complete mess in 5.0.
- Radek: It would be good to see it (show the text on the screen).
- Arpad: Should we look into this now?
- Walter: Let the Editorial Committee handle it.
- Arpad: Okay, let's move on.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad to submit BIRD 160.1 to the IBIS Open Forum.
- done
- Arpad to check if BIRD 158 can be incorporated in BIRD 116-118 as
a shortcut syntax.
- done
- Walter to write new BIRD for [Repeater/Retimer Pin] keywords.
- in progress
-------------
New Discussion:
IBIS Interconnect Teleconference update:
- Michael: (short summary of the last Teleconference).
- Continuing review of EMD.
- Five specific issues under discussion.
Current BIRD Discussions:
- Arpad: Which ones should we look at first? I'm open to suggestions.
- Fangyi, Radek, can we get an update on Repeater and Dependency BIRDs?
- Walter had asked for the Labels BIRD to be discussed.
- Walter: I think we should limit discussions to topics for IBIS 6.0.
- Radek: Redriver is the first one to worry about for 6.0.
- Fangyi: (summary of the current state of the Redriver BIRD 156)
- Approach is specifically for AMI, not legacy IBIS SPICE simulations.
- Consensus via email discussions was to restrict the BIRD to AMI for now.
- Require [Algorithmic Model] keyword in [Model] section.
- Ambrish: That doesn't inform the user that it is only for AMI.
- Fangyi: Would it be a statement of intent?
- Michael: Illegal to use without AMI (so the parser can flag it).
- It is much easier to remove a restriction later than to add one.
- Place the AMI only restriction on for now, and we can lift it later.
- Fangyi: Agree, would a comment saying AMI is required be sufficient?
- Bob/Michael: No, it needs to be something the parser can use.
- Fangyi: If we limit the scope to AMI we can merge the two BIRDS.
- [Repeater Pin] is required. (from BIRD 131)
- Michael: If repeater pin is not AMI, then FAIL.
- Walter: There are two pins (Tx/Rx), each must use AMI models.
- Ambrish: Wouldn't a separate [Model] type be more elegant.
- Radek: Nothing to be gained.
- [Repeater Pin] gives you two pins.
- Michael: [Repeater Pin] does it, or you could do it at the [Model] level.
- For example, introduce a new [Series MOSFET] type model.
- Walter: Repeater models of this form are already out there.
- Ambrish, if you have your own proposal, draft your own BIRD.
- Ambrish: I'm just asking for discussion/clarification.
- Michael: Everything done in this proposal is based on re-use of [Model].
- [Repeater Pin] would say:
- Treat these 2 pins as a single unit.
- They both have to be AMI models (at this time).
- Radek: There is no need to restrict them to AMI or "error out."
- For legacy applications, use them the way they always have been.
- Michael: Analogous to [Driver Schedule]
- It ties models together, but they can be used independently.
- Radek: It is even simpler.
- Ambrish: No, you can't do that.
- Radek: Repeater is not applied to legacy sims, but the [Models] can be.
- Walter: I'll be working on a write-up for a more fundamental issue.
- Repeater flow has fundamental Tx, Rx pairs.
- Each pair uses the classic IBIS impulse response calculation.
- But how does the EDA tool analyze the whole channel for BER?
- Problems could arise for the tool during end to end flow.
- Each primary pair (Tx,Rx) uses GetWave() or doesn't.
- Could easily end up with hundreds of possible combinations of flow.
- Working on a document to simplify and explain it.
- Arpad: I'm thinking about the timeline.
- Need at least one more revision of this.
- Deadline is June, 7, and we need to be in two weeks before that.
- Who is taking ARs to do what?
- Walter: I'll do a flow document for retimers/redrivers for next meeting.
- I'm not concerned with combining the existing BIRDs (editorial task).
- Radek: Could we approve and forward them to the Open Form next meeting?
- Walter: Reference flow is needed, it's currently unclear.
- Fangyi: My BIRD says, "flow is the same as 5.1".
- Walter: I know you said that, and I actually understand what you mean.
- But, does everyone here understand the subtleties?
- I could give an example next week and see what everyone does.
- How does Rx communicate with Tx?
- Ambrish: What do you mean?
- Walter: How do you get the input to the Redriver Tx?
- What if one uses Init() and one uses GetWave()?
- Arpad: We (5.1) have a flow for each "half" channel.
- Walter: Fangyi does describe the flow based on the 5.1 flow.
- But, how do we handle various combinations?
- I know what to do, but we can't assume everyone will.
- Bob: There are undefined terms in the BIRD.
- Fangyi: (sharing text of his latest BIRD revision)
- Walter: Where do you do GetWave()?
- Fangyi: Step 7 in the flow refers back to the 5.1 flow.
- Walter: If Tx GetWave() does not exist, convolve stimulus with
output of Tx Init().
- What about the Tx of the Redriver?
- Fangyi: Step 8.
- Don't generate stimulus for Redriver Tx, it comes from Redriver Rx.
- Walter: Digital vs. Analog stimulus.
- Taking a long channel and breaking it into individual 5.1 channels.
- Subtle differences occur.
- Things get nasty if Tx uses GetWave() and Rx is Init() only.
- Ambrish: No nastier than 5.1.
- Walter: No, it's worse if daisy chaining multiple Redrivers.
- We should advise not to do Tx GetWave() only with Rx Init() only.
- Fangyi: We solved these issues in 5.1.
- Ambrish: Walter is just saying it's complicated.
- Walter: Fine (if you think everyone understands it).
- Arpad: We still have the AR issue. Who does what?
- Walter: Fangyi, Rx/Tx [Models] should be referenced in [Repeater Pin].
- Ambrish: Just integrate the two BIRDS (131, 156) into one BIRD.
- Walter: Why not just leave that to the Editorial Committee?
- Radek: Yes, best to go ahead with two separate BIRDs.
- In Walter's, legacy IBIS ignores all this.
- Bob: I disagree, we should roll them into one BIRD.
- Ambrish: What about differences in flow between Redriver and Retimer?
- Fangyi: Walter and I talked about our differences with Retimer.
- Our proposal - Stimulus for Tx created by EDA tool sampling Rx output.
- Walter: Retimer document will be ready for next week's meeting.
- Ambrish: What is the other way to do it?
- Walter: The Rx of the Retimer has a CDR.
- The Rx generates the follow on stimulus for the Tx.
- Ambrish: Oh, Fangyi's doesn't do it that way?
- Walter: We may need another specifier for Redriver vs. Retimer.
- Arpad: Still have my original question. We need a clear set of ARs.
- 1. Walter will write up the Retimer BIRD.
- 2. Merge BIRD 131 with BIRD 156? Fangyi, can you do that?
- Bob: I think we should combine them so it's complete.
- Ambrish: Agree.
- Walter: We should maintain 3 separate BIRDS.
- The Retimers BIRD changes IBIS sections.
- The Redrivers BIRDs only affect AMI.
- Arpad: Are BIRDs 131 and 156 likely to get opposite approval votes?
- Walter: No, they both will pass.
- If they don't, then the Open Forum can still vote down what results.
- Why bother with the effort to merge them now?
- I won't do it. Fangyi can do it if he wants to spend his time.
- Ambrish: They should just be combined.
- Radek: Walter is right.
- If you combine them, then it will be more difficult to do Retimers.
- Leave them separate.
- Bob: Then how do you link BIRD 156 to [Repeater Pin] (BIRD 130)?
- Radek: The only consequence is ambiguity and extra choice for the user.
- Bob: We don't want the ambiguity in IBIS.
- We need the explicit ties between the BIRDs.
- Ambrish: I have to leave now (just past 4PM).
- Walter: I'm not wasting any more time on this discussion. Good bye.
- Arpad: Unfortunately, no ARs came out of that final discussion.
- We'll have to see how this work falls out in the coming week.
- Arpad: If there are no other questions, this is a good stopping point.
New ARs:
AR: Walter working on clearer flow document for Redrivers.
(Was this idea abandoned?)
-------------
Next meeting: 7 May 2013 12:00pm PT
Next agenda:
1) BIRD 131 and BIRD 156
2) BIRD 154, Leaf Labels in List Parameters
3) Task list item discussions.
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 30 Apr 2013 ibis-atm meeting - Mike LaBonte
