[ibis-macro] Re: Last draft of the AMI BIRD before submission

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: huangchunxing@xxxxxxxxxx
  • Date: Wed, 10 Oct 2007 09:53:07 -0500

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. huawei_logo
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 -----
Sent: Wednesday, October 10, 2007 4:53 AM
Subject: [ibis-macro] Last draft of the AMI BIRD before submission

Per our meeting discussions, here is the revised BIRD
once again with the changes that we decided on in the
meeting.  I incorporated the changes on the Tap
syntax distributed this morning.

Please review the document to make sure I didn't
make any other mistakes and send me your comments
no later than tomorrow.  I will give Mike Mirmak
the green light to officially submit this BIRD at
the end of the day tomorrow.

Thanks to all who contributed to this effort,

Arpad
======================================================

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 10-2007