[ibis-macro] Re: Table BIRD Comments - Re: Updated Out/InOut BIRD
- From: "Bob Ross" <bob@xxxxxxxxxxxxx>
- To: <wkatz@xxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 29 Mar 2011 10:45:13 -0700
All:
Attached are some comments on the latest version? of the draft
Table Bird by Walter.
To summarize, my main points are:
1. Like the notion that additional rules can be specified for
Reserved_Parameters.
2. Object to having the first column required to be a row-number
for Model_Specific or even sequential. Totally unnecessary. It is
contrary to existing applications.
3. Major - the .dll parenthesis grouping shown for rows is unsupported by
Section 10 rules.
4. The .ami format already defines the parenthesis group for the
EDA tool and the .ami author already knows the the .dll grouping
by knowing the processing algorithms.
---
Added Comment
5. Using Type with multiple meanings is overloading "Type".
Float works well for for all Reserved_Parameters cases.
For the example in Version 5.0, Integer and UI (and Tap) are numerically
identical and are subsets of Float. ForModel_Specific Tables, all entries
be of the same Type.
I would prefer Table columns to all be Float, as shown in the
Reserved_Parameters
examples, but the Reserved Parameter rules define the suggested
interpretation
for the EDA tool. The EDA tool will need to do any checking rules anyway
since the
source of information can be generated by the .dll.
I would choose either time or UI for the second column and disallow
the other interpretation. It may have been intended, but it was
never defined.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, March 24, 2011 12:12 PM
To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Updated Out/InOut BIRD
All,
After reviewing the comments made by Arpad and Ambrish, I came to the
conclusion that the thing that made the most sense is to require that the
first field in a row be a sequential integer row number, and that the rest
of the fields need to be of the specified Type (although special rules can
apply here for Reserved_Parameters).
Updated BIRD enclosed.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, March 24, 2011 2:43 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Updated Out/InOut BIRD
Glad to hear that. Attached is the Word
document with my text inserted (just so
that we all have the same version for the
next iteration).
Thanks,
Arpad
==========================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, March 24, 2011 1:35 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Updated Out/InOut BIRD
Arpad,
Your rewrite does not change the intent, and I agree with it.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, March 24, 2011 2:04 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Updated Out/InOut BIRD
Walter,
I changed the subject so that we can have two independent
threads on these two proposals. In this one I will comment
on the Out/InOut BIRD draft you wrote.
The 1st sentence of the 1st paragraph is a little misleading.
It could be interpreted like: in some cases the Init and
GetWave functions will not return anything in either of
the two AMI_parameters_out strings. Reading the 2nd sentence
it seems that what you are trying to say is that the returned
parameters may not all appear in one of the two AMI_parameters_out
strings, in other words there is a possibility that some of
the returned parameters may come out in the Init function's
"out" string, and some may come out in the GetWave function's
"out" string.
The thoughts captured in the 2nd sentence of the 2nd paragraph
are repeated in the 4th paragraph, so I would remove one or the
other.
The 3rd paragraph talks about Reserved Parameters, correct? If
so, I don't think it should be here at all, since the spec will
describe each reserved parameter individually (or collectively
in the area where they are described).
So based on all these observations, I would suggest the following
text in place of the four paragraphs you wrote:
"Algorithmic models may return (Usage Out) or (Usage InOut)
parameters in the AMI_parameters_out argument of either the
AMI_Init, or the AMI_GetWave functions, or both.
Each reserved parameter is described by the specification
in detail so that the model writer and the EDA tool knows
which function's AMI_parameters_out argument has to return
any given parameter, what the meaning and format of the
parameter is and how the EDA tool is expected to handle it.
The meaning of Model_Specific parameters cannot be defined
in a similar manner by the specification. However, EDA
tool vendors are encouraged to record the information
returned by Model_Specific parameters of (Usage Out) or
(Usage InOut) and provide mechanisms for the user to
display it in various ways."
I hope I didn't change your intensions with this text.
Thanks,
Arpad
============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, March 24, 2011 11:56 AM
To: IBIS-ATM
Subject: [ibis-macro] Updated Table and Out_InOut BIRDs
All,
I am enclosing updated versions of the Table and Out_InOut BIRDs, thanks to
Arpad Muranyi and Mike Steinberger for their comments.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 720.333-1107
Other related posts:
