[ibis-macro] Re: some AMI questions
- From: "Danil Kirsanov" <dkirsanov@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 5 Feb 2010 15:47:34 -0500
Hi Walter,
Thanks a lot for your comments. While I agree with most of them, I am still
concerned about Limit and Scale.
In particular, here is how they are defined in a spec:
| Tap parameter names Limit and Scale are used to adjust Tap
values.
| A Tap may have a Scale, a Limit, or neither. If Scale is
specified
| then the sum of the absolute values of all of the Taps must
equal Scale.
| If Limit is specified then the Taps are scaled by
| Limit/(maximum value of the absolute values of all of the
Taps).
| Scale and Limit must be Usage Info, Type Tap, and
Allowed-Value Value)
While I understand that having these constraints might be useful for some
application, I wonder how general they are and whether these names should be
standardized in AMI spec. I mean, scaling and limiting can always be done on
the model side, so Limit and Scale could be some regular model-specific
parameters; there is no need for the EDA tool to know what they mean.
If possible, could you give me an example when Limit and Scale have to be
known and/or enforced by the EDA tool before the taps are passed to the
model? Something that cannot be easily implemented on the model side?
Thank you,
Danil
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, February 05, 2010 2:20 AM
To: dkirsanov@xxxxxxxxxx
Subject: RE: [ibis-macro] some AMI questions
Danil,
Thank you very much for your comments. My comments below.
1. Scale and Limit are meant to simplify the user interface when
specifying tap values of Tx FIR filters. Often, the sum of the absolute
values of the tap coefficients cannot be greater then one, or that value of
the largest tap cannot be greater than one.
2. Array is not added for backward compatibility, but at the request of
IBM to support the method that HSSCDR operates. HSSCDR uses a single DLL for
the complete series of IBM SerDes models. This single DLL supports models
with 2, 3, 4, . taps. Instead of passing the taps as individual parameters,
the IBM AMI models require that the values of the taps be passed into the
DLL as a list of values of a single tap parameter. The Cadence interface to
the IBM AMI models supported this interface, and SiSoft followed suite.
3. I agree that the Rx Clock_Recovery parameters (as well as the new Tx
Jitter parameters (Tx_Rj and Tx_Dj) need further discussion. I will be
recommending next Tuesday, that these parameters be removed from the current
BIRD to expedite the cleanup of the existing AMI specifications. As soon as
we get the current AMI BIRD to the Open Forum, we should start discussion on
a BIRD that would include a more complete set of Tx and Rx jitter parameters
including other parameterized jitter contributions such as Sj and
Sj_Frequency. I will propose additional parameters to deal with differential
analog characteristics of both Tx and Rx buffers.
4. I see no compelling reason to deprecate Range.
5. Out parameters should not be passed to the DLL. This should be
explained clearly.
6. If Type is integer, it would be an error to specify numbers like .5,
and 1.0. I believe the revised BIRD does say that if Default is specified,
then it must have a legal vaue with respect to Type, and Allowed Values.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Danil Kirsanov
Sent: Thursday, February 04, 2010 7:29 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] some AMI questions
Hello everybody,
I was going one more time through the proposed BIRD(01/26 edition) and
realized that I still have a couple of questions. I am sorry if some of them
were already mentioned in the previous discussions (I did my best to check
them, but I could miss something).
1. I doubt that we should put the tap optimization parameters (Scale,
Limit) in AMI spec, unless we exactly define what "optimization procedure"
does and require that it is supported by all simulators. Otherwise there
will be a lot of confusion among the model writers and the EDA vendors. I
propose at this point keeping the choice of the optimization procedure (and
optimization parameters) on the EDA side or model side. In both cases I do
not see the necessity for standardizing the names of the optimization
parameters, because they will be either EDA- or vendor- specific anyway.
2. Do I understand correctly, that the only reason for the alternative
Array definition (page 17, (Array (Usage Info)(Type Boolean) (Value True)))
is to provide backward comparability? If this is the only reason, we might
want to state explicitly that the first definition is "correct" and (.(Value
True)) trick is done for compatibility only -- to discourage future model
developers of using the "wrong" Array definition. We can even say that this
form of the Array might not be allowed in the future versions of AMI spec.
3. I believe we need further discuss the usage of Rx_Clock_Recovery.
parameters, because I can see several possible questions. If
Rx_Clock_Recovery_Mean depends on the length of the channel, how can it be
of the type "Info"? If Rx_Clock_Recovery. parameters are computed at every
evaluation of AMI_GetWave, is the result cumulative or EDA has to combine
them together? Etc. - it seems like a topic for a separate discussion, so I
do not want to start it in this e-mail.
4. If I understand correctly, the only difference between Increment
and Range data types is that Increment has non-zero step. Maybe, we could
merge them together into a single type? If we allow zero step in Increment,
it would cover the Range.
5. On page 8, there is a line "Parameters defined as Usage Info are
NEVER presented to algorithmic models via the AMI_Init call". Why do we need
such a requirement only for "Info" parameters? Why "Out" parameter can be
presented to the model but "Info" parameter can't?
6. For data types with <typ>, does <typ> conflict with Default? For
example, can you write (coeff (Usage InOut)(Range 0.0 -1.0 1.0)(Type
Integer)(Default 0.5)) and what would it mean? Is there a case where we
would like to specify <typ> instead of (Default)?
Thank you very much for your time and effort,
Danil
Other related posts:
