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

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!