[ibis-macro] Minutes from the 30 Sep 2014 ibis-atm meeting
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 30 Sep 2014 16:34:04 -0400
Minutes from the 30 Sep 2014 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 30 September 2014
Members (asterisk for those attending):
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
Keysight Technologies: Fangyi Rao
* Radek Biernacki
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
* Bob Ross
(Note: Agilent has changed to Keysight)
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- Arpad will be traveling, may not be able to run the meeting next week.
- Todd will be away also.
- The meeting will still be held, Arpad will ask John to chair.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Todd produce slides for co-optimization requirements discussion next week.
- Not done.
- Arpad to review IBIS spec for min max issues.
- In progress.
-------------
New Discussion:
BIRD 147.1:
- Walter showed a presentation "BCI Generic Protocol".
- slide 2:
- Walter: This was sent to Cadence for an opinion on whether it could be an
IBIS approved protocol.
- This uses both "Back-channel" and "Link training" so everyone understands.
- Cadence said this could be a private protocol but not approved.
- slide 3:
- Walter: The evaluator path is blue here.
- The TX must be able to tell the RX when it can't complete a request.
- The protocol is yellow.
- slide 4:
- Walter this is a generic protocol.
- slide 6:
- Walter described a TX BCI parameter example with both indexes and
coefficients.
- Bob: Would those be reserved names?
- Walter: The protocol defines these names.
- David: This is a mode where TX DLLs have to be recompiled to do this?
- Walter: Yes.
- slide 7:
- Walter: The AMI format is useful for documenting the protocol.
- Calling it "InOut" is not quite compatible with AMI language.
- This is documentation, the tools and DLLs do not read this.
- slide 8:
- Walter described an RX BCI parameter example.
- Walter: It can send either indexes, coefficients, or increments.
- slide 9:
- Walter: The TX reports back how it handled the request.
- It reports the coefficients actually used.
- slide 10:
- Walter: The RX may make more adjustments or switch to GetWave optimization
flow.
- An additional Init call might be made for statistical analysis using
GetWave results.
- There might be multiple time domain iterations.
- Radek: This keeps the flow with the AMI description.
- Walter: It means TX Init is re-entrant.
- The ** pointer would initially be NULL.
- Or we might want a different entry point for this.
- slide 11:
- Walter: This is not in BIRD 147.
- It adds reserved Training_State in the AMI file.
- The RX is much "smarter" than the TX.
- There are also reserved Training_Protocol and Training_Pattern parameters.
- slide 11:
- Walter: This was the reply from Cadence.
- slide 12:
- Walter: A number of vendors agree the TX is very general purpose.
- RX buffers report the eye at the decision point.
- The logic to search the tap solution space is not clear.
- IP providers may hesitate to reveal their secret sauce.
- slide 6:
- David: Why can't this be communicated by AMI file?
- Walter: It could be, but the RX needs to have this information.
- They would be AMI reserved parameters.
- New parameters are not likely soon, but would required new reserved
parameters.
- Radek: Why would this not require recompiling the TX?
- David: It doesn't change. Once in the AMI file I am done.
- Walter: It could be in AMI but we want to be able to dynamically report tap
settings.
- That would require recompilation.
- David: You proposed that only the range needs to be known.
- Walter: That was Init training, not GetWave training.
- TX models can have integer parameters for each tap.
- We have to tell the EDA tool which tap is which.
- The tool would get response after changing settings.
- David: Existing TX models could not participate in GetWave training.
- But they could participate in Init training.
- Ambrish: BIRD 147 does not go there, but another BIRD could.
- slide 14:
- Walter: Another BIRD could be combined with this.
- We still have to say which tap is which.
- The purpose here is to propose something that is compliant with BIRD 147.
- It would allow TXs and RXs to work together.
- Ken: You can have private protocols, but it doesn't have to be part of this
BIRD.
- Todd: Cadence seems to be reversing position.
- The question is if we can define parameters beyond what the BIRD defines.
- We asked if a "framis" could be defined in a "ibis_" standard BCI file.
- It could be a jitter number, anything.
- Ambrish: The BCI file can have what the committee approves.
- Walter: Ambrish should explain the last sentence on slide 12.
- It prohibits "generic" parameters.
- Ambrish: It has to belong to some existing protocol.
- Todd: What on slide 6 is not eligible for standardization?
- Ambrish: Which protocol is it?
- Todd: Who decides what is industry standard?
- Only approved industry bodies are eligible.
- Ken: If you make your own I still expect any compliant tool to work with the
models.
- Todd: If a handful of silicon vendors decide on a protocol can that be
standard?
- Ambrish: Why does it need to be standard?
- Todd: Once we agree, we like a stamp of approval.
- Ambrish: When the time is right you can ask an organization to standardize it.
- John: It might not correspond to what any hardware does.
- Todd: Ambrish, you are saying yes, it would be eligible for standardization.
- Ambrish: The intention was to call only IEEE protocols standard.
- Todd: That should be in the BIRD, but it might sink it.
- Ken: Industry standard means it is published for global use.
- Arpad: What if IEEE came up with a generic standard?
- Todd: The question is if 3 or 4 companies could create a standard BCI by
their own agreement.
- There should be a yes or no answer.
- Ken: Where would the new parameters be?
- Walter: It is all protocol specific in this example.
- John: BIRD 147 gives List parameters, but it really would be a value in the
end.
- Walter: BIRD 147 is confusing on that.
- Ambrish: Disagree that it is confusing.
- Todd: We need BCI files to be standardized because our customers will want
that.
- John: The first issue is what is allowed in BIRD 147.
- We need to talk about doing both modes in the same model.
- That is not clear in the current BIRD.
- Ken: A legal but non-standard BCI file should work in any compliant tool.
- We will respond to Todd's question.
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 30 Sep 2014 ibis-atm meeting - Mike LaBonte
