[ibis-macro] Re: AMI analog modeling
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 6 Jan 2011 08:33:25 -0800
Walter,
I know that the two approaches are mathematically equivalent.
Regarding:
> 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.
I guess you are missing the point. First a terminology clarification:
The output of the IBIS D_to_A converter is analog, even though its shape
is
a trapezoid. So the waveform that goes into my ISS subcircuit is
analog,
period. This is completely equivalent of the PWL source you use in your
SPICE netlist to illustrate the BIRD 122 analog Tx models. The output
of your
PWL source is analog, regardless that its shape is a trapezoid the same
exact way as the output of my D_to_A converters.
The input to my IBIS D_to_A converter is digital. But the inaccessible
"input" to the PWL source you are using is digital the same way, because
it is an "event" inside the simulator engine that triggers its edges.
So
we are still completely equivalent on this side also.
What is different is that in my case the simulator could apply all kinds
of bit patterns on the digital side of the D_to_A converter as a
stimulus
with a simple 1/0 representation, while in your case the PWL source
would
need a more cumbersome description of the waveform, or would need to be
replaced by other types of sources, but this is just a minor practical
difference. The electrical nature of both circuits are still identical.
Please note that my D_to_A converter is doing exactly the same as your
PWL source. So if the D_to_A converter in my BIRDs is a kludge, then
your PWL source is also a kludge by the same exact argument.
However, the real issue here is different. Scott is right, this is an
issue of boundary definitions. I have to ask the question, what is
"THE"
analog model? Is it a glorified Thevenin circuit, i.e. an ideal source
with a series "impedance" where the impedance is either an S-parameter
block or a discrete RC circuit? Or is it just the S-parameter block or
RC circuit without the ideal source?
The reason this question is the real issue here is because in BIRD 122
and your corresponding SPICE netlist you seem to indicate that "THE"
analog
model is a Thevenin equivalent, which includes the ideal PWL sources.
However, if the input to the analog model is the output of the Tx
GetWave
function, then the ideal source of this Thevenin equivalent analog model
becomes either the GetWave function itself, or a source which acts as a
high
impedance to zero impedance converter (buffer, or ideal Op-Amp) with or
without gain, but definitely without any wave shaping, that uses the
waveform
of the GetWave function as its input. In other words, the PWL source is
replace with something else.
This becomes a different circuit from what is described in BIRD 122 and
in your
SPICE netlist. I don't mind defining this circuit in the specification,
but
the point I am trying to make is that we need to define it and describe
when
and how it is used. We can't define the other circuit only and assume
that
people will automatically know how to do it this way. The differences
in
the ideal sources and their input signals are significant enough to
warrant
separate definitions and discussion for both approaches.
But for the sake of our ATM discussions, we cannot define one circuit
(BIRD 122)
and use another circuit (undefined in any of your documents so far) as
the
basis of criticism when discussing an alternative implementation (BIRD
116-118)
of that circuit that was defined (BIRD 122). This simply doesn't make
sense
and is not fair.
Thanks,
Arpad
========================================================================
========
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, January 06, 2011 8:43 AM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] AMI analog modeling
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:
