[ibis-macro] Minutes from the 22 Apr 2014 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: ibis-macro@xxxxxxxxxxxxx
- Date: Tue, 22 Apr 2014 16:36:40 -0400
Minutes from the 22 Apr 2014 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 22 April 2014
Members (asterisk for those attending):
Agilent: Fangyi Rao
* Radek Biernacki
Altera: * David Banas
ANSYS: * Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
Brad Brim
* Kumar Keshavan
Ken Willis
Scott Huss
Ericsson: Anders Ekholm
Intel: * Michael Mirmak
LSI Amaresh Malipatil
Dai Xingdong
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Andrey Matvienko
Vladimir Dmitriev-Zdorov
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:
- Walter asked which of two web meeting services to use for ibis-interconn
meetings.
- Michael M. said the Intel meeting service would be used
-
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- None
-------------
New Discussion:
DLL dependency checking:
- Arpad: Should we require models to be checked for code library dependencies?
- David: There is a utility with a dumpbin command for that.
- Arpad: It should be built into our own checking.
- Walter: Maybe one of the test suites could be used.
- Ambrish: The DLL is too much of a black box.
- Todd: The spec says there should be no dependencies.
- We should at least make sure that part is clear.
Backchannel:
- Arpad asked that we focus on the issue at hand to avoid going in circles.
- Walter showed two example AMI files.
- Walter: The BCI file requirement poses maintenance problems.
- A very general TX AMI file would eliminate the need for that.
- One shown here is generic, the other for PCIe3.
- There are three co-optimization modes.
- Manual: The TX does what it's told.
- Auto: The TX can modify based on impulse response inputs.
- Co-optimize: RX inputs and impulse response are used.
- TX taps indexes are usually given as integers from 0 to N.
- Coefficients are float numbers.
- There would be reserved parameters to say what the names of key
Model_Specific parameters are.
- Also the ranges would be given, even the target parameters have these.
- Michael M.: Coefficients do not assume summation to 1.0?
- Walter: Yes they must sum up to 1.0.
- Michael M.: Shouldn't the index ranges map up to 1.0?
- Walter: Tap -1 shown here has 32 index settings.
- The register may have a different set, not discussed here.
- The 32 values may not map the whole range,and maybe not linearly.
- Converting from coefficient to index can be very complicated.
- This is why Tap_Conversion is proposed.
- Rarely are both indexes and coefficients used together.
- Michael M.: You may have those reversed.
- Walter: The RX sends out tap coefficients.
- Michael M.: One of the 4 phases of EQ is stating max index values each side
supports.
- Walter: We need to look at that.
- To exchange tap coefficients we only need to know the parameter to use.
- RX Init can effectively only return tap coefficients.
- Walter showed an 802.3KR example.
- The TX has co-optimize mode which means it accepts tap increments.
- The increment parameter is a table showing the range for each tap.
- The RX can only increment and decrement.
- Michael indicates it can also set index values.
- This should work for the foreseeable future, at least four years.
- We need to know if the RX Init can co-optimize the TX.
- Likewise for RX GetWave.
- Another parameter tells whether the impulse response includes TX EQ.
- David: Is this a new information flow?
- Walter: It is the output of TX Init with no EQ.
- This is an important detail.
- Arpad: Is this related to Use_Init_Output?
- Walter: There is no connection.
- The RX defines training requirements, similar to BIRD 147.
- BIRD 147 adds the Bit type, we should not add new types.
- This proposal uses reserved String parameter names.
- Tap_Increment is declared by the RX too.
- This has all of the BIRD 147 functionality, eliminating the BCI file.
- Ambrish: How you the RX and TX support multiple protocols?
- Walter: This will not support that.
- Mike: BIRD 147 has Backchannel_Protocol pointing to a single BCI file.
- Ambrish: There can be multiple List values.
- Walter: If we have a BCI file it should belong to the RX.
- Ambrish: The TX and RX must point to the same BCI file to insure they support
the same protocol.
- Walter: Is there any way other than increment to send information to a TX?
- Ambrish: The BCI allows that to be defined, we don't know what will be done
in the future.
- Walter: Do we know of any new requirements in development?
- Ambrish: The BCI contains all parameters for the TX and RX for whatever
protocol is used.
- Walter: This requires us to standardize the BCI files.
- Ambrish: A subcommittee could meet every 6 months to set that.
- Walter: This eliminates the need for the subcommittee.
- Ambrish: Your proposal will require more changes as new protocols arise.
- Walter: I am on several standards committees, none of them need new
parameters.
- Ambrish: We don't want to make changes soon after a standard comes out.
- Walter: No Reserved_Parameter has been suggested since the 5.1 changes.
- Some people have been co-optimizing for years.
- We need to decide which method is easier for IC and EDA tool vendors.
- Bob: A key item would be the need for a new file checker.
- Both proposal involved about 8 new Reserved_Parameters.
- We would need TapIndex as a new type.
- Kumar: The EDA tool should not have to translate what the RX sends to the TX.
- Also indexes are very architecture specific.
- This has a lot of new parameters.
- BCI has the minimum set of parameters for communication.
- Standards committees have no hard rules that coefficients will always work
the same way.
- Ambrish: And the BCI file makes it easier for models to support multiple
protocols.
- Walter: Co-optimization can be done in different places.
- Each has different requirements.
- Ambrish: It is not that complicated, Init works one way and GetWave works
another way.
- Kumar: It is important to support the Init flow with coefficients.
- Arpad: These should be posted online.
AR: Walter send backchannel example files, Mike post these.
- Michael M.: We need to define how presets fit in.
- Walter: We might need a table for that.
- Kumar: That is a good one for the BCI file, it is protocol-specific.
- We should not need a Reserved_Parameter for that.
- Walter: If it's in the BCI file there is a reserved parameter.
- Ambrish: I would like to present next week.
- Michael M.: We need to work out more details on PCIe too.
-------------
Next meeting: 29 April 2014 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 22 Apr 2014 ibis-atm meeting - Mike LaBonte
