[ibis-editorial] Re: IBIS-AMI - Unifying the terminology
- From: "Bob Ross" <bob@xxxxxxxxxxxxx>
- To: <ibis-editorial@xxxxxxxxxxxxx>
- Date: Thu, 5 Apr 2012 21:50:40 -0700
Arpad:
I think we are in agreement. In Section 10, leaf is used only to describe
parameters
whereas in Section 10A, "leaves" describe the reserved words that
are needed to convert a "branch" into a parameter. The Section 10
application of "leaf" for the BNF is clear and should be retained.
To avoid confusion, I would prefer not using "leaf" in Section 10A as
applied to
the .ami file. You are correct that for a branch to become an AMI
parameter for the parameter definition (.ami) file, there must
exist several "leaves". However Format <data_format> has
a special case syntactical variation when the <data_format> "leaf"
is Table. Unlike the other "leaves", its arguments are bounded
by one or more rows of (..... ) lines. Furthermore the first row can begin
with an optional leaf called Labels.
Therefore we have a Labels "leaf" among the row(s) of data that is
scoped by the Table "leaf" - a contradictory and confusing
situation if we try to apply the leaf terminology within Section 10A,
and in contrast to using leaf in Section 10.
Rather than get bogged down with such distinctions,
I would just minimize or eliminate the leaf terminology
entirely for section 10A and just use reserved words or
some other agreed upon terminology. That way we do
not collide with and become confused with the Section 10 leaf
terminology as applied to the BNF rules for EDA platform to/from
the executable model (parameter_name value_list) transfers.
Bob
-----Original Message-----
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, April 05, 2012 12:55 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: IBIS-AMI - Unifying the terminology
Bob,
Nice list.
I want to comment on the BNF, because this came up in an
internal discussion here at Mentor. The definition of
leaf is very confusing if not dead wrong:
<leaf>:
( <parameter name> whitespace <value list> )
Here the <parameter name> does not refer to an AMI parameter
at all when we are talking about the content of an .ami file.
A parameter name in the .ami file is usually a branch name.
Leaves in the .ami file begin with a reserved word, as you
noted later:
All leaves of the .ami file must begin with one of the following reserved
words:
Type
Usage
Description
Default
<data_format> or Format <data_format>
The previous definition, however, might be true for a parameter string
that is passed into the DLL, after the EDA tool processed the content
of the .ami file.
So I think we have two contexts here, one for the .ami file and the
second for the parameter string that is passed into the DLL. We will
probably need to deal with these in two separate sections in the spec.
Thanks,
Arpad
=========================================================================
-----Original Message-----
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Wednesday, April 04, 2012 8:26 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] IBIS-AMI - Unifying the terminology
All:
Per our discussion today, attached are names that
usually mean the same thing across the three IBIS-AMI
sections 6C, 10, and 10A. We should settle on only
one name throughout or have purposeful distinctions among
several names and then do a pass to unify the terminology.
More cases might be found. Even the section titles can
be tweaked.
(We did that for standard IBIS at some earlier version
using, for example, I-V tables throughout in place of many
variants such as V-I tables, I/V, V/I tables, I/V curves,
V/I curves, and other variants)
Bob
--
Bob Ross
Teraspeed Consulting Group, LCC
http://www.teraspeed.com
bob@xxxxxxxxxxxxxx
Direct : 503-246-8048
Teraspeed Labs: 503-430-1065
Headquarters: 401-284-1827
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
Other related posts:
