[ibis-macro] Re: Backchannel/Training/Co-optimization Discussion
- From: Ambrish Varma <ambrishv@xxxxxxxxxxx>
- To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, Bradley Brim <bradb@xxxxxxxxxxx>, IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 9 Jun 2014 16:39:24 -0700
Walter:
Can you point to the part of the presentation and Brad's email response that
'clearly' states Cadence does not want to have a regular way of standardizing
the BCI file?
I have already pointed out that the presentation at the Summit says no such
thing - and Brad's email says only 2 things - I will repeat here:
- It would be a much better idea if the protocol standards committee
would themselves publish the .BCI files - allowing IBIS to 'get out of the way'
of .BCI files for future standards. Until that happens - IBIS will approve
of/provide the .BCI file for each standard going forward - as well as the
standards that have supported back channel communication in the past.
- Vendors can augment the approved .BCI files for existing protocols
to accommodate differentiating capability to support 'Private' training
protocols, over and above the published standards.
I want to point out that we have already provided 3 sample BCI files in my
slides here:
http://www.vhdl.org/ibis/macromodel_wip/archive/20140506/ambrishvarma/The%20BCI%20File/BCI_File_and_Communications.pdf.
Future BCI files will follow similar structure.
I would hope that you will refrain from making incorrect statements like your
last 2 emails and engage in substantive discussions that will move this subject
forward.
Best Regards,
Ambrish.
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Monday, June 09, 2014 6:36 PM
To: Bradley Brim; IBIS-ATM
Subject: [ibis-macro] Re: Backchannel/Training/Co-optimization Discussion
Brad,
Your presentation at the Summit and your e-mail response clearly states that
Cadence does not want to have a regular way of standardizing the BCI file.
I would like to remind everyone of the intent of IBIS-AMI. In a presentation
submitted to IBIS ATM on April 10, 2007 (enclosed), Cadence, SiSoft and Mentor
clearly stated the IBIS-AMI Goals:
*Establish a modeling standard for SerDes devices that describes
-Analog I/O & electrical package characteristics
-Transmit / receive equalization
-Clock recovery behavior
*The standard must:
-Support prediction of link Bit Error Rate (BER)
-Enable EDA & SerDes model interoperability
-Protect Semiconductor vendor IP
-Support design optimization
What you have proposed clearly violates "EDA & SerDes model interoperability"
and therefore should not and cannot be considered for approval by IBIS.
Walter
From: Bradley Brim [mailto:bradb@xxxxxxxxxxx]
Sent: Monday, June 09, 2014 1:43 PM
To: wkatz@xxxxxxxxxx; IBIS-ATM
Subject: RE: Backchannel/Training/Co-optimization Discussion
Hello Walter,
Thanks much for a lively and informative discussion during the IBIS Summit. It
seems you did not fully understand my points.
Yes, I proposed for IBIS to proceed "without a plan for standardizing BCI
files". More concisely and precisely stated I proposed for IBIS to proceed
"without standardizing BCI file content". I absolutely did not propose to
proceed "without a plan" to provide the industry with a framework for
consistency and short term service to support such for existing protocols by
publishing IBIS-consensus BCI files.
I stated that BCI files should be viewed as an interpretation of information
already contained in existing formal protocol standards and appear in an
IBIS-specified format (of a BCI file). I suggested the IBIS committee define
the format of a BCI file but questioned if the IBIS committee should be
creating formal "standards" for BCI file content. I suggested the IBIS
committee should publish a consensus interpretation of existing standards
information in a format of a BCI file (or alternately a list of reserve
parameter values) for all AMI users to apply consistently. Lastly, I suggested
future protocol standards committees could publish (without IBIS committee
involvement) BCI files for their protocols. My view applies to BCI files as
well as the protocol-dependent list of reserved parameter values your proposal
would require.
Our group discussion with the audience included observation that today with
existing protocol standards ambiguous information exists that has been
interpreted differently among TX/RX vendors and already caused backchannel
communication issues between TX and RX from different vendors. A consensus
interpretation was agreed to provide value, whether that comes from the IBIS
committee for existing protocols or from the future protocol standards
committees.
I did not at any point propose "to have device vendors create models that only
communicate between that vendors Rx and Tx is using their proprietary
protocol". I certainly pointed out that an IBIS consensus BCI file for existing
protocols could easily be augmented by a vendor to accommodate differentiating
capability they have implemented in their hardware. If you are still confused
Ambrish, Kumar or Ken will be happy to once again explain during the upcoming
Tuesday ATM meeting how BCI files primarily enable and in no way limit
standard/consensus/consistent protocols; while also easily enabling proprietary
protocols.
Hope this helps to clarify for you and others who were not able to attend the
points made during our discussion.
Best regards,
-Brad
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, June 06, 2014 11:31 AM
To: IBIS-ATM
Subject: [ibis-macro] Backchannel/Training/Co-optimization Discussion
All,
The discussion in the IBIS Summit on the two
backchannel/training/co-optimization proposal was enlightening - to say the
least.
BIRD 147 introduces the concept of BCI files without a plan for standardizing
BCI files. In fact it was made clear during the Open Summit that IBIS should
not be in the business of standardizing BCI files, and the intent of BIRD 147
is to have device vendors create models that only communicate between that
vendors Rx and Tx is using their proprietary protocol. Although we should not
prohibit a vendor from creating Rx and Tx models that communicate with each
other is a proprietary way, it must be a requirement that IBIS provides a
mechanism that Rx and Tx models from different vendors communicate in a
standard way , especially when training is done compliant to such standards as
802.3 and PCIe. One of the basic premises of IBIS AMI was to support
interoperability of models from different vendors. Seems to me that creating a
standard way for device vendors to only create models that train using
proprietary Rx to Tx communication is not part of the IBIS charter, and
therefore BIRD 147 should either be modified or set aside.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
