[ibis-macro] Minutes from the 06 May 2014 ibis-atm meeting

  • From: Mike LaBonte <mike@xxxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Wed, 07 May 2014 15:09:55 -0400

Minutes from the 06 May 2014 ibis-atm meeting are attached. Thanks to
Curtis Clark for taking minutes.

Mike
IBIS Macromodel Task Group

Meeting date: 06 May 2014

Members (asterisk for those attending):
Agilent:                      Fangyi Rao
                            * Radek Biernacki
Altera:                       David Banas
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                 * Xingdong Dai
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                            * Kumar Keshavan
                              Ken Willis
Ericsson:                     Anders Ekholm
Intel:                        Michael Mirmak
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
Teraspeed Consulting Group:   Scott McMorrow
                            * Bob Ross

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad
  - What should we do about next week's meeting?
  - Will many participants be at the European IBIS Summit?
- Bob
  - As far as I know, Randy Wolff is the only one from our group who will be
    traveling to the Summit.
- Arpad
  - Okay, we will not cancel next week's meeting.

--------------------------
Call for patent disclosure:

- None

-------------
Review of ARs:

- None

-------------
New Discussion:

BIRD 147 Back-channel:

- Arpad - Ambrish, are you prepared to continue the back-channel discussion.
- Ambrish - yes [sharing BCI presentation]
  - BCI Basics
  - Link to BCI from AMI
  - BCI Examples (published or private protocols)
  - BCI Communications
  - Advantages of BCI

  - BCI Basics
    - Used by Tx, Rx and EDA tool
    - .bci file discussed for each new protocol
    - published after review
    - .bci file contains what needs to be supported

  - Link to BCI from AMI
    - Two Top Level Reserved AMI parameters
      - Training - tells EDA tool what type of backchannel sim is supported.
      - Backchannel_Protocol - list protocols supported by this model.
    - Keeps params in .bci, with just two top level params in .ami

  - What's in BCI?
    - Training Pattern/Sequence
      - typically data sequence with set preamble and postamble.
    - Training length/max bits
    - Declaration of minimum number of Tx taps that Rx must accommodate.

- Todd - The pattern for pre and postamble is in the .bci.  Who uses it?
- Ambrish - The EDA tool reads the .bci and generates the bit pattern.
- Kumar - Reserved .bci params are for the EDA tool.  These two are reserved.
- Todd - I'm asking because...
  - Argument for having .bci separate is that it's independent of the .ami file.
  - But this is a dependency on the tool.
- Walter - This is a nice presentation.
  - What's in the reserved section is what the EDA tool needs to know about.
  - What's in the model specific part of .bci is what Kumar has been referring
    to as the "black box."  It's the way the Rx and Tx communicate with each
    other without the EDA tool having to know.
- Ambrish - [continuing presentation]
  - BCI Examples
    - 802.3KR BCI file
      - Reserved_Parameters here refer to BCI only.
      - Protocol_Specific params analogous to Model_Specific in .ami files.
        - Independent of EDA tool.  Models understand these.
    - PCIe3 BCI File
    - 12GBps SAS-3 BCI File example
      - Extracted relevant tables from the spec for this slide.
      - We haven't talked about SAS in general.  They do require backchannel.
      - Similar training to 10G KR (increment, decrement tap coeffs).
    - Other protocols [referred to DesignCon 2012 paper]
  - Private BCI file
    - Company A may make a proprietary one.
    - Need only send the .bci to company B.
    - All other info is contained in the IBIS spec.
    - EDA tool would not need to do anything different.
    - Example - one with just two pre taps. 
  - When will BCI file originate?
    - Three published with the BIRD.
    - Future work could go from there.
    - New protocols could be added, independent of AMI spec changes.
    - Hard work is to scour the protocol to find the relevant training info.
- Dai - Would .bci files be part of the spec?
  - One of my concerns is whether .bci defined earlier is general enough.
  - Preamble, postamble often handled by link layer.
  - We often only want a random bit sequence (similar to PCIe example).
  - If we want to build a model to support training then we would need to
    build link layer support into the model?
- Ambrish - Reserved_Parameters have training information.
  - Those are available in the BIRD.
  - You could define what you want there.
- Dai - Here we use PRBS23 most often.
  - Here the Tx continues sending the random bit pattern.
  - Receiver just adapts to it and sends back info every 4k.
  - When you have preamble and postamble then bit pattern at Rx includes them?
- Ambrish - Yes, it's the EDA tool's job to generate the bit pattern.
  - Rx may choose to respond every block or wait every 10k to decide.
    - It's up to the models to decide.
- Kumar - Usually less than 10 percent of the bits are pre and postamble.
  - Robust Rx probably won't be bothered by it too much.
  - One could create an Rx device that is not pattern dependent.
- Dai - Agreed.

- Ambrish [continuing presentation]
  - How is info extracted?
  - EDA Tool looks at .bci file and generates training pattern.
    - It notes the max training bits and limits the communication at that point.
    - It operates in Init() or GetWave() mode as specified.
  - AMI model
    - Tx Looks at Protocol_Specific part of .bci and generates the parameters
      string used to communicate.
- Todd - What is this string telling me?
- Ambrish - It's telling you [in this example] we have 3 taps.
  - Sent to the Rx, which parses it and realizes there are 3 taps.
    - 0s indicate taps open to be changed.
  - Rx gets back to Tx and says up or down so many increments for each tap.
  - Tx sends this to Rx, details in BIRD describe what 0, +1, -1 mean.
- Walter - You're now into the "black box."
  - So this +1, -1, etc. has nothing to do with the IBIS standard.
  - It is protocol specific.
- Ambrish - Actually, the communication is described in the spec.
- Walter - We need to be clear.
  - IBIS spec says there is BCI root and all this "black box" the Rx generates,
    and all the EDA tool does is send this to the Tx and vice-versa.
  - In the BIRD itself there should be nothing about the contents of the string.
  - In the protocol is the description of the string.
    - It is read and interpreted by the Tx and Rx without the EDA tool, correct?
- Ambrish - Partially.
  - String here is a black box, yes.
  - To simplify matters we have also described the communication between Tx and 
Rx.
- Walter - When you say "communication," that's the string, which is a black 
box.
  - EDA tool doesn't interpret the contents.
- Ambrish - Right.
  - But the Tx will have to formulate the string based on what is provided.
- Walter - That's based on the protocol.
- Ambrish - No, we've picked increment-decrement as one of the ways to 
communicate.
- Walter - So it's not a black box?
- Ambrish - No, parameters can be added to the string.  That's the black box.
  - But the back and forth communication types are defined by the spec.
- Walter - So you have increment, decrement, tap coefficientÉ
  - What about tap index?
  - I don't understand why BIRD 147 is involved in the black box.
- Ambrish - To make the communication simpler.
  - This is where the Tx may send the Range available over to the Rx.
- Kumar - Walter is saying he wants to make it very clear.
  - Even the increment and decrement should be in the .bci file.
  - That does provide a crystal clear indication that all the communication 
stuff
    is in the .bci file.
- Ambrish
  - The entire reason we added it to the BIRD is to make it simpler for the Tx
    and Rx to understand the communication.
- Kumar - It can be put in the .bci file to make it clear.
- Todd - Walter's question, as I heard it, is...
  - Is the simulator expected to look into the BCI messages or not?
- Kumar - It only looks in them for "Training_Done".
- Ambrish - That is a reserved parameter the EDA tool detects.
- Kumar - That's why it's in the reserved section.
- Walter - But Training_Done is a reserved parameter.
  - EDA tool does look at reserved, but not protocol specific.
  - Only EDA tool responsibility for that is to move it back and forth.
- Todd - I think we're mixing things up.
  - On the one hand .bci files, on the other hand these strings from the BCI
    branch flying around the simulator.
  - Does the EDA tool look into that BCI branch of the string or not?
- Kumar - Yes it looks for Training_Done.
  - Simulator can also push that Training_Done into the message string.
- Todd - Now the simulator is responsible for monitoring messages.
  - Simulator looks for Training_Done and then shifts the stimulus into the
    Tx into post-amble mode and then goes back to normal operation?
- Walter
  - Wouldn't it make sense if training is just a normal reserved parameter of
    the .ami file?
  - Normal for the EDA tool to parse and handle it.
  - It becomes a directive from the Rx to the tool to do something.
  - Then you make the BCI root something the tool really doesn't have to look 
at.
- Kumar - Only issue is that parameter is a static one.
  - Rx may be able to cut if off half way through a block.
- Walter - Agreed, it has to be an input/output.
  - EDA tool can tell Rx or be told by Rx that training is done.
- Walter - Make Training_Done a normal reserved param of the .ami file.
  - Then it's where the tool already has to parse.
- Kumar
  - Okay, in that scenario the EDA tool never has to parse anything from the 
BCI.
  - That sounds okay to me.
- Walter - Then one doesn't have to describe the contents of that .bci file.
  - Protocol decides what it is, and all we have to do is have (BC ...)
- Ambrish - When you say protocol you mean we're defining the .bci file?
- Walter - When you're defining the protocol portion of the .bci file.
  - Training_Done can be moved to .ami.
  - All the others are info that describe the training file.
  - Phy layer not responsible for pre and postamble.  Link layer does that.
  - Most Phy layer models happy with just PRBSn
  - All you really need here are PRBS for the Rx and max training bits.
  - Protocol_Specific section is a black box to the tool
    - Contents of it have to be defined according to the standard.
- Ambrish - We don't expect a standards group to make the .bci file.
- Walter - Who approves the .bci communication info?
- Ambrish - We believe the IBIS group consists of everyone who needs this.
  - We would specify the black box protocol specific portions.
- Kumar - Walter, these are good suggestions.
  - We will think about that, it is good input.
- Ambrish - Yes, but we need to define what's in the Protocol_Specific section.
- Walter - We, in BIRD 147, do not need to do that.
  - The protocols, which are separate docs with a separate approval process
    will define that.
- Ambrish - Yes, but the person making the model uses what?
- Kumar - Protocols are done in hardware.
  -  We are doing the software version, so we need the .bci file.
- Walter - The .bci file may be the way to define that communication.
  - But there's no reason for the EDA tool to know anything about that protocol
    syntax in the .bci file, or whatever communication string the protocol
    chooses.
- Radek - This is an excellent discussion.
  - It comes back to something we've discussed a few times.
  - A new API would be useful.
  - Basically have a BCI_GetWave() like we have AMI_GetWave().
  - BCI_GetWave() stuff goes back and forth without the tool looking at it.
  - Why do we use AMI_GetWave() at all?
- Ambrish - We are essentially making another GetWave().
- Radek - That's fine, but we could have two paths.
  - EDA tool would know which to do and not do.
  - Now the requirement is you still have to parse the BCI communication.
  - In addition to Training_Done...
- Walter - One string goes in and out of Rx GetWave().
  - It has two roots.  One is the .ami file parameters.
  - Then there's another (BCI ... ) root section.
  - We could have chosen to have an AMI parameter call "communication string."
    - A reserved parameter in the .ami file could have been another method.
  - Another way is to make assumptions, as all the standards do, about the types
    of communication:  tap indices, tap coefficients, etc.
    - Just say there is a standard way of defining taps.
- Ambrish - Tx may need to advertise ranges to the Rx model.
- Walter
  - We need to defer that discussion until I can describe the scenario in more
    detail.
- Ambrish [continuing presentation]
  - Advantages of BCI file
    - Multiple protocols
    - Prevents having to add reserved parameters.

- Arpad - Our time is up.
  - Thanks Ambrish.
  - Walter, will you be ready to present next week.
- Walter - Yes.
- Arpad 
  - Any last minute questions? [none]
  - Thanks for joining everybody.

AR: Ambrish to send presentation to Mike to be posted.
-------------
Next meeting: 13 May 2014 12:00pm PT

-------------
IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 06 May 2014 ibis-atm meeting - Mike LaBonte