Minutes from the 16 Aug 2016 ibis-atm meeting are attached. The following
document was shown in the meeting:
DATE
AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html>
TITLE <http://ibis.org/macromodel_wip/archive-title.html>
FORMATS
16-AUG-2016
Bob Miller
Broadcom
Lightweight Backchannel BIRD draft 5
(zip
<http://ibis.org/macromodel_wip/archive/20160816/bobmiller/Lightweight_Bac
kchannel_BIRD_draft_5.zip> )(docx
<http://ibis.org/macromodel_wip/archive/20160816/bobmiller/Lightweight%20B
ackchannel%20BIRD%20draft%205/LightweightBackChannelBIRD_rev5.docx> )
Mike
IBIS Macromodel Task Group
Meeting date: 16 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 lightweight back-channel proposal do discuss under item 6
-------------
Review of ARs:
- Ambrish to check for collaborators' feedback on his nearly ready new version
of the back-channel proposal.
- Done, presented today.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Dan: Motion to approve the minutes.
- Bob M.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Item 6, new Lightweight Back-channel BIRD:
- Ambrish: The authors of this new BIRD will be the same as for BIRD 147.
- Arpad: Should we have a BIRD 147 update first?
- Ambrish: This new BIRD is the update.
- Mike: Is this a new BIRD or an update to 147?
- It could be 147.1 if the history is retained.
- Bob: I would prefer a new BIRD.
- Arpad: That can be decided a little later.
Bob M showed the new BIRD draft.
- Bob M: This is about the way messages are passed.
- Requirement 1 keeps the EDA tool agnostic. File I/O is simpler than
parameter passing.
- We can have chains of DLLs and they can all have access to the files.
- Arpad: Can statistical analysis be done?
- Bob M: Walter and I have pushed for that but it got poor traction and we are
ready to abandon it.
- Arpad: I thought optimization would take place before simulation.
- Bob M: That requires a tremendous amount of EDA tool support.
- Ambrish: This BIRD does not call for training first then regular simulation.
- Bob M: We minimized the EDA tool support required.
- Bob M: Requirement 3 allows the EDA tool to improve the user experience,
but users can also just edit the AMI file and get the job done.
- Requirement 4: The user must know when training has ended.
- Reg 5: We want to support both private and published protocols.
- We do not define how protocols are defined.
- Requirement 6: We need to insure unique namespaces for file names.
- Some tools run every channel in the same directory.
- Bob M: There are 5 new Reserved_Parameters.
- The TX and RX have to understand the same BCI_Protocol to proceed.
- BCI_ID gives the namespace. It will be prepended to file names.
- Not comfortable with name BCI_GetWave_Bits yet.
- It's not like block_size, it's in UI.
- It is the only mechanism to control when messages are passed.
- The TX and RX do not run concurrently, so after the TX GetWave is
done it's messages are passed to the RX GetWave.
- Mike: Will it matter if the TX is not called before the RX?
- Bob M: If one model has no message to send it will just wait until the next
call.
- Walter: IBIS says the TX is called first.
- The call order needs to be Tx Init, RX Init, then the GetWave calls.
- There is a subtle point there about order.
- Bob M: BCI_Protocol can be a List, allowing "multi-lingual" models.
- The TX and RX must have same settings.
- GetWave_Exists must be True.
- Arpad: Why must GetWave_Exists be True?
- Can't this be done with Init?
- Walter: The EDA tool would have to change to do that.
- Only GetWave is called iteratively.
- Bob M: BCI_ID is a String similar to DLL_ID, but in this case it makes
message passing files unique.
- Others have asked if the string could have a path prepended,
we need to talk about that.
- The TX and RX must receive the same BCI_ID.
- There could be any number of files used.
- Ambrish: We might provide an example for this in the BIRD.
- Bob M: And it should allow a path.
- Arpad: Will this work in a crosstalk simulation?
- Bob M: The aggressors need to have different BCI_IDs.
- Walter: The victim needs a different BCI_ID too.
- Bob M: The EDA tool could help here, or users will do a lot of editing.
- Mike: Users would have to clone models and edit?
- Walter: BCI_ID could be a List and set by the user for each buffer.
- Bob M: BCI_State has five states.
- Off means there is no back-channel at all.
- Training means it's in training mode.
- Converged means training is done, successfully.
- Failed means training is done but found no optimum settings.
- Error means a DLL in the channel got some bad parameter.
- Any DLL can send error.
- Arpad: What is the difference between failed and error?
- Ambrish: Failed would mean an inability to find the right tap settings.
- Bob M: The downstream RX is the one that knows what's going on. It's
the one that knows when training is done.
- Bob M: BCI_GetWave_Bits might instead be called BCI_GetWave_Block_UI.
- Arpad: Isn't this redundant with block_size?
- Bob M: This overrides what the tool would set for block_size.
- Mike: For example an extremely large block size might cause training changes
to
be missed.
- Arpad: The tool usually sets it, so this allows the model maker to tell the
tool
what to use.
- The block_size could even be different across GetWave calls.
- What happens if the samples do not end on a bit?
- Walter: The RX needs to be polled at reasonable times.
- The exact number of samples is not that important.
- Arpad: Why not call it Bits instead of UI?
- Bob M: With PAM4 the term "bits" became ambiguous, so UI is better.
- Bob M: BCI_Training_Bits lets the EDA tool know when training should be done.
- Mike: Maybe this should be called BCI_Training_UI.
- Arpad: Are these sent between each GetWave call?
- Bob M: Each GetWave call is in training mode until we get the message.
- Ambrish: It might be in training mode for the entire simulation.
- Arpad: Can training be restarted?
- Bob M: The EDA tool would have to be able to send in a command.
- Bob M: The flow is described in the BIRD, that should be helpful.
Arpad: What are the next steps?
- Bob M: This could be sent to ATM for further discussion.
- Arpad: Will it be submitted to get a BIRD number?
- Bob R: We should keep it in ATM as a draft for now.
AR: Arpad forward BCI BIRD draft to Mike for posting.
IBIS Interconnect SPICE Wish List:
1) Simulator directives
