Minutes from the Aug 30 and Sep 6 ibis-atm meetings are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 06 September 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
Curtis Clark
Broadcom (Avago): Xingdong Dai
* Bob Miller
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM * Luis Armenta
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
Radek Biernacki
* Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Walter said Michael M had emailed back-channel questions.
- Arpad: Ambrish and Curtis emailed that they could not attend.
-------------
Review of ARs:
- Walter submit [Pin Mapping] BIRD to Open Forum.
- Done.
- Bob Miller submit Backchannel BIRD to Open Forum.
- Done.
-------------------------
No patents were declared.
-------------------------
Review of Meeting Minutes:
- No Aug 30 minutes yet.
-------------
New Discussion:
Michael M email about back-channel communication:
- Michael M: Colleagues had concerns about using files for communication.
- Are I/O restrictions needed?
- Bob Miller pointed out that it is not a live simulation, that the models
are called at separate times.
- Walter: That is correct.
- Synchronization might be every 1000 UI, for example.
- Bob M: Block size could theoretically be 1 UI but that would be silly.
- Michael M: With a large block size some events might be missed.
- Arpad: EDA tools determine block size.
- There is no restriction that it must remain the same.
- What if the block size changes from call to call?
- Walter: We will be requiring only a minimum.
- The exact number should not be critical.
- Arpad: Can this change after initialization?
- Walter: Maybe the suggested block size should apply only during training.
- Bob M: This is used for latency during message passing.
- The EDA tool could choose a smaller block size for memory reasons, for
example.
- Walter: The model might not send messages every block.
- Arpad: We should clarify that it is only for the training period.
- Bob M: We could do that.
- The overhead of a GetWave call is small.
- Mike L: File caching can be a problem, particularly with Windows.
- Has this approach been tried?
- Bob M: Some testing has been done.
- Walter: Caching should be a problem only for separate processes.
- Arpad: We should not count on the TX and RX being in the same process though.
- Mike L: The BIRD appears not to preclude using sockets.
- Walter: This is much like the original BIRD 147.
IBIS 6.2 BIRDs:
- Walter showed an updated IBIS 6.2 BIRDs spreadsheet.
- Bob: BIRD A is not BIRD 184, D is 184.
- Walter: BIRDs F, G, and I all have to do with pin reference.
- The question is what to do when the component has no reference pin.
- Bob and Radek are working this out.
- Bob: We have not connected to discuss that yet.
- Walter: There are two worlds:
- One in which everything is floating.
- One which is ground based.
- Arpad: A number of BIRDs were untabled in the previous Open Forum meeting.
- It is not clear if we should discuss them here.
- Walter: BIRD 128 was untabled because BIRD 147.1 doesn't need it.
- BIRD 180 relates to BIRDs 125, 163, and 164. Maybe BIRD 165 too.
- It says there are no joins or splits between pins and models.
- You can't have the same pin twice.
- The parser flags these as errors.
- BIRD 180 makes that illegal.
- It's not clear how an EDA tool should handle such a case.
- Arpad would prefer to avoid voting on BIRD 180 until BIRD 125 is voted down,
but that is waiting for the new Interconnect BIRD.
- The Interconnect BIRD is inconsistent with BIRDs 125, 163, and 164.
- Those should be voted down sooner rather than later.
- Arpad: The question is if we discuss them here.
- Mike L: It would be good to have them on this agenda.
- Walter: It helps for IBIS to be consistent with the parser.
- Arpad: We could put BIRD 180 on this agenda.
- Bob R moved to put BIRD 180 on the agenda.
- I would not change the parser to handle multiple pins.
- Mike L seconded.
- Without objection the motion passed.
- Walter moved to remove BIRD 147.1 from the tabled BIRDs list.
- This was to delete, not to untable.
- Bob R seconded.
- Without objection the motion passed.
- Bob R: Is the New Redriver Flow BIRD an update to the Redriver flow BIRD?
- Walter: There is no BIRD yet, just a PowerPoint.
- It overlaps with BIRD 166.
- It adds multiple Impulse Response inputs and outputs.
- They could be combined into one BIRD.
- Bob R: A draft BIRD was sent last October.
- Walter: I have not seen it posted.
- Michael M: There should be no interaction between BIRDs 147.1, 166, and this
new BIRD.
- Walter: There will be none.
- Walter: Motion to adjourn.
- Bob R: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 13 September 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 30 August 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
Curtis Clark
Broadcom (Avago): Xingdong Dai
* Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM * Luis Armenta
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
* Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Arpad: We have a new agenda item 7 for IBIS 6.2 BIRDs
-------------
Review of ARs:
- Walter send [Pin Mapping] change proposal to Mike for posting.
- Done.
- Bob Miller submit Back-channel BIRD to Open Forum
- Done, but there is a numbering issue.
-------------------------
No patents were declared.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
New Lightweight Backchannel Proposal:
- Bob: The word DLL is used throughout, but it should be "executable model",
except for the "DLL_Id" parameter.
- Bob M.: I'm OK with that change.
- Arpad: Should the BIRD be rewritten?
- Bob R.: That would be best.
- It should be a new BIRD too, not an update to 147.
- Part of this should be a in a new IBIS section 10.9, not in 10.8.
- Bob M showed the BIRD.
- Arpad: We decided last week that discussion on this was finished.
- Bob R: The only stated protocol is "basic".
- Should there be definitions for Fibre Channel, etc.?
- Bob M: Basic describes a hypothetical protocol.
- Walter: Basic is a placeholder, we should not imply that it exists.
- Bob R: I want to send change suggestions to Bob M.
- Radek: We should discuss how protocols will be established.
- How will we avoid name conflicts?
- Arpad: BCI_ID might help make it unique.
- Bob M: Two vendors might use the same name for different protocols.
- Walter: An approval process is implied.
- The Open Forum can handle that.
- We need just a name registry.
- Radek: It should be in the BIRD explicitly that private protocols are
prohibited.
- Or they might start with underscores, for example.
- We need to establish IBIS approved protocols.
- Walter: That could be in this BIRD or separate from it.
- Radek: I would prefer it in the BIRD.
- Bob M: We can highlight this in the notes.
- Standard protocols might always begin with "IBIS".
- Bob R: Private protocols might start with a company name.
- Bob M: We don't know who will do this outside of IBIS.
- Arpad: Could other organizations approve protocols?
- Bob M: Any company could publish their protocol.
- Ambrish: PCI-SIG might want to create a new name but IBIS would own it.
- Bob M: A protocol could be private or published?
- This condenses three options to two.
- Radek: We should at least set a naming convention.
- Bob R: Prepend with IBIS for official protocols.
- If PCI-SIG copyrights PCI-Gen4 we can't publish it.
- Walter: We should hope to have that problem a year from now.
- The IBIS prefix should be all we need for now.
- Arpad: How do we prevent someone from using a protocol name before approval.
- Ambrish: We have had this discussion before.
- Arpad: Do we discuss this next week?
- Walter moved to table the issue.
- Bob R seconded.
- There were no objections.
[Pin Mapping] modifications proposal:
- Walter: I'm ready to submit this to the Open Forum.
- Walter showed the BIRD.
- Bob: I favor submitting this.
- Arpad: Time check, are there other IBIS 6.2 BIRDs to discuss here?
- Mike: Some 6.2 BIRDs are editorial, some are submitted.
- Walter described changes to the Pin Mapping BIRD.
- Arpad: Has this been submitted?
- Mike: Usually we have a motion to send to Open Forum.
- Walter: We usually recommend whether to approve.
- Arpad: That is for submitted BIRDs that come back here.
- Walter: I will submit it.
Model_name and Signal_name Restriction for POWER and GND Pins BIRD draft:
- Bob R showed draft 3 of the BIRD.
- Bob R described the changes.
- Arpad: If the third column has POWER for two pins and the signals are VCC3
and VCC4, does the tool short them together?
- Bob R: No.
- I plan to submit this.
- It also has a few editorial changes.
- Arpad: Do CIRCUITCALL and NC fall in this category?
- Mike: CIRCUITCALL connectivity is established externally.
- Walter: I originally suggested same signal name must have same model name.
- If two pins are signal A but have different model names should that be
allowed?
- We certainly don't want POWER and GND mixed up
- Radek: It is OK to limit this to POWER and GND.
- Bob R: It would be a violation for pins with the same signal to use POWER and
NC model names.
- Walter: If four pins use POWER, GND, CIRCUITCALL, and NC some are in
violation,
but others aren't.
- Arpad: We have POWER and GND model names, not pin names.
- Bob R: For pins with same signal name all should have the same model name.
- Bob R showed [Model Data] Matrix Sub-parameter Terminology Correction BIRD
draft 1:
- Bob R described the changes.
- Michael M and Radek agreed with the changes.
- Bob will submit the BIRD to the Open Forum.
- Walter: Motion to adjourn.
- Michael M: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 06 September 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives