[ibis-macro] Re: Backchannel/Training/Co-optimization Discussion
- From: Bradley Brim <bradb@xxxxxxxxxxx>
- To: "msteinb@xxxxxxxxxx" <msteinb@xxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 9 Jun 2014 14:15:24 -0700
Hi Mike,
We defined an IBIS buffer file format and now buffer designers generate IBIS
buffer models in that format. In exactly the same manner, we are proposing to
define a BCI file format and then future protocol standards committees will
define their backchannel communications protocols in that format. Both of these
seem to conform to the charter of our organization. The present concern is how
do we handle BCI files (or lists of reserved parameter values required for the
alternate proposal) for existing protocols. This is an issue we need to address
for either of the two proposals!
The information to occur in BCI files or in lists of reserved parameter values
exists in the protocol standards. However, we did not previously have a
standard manner in which to specify such information. The IBIS committee could
work with those protocol standards committees to generate an official BCI file
to be published as part of each protocol standard. In the absence of protocol
standards committee participation, the IBIS committee could alternately publish
a group consensus interpretation of the protocol standard's information.
For either proposal we either all individual designers on their own to create
BCI files (or the required lists of reserved parameter values) or someone needs
to provide a common source for such information. I quote my previous message
... "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". Regardless of which proposal we pursue, seems a mechanism
needs to be put in place to enable consistent interpretation of protocol
standards.
On a detailed point of process ... concerning either a BCI file or a list of
reserved parameter values for a given protocol:
The IBIS committee has no formal standard for each protocol. I agree that we
cannot pursue a BIRD (formerly Buffer, now Backchannel Issue Resolution
Document) to a standard we do not control. We could provide a committee
consensus interpretation BCI file (or reserved parameter value list). If you
don't like my usage of "committee consensus interpretation", then we simply
publish as "examples" with the BCI specification for the protocols for which
the standards committees do not wish to invest the effort.
Best regards,
-Brad
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Mike Steinberger
Sent: Monday, June 09, 2014 12:58 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Backchannel/Training/Co-optimization Discussion
Brad-
At several points in your response, you refer to something you call "IBIS
consensus", and I'm not at all sure what that could possibly mean. So far as I
understand it, IBIS is a standards organization in which proposals are
documented in the form of a BIRD, reviewed by the members of the organization,
possibly modified, and then either approved or rejected by formal vote. The
only expression of consensus in that process is the result of the formal voting.
It appears that whatever these proposed "BCI" files are, their content has not
yet been described in any BIRD in enough detail that anyone could attempt any
form of implementation. Thus, it appears that you want to somehow jump to the
end of the process without having completed the first step.
I really must insist that you work within the process as it is defined by the
organization.
Mike Steinberger
On 06/09/2014 12:42 PM, Bradley Brim wrote:
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:
