[ibis-macro] Re: Flow
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 20 Oct 2009 21:28:42 -0700
Rich,
Thank you for your comments. I think you are correct that
the current IBIS-AMI specification and the flow discussions
fail to address the situation you mentioned. Although the
Tx or Rx models may contain optimization algorithms, there
are currently no provisions for letting them talk to each
other about that, i.e. having an optimization where the Tx
tap coefficient depends on information coming from the Rx
(or vice versa).
Currently the only link between the Tx and Rx is the main
communication (data) channel (which you call the downstream
link).
I don't think it would be too difficult to add an additional
channel to the flows we are discussing for this purpose.
I would like to ask you a basic question, though. Is this
"upstream" channel just as fast as the "downstream" channel?
My guess is that these would usually be much slower than the
main "downstream" channel, and they wouldn't have to be
simulated for SI effects. If this is true, we could just
extend the DLL interfaces of Tx and Rx so that they could
talk to each other directly. Otherwise we would have to
do a little more work, basically duplicating the entire
SI analysis of both down and upstream channels which may
become a little more complicated, but not totally impossible...
Thanks,
Arpad
================================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mellitz, Richard
Sent: Tuesday, October 20, 2009 4:30 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Flow
I'm trying wrap my mind around the concept of flow that y'all are
tossing about. Maybe an interface spec is more pertinent? What is the
role and responsibility of each feature? What are the pipes between?
Adaptive equalization may require a number different flow steps
depending on operation.
Let's take PCIe Gen3 as an example. I think at very minimum IBIS-AMI
should support that. It's not too different from IEEE802.3ap.
There is a notion of downstream (motherboard) and upstream. The Rx is in
control but the downstream device lends hints to start (per spec).
First the downstream device commands the upstream device as to where Tx
eq tap setting should start.
The Rx can either take those hints or tell the Tx go an initialization
equalization pre-set. The Rx could decide it doesn't want any Tx Eq and
do FFE in the Rx unannounced to anybody.
Now training may occur if the Rx wants adjust the Tx per spec. A special
pattern is used. The Rx may recursively tell the Tx to change taps. In
all likelihood it would not be a zero forcing solution for taps because
of some Rx linear EQ. It may use the Tx tap adjustment as an AGC.
Once the Tx taps are locked in training, the Rx can accept transmitted
data through the channel and do its EQ operation which will in all
likelihood be non LTI.
One flow could use the bit stream convolution or PDA for the above and
just determine the equalization setting internal to the Rx and Tx.
Subsequently a data edge PDF convolution could be used to create a CDF
BER eye. (I think you are calling this statistically simulation) Some
folks are looking for 1e-14 BER or better an want to analyze a CDF BER
eye.
How would IBIS-AMI handle this scenario?
Thanks,
... Rich Mellitz, Intel
Other related posts:
