[ibis-serdes-backchan] Re: Feedback now required from Backchannel SerDes Silicon Developers.
- From: "Chong, Alfred" <alfredchong@xxxxxx>
- To: "ibis-serdes-backchan@xxxxxxxxxxxxx" <ibis-serdes-backchan@xxxxxxxxxxxxx>
- Date: Tue, 15 Feb 2011 16:08:48 -0600
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"
<wkatz@xxxxxxxxxx<mailto: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.
>
> wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
>
> 303.449-2308
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.883-2120
Other related posts:
