Thanks all your replies. It takes me some time to look at them, but worth it. :
)
I have no more questions on AMI BIRD. Here are some further technical prolbems
here.
1. I noticed that AMI BIRD support user defined parameters. If parameters for
peaking filter are user defined, how can EDA tool recognize it and correctly
pass them to dll function. Yes, peaking filter has limited number of setting.
But I have no idea of how can EDA tool to distinguish pole values from other
user-defined value and zero values. Also same thing for recognizing zero value.
2. I previously thought that one AMI model could support only one DLL model.
As for cascade blocks in a single AMI model, I want to make sure that cascade
blocks may like this example.
[Algorithmic Model]
Executable Windows_VisualStudio_32 rx_FFE.dll rx_FFE_params.ami
Executable Windows_VisualStudio_32 rx_DFE.dll rx_DFE_params.ami
Executable Windows_VisualStudio_32 rx_CDR.dll rx_CDR_params.ami
[End Algorithmic Model
3. As for crosstalk cancellationk , I don't know method based on impulse
response. Someone here could show me some papers on this? I only know crosstalk
cancellation control method based on energy minimization and PDF minimization.
Here is one paper for all to refer to.
Overcoming Signal Integrity Issues with Wideband Crosstalk Cancellation
Technology
Michael G. Vrazel, Quellan, Inc.
Presented at Designcon2006
Regards,
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!
----- Original Message -----
From: C. Kumar
To: msteinb@xxxxxxxxxx ; Arpad_Muranyi@xxxxxxxxxx
Cc: IBIS-ATM
Sent: Thursday, October 11, 2007 3:25 AM
Subject: [ibis-macro] Re: Last draft of the AMI BIRD before submission
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!
Attachment:
outlook_huawei_logo_en.jpg
Description: JPEG image
Attachment:
ATT3749817.jpg
Description: JPEG image
