[ibis-macro] Re: Backchannel/Training/Co-optimization Discussion
- From: Walter Katz <wkatz@xxxxxxxxxx>
- To: "Bradley Brim" <bradb@xxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 9 Jun 2014 18:36:01 -0400 (EDT)
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] 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
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
