[ibis-macro] some AMI questions
- From: "Danil Kirsanov" <dkirsanov@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 4 Feb 2010 19:28:55 -0500
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: