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 <mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
