[ibis-macro] Re: I think I can now do a better job of explaining the BIRD 147 way of communicating ...
- From: Ambrish Varma <ambrishv@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 30 Apr 2014 14:07:31 -0700
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.
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?
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?
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<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
