[ibis-macro] Re: AMI analog modeling
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 6 Jan 2011 09:42:32 -0500 (EST)
Arpad,
Since ISS subckts are LTI, and since the interconnect between the SerDes
buffers are LTI, then the whole channel between the input to the analog
section of the Tx and the output of the analog section of the Rx (what we
have been calling the "High Impedance" interface point) is LTI and can be
represented by a transfer function and equivalently by an impulse
response. Given a stimulus that is modified by the equalization of the Tx
algorithmic (signal processing) section, then the waveform at the input to
the Rx algorithmic section can be determined by convolving the output of
the Tx GetWave with the impulse response of the channel. Because the
channel is made of LTI elements, then the waveform generated by this
method is identical to the waveform generated by doing a SPICE time domain
simulation using the ISS subckts concatenated with the interconnect
subckts in any way that the EDA tool chooses to do it. What IBIS 5.0 and
BIRD 120 say is that here is one way of generating this waveform, the EDA
tool can do it any way it wishes, as long as it gets the same answer.
Bottom line is that the ISS subckt does not care if it is driven by a step
response, or the waveform output of Tx GetWave, and therefore its inputs
are not digital, or an analog PWL form of digital, but in fact can be true
analog waveforms. This is why I consider using the D/A and A/D converter a
confusing Kludge.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, January 06, 2011 4:09 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] AMI analog modeling
Hello everyone,
In the last ATM teleconference, using my slides I was explaining how IBIS
ISS could be utilized under [External Model] for analog AMI modeling.
Walter made several (negative) comments regarding the usage of the D_to_A
converters as a stimulus to the Tx analog model. One of his comments was
that that the input to the analog model would (some times?) be the output
of the Tx GetWave function.
This raises several questions in my mind which I would like to bring up
for discussion now.
We have at least two basic ways of dealing with AMI simulations.
1) We can generate an Impulse Response (IR) for the channel and convolve
this with the various filters inside the AMI Init functions and/or in the
EDA tool between the GetWave functions, as described by the current
specification and the new flow BIRD (120).
The IR can be generated several different ways. It can be generated from
a normal time domain simulation where the stimulus is a step function.
Taking the derivative is the IR. If the analog model is perfectly LTI and
is made up from simple RC circuit elements or an S-parameter model, a time
domain simulation is not even necessary, the circuit could be solved
(converted) analytically to an IR. But no matter how we do it, the
impulse response is still a time domain waveform.
Our entire AMI specification reflects this time domain thinking.
We are talking about IR and convolutions.
2) Another way to do this is to use a transfer function of the channel and
multiply it with the FFT of the output of the Tx GetWave function. Since
S-parameters are basically nothing but a transfer function (and simple RC
circuits can also be easily converted to that), the transfer function
representation of the analog AMI buffer models can be used very easily for
direct multiplication with the FFT of the Tx GetWave output.
Walter's comment that the input to the Tx analog model could be the output
of the Tx GetWave function indicates that the analog models may be used in
the frequency domain in this scenario.
(It could probably be done in the time domain also, but that would defeat
the purpose of the AMI technology since it would be so slow).
So here comes the issue I would like to discuss.
None of our documentation mentions or describes the second method.
Everything we have written down do far goes by the first method. The
current spec, the new flow BIRD (120), the Opal document and its BIRD
version (BIRD 122) and the SPICE netlist Walter showed us for the BIRD 122
buffer models are all written with the time domain thinking.
Why are we documenting everything with the time domain approach, when in
practice it may be done differently?
I understand very well that we have a certain competitive secrecy in the
wording of the specification, using expressions "combined, for example by
convolution" to indicate that this is only one way of doing it and hinting
that we can implement things in different ways also.
However, the sticky point of this situation is when we are trying to
describe the analog models.
Walter's netlist contains two PWL sources to drive the Tx model.
These correspond to the entire left side of the "Tx Analog Buffer
Equivalent Circuit" on pg. 5 (and also pg. 3) of BIRD 122 (the triangles,
the summation boxes and the DC source level shifters).
In my BIRDs the same functionality is achieved by the IBIS D_to_A
converters. BIRD 122 doesn't define what the input waveform is to the
triangle symbols. However, since Walter's equivalent SPICE netlist uses a
PWL source for all those symbols in which the edges are triggered by an
internal event inside the simulator, I would conclude that the input in
Walter's circuits can be thought of being a digital edge or bit stream.
This is in perfect agreement with my use of the D_to_A converters as the
input to my ISS subcircuit.
So Walter's comment that the usage of anything digital is nonsense in
SERDES work is then equally nonsensical for BIRD 122 and its accompanying
SPICE netlist.
On the other hand, if the Tx analog models are supposed to be used so that
their input may be the output of Tx GetWave (presumably in frequency
domain), then my question is what is the point where the Tx model in BIRD
122 or its accompanying SPICE netlist acts as the input? Common sense
would tell me that the input in this usage would be at the left side of
Rs_H and Rs_L, or ports 1 and 3 of the S-parameter version. Since the ISS
subcircuit of my BIRDs begin at the same point (recall, the D_to_A
converter is outside of the ISS subcircuit), I would think that just as
the triangles, summation boxes and DC level shifters of BIRD 122 would be
eliminated from the circuit of BIRD 122, the D_to_A converters could also
be eliminated the same way from my BIRDs in this usage model.
One way of solving these problems would be to not include the stimulus
sources in the analog model. From this perspective, my BIRDs are better,
because the D_to_A converters (the stimulus
sources) are not included in the ISS subcircuit (the analog model).
However, none of this is documented in the spec or BIRD 122. My BIRDs
just faithfully reproduce the same capabilities which are documented in
BIRD 122 (using the time domain thinking). But, the D_to_A converters of
my BIRDs can be left out of the simulations the same way as the stimulus
elements would be left out from Walter's SPICE netlist or BIRD 122 for the
2nd, frequency domain approach. So I see a perfect equivalence between my
BIRDs and BIRD 122 in this regard.
To summarize, I don't see any difference in the usage of the IBIS D_to_A
converters in my BIRDs and the PWL sources in Walter's SPICE netlist or
BIRD 122. The problem I see is that we document the analog models only in
the time domain thinking while we want them to be usable in the frequency
domain as well without mentioning the differences between the two
approaches and the corresponding differences that the analog models would
have.
I feel that this dual usage of the analog models should be documented
somewhere in the AMI specification. Most of our debates and
misunderstandings would go away if we did that. I think that the flow
BIRD (120) may be a good place to mention these thoughts, or we could
address this in another BIRD which deals with how to generate the channel
characterization IR, which is on row 35 in our Task List:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20101026/arpadmurany
i/IBISv5.0%20AMI%20specification%20BIRD%20task%20list/IBIS50AMI_TaskList
_2010_10_26.pdf
Questions, comments welcome.
Arpad
========================================================================
==
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
