[ibis-serdes-backchan] Re: Structural changes to the AMI standard required to support Backchannel Co-optimization
- From: Walter Katz <wkatz@xxxxxxxxxx>
- To: ibis-serdes-backchan@xxxxxxxxxxxxx
- Date: Fri, 11 Feb 2011 12:57:25 -0500 (EST)
Arpad,
These new parameter become either Reserved Parameter in the official IBIS
specification, or standard specific Reserved Parameters. We would have an
official Reserved Parameter (e.g. Backchannel_Protocol=PCIe-Gen3). The
PCIe-Gen3 standards group would then define their own set of AMI parameters
used for this particular protocol.
Walter
----- Original Message -----
From: Arpad Muranyi <Arpad_Muranyi@xxxxxxxxxx>
To: ibis-serdes-backchan@xxxxxxxxxxxxx, IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Sent: Fri, 11 Feb 2011 09:54:48 -0500 (EST)
Subject: [ibis-serdes-backchan] Re: Structural changes to the AMI standard
required to support Backchannel Co-optimization
Walter,
Thanks for initiating the conversation on this topic.
I have a couple of questions on what you wrote below.
Assuming this twofold root format is implemented, but we
have two AMI models from two different vendors, how would
one vendor know what the other vendor calls its parameters?
This is what you have in your example:
"(Rx_Root (DFE_Tap (1 -.1) (2 -.05) (3 .05) (4 .1) (5 -.01)))"
but what if the vendor calls these by different names:
"(Rx_Root (my_DFE_taps (First -.1) Second -.05) (Third .05) (Fourth .1)
(Fifth -.01)))"
It seems that this would only work if we also standardized
names of the variables which are part of the conversation
between Tx and Rx in the back channel.
The other comment I have is making the GetWave function's
AMI_parameters_out argument bidirectional because we didn't
specify an AMI_parameters_in argument as for the Init function.
Wouldn't it make more sense to just add this missing "in"
argument to the GetWave function, instead of "hack" the
existing "out" argument to be bidirectional?
Thanks,
Arpad
================================================================
From: ibis-serdes-backchan-bounce@xxxxxxxxxxxxx
[mailto:ibis-serdes-backchan-bounce@xxxxxxxxxxxxx] On Behalf Of Walter
Katz
Sent: Friday, February 11, 2011 8:00 AM
To: 'IBIS-ATM'
Cc: ibis-serdes-backchan@xxxxxxxxxxxxx
Subject: [ibis-serdes-backchan] Structural changes to the AMI standard
required to support Backchannle Co-optimization
IBIS-ATM,
This e-mail is being sent to the IBIS ATM (Advanced Technology Modeling)
group to describe the structural changes required to the IBIS-AMI
interface. The Backchannel Reflector is being cc's as well.
Two changes are required to the IBIS-AMI interface to support
backchannel. The first is to allow the Tx AMI DLL to know what the Rx
AMI DLL is telling it and the Rx AMI DLL needs to know what the Tx AMI
DLL is telling it. Information is currently passed into a DLL as a text
string in in a similar parameter tree format as defined in the .ami file
for that model. The roor of this parameter tree is the root of the
parameter tree in the .ami file. The simple enhancement to the AMI
interface is to allow this string to contain two parameter trees, one
with the root of the parameter tree for the model, and the other tree
containing the root of the parameter tree fo the model at the other end
of the channel. The following example should make this clearer:
Assume that the parameter tree for the Tx model is:
(Tx_Root (FFE_Tap (-1 -.03) (0 .9) (1 -.07)))
and the parameter tree for the Rx model is:
(Rx_Root (DFE_Tap (1 -.1) (2 -.05) (3 .05) (4 .1) (5 -.01)))
In the current standard the Tx just gets the (Tx_Root ...) tree and the
Rx just gets the (Rx_Root ...) tree.
The proposed change will allow the Tx model to receive:
(Tx_Root (FFE_Tap (-1 -.03) (0 .9) (1 -.07))) (Rx_Root (DFE_Tap (1 -.1)
(2 -.05) (3 .05) (4 .1) (5 -.01)))
and the Rx model to receive
(Rx_Root (DFE_Tap (1 -.1) (2 -.05) (3 .05) (4 .1) (5 -.01))) (Tx_Root
(FFE_Tap (-1 -.03) (0 .9) (1 -.07)))
Thus, the Rx model can determine the number of Tx pre-cursor and
post-cursor taps, and the values of all of the Tx taps.
The DLL's not only receive data in this format, but also output data in
this same format. Thus the Rx model can output these same trees with
updated values of the Tx Taps.
As described in previous e-mails, there are three entry points to an AMI
model, AMI_Init, AMI_GetWave, and AMI_Close. The AMI_Init entry has a
parameters_in pointer and a parameters_out pointer. The AMI_GetWave
entry only has a parameters_out pointer. Since Backchannel will require
the ability to pass a parameter tree inot the AMI_GetWave entry, the AMI
interface standard needs to modified to allow the AMI_GetWave
parameters_out pointer to also serve as a pointer to an input string.
To enable the above changes, we will need to define a new Reserved
Parameter to indicate that this DLL does support multiple parameter
trees in the input parameter tree, and that the AMI_GetWave support the
parameter_out pointer use as an input as well as an output.
Walter
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
---------------------------------------------------------------------
IBIS SerDes BackChannel website: http://www.eda.org/pub/ibis
List email archives: //www.freelists.org/archives/ibis-serdes-backchan
To unsubscribe send an email:
To: ibis-serdes-backchan-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
