[ibis-macro] Minutes from recent ibis-atm meetings
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 29 Nov 2011 09:21:41 -0500
Minutes from 6 recent ibis-atm meetings are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 11 Oct 2011
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
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
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:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad look for Table column type issues in BIRD 127.2
- Done
- Arpad check on AMI_parameters_out exceptions and maybe send email
- Done
- Arpad update BIRD 127
- Done
AR: Mike check on posting of BIRD 127.3 draft
-------------
New Discussion:
Backchannel BIRD:
- Ken: It has not been changed for a while
- We need to finalize any remaining issues
- Arpad showed the BIRD draft
- Ken: We should move crosstalk issues into a separate BIRD
- Walter: This should be submitted to the Open Forum to get a BIRD number
- Vendors can check for compliance and deal with problems as found
- We should have done this for AMI 4 years ago
- There is no rush to get approval
- Ken: No issue with that
- Bob: That is a misuse of the BIRD process
- It would have zero status
- Walter: It would be under revision control
- People would know they do it at their own risk
- Ken: The only reason not to submit is if there is a known flaw
- We know of none now
- Bob: The rules for pattern definition are not well defined
Arpad showed BIRD 127.3:
- Arpad: This calls for Type to have multiple values
- Some notes have been removed to avoid confusion
- Added a reference to section 3.1.2.7 because we separated
AMI_parameters in and AMI_parameters_out
- Added explanation of AMI_parameters_out string formation
- This needs to be reviewed
- Walter: It looks fine but needs study
- The parser should check for multiple Type values if version is 5.1
- Even a list of values is a single value if between one set of parentheses
- Arpad: This is not a technical issue
- Bob: We should add note 9 on page 6
- Description is optional but it might be construed as required here
Arpad showed SamplingRateBIRD_03.txt:
- Arpad: Sample rate is discussed in three places
- The sample_interval parameter is introduced
- Walter: Some models only work at certain block sizes
- We should have the same wording for that
- Arpad: Should that be an independent BIRD?
- Mike: They are somewhat related
- The sample_interval factors into the number of samples sent to Getwave
- Arpad: We will postpone this to another meeting
BIRD 123:
- Arpad: It should be bumped up to a different number
- Walter: It will 123.5 rev locally, submitted to Open Forum as 123.3
Corner issues:
- Walter: IBIS has a good definition of slow/weak and fast/strong.
- It does not require tools to use them
- AMI corners match the defined derivation methods
- Typ is the 1st value, slow 2nd, fast 3rd
- Walter showed his recent email on the subject
- Walter: The term "it is permissible" in section 9 should be changed
- Anything that is Format Corner has to do with the derivation method
- Arpad: What about C_comp?
- Walter: A new C_comp parameter such as Bob's proposal would be valid
- Bob: Agree, but analog models might have C_comp
- Walter: AMI models can not use regular IBIS models
- There are more than 3 corners
- Touchstone can be used
- Arpad: It is still allowed in 5.0
- Walter: It only makes sense with parameterized ISS subcircuits
- Arpad: We need to move on to discussing 5.2
-------------
Minutes by Mike LaBonte
Next meeting: 18 Oct 2011 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 08 Nov 2011
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
Celsionix: Kellee Crisafulli
Cisco Systems: Mike LaBonte
Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: * Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
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
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:
- None
-------------
New Discussion:
Quick question from Ken regarding Backchannel BIRD status:
- Ken: Backchannel BIRD was tabled in IBIS Open Forum. Next step?
- Arpad: Pull it back here in ATM for review or stay in Open Forum.
- Ken: Anymore feedback? What's left to do before acceptance?
- Bob: I had syntax objections I'd raised privately.
- Ken: What's the process to move forward?
- Arpad: Feedback, discussion, then vote to have Open Forum move on it.
- Ken: Okay, everyone please help by providing feedback.
- Bob: After the upcoming summit.
- Arpad: I haven't had time to give it a thorough review yet, but intend
to do it soon.
- Let's get email feedback to Ken, then we can discuss it.
BIRD 140.1 Corner Clarifications:
- Arpad: Start with the new BIRD (proposing Model_type restrictions)
- Summarized previous meeting's decision to restrict the Model_type
- new BIRD reduces number of parameters with corner mapping issues.
- Very simple new BIRD as written.
- Discovered a new issue, however.
- 3-State Model_type should be restricted to AMI Tx.
- But, I/O has same issue and no way to tell if AMI is Tx or Rx.
- How do we know?
- Should we address this ambiguity?
- Arpad: Walter and Todd privately suggested a solution
- Restrict Model_Types to Input, Output, Input_Diff, Output_Diff?
- Arpad: This suggestions concerns me. What about ECLs for example?
- Bob: Don't address it here. Leave it alone.
- Address it in 5.2, not hurting anything to leave it alone.
- Don't want more work for the parser.
- Radek: I/O not really a problem. If enabled it's Tx, else Rx.
- Arpad: No way to know if the [Algorithmic Model] is Tx or Rx.
- Radek: Oh, the .dll name usually makes it clear what the model is.
- Bob: Yes it's an issue, should not be resolved now, new parameter?
- Arpad: Yes, agreed. Ultimately, we could add a selection parameter
- Then have both Tx and Rx references in the same [Algorithmic Model].
- Bob: Would bi-directional AMI be a stretch?
- Arpad: Yes, probably a stretch.
- Would need selection of both Tx and Rx parameters.
- defining the selection process would be a big effort.
- Radek: Not a real ambiguity. Up to the user.
- Bigger ambiguities in [Diff Pin] vs. differential buffer.
- Arpad: Anyone opposed to moving on with the simple BIRD as is?
- Do we need another review cycle
- Wait, don't act on that question until we review other changes.
Move on to changes in BIRD 140.1 itself:
- Arpad: [Diff Pin] keyword, tdelay_*** values are ignored for AMI
- Do we need more verbiage?
- Radek: intent was to clarify tdelay_*** has no association with corner.
- We should not force zero to be used at all times.
- Arpad: this is just saying that tdelay_*** ignored for AMI channel
characterization, normal simulations are not affected
- Bob: Last meeting I had agreed with "just ignore" or treat as zero.
- These weren't really "corners" they were delay tolerances.
- Concern now is that this text should go under AMI not [Diff Pin].
- Any elaboration should also go in AMI.
- Arpad: Partially disagree
- [Diff Pin] user should immediately see tdelay_*** is ignored for AMI.
- Bob: I guess I'd be okay with adding it in both places.
- Radek: Agree with Bob, keep it separated in AMI.
- Arpad: Open to suggestions.
Move to next section/modification:
- Arpad: for External Model/Circuit
- "min" Model -> slow/weak
- "max" Model -> fast/strong
- Bob: Okay with [External Model] (buffers).
- Not Okay with [External Circuit], might be passive interconnect.
- Would represent "tolerance" not a "corner" in that case.
- Arpad: isn't "long trace" -> slow corner?
- Bob: yes, could be okay.
- Radek: sounds fine
- Bob: it might render all [External Circuit] parameter selection muddled.
- Arpad: I always thought "min" and "max" kind of odd for External Model
- this is actually more of a clarification.
- Bob: This runs the risk of making [External Circuit] just another buffer.
- [External Circuit] has a higher scope (outside Model)
- strange to tie it to a model/buffer-centric parameter like typ.
- Arpad: Issue is already muddled
- if user wants all "slow" cases, shouldn't they be able to get slow?
- slow package and slow buffer for a system analysis?
- Bob: Using the same lingo, what's a strong/fast connector? (Ext Circuit)
- Arpad: low impedance, fast propagation velocity...
- Bob: Could depend, series vs. parallel termination, for example.
- Arpad: an interconnect could be fast/slow from system design perspectives
- everyone propose suggested text and I'll consider it.
Move on to next section/modification:
- Arpad: (revisiting the "implicitly aligned" section)
- reiterate "typ/min/max" and reference section 9 on Data Derivation.
- Bob: Changes are good, now acceptable for 5.1.
- these changes avoid the problem areas we'd run into.
- Fangyi: slow -> "Min", fast -> "Max", is this always true?
- What about a jitter parameter? Minimum should be fast.
- What about a Range parameter (AMI).
- Arpad: A jitter parameter is an AMI Format Corner parameter, which doesn't
require the <slow value> to be smaller than <fast value>
- It would not need the linkage being defined here with old IBIS analog.
- Radek: Fangyi is saying corner would force "slow" -> "Min" mapping.
- What would Range do? We should address them together.
- Arpad: disagree. AMI List/Range are explicitly independent of Corner.
- Last sentence in paragraph is saying this.
- Radek: there is a new ambiguity with Range.
- Fangyi: Oh, I see (realizing the source of his confusion)
- Could we make two things more explicitly clear?
- Mapping AMI corner to legacy IBIS analog
- AMI Range/List are independent of Corner.
- Radek: Last sentence is insufficient to clear up Range ambiguity.
- Bob: Range has an entirely different meaning (it's independent of corner)
- Choosing tap coefficients, for example
- Range/List are user tunable parameters
- Arpad: I've added extra verbiage (showed the location) detailing these
- Corner description
- Range description
Arpad: This has been a good discussion.
- Those of you who have suggestions or made suggestions please email them.
- Back to the previous question about proceeding with the new BIRD.
- Let's go through one more review cycle with this discussion.
Meeting ended.
-------------
Next meeting: 29 Nov 2011 12:00pm PT
(11/15 and 11/22 canceled due to IBIS Asia Summit)
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 25 Oct 2011
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
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
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:
- Mike: Europe DST change is this weekend, US Nov 6
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad prepare slides for today on corners
- Done
- Mike post Jitter BIRD
- Done
-------------
New Discussion:
Meeting schedule:
- Arpad showed a list of future meeting dates
- Some conflict with summits
- We will not meet Nov 15 and 22, Dec 27
Arpad showed Notes on Corners in IBIS (BIRD 140):
- Slide 2:
- IBIS 1.1 note on data derivation of corners
- Arpad: It was felt that min/max could be scaled from typical
- Slide 3:
- IBIS 2.1 relaxed the rules
- Slide 4:
- Page 174 requires min and max values "for all remaining keywords"
- Examine which keywords fall after that statement
- Arpad: We can't go by that strictly
- Recent spec changes may not have observed it
- Slide 5:
- Arpad: C_Comp is independent even where correlation is known
- Defines "conservative approach" as max=slow, min=fast
- Slide 6:
- Arpad: More ringing could slow down effective performance
- We avoided defining it for that reason
- Slide 7:
- Arpad: Does IBIS min = AMI slow and IBIS max = AMI fast?
- C_comp is not the only questionable parameter
- Slide 8:
- BIRD 133 [C Comp Corner]
- Walter's proposal: let EDA tool decide until BIRD 133 approved
- Use new keyword after that
- Kumar: Does AMI Corner format define this?
- Walter: It is typ/slow/fast, not typ/min/max
- Bob: There are no GT/LT requirements
- Problems:
- [C Comp Corner] is optional
- What does tool do if absent?
- There are other independent parameters
- Slide 9:
- Other independent keywords:
- [Diff Pin] tdelay_***
- [Rgnd], [Rpower], [Rac], [Cac]
- [* Series]
- [External Model], [External Circuit]
- Slide 10:
- Arpad proposes extending IBIS to 5 corners, adding slow and fast
- Slide 11:
- When slow not present max is used for slow
- When fast not present min is used for fast
- Slide 12:
- Why have a default that is opposite of the intuitive approach?
- Slide 13:
- We may need 6 corners because AMI_typ may not equal IBIS_typ
- Slide 14:
- Summary
- David: On slide 5 it is fundamental that the tool makes the choice
- IBIS is a datasheet, not a model
- We are getting away from our roots
- Walter: People generally have a good idea of slow and fast
- David: We know that min is faster for C_comp
- Walter: Sometimes C_comp is larger for the fast corner
- Walter: Disagree on using min for slow and max for fast
- Model makers should document what they are doing
- David: This would have us using reverse order of current practice for C_comp
- Bob: IBISCHK will warn for min > max
- David: On slide 11 is say min is fast corner
- Walter: People want more than three corners
- We should do this in a general way
- Arpad: Simulators can't just do what they do now because the spec is not clear
- Walter: In 5.1 they can use [C Comp Corner]
- Kumar: Min/typ/max is a numerical concept
- It doesn't map to typ/slow/fast
- With 5 corners do I simulate all 5 or just three?
- David: Complexity creates more work
- Walter: In 5.1 there should at least be a comment
- Should this be done so the program can read it?
- Kumar: A comment is not a major, fundamental change
- Walter: We should solve the fundamental C_comp problem with BIRD 133
- Radek: We should consider a long term solution
- This needs to address all parameters, not just C_comp
- Extending BIRD 133 to other parameters would require more keywords
- In Arpad's proposal 4th and 5th columns would only be needed for C_comp
- Comments are welcome but users might not see them in large IBIS files
- Arpad: We could use 5 columns for C_comp for now
- The overwriting mechanism is confusing
- Bob: I oppose adding the 2 more corners
- Tools would have to handle it forever
- Kumar: A new keyword could document the C_comp mapping
- Arpad: What about the other problem parameters?
- Bob: Params like [R Series] not derived from silicon are a problem
- We will not solve those with new keywords
- Walter: Associating ISS subckts with typ/slow/fast would be better
- We should vote to use either Bob's approach or Arpad's
- Bob: I'm prepared to move forward on the C_comp BIRD
- Arpad: What does AMI Corner align with?
- Walter: It aligns with data derivation
- Arpad: C_comp is still needed for AMI models
- Walter: [C Comp Corner] fixes that
-------------
Minutes by Mike LaBonte
Next meeting: 01 Nov 2011 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 18 Oct 2011
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
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
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:
- Arpad: We had agreed on a different time slot
- David 10:00 PT
- Arpad: Fangyi was unable to make it at that time
- Fangyi: 9:00 is not good once per month
- David: 9:00 is bad for me
- Bob: We should not change until we have a good time slot
- Arpad: We will make no change until further proposals
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad: Add rule #9 to BIRD 127.3 draft
- Done
- Arpad: Add to Getwave call size rule
- Done
- Ken: Submit backchannel BIRD to Open Forum
- Kumar: I will check with him
- Walter: Send latest jitter BIRD to Mike L. for posting
- In process, expected next week
-------------
New Discussion:
Arpad showed a side-by-side comparison of BIRD 127.2 vs. 127.3:
- Arpad described the changes
- Bob: There is conflicting terminology "leaf/value pair"
- Leaf is already defined to include the value
- Arpad: Can the editorial group address this?
- Bob: That would be OK
- Kumar: Are we clear on what a parameter is?
- Bob read the definition
- Bob motioned to approve the draft for submission
- Curtis seconded
- VOTE: No objection, the motion passed by acclamation
Arpad showed a side-by-side comparison of sampling rate BIRD version 4 vs 5
- Arpad described the changes
- Fangyi: What does analog to digital conversion mean here?
- Kumar: Internally the model has to do conversions
- An incoming waveform should be treated as continuous
- Fangyi: Can Init() and Getwave() exit with a failure return?
- Walter: Getwave can, for example with regard to block size
- Fangyi: Which function returns the code?
- Arpad: Any of them can
- Kumar: For this 0 is failure and 1 is success
- Arpad: The opposite is more common, to include failure codes
- David: Modern languages are getting away from that
- Curtis: We should change "must be able to produce valid results"
- Walter: Or add "to be compliant"
- Ambrish: Can wave_size be different from call to call?
- Arpad: It can
- Kumar: The software should accept any block size
- Arpad: We should not have to say it, but we could anyway
- Ambrish suggested language to add
- Walter: I am researching this issue
- Curtis motioned to approve this BIRD for submission with changes
- Ambrish seconded
- VOTE: No objection, the motion passed by acclamation
Arpad showed his BIRD on corners:
- Walter: AMI in IBIS 5.0 clearly correlates to derivation method corners
- Original IBIS does not
- C_comp has been a thorn in our sides for years
- Bob's proposal for C_comp_corner would resolve that
- Arpad: We should map slow to min and fast to max if they don't use it
- Walter: Simulators would have to de-embed C_comp
- Usually tools use min C_comp for fast, etc.
- Arpad: C_comp could be an exception
- Walter: C_comp_corner should be in IBIS 5.1
- Arpad: My proposal would be to document what should be done today
- Bob: I agree with Walter
- This is an existing problem
- Walter: I don't know anyone supporting 5 value C_comp
- Agree: It is the same as Bob's proposal with different syntax
Walter motioned to vote on Bob's BIRD or Arpad's BIRD
- Arpad: I do not have a BIRD yet
-------------
Minutes by Mike LaBonte
Next meeting: 25 Oct 2011 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 04 Oct 2011
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
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
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:
- Mike noted that he is now affiliated with SiSoft
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad ask Radek to propose a methodology
- Done
-------------
New Discussion:
Arpad: BIRD 140.1 is on the ATM website
Backchannel BIRD:
- Ken was not present
Arpad: BIRD 127.2 was brought back to this committee
- Radek: There are just a few issues
- The Usage language needs to be more neutral.
- Arpad: It says "optionally" but it is not optional if it
is a Reserved parameter.
- Bob: Does this shut the door for Model_specific params?
- Radek: It just doesn't matter if they are reserved params
- Bob: Tap params are already reserved
- Bob moved to accept the change made today
- Curtis seconded
- The motion passed by acclamation
Arpad scrolled to the pg. 141 changes to the Rx_Clock_PDF example
- Radek: The param is float but the Table contains string labels
- Bob: We made an exception for Labels
- This is allowed
- Walter: Type should be Integer, UI, Float
- David: Are Labels singular or plural?
- It doesn't seem to work singular
- Walter: In 5.0 it is plural
- Arpad: Any parser issues like this should be reported
- David: It is a tool issue
- Arpad scrolled to the Tx_Jitter section
- It says the first column of a Table is a string param name
AR: Arpad look for Table column type issues in BIRD 127.2
Arpad scrolled to the section on Default
- Radek: It needs to also have the exceptions used for AMI_parameters_out
AR: Arpad check on AMI_parameters_out exceptions and maybe send email
Arpad showed the "Clarify sample intervals in IBIS-AMI" BIRD proposal
- Arpad: The specification intends for any sample rate to be supported
- Enhanced description of impulse_matrix parameter to say more about
sample spacing
- David: Is it a single matrix, no aggressors?
- Arpad: That is a later change
Arpad: 3.1.2.4 would add more about sample_interval
- Radek: It is not precise to say "data rate" here
- David: We are not making a "must " constraint here
- Fangyi: Should it be a fraction of the bit time?
- David: It should not be any definite requirement
- Walter: It is a fraction of the bit_time
- Fangyi: Do we allow fractions like 64.7?
- Walter: Kumar said we should treat the waveform as continuous
- sample_interval should at least be a rational fraction of bit_time
- It is well understood how to convert time intervals
- Fangyi: The DLL will have to convert again on output
- What if a bit pattern is out of the device range?
- Walter: DLLs can have speed limit checking for bit rates the device
will not support
- Arpad added that the DLL can report an error for unsupported sample intervals
- Do we need to change lowest_bit_time?
- Walter: Yes it should be just bit_time
AR: Arpad update BIRD 127
BIRD 140:
- Arpad: This has been posted on the website for weeks
- The ** section about pg 141 is the trouble
- Bob: "In IBIS-AMI" should be "In IBIS"
- Format Corner is used and values are 0, 1, 2
- Arpad: This is looking ahead to dependency table
- The selector is actually hidden from the user
- Radek: That is confusing
- We use "corner" for different things
- Bob: It is making forward statements
- Arpad: I see no forward statements
- Bob: We have not yet defined Typ/Min/Max for Table yet
- Walter: This can be clarified in the Dependency BIRD
- No one is confused by this now
- Bob: Agree
- We can deleted it for this BIRD
- Arpad: We should leave it and pick it up for 5.2
- We can take it off the plate for 5.1
- Bob motioned to delete paragraph 2
- Fangyi: What are we trying to solve?
- Arpad: It says "align implicitly to slow and fast corners",
but doesn't define them
- Walter: Maybe it can say "align with IBIS corners"
- Radek: It is a future extension and should be deleted
- Arpad: For the use to select it should be a parameter
- We should not have two ways to do the same thing
- Radek: If we define it now it will have to be supported forever
- Fangyi: The issue is about how to select, not who selects
- Because of the C_comp issue we have to make it clear
what association must not be made
- The user should know how the data was generated
- Radek: When I need to run Slow I don't know what values to use
- Walter: The IBIS spec makes that clear, but uses different column names
- Fangyi: That is logically clear
- We need to separate that you end up with different individual values
- Radek: A strict association may not be right
- Arpad: I proposed another solution, with 5 values
- It allows users to forcibly select min or max in addition to slow and fast
- Fangyi: We do not define them well enough
- What is the meaning of "min"?
- Arpad explained the "C_comp problem"
- Fangyi: The user chooses a condition, and the model choose the settings
- Bob: The 5 choice proposal is a step backward
- The biggest problem is just C_comp
- Slow=max and fast=min works 90% of the time
- Walter: Should we remove the C_comp min < max restriction?
- Then the fast value could be put in for max, etc.
- Radek: That would make IBIS strictly slow and fast
- Arpad: There is a statement more or less to that effect
- Walter: We could get rid of Typ/Min/Max altogether in this section
- Arpad: IBIS defines corner names
- In [External Model] we have a definition of corners
- Fangyi: Does the spec define how model makers set the values?
- Arpad: It is in section 9
- It says params like C_comp do not correlate to I-V and V-T curves
- It is then unknown which values to use for fast or slow
- Fangyi: At least it is clear when we say we are not solving a problem
- It is confusing when we do not solve a problem and don't say it
- Can we explain the meaning in section 9?
- Arpad: The meanings are already described in section 9
- Fangyi: It doesn't say slow and fast
- Arpad: It says high/low voltage and strong/weak
- Fangyi: Why does Format Corner have 3 values in one place and 5 in another?
- Arpad: If it is only 3 slow and fast have to be decoded from min and max
- Walter: There would have to be a 6th "Typ" value
- The "Typ" corner might actually require the min value
- Arpad: Added a 3rd proposal with Typ/Min/Max_performance labels
-------------
Minutes by Mike LaBonte
Next meeting: 11 Oct 2011 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 01 Nov 2011
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
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
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:
- Arpad reviewed the upcoming meeting schedule
- No meeting Nov 15 & 22, Dec 27
- Mike: US DST time shift is Nov 6.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- None
-------------
New Discussion:
BIRD 140:
- Arpad showed version 2 of his "Corner Notes" presentation
- Slide 15:
- What Model_types can be AMI?
- This affects the min/max <> slow/fast mapping issue
- Many typ/min/max keywords are eliminated if Terminator not allowed
- Only [Diff Pin] and [External Model] would remain
- Slide 17:
- Mapping is stated for I-V V-T
- Sort of stated as "conservative approach" for C_comp
- Slide 18:
- Define which Model_types are allowed
- Mapping of min/max for Pin[Diff ] [External Model]
- Reiterate for I-V, V-T, C_comp
- BIRD 133 not needed
- Walter:
- Can assume fast = min for [External Model]
- Faster part should have less skew
-
- Arpad: A Terminator is the same as a receiver, but no thresholds
- With AMI we don't do those measurements
- Hard to see why Terminator is needed for MAI
- S-params would be better than these RLC keywords
- Walter: Several vendors use Terminator and [R Series]
- No objection if we restrict AMI to Input and Output types
- Arpad: Agree
- Bob: Series can be used as diff terminator
- Arpad: This is only because we have pseudo-diff models
- With IBIS-ISS we can have true differential
- Bob: We should not make these types illegal
- Radek: Agree, we should allow them
- Walter: We should not handle typ/min/max for them
- BIRD 120 would do it
- Arpad: We should warn about typ/min/max issues for these
- Bob: No spec statement that Rgnd min < max
- The parser warns though
- That message could be removed
- Radek: We should at least recommend not to use them
- Bob: It would be OK to not have Terminator because that is just a stub
- Radek: We can disallow if we feel strongly about it
- Arpad: There might be a gap between 5.1 and 5.2
- Without IBIS-ISS model makers might have no solution during the gap
- John: Only [Rac] and [Cac] pose a problem
- Bob: We only need a note that Terminator might not be supported in all tools
- Arpad: Can we add the warning text to BIRD 140?
- John: I would rather disallow Terminator and Series models
- Bob: Where does [Algorithmic Model] reside?
- Arpad: in [Model]
- Bob: [Algorithmic Model] does not make sense under Terminator
- Arpad: Actually there can be two models connected to a pin
- single plus series
- Bob: [Algorithmic Model] should be restricted from Series types
- Arpad: Can we exclude AMI from Series types?
- No objection
- Bob: There should be a new BIRD for that
- It does not belong on a corner BIRD
- Bob: [Diff Pin] tdelay* was for statistical use, tolerances
- Arpad: The jitter parameters are better
- Bob: The TT parameter is similar, it only shows how bad your part is
- Walter: Agree with Bob
- Arpad: Should this be addressed in later analog BIRDs?
- Walter and Radek agreed
- No objections
- Radek: It is a good suggestion to clarify for I-V, V-t, C_comp, etc.
- Maybe it should be for IBIS in general, not just AMI
- Arpad: I will rewrite BIRD 140
AR: Arpad rewrite BIRD 140 to disallow AMI Terminator, etc.
Walter showed the jitter BIRD 123.3
- Walter: Draft 2 fixes typos
- Added paragraphs to introduction
- Critical that people review in detail
- Walter read the paragraphs
- Bob: Is this BIRD text or explanation?
- It refers to the BIRD itself
- Walter: That may change in the final version
- Arpad: Will jitter show up in common mode?
- Walter: Getwave inputs are diff, do not account for channel common mode issues
- Skew on the TX would not be modeled correctly
- This is a non-trivial change to Getwave
- Skew under 20% is not an issue
- Don't know of any buffers that bad
- People are worrying about common mode diff coupling
- It is independent of the CDR
- Arpad: Will this be in the spec?
- Walter: The group can decide
- Arpad: This might be useful to explain the jitter parameters
- Bob: It would fit into the analysis section
- Arpad: We should check each jitter description against this
-------------
Minutes by Mike LaBonte
Next meeting: 08 Nov 2011 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
