Minutes from the 21 Apr 2014 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 21 April 2015
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Avago (LSI) Xingdong Dai
* Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC * David Banas
Ericsson: Anders Ekholm
IBM Steve Parker
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
* Nicholas Tzou
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: * John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp. James Zhou
Andy Joy
eASIC Marc Kowalski
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
(Note: Agilent has changed to Keysight)
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad, Randy and Radek prepare BIRD 175 draft ready for Open Forum.
- Still discussing details.
- Walter find all places in IBIS specification affected by PAM4 BIRD.
- Done and distributed.
- Michael M update AMI Directionality BIRD
- No update
- Arpad to review IBIS specification for min max issues.
- In progress.
-------------
New Discussion:
Bob Miller introduction:
- Design engineer and IBIS-AMI modeler at Avago.
BIRD 175:
- Arpad: An update was supposed to go out Thursday but we are still working on
it.
- The deadline has been missed for a May 1 Open Forum vote.
- It will be discussed next Tuesday.
PAM4 BIRD:
- Walter showed the BIRD draft.
- Walter: All known updates have been made.
- This is waiting for review comments.
- The next IBIS will have to support PAM4 as well as NRZ.
- Many places in IBIS talk about zero crossings.
- This is really about transitions.
- Bit time is really symbol time.
- It would help for others to check this work.
- Bob R: "Rest of IBIS" means "rest of IBIS-AMI"?
- Walter: The key changes are in AMI.
- Arpad: Legacy models will not support PAM4.
- Walter: PAM4 still assumes an analog model from legacy curves.
- It can only go from symbol 0 to symbol 3, without EQ.
- Arpad: Then no changes are needed outside of IBIS-AMI.
- Walter: Agree.
- An introductory paragraph should appear somewhere.
Back-channel BIRD:
- Walter showed two draft BIRDs.
- Arpad: Was this supposed to be a modification of BIRD 147?
- Walter: That was not my intention.
- Ambrish: At DesignCon we agreed to look at BIRD 147 again.
- Walter: The change to BIRD 147 as structured would be massive.
- The BIRD on the left defines AMI parameters for back-channel.
- The BIRD on the right describes a BCI protocol for TX-RX communication.
- Ambrish: Why are they not one BIRD?
- Walter: The management should be agnostic to the protocol.
- I'm defining a "basic" protocol.
- The BIRD on the left must be approved first.
- The basic protocol is a superset of BIRD 147.
- It does not prohibit other protocols.
- The EDA tool does not need to understand the messages.
- Radek: The word "not" is missing.
- Walter corrected a sentence.
- Walter: Models can use a private protocol.
- Public protocols can use the BIRD process.
- Nicholas: This will support models from different vendors?
- Walter: Yes, they just need to support the same protocol name.
- Public protocols should be well supported.
- Two vendors could support a private protocol.
- The EDA tools would handle it because they don't care what is being passed.
- Backchannel_Protocol gives the protocol name.
- BCI_State has fixed allowable values.
- BCI_GetWave_Block_Size lets the RX set a block size requirement.
- Mike: Isn't block size in samples?
- Walter: Yes but it should be given in UI quantities.
- BCI_GetWave_Training says if time domain training is supported.
- BCI_Init_After_GetWave says if Init should be trained after GetWave is done.
- An informative table is included to describe allowed combinations.
- Training flows are shown in diagrams.
- Radek had suggested we do need a new function for a second Init call.
- Radek: I did suggest a separate function.
- Walter: We can go either way on that.
- Arpad: The SiSoft logo should not go in the IBIS specification.
- Walter: We need to decide if we want the graphics at all.
- The EDA tool call sequence is listed in text too.
- This is informative, other variations are possible.
- There is a note about number of bits which need not be known in advance.
- The RX will terminate when done.
- Ignore_Bits should be replaced with waiting until training is done.
- Only the PRBS7 pattern is called for by every known standard.
- If a protocol name ends in .bci that means there is a .bci file.
- There is no need for the EDA tool to read that.
- Bob R: If that is standardized does that mean the .bci file is standardized?
- The parser would have to check it for compliance.
- Walter: That would be up to the protocol being incorporated into IBIS.
- RX eye quality metrics should be output.
- Silicon programming tools should be provided, as a best practice.
- An 802.3KR example AMI file is provided.
- Ambrish: What is a .ibc file?
- Walter: That should be .bci.
- Ambrish: How does a model prepare for what it will receive from other models?
- Walter: A standard protocol must be written.
- My "basic" protocol would be one.
- Bob M: The extra AMI_Impulse function will be needed.
- Otherwise neither TX nor RX has saved any history.
- Ambrish: Models w=know when they are in BC mode.
- Bob M: AMI_Init will start from scratch each time.
- Walter: I had proposed that when the allocated memory handle is passed back
in it does not start fresh.
- It doesn't matter much which way we go.
- Walter switched to the basic protocol document.
- Walter: This describes a Back-Channel Protocol called "basic".
- BCP here could stand for Black Capped Pigeon, a "messenger" BIRD.
- The TX would output a description of itself.
- Bob R: So BCI is a reserved branch name. It can be repeated several times?
- Walter: No there can be only one.
- Bob R: It is in the AMI file?
- Walter: No it is only in the DLL parameter string in our BNF format.
- Ambrish: The TX would be restricted to just tap parameters?
- Walter: The TX describes whatever parameters it will allow changes to.
- The example that looks like AMI file format is just for documentation.
- Neither the tool nor model reads that.
- Bob R: It sends a sequence of values?
- Walter: Each bottom level parameter has only one value here.
- The RX will create a string with an instruction in it.
- The instructions use one of several methods such as "increment" and
"decrement".
- The TX needs to support each method.
- Nicholas: How would a third party optimizer work?
- Walter: That is not in this document.
- Nothing prevents the EDA tool from updating tap coefficients.
- The command does not have to come from the RX.
- Only published protocols could be supported by tools.
- Bob M: If the EDA tool is agnostic do the TX and RX communicate by file I/O?
- Walter: The EDA tool finds the BCI branch and copies it.
- Radek: This is a good argument for the special API function.
- That is a good way to do it.
- Walter: I can change the BIRD if we decide that.
- Ambrish: How does one create a private protocol?
- Walter: The contents of the BCI string can be anything.
- Bob R: Does this depend on BIRD 128?
- Walter: Yes, if the existing AMI_GetWave function is used.
- Bob R: There is no Protocol_Specific branch?
- Walter: There is not.
- This should be easy for AMI model developers.
AR: Walter send back-channel BIRD drafts to Mike for posting.
-------------
Next meeting: 28 Apr 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
