[ibis-macro] Re: I think I can now do a better job of explaining the BIRD 147 way of communicating ...
- From: Walter Katz <wkatz@xxxxxxxxxx>
- To: <ambrishv@xxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 30 Apr 2014 19:47:22 -0400 (EDT)
Ambrish,
The propose of this e-mail was to understand the difference between your
approach and my approach. The example .ami files in this e-mail is
essentially you approach. I move the Reserved Parameters in the .bci file
into the Rx .ami file. The Model Specific parameters in the .bci file
describes the "black box" communication between the Rx and the Tx. The
contents of this black box is the key element that has to be agreed upon
for a .bci standard since both the Tx and Rx DLL need to be able to read
and write it. You define this black box in the .bci file, I just said the
contents of the black box need to defined by the protocol and just put it
in the Backchannel Message. I will remind you that these AMI models are
not intended to be an alternative implementation of your proposal, just a
better way of describing your proposal.
As to who and how protocols are developed, published and approved, that is
a problem. In my opinion, BIRD 147 should not be approved until there is a
PCIe Gen3 and 802.3 protocol that gets approved at the same time.
As for private training, a Tx model writer and an Rx model writer can do
anything they want as long as there is a mechanism in the standard for the
EDA tool can move their agreed upon message back and forth between the Tx
and Rx.
No I am not abandoning my belief that a Tx should be protocol agnostic. It
is clear that a principle point of BIRD 147 is that communications between
the Tx and Rx are a black box and therefor the Tx cannot be protocol
agnostic. Note that the first line of my e-mail was "I think I can now do
a better job of explaining the BIRD 147 way of communicating between the
Tx and Rx."
As to the .ami files that I presented last week, see my comments below:
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Wednesday, April 30, 2014 5:08 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: I think I can now do a better job of explaining
the BIRD 147 way of communicating ...
Hi Walter,
Could you please help clarify these issues with your proposal:
1) You mention in the description for 'Backchannel_Message' 'The
contents of this message is agreed upon in the 802.3KR protocol.' Can you
elaborate how and who agrees to this content - with a) published protocols
- and b) with 'private' protocols that the designers of Tx and Rx have
agreed upon.
2) It is not clear if this method supports multiple protocols in the
Tx and Rx AMI Models - can you please elaborate on that?
3) With the 'Backchannel_Protocol' parameter in the 802.3KR_Tx file
below - are you now abandoning your 'Protocol agnostic' Tx AMI model
concept?
I also have a question about the .ami files that you discussed in the ATM
last couple of weeks:
4) In PCIe3_Rx.ami, you have a Reserved Parameter
'Tx_Tap_Coefficient_Ranges', Usage In, where you mention that the EDA tool
sets this after reading the 'Tx_Tap_Coefficient_Ranges'. This is not a
dynamic parameter (being reserved - and set by the tool once). How does a
Tx help the Rx in reducing the range dynamically, thereby 'honing' in on a
coefficient value over the backchannel process.
WMK> This is equivalent to BIRD 147_Draft8 1.5.2 i) on page 11:
Example for the string created by the Tx AMI_Init and a brief description
are included below:
i) "(BCI (taps (-1 -0.25 0)(0 1)(1 -0.3 0.3)))" : The
main tap is specified by the tap number 0 with a value of 1. The pre tap
(-1) cannot be lower than -0.25 and higher than 0 (-0.25 <= value <= 0).
The post tap (1) can have a value between -0.3 and 0.3 (-0.3 <= value <=
0.3).
You have chosen to overload the .bci Model specific parameter taps to
sometime convey tap values, sometimes tap limits and sometimes tap
increments. I chose to create a specific Tx Reserved Parameter in table
format to publish the limits of the tap coefficients, and a separate Tx
reserved parameter to publish the limits of the tap indexes. The Tx never
has a need to reduce the range, it simply publishes what the limits are.
5) Could you explain how 'Tx_Tap_Increment_Parameter' and
'Rx_Tap_Increment_Parameter' work in the 802.3KR_Tx.ami and 802.3KR_Rx.ami
respectively?
WMK> The point here is that all a Tx needs is a model specific tap
increment parameter, and it can be any name the Tx model maker chooses.
Similarly the Rx can have a parameters for incrementing the Tx taps. The
'Tx_Tap_Increment_Parameter' and 'Rx_Tap_Increment_Parameter' are the
reserved parameters that the Tx and Rx publish the name of their Model
Specific parameters that are used to increment and decrement the Tx taps.
Rx GetWave in **parameters_out outputs the Tx tap increments in its model
specific parameter of the name specified by 'Rx_Tap_Increment_Parameter'.
The EDA tool know to populate the Tx Model specific tap parameter with the
name specified by the value of 'Tx_Tap_Increment_Parameter'. This is a
little more work for the EDA tool then just copying the Rx GetWave output
string and putting it into the Tx GetWave input string, this is the little
bit of overhead the EDA tool needs to do because the communication between
the Rx and Tx is not a black box.
6) In 802.3KR_Rx.ami in the Model_Specific parameters, you have a
parameter 'This_Tap_Increment' which says 'EDA tool sets
Tx_Tap_Increment_Parameter to/from these values'. Could you please explain
how the EDA tool gets access to the Model_Specific parameters and know
what to do with them?
WMK> Explained in the answer to 5) above. The Rx Reserved parameter
'Rx_Tap_Increment_Parameter', and the Tx reserved parameter publish to the
EDA tool the Rx and Tx model specific parameters that contain the tap
increment information that needs to be passed back and forth between the
Tx and Rx. There are similar parameters that publish the Rx and Tx model
specific parameters that contain the Tap coefficients and tap indexes.
Thanks,
Ambrish.
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, April 29, 2014 11:03 PM
To: IBIS-ATM
Subject: [ibis-macro] I think I can now do a better job of explaining the
BIRD 147 way of communicating ...
All,
I think I can now do a better job of explaining the BIRD 147 way of
communicating between the Tx and Rx. One does not need a .bci file for
this as suggested in the following example Tx. One does need a parameter
that advertises the Backchannel_Protocol "802.KR" and a placeholder to
contain messages between the Tx and Rx AMI_Init and AMI_GetWave functions.
(802.3KR_Tx
(Description "802.3KR transmitter model")
|| Revision 1.0 -- 4/15/2014
(Reserved_Parameters
(AMI_Version (Usage Info) (Type String) (Value "7.0")
(Description "AMI Version 7.0."))
(Ignore_Bits (Usage Info) (Type Integer) (Value 3)
(Description "Ignore three bits to fill up tapped delay line."))
(Max_Init_Aggressors (Usage Info) (Type Integer) (Value 25)
(Description "Number of aggressors is actually unlimited."))
(Init_Returns_Impulse (Usage Info) (Type Boolean) (Value True)
(Description "Impulse response is returned."))
(GetWave_Exists (Usage Info) (Type Boolean) (Value True)
(Description "GetWave is well and truly provided in the
module."))
| New Reserved Parameters
(Backchannel_Protocol (Value "802.KR")(Type String)(Usage In)
(Description "This model supports the 802.3KR protocol"))
(Backchannel_Message (Value "NA")(Type String)(Usage InOut)
(Description "The contents of this message is agreed upon in the
802.3KR protocol.
The Tx AMI_Init call may out put this message which
gets passed
Into the Rx AMI_Init input. The output of Rx
AMI_Init input may
output a message in as agreed upon in the 802.3KR
protocol. This
message can be input to the Tx AMI_Init function or
calls to Tx
AMI_GetWave, and so forth."))
)
| End Reserved_Parameters
(Model Specific
| .
) | End Model_Specific
)
Similarly, the Rx model might look like the following. This is equivalent
to having a .bci file as in BIRD 147, both the Tx and Rx point to the same
protocol name (not a file as in BIRD 147), and the training information is
all in the Backchannel_Message, and this message is defined in the
(Backchannel_Protocol "802.KR") specification. I am not trying to do BIRD
147 in a different way just to be different, I think that this example
does a better job of explaining how BIRD 147 works. The key in BIRD 147 is
that both Tx and Rx models need to agree on the contents of the
Backchannel_Message, and this message can truly be a black box.
Ultimately, the choice is do we proceed with the statement that all Tx's
are essentially the same and they have Tap indexes and/or Tap coefficients
and therefore can be protocol agnostic, requiring that the EDA tool
translate what the Rx wants the Tx to do into terms the Tx understands, or
does the DLL have to agree to the contents of a Message that gets passed
back and forth between the DLL's.
(802.3KR_Rx
(Description "PCIe3 receiver model")
|| Revision 1.0 -- 3/15/2014
(Reserved_Parameters
(AMI_Version (Usage Info) (String Integer) (Value "7.0")
(Description "AMI Version 7.0."))
(Ignore_Bits (Usage Info) (Type Integer) (Value 10000)
(Description "DFE may take a 10,000 bits to settle."))
(Max_Init_Aggressors (Usage Info) (Type Integer) (Value 25)
(Description "Number of aggressors is actually unlimited."))
(Init_Returns_Impulse (Usage Info) (Type Boolean) (Value False)
(Description "Impulse response is not returned, statistical
simulation is not supported."))
(GetWave_Exists (Usage Info) (Type Boolean) (Value True)
(Description "GetWave is well and truly provided in the
module."))
(Rx_Receiver_Sensitivity (Usage Info)(Value 0.20) (Type Float)
(Description "The receiver sensitivity."))
| New Reserved Parameters
(Backchannel_Protocol (Value "802.KR")(Type String)(Usage In)
(Description "This model supports the 802.3KR protocol"))
(Backchannel_Message (Value "NA")(Type String)(Usage InOut)
(Description "The contents of this message is agreed upon in the
802.3KR protocol.
The Tx AMI_Init call may out put this message which
gets passed
Into the Rx AMI_Init input. The output of Rx
AMI_Init input may
output a message in as agreed upon in the 802.3KR
protocol. This
message can be input to the Tx AMI_Init function or
calls to Tx
AMI_GetWave, and so forth."))
(Training (Usage InOut) (Type Boolean) (List True False)
(Description "As In, True tells Rx GetWave to continue training
as Out, False Rx GetWave tells EDA tool to stop
training"))
(Max_Training_Bits (Usage Info) (Type Integer) (Value 100000)
(Description "Stop training after 100,000 bits."))
(Pre_Amble (Description "Bit pattern to start training.")
(Pattern_Type (Usage Info)(Value "b") (Type String)
(Description "Pattern is string of 0's and 1's."))
(Bit_Pattern (Usage Info)(Value "0000000001111111111") (Type
String)
(Description "Pre-amble pattern")))
(Training_Pattern (Description "Training pattern.")
(Pattern_Type (Usage Info)(Value "LSFR") (Type String)
(Description "Pattern is LSFT."))
(LSFR_Seed (Usage Info)(Value "10110011101") (Type String)
(Description "LSFR Seed")))
(LSFR_Taps (Usage Info)(Description "LSFR Taps")(Type Integer)
(Table
(Labels "First tap" "Second tap" "Thirs tap")
(1 9 11))))
(Post_Amble (Description "Bit pattern to end training.")
(Pattern_Type (Usage Info)(Value "b") (Type String)
(Description "Pattern is string of 0's and 1's."))
(Bit_Pattern (Usage Info)(Value "000000000000000000000") (Type
String)
(Description "Post-amble pattern")))
) | End Reserved_Parameters
(Model_Specific
| .
) | End Model_Specific
)
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
