[ibis-serdes-backchan] Re: Feedback now required from Backchannel SerDes Silicon Developers.
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <ibis-serdes-backchan@xxxxxxxxxxxxx>
- Date: Wed, 16 Feb 2011 07:39:47 -0500 (EST)
Alfred,
The devil in the detail for taps has a simple solution. IBIS AMI has a
special tap type of parameter. Here is an example of how this looks in the
.ami file:
(My_Tx
(Reserved_Parameters
(.)
(Backchannel_Method (List "KR" "PCIe3" "IEEE-25G") (Type String) (Usage
InOut)
(Description "Backchannel
Method")
)
)
(Model_Specific
(Tx_Tap_Register
(-1 (Increment 0 0 15 1) (Type Tap) (Usage InOut)
(Description "Pre-cursor tap register value"))
(0 (Increment 63 0 63 1) (Type Tap) (Usage InOut)
(Description "Main-cursor tap register value"))
(1 (Increment 0 0 31 1) (Type Tap) (Usage InOut)
(Description "Post-cursor 1 tap register value"))
(2 (Increment 0 0 15 1) (Type Tap) (Usage InOut)
(Description "Post-cursor 2 tap register value"))
)
(Tx_Tap_Normalized
(-1 (Range 0. -.25 .25) (Type Float) (Usage InOut)
(Description "Pre-cursor tap normalized value"))
(0 (Range 1. 0. 1.) (Type Float) (Usage InOut)
(Description "Main-cursor tap normalized value"))
(1 (Range 0. -.5 .5) (Type Float) (Usage InOut)
(Description "Post-cursor 1 tap normalized value"))
(2 (Range 0. -.25 .25) (Type Float) (Usage InOut)
(Description "Post-cursor 2 tap normalized value"))
)
(Tx_Swing (Range (7 0 7) (Type Integer) (Usage InOut) (Description "Swing
settings"))
(Tap_Conversion_-1
(Dependency
(Labels "My_Tap_Register.-1 In" "My_Tap_Normalized.-1 Out_PWL")
(Row1 (List 0
-.25) (Usage Info) (Type Float))
(Row2 (List 15
.25) (Usage Info) (Type Float))
)
)
(.)
)
)
The tells the EDA tool (and the Rx) that the Tx has one pre-cursor and two
post-cursor taps. The minimum "Register" value of tap -1 (precursor) is 0,
max is 15, allowed values are 0, 1, .15, and the default is 0. The minimum
"Normalized" value of tap -1 is -.25 and the maximum value is .25. The
Tap_Conversion_-1 Dependency table describes the relationship between the
register value of the tap and the Normalized or relative tap weights that
the buffer actually uses for each tap register settings. I would expect
that this group can agree on reserved names for Tx_Tap_Register,
Tx_Tap_Normalized, and Tx_Swing, and hopefully we can agree to the same
names for the various standards.
The Rx AMI file that supports only one post cursor tap might look as
follows:
(My_Rx
(Reserved_Parameters
(.)
(Backchannel_Method (List "KR") (Type String) (Usage InOut)
(Description "Backchannel
Method")
)
)
(Model_Specific
(Tx_Tap_Normalized
(-1 (Range 0. -1. 1.) (Type Float) (Usage InOut)
(Description "Tx pre-cursor tap normalized value"))
(0 (Range 1. 0. 1.) (Type Float) (Usage InOut)
(Description "Tx main-cursor tap normalized value"))
(1 (Range 0. -1. 1.) (Type Float) (Usage InOut)
(Description "Tx post-cursor 1 tap normalized value"))
)
(.)
)
)
The EDA tool know that although the Tx supports "KR" "PCIe3" "IEEE-25G"
and four taps, this particular Rx supports only "KR", and only three taps.
It is not clear to me if KR specifies that the Tx Tap Register must have
the same allowed values as described above, or if this mapping of the tap
register to the normalized tap value can be model/vendor specific. In this
example the EDA tool and the Rx knows the Tx has four taps (and their
limits), and it knows that it can only optimized the first three. Also,
in this case the RX returns updated values of the normalized tap
coefficients, which the Tx will then internally convert to register
values.
This example just demonstrates the capabilities of AMI models to describe
themselves to the EDA tool and their mated model. Whether we need to
support both normalized and register representations now gets into
details of the various specifications that and how the standards groups
can agree on methods in AMI that will support interoperability between
models from different vendors.
Walter
From: ibis-serdes-backchan-bounce@xxxxxxxxxxxxx
[mailto:ibis-serdes-backchan-bounce@xxxxxxxxxxxxx] On Behalf Of Chong,
Alfred
Sent: Tuesday, February 15, 2011 9:35 PM
To: ibis-serdes-backchan@xxxxxxxxxxxxx
Subject: [ibis-serdes-backchan] Re: Feedback now required from Backchannel
SerDes Silicon Developers.
Walter,
If the devil is in the details, I think you are the right
candidate to tame the devil.
In my previous email, I did not restrict the backchannel parameter to 1
pre and 1 post cursors; it can be expanded to multiple pre and post
cursors.
Eg,
(Tx_Root_backchannel (Pre_cursor1) (Pre_cursor2) .
(Pre_Cursor[n]) (Post_cursor1) (Post_cursor2) .(Post_cursor[n]))
The above example is merely to illustrate the idea, I will leave the fun
of working out the detail of the parameter tree structure to you.
I think you also need to work out the detail of determining whether one
vendor TX.dll can run with another vendor RX.dll in backchannel.
Here is an example that I can think of on the fly,
Vendor A has three parameters for optimization in its TX.dll.
(Tx_Root_backchannel (Pre_cursor1) (Post_cursor1) (Swing))
Vendor B can only optimize two parameters in its RX.dll
(Rx_Root_backchannel (Post_cursor1) (Pre_cursor1))
There are two concerns here. Firstly, the RX pre and post
cursors was defined in reverse order of TX, should the order be
standardized or EDA tool should take care of it?
Secondly, RX searching algorithm from vendor B can only train
post and pre cursors and not swing. EDA tool should be smart enough to
handle this case. One solution is
always return 'hold' for swing to TX from EDA tool, and
return the value (inc/dec/hold) for post and pre cursors generated by the
RX.
Regards,
Alfred
_____
From: ibis-serdes-backchan-bounce@xxxxxxxxxxxxx
[mailto:ibis-serdes-backchan-bounce@xxxxxxxxxxxxx] On Behalf Of Walter
Katz
Sent: Tuesday, February 15, 2011 5:47 PM
To: ibis-serdes-backchan@xxxxxxxxxxxxx
Subject: [ibis-serdes-backchan] Re: Feedback now required from Backchannel
SerDes Silicon Developers.
Alfred,
I understand your proposal, and I generally agree, the devil is in the
details, but I can work out these details from what you have proposed. I
have two specific questions/comments. I understand that the KR and PCIE3
gen specs require that there be at least one pre-cursor and one
post-cursor tap. But I believe that they also allow more than one
pre-cursor and more than one post-cursor taps as well. We will also need
to define a new reserved parameter (e.g. Tx_Stimulus) which would have
defined values like PRBS-7, PRBS-15, .).
Walter
From: ibis-serdes-backchan-bounce@xxxxxxxxxxxxx
[mailto:ibis-serdes-backchan-bounce@xxxxxxxxxxxxx] On Behalf Of Chong,
Alfred
Sent: Tuesday, February 15, 2011 5:09 PM
To: ibis-serdes-backchan@xxxxxxxxxxxxx
Subject: [ibis-serdes-backchan] Re: Feedback now required from Backchannel
SerDes Silicon Developers.
Walter,
I personally prefer second suggestion with some modification
on your proposed parameter structure to avoid over exposing proprietary
information as mentioned by Kumar.
(Tx_Root_backchannel (Pre_cursor) (Post_Cursor))
In TX ami file, Pre_cursor and Post_Cursor are specified as backchannel
parameters that need to be optimized.
(RX_Root_Backchannel (Pre_Cursor) (Post_Cursor) (Swing))
The above parameter tree tells the users that RX supports back-channel
optimization, it can train three parameters, and the preferred order is
Pre_Cursor, Post_Cursor, and followed by Swing.
At the start of the back-channel training, TX is set to default pre-cursor
and post-cursor settings and RX have no idea what the pre and post cursors
settings are.
After the simulation, RX dll returns increment, decrement, or hold for
(Pre_cursor) and (Post_Cursor) respectively to EDA tool and thus TX dll.
Then, TX dll re-acts
accordingly and returns max, min, or updated. The back-channel training is
complete when RX dll returns hold for both Pre_cursor and Post_cursor.
RX does not need to tell TX to increment or decrement the Pre_cursor and
Post_Cursor by how much, TX has its own default step size for each of the
parameter for back-channel optimization.
Finally, TX dll spells out the adapted Pre_cursor and Post cursor settings
at the end of the back-channel-optimization.
This method is very similar to IEEE auto-negotiation protocol specified in
KR or PCIE3, and I think it is appreciated if AMI back-channel
optimization follows this practice to avoid
the needs for silicon vendors to put in dramatically huge effort to modify
existing searching algorithm code to work with AMI EDA tool.
I would modify #2 to
The Rx tells the EDA tool what pattern needs to be simulated next, and
which taps needs to be incremented/decremented/hold.
Regards,
Alfred
_____
From: ibis-serdes-backchan-bounce@xxxxxxxxxxxxx
[mailto:ibis-serdes-backchan-bounce@xxxxxxxxxxxxx] On Behalf Of Walter
Katz
Sent: Monday, February 14, 2011 12:01 PM
To: IBIS-BackChannel
Subject: [ibis-serdes-backchan] Feedback now required from Backchannel
SerDes Silicon Developers.
Backchannel SerDes Silicon Developers.
We now need feedback from the developers of Backchannel Silicon on the
"Layers" of Backchannel Co-Optimization that AMI modeling needs to
support. Three possible "Layers" are:
1. Statistical: The Rx tells the EDA Tool and the Tx model what its
tap coefficients should be.
2. Time Domain Behavioral: The Rx tells the EDA tool what pattern
needs to be simulated next, and which taps needs to be
incremented/decremented and by how much.
3. Time Domain Detailed: The Rx communicates the actual binary
commands to the Tx models that will be sent to the Tx model, and the Tx
model sends the appropriate payload, and adjusts its configuration
accordingly.
Can the Backchannel SerDes Silicon Developers in this reflector please
respond.
Walter
-----Original Message-----
From: ckumar [mailto:ckumar@xxxxxxxxxxx]
Sent: Friday, February 11, 2011 1:41 PM
To: wkatz@xxxxxxxxxx
Cc: IBIS-ATM; ibis-serdes-backchan@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Structural changes to the AMI standard required
to support Backchannle Co-optimization
I see that this proposal exposes the entire architecture of tx and rx to
each other and expects them to interpret each other's parameters.
The back channel communication standards are based on minimalist and
necessary communication between rx and tx.
from rx:
1. rx knows the number of taps in tx
2. rx can only ask tx to increment/decrement the taps. It does not or care
to know what the absolute value of tx means
from tx:
tx communicates to rx whether the the specified taps are adjustable at all
or they have reached their min/max limit
The mode of communication also depends upon the standard and should be
defined in the particular standards file
On Fri, 11 Feb 2011 09:00:05 -0500, "Walter Katz" <
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx>
wrote:
> 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
>
>
>
>
>
>
>
>
>
> 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.
>
> <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
>
> 303.449-2308
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.883-2120
Other related posts:
