[ibis-macro] Re: Last draft of the AMI BIRD before submission
- From: "C. Kumar" <ckumar@xxxxxxxxxxx>
- To: <msteinb@xxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>
- Date: Wed, 10 Oct 2007 15:25:13 -0400
1. I concur with Mike especially on the points of pole-zero filters. You should
be able to include in an AMI model , but the parameters have to be user defined
2. cascaded blocks can be encased in a single ami block
3. yes, cross talk cancellers can be designed using the input impulse response
matrix. However if there are designs which depend upon using live neighbor
signals for xtalk cancellation that is not supported in the present BIRD
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Wednesday, October 10, 2007 3:15 PM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: IBIS-ATM
Subject: [ibis-macro] Re: Last draft of the AMI BIRD before submission
Arpad-
I have to disagree with some (well, actually most) of your points.
1. The BIRD allows a model developer to define whatever model-specific
parameters they want. Thus,
the BIRD _does_ allow the model developer to define filters in terms of
poles and zeros. Poles and
zeros are simply parameters, and can be passed into the model like any
other parameters. While it is
true that the proposed standard defines modeling in the time domain, it
is entirely straightforward
to translate poles and zeros into a time domain model. The bilinear Z
transform is the classic
approach to this; it's been around for 40 years or more.
2. The models we've discussed to date have combined multiple functions
into a single model. As an
example, a receiver model with a peaking filter / DFE equalizer / CDR
loop would be expected to
define separate parameters for each block, then employ a single
algorithmic model to for the
receiver. The independent parameter sets would allow users to control
each block independently.
In point of fact, there is nothing in the proposed standard that would
prevent multiple algorithmic
models from being cascaded directly. The structure of the function
arguments makes this very easy to
do. There is therefore no reason multiple blocks HAVE to be combined
into a single AMI model.
Take, for example, a link in which an equalizer such as a Maxim part is
being used at the edge of
one PCB in a multi-PCB interface. The transmitter would have one AMI
model, the repeater a
second AMI model, and the receiver a third AMI model. All three models
could readily be included in
the same simulation and analysis, whereas it would make no sense to try
to combine the repeater and
receiver into one model, especially since the models would be coming
from different vendors.
3. I think your summary of my remarks about crosstalk cancellation is
inaccurate in a way which
leaves entirely the wrong impression. A much better summary would be to
say that the proposed
standard can support the modeling of crosstalk cancelers as seen by
system designers, but not as
seen by crosstalk canceler developers. Putting the two points I made in
reverse order:
a. It is entirely straightforward to model _the_ _effects_ _of_
crosstalk cancellation on the
link BER. As it happens, I have extensive practical experience with
interference cancelers
(including several patents), and I know for a fact that a crosstalk
canceler can be modeled
quite accurately in an LTI analysis such as would be possible in
AMI_Init(). In contrast to a SerDes
receiver (which, frankly, none of us understand well enough yet), a
time domain simulation is not
needed to determine the steady state response of a crosstalk canceler.
b. It is true that the designer of a crosstalk canceler would want
to simulate their design in
the time domain to verify their algorithm or circuit design, and the
proposed standard does not
directly support such a simulation.
Your comments comparing AMI and AMS entirely miss the point of the
standard. The proposed AMI
standard defines a _software_ _interface_ whereas AMS is a _software_
_language_ (well, two
actually). These are two orthogonal concepts.
-A software _language_ guarantees that code written by a single
software developer can be
compiled and run.
-A software _interface_ guarantees that code written by two
different software developers can
work together.
For example, if someone at TI were to write an AMS model and someone at
Mentor were to write another
AMS model, there would be no reason to expect that the two models could
be combined into a single
simulation and produce meaningful results. It would actually be
surprising if such a simulation ran
to completion.
Conversely, if someone at IBM were to write a model in C++ conforming
to the AMI software interface
and someone at Mentor were to write a model in (one of the dialects of)
AMS and then wrote a wrapper
around it that made that model conform to the AMI software interface,
those two models could be run
in the same simulation and would be expected to produce meaningful
results.
Not only could an AMI wrapper be written around a model written in AMS,
but wrappers could be
written around models written in MatLab, Octave, Perl Data Language,
and Python pyNum.
Finally, I assert that the AMI eval kits that have been published to
date have every bit as much
functionality as your AMS code examples, so again I have to take
exception to your comments.
Respectfully yours,
Mike Steinberger
Muranyi, Arpad wrote:
Mike,
Thank you for the detailed answers.
Huang,
I would like to add a few things to Mike's reply.
1) No, this BIRD does not allow you to define filters in
terms of poles and zeros. This has been brought up in the
discussions, but it was decided to do everything in the
time domain (at least for now).
2) Reading between the lines of your question it seems as
if the reason you are asking for multiple AMI keywords in
a [Model] is because you may want to cascade them as if
they were multiple blocks in series in the buffer. Is this
correct? (The reason I feel that this is what you may be
interested in is because the associated question about
sequence ordering).
We have discussed multiple AMI keywords in a [Model] but
not in this context. It was more of a "model selector"
idea to use one or the other. Your question seems to
want to use them all together. In that case couldn't you
just include all of the blocks in one AMI model?
3) I think Mike said it all, it can't be done (at least
for now).
In general, we are aware of some of these limitations, and
these can all be addressed in the future. We all have to
start somewhere and what we have in the BIRD is a start, not
necessarily a complete solution for all possible needs.
On the other hand, all of the topics you mentioned COULD
be modeled using the *-AMS extensions of IBIS TODAY. I
have shown some very basic examples (again starters) in
two of my presentations (both of which have working code
examples):
http://www.bmas-conf.org/2006/4.7_presentation.pdf
http://www.bmas-conf.org/2006/4.7_project.zip
http://www.vhdl.org/pub/ibis/summits/feb07/muranyi.pdf
http://www.vhdl.org/pub/ibis/summits/feb07/StatEye_project.zip
Even though these code examples are very basic and do not
include the features you are asking for, the beauty of
using the *-AMS language(s) is that you don't have to
wait for a BIRD or a specification to be finished, since
the *-AMS languages are already established languages,
and they have been supported by IBIS and some tools
for several years now.
As far a coding goes, you would pretty much end up writing
the same amount of code whether you do it as the AMI BIRD
suggests or in *-AMS. You may only need to use a different
language to write your code.
I hope this helps,
Arpad
=========================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Wednesday, October 10, 2007 7:53 AM
To: huangchunxing@xxxxxxxxxx
Cc: IBIS-ATM; Muranyi, Arpad
Subject: [ibis-macro] Re: Last draft of the AMI BIRD before
submission
Huang-
Good questions, as usual.
As a general statement, one must view the algorithmic modeling
standard as a critical part of a total solution, but not a complete solution by
itself. I've inserted my opinion/understanding below. Other contributors may
have a different point of view.
Thanks for the questions.
Mike Steinberger
Huang chunxing wrote:
Hi Arpad and all,
I have some comments here.
1. As for the "Model Specific Parameters", it has the
syntax "Type Tap" for Linear feedforward equalization or emphasis.
(Model_Specific | Required
heading
(txtaps
(-2 (Usage Inout)(Type Tap) (Format Range 0.1
-0.1 0.2)(Default 0.1)
(Description "Second Precursor Tap"))
(-1 (Usage Inout)(Type Tap) (Format Range 0.2
-0.4 0.4)(Default 0.2)
(Description "First Precursor Tap"))
(0 (Usage Inout)(Type Tap) (Format Range 1 -1
2)(Default 1)
(Description "Main Tap"))
(1 (Usage Inout)(Type Tap) (Format Range 0.2
-0.4 0.4)(Default2 0.2)
(Description "First Post cursor Tap"))
(2 (Usage Inout)(Type Tap) (Format Range 0.1
-0.1 0.2)(Default 0.1)
(Description "Second Post cursor Tap"))
) | End txtaps
AMI Bird has clearly showed that parameter could
support parameter for LFE. Instead of LFE, some SERDES would use peaking
filter(Continous Time Equalization) as emphasis at transmitter or equalization
at receiver. I believe peaking filter is also a common technique for
compensating channel loss. Peaking filter is analog filter and change its
frequency response by adjusting its poles and zeros.Its parameter may like this,
Zero: 0.1/UI 0.2/UI
Pole: 0.6/UI 0.5/UI
Does BIRD have any method to define specific parameter
for this filter?
It is possible for a model developer to parameterize a peaking
filter in any way they choose; however, the BIRD does not suggest any one
method over another. When compared with FIR equalization structures, the
difference is that whereas the degrees of freedom offered by an FIR structure
always have the same structure (in the sense that there are independent tap
weights), the ways in which the poles and zeros of a peaking filter can be
manipulated depend very much on the details of the circuit design. One can't
simply move the poles and zeros anywhere one wants. What I've seen so far has
been peaking filters which offered a fixed number of configurations. Each
configuration had a set of poles and zeros, but the way in which the poles and
zeros varied from one configuration to the next was not necessarily obvious.
This affects the interaction between the model and the
execution environment it runs in, in the sense that whereas the execution
environment can have a relatively simple and effective optimization routine for
FIR equalizers because their degrees of freedom follow a regular and well
defined pattern, the only general approach for peaking filters that I know of
is to try each and every configuration and then choose the one which gave the
best results. I have algorithms for designing rational transfer functions, and
I've used those algorithms to define the requirements for peaking filters;
however, those algorithms are only applicable before the circuit has been
designed.
It's perhaps a minor point, but I've seen LFE structures that
were not FIR. Unfortunately, they were shown to me under NDA (non-disclosure
agreement), so I can't provide any more details. What we've defined in the BIRD
truly does assume FIR.
2、As for Keywords [Algorithmic Model], Bird metioned,
| Usage Rules: The [Algorithmic Model] keyword must be
positioned within a
| [Model] section and it may appear only
once for each [Model]
| keyword in a .ibs file. It is not
permitted under the
| [Submodel] keyword.
Is it possible that Algorithmic Model appears more than
nonce in Model keyword? I think one Algorithmic Model for RX model may be not
enough. If we can use more than one Algorithimic Models here, how can EDA
simulator know the calling sequence?
I know very little about how IBIS is used in general; however,
it will often be the case that several IBIS files are used in a single analysis
or simulation. For example, there can be several circuit blocks in a system
that are to be modeled with algorithmic models, and each such circuit block
will have an IBIS file associated with it. There is no reason why a single IBIS
file has to be applicable to two different circuit blocks. Rather, the two
circuit blocks may be supplied by different vendors, and so would have to have
different IBIS files. All that is required (and all that we've attempted to
achieve) is that a single IBIS file can contain enough information to fully
describe a single circuit block.
As regards calling sequence, that is an interesting problem
which is to be solved by the execution environment based on the circuit
topology that has been defined and the simulations/analyses that are to be
performed. The only constraint is that AMI_Init() is called before
AMI_GetWave() is called before AMI_Close().
3、As for AMI_GetWave function, one wave input may be
not enough also.
| 3.2 AMI_GetWave
| ===============
|
| 3.2.1 Declaration
| =================
|
| long AMI_GetWave (double *wave,
| long wave_size,
| double *clock_times,
| char **AMI_parameters_out,
| void *AMI_memory);
Like crosstalk cancellation equipment, it needs not
only receiver waveform, but also aggressor waveform. AMI_GetWave function
contains only one wave input parameter. In such case, it may be difficult to
fulfill this kind of modeling work.
You're quite right that the proposed standard does not directly
support modeling crosstalk cancellation equipment explicitly in the time
domain. Similarly, the proposed standard does not directly support modeling
clock forwarded interfaces (e.g., PCI-X, HT3.0) explicitly in the time domain.
In both cases, the problem, as you've pointed out, and that there is only a
single input time domain waveform whereas an explicit time domain model would
require two or more. Thus, for example, the proposed standard would not enable
the designer of a crosstalk canceler to model the internal behavior of the
canceler in the time domain.
It is, however, possible to model crosstalk cancellation in the
AMI_Init() function, and to output the resulting impulse response for each
aggressor. These impulse responses could then be incorporated into a
semi-analytical BER estimation. There are some critical details to this
procedure that are not covered in the BIRD, and there are several possible
choices for the implementation of the BER estimator. All that the BIRD assures
us is that a model which includes _the_ _effects_ _of_ crosstalk cancellation
will run in anyone's execution environment, and an execution environment which
implements the right analyses will be able to accurately model _the_ _effects_
_of_ crosstalk cancellation. What is not guaranteed is that any execution
environment will accurately model the effects of crosstalk cancellation. (-;
Thanks!
Huang
HUAWEI TECHNOLOGIES CO.,LTD.
Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: +86 755 28976426
Fax: +86 755 28976758
E-mail: huangchunxing@xxxxxxxxxx
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential
information from HUAWEI, which
is intended only for the person or entity whose address
is listed above. Any use of the
information contained herein in any way (including, but
not limited to, total or partial
disclosure, reproduction, or dissemination) by persons
other than the intended
recipient(s) is prohibited. If you receive this e-mail
in error, please notify the sender by
phone or email immediately and delete it!
Other related posts:
