[ibis-macro] AMI analog modeling
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 6 Jan 2011 01:08:40 -0800
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
Other related posts:
