[ibis-macro] Re: IBIS-AMI Working Draft of AMI Quick Reference
- From: Bob Ross <bob@xxxxxxxxxxxxx>
- To: Walter Katz <wkatz@xxxxxxxxxx>
- Date: Tue, 23 Feb 2010 10:45:35 -0800
Walter:
The working document is something I needesd to try to understand
the .AMI syntax and its limitations, specific case rules and
its implications concerning what we have and what we are proposing.
I did not intend that this be included directly as is. However,
the new chapter 6c must be absolutely clear on all available
choices. If not, than we have the same problem as before -
the official parser cannot be written from the specification,
and no two EDA vendors can write compatible parsers. That
could imply a restructing at this time, or an inclusion of
a formal syntax section for just .AMI to be the official
syntactical interpretation. The parser developer could
also rely on this as the primary reference.
But at this time the document is useful to me to question
some verbage within the proposed BIRD from a top-level
structural point of view.
-----
You raised a valid point regarding Model_Specific and
Reserved_Parameters being interpreted as white-space as
a syntactical violation of the AMI syntax from a tree
structure perspective.
I missed that point. I just assumed a more simple
paranthesis rule interpretation for the AMI file that ( ) and
(( )) are equivalent. This grouping rule exists in most languages.
But it is contrary to the parameter tree passing syntax if applied
to the .AMI file and is not explicitly allowed.
Since the .AMI syntactical content is different than than what
is passed to/from the DLL, one solution is to modify the
AMI syntax to accomodate these special case structural changes.
So the revised rule might be that if (Model_Specific ........) exists,
it shall be processed as if Model_specific is null and
the left and right paranthesis at the same level are also
deleted (to move the other parameters as direct branches off
of the root level - as you state. Parsers and EDA tools can
do this automatically. (Same for Required_parameters.)
That way a legally compliant .AMI file that is shipped today
and passes ibischk5 at the V5.0 spec. level will work both
with V5.0 and V5.1 syntax rules.
Bob
Walter Katz wrote:
Bob,
Please confirm that this is working document that you want to hand over to
assist a parser developer, and that this document will not be specifically
added to the AMI specification.
In any case, there is one confusing item. If Model_Specific and
Reserved_Parameters are replaced by white space, there would still be two
branches with branch names blank. What I have proposed in the new AMI BIRD
is that these branches will simply not exist, but for compatibility sake, if
they do exists then the branches off these two branches would be treated as
if they are off the root branch.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Bob Ross
Sent: Tuesday, February 23, 2010 3:38 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] IBIS-AMI Working Draft of AMI Quick Reference
All:
I am trying to fully understand the AMI file syntax and its
constraints from just a parser developer perpective.
After attempting a spread sheet, and then a formal syntax
approach, I opted for a psuedo formal definition in a
quick reference style format to show all of the allowable
choices. I did not add some special cases and exceptions since
my top priority is to understand just the basic rules.
The first cut is a blend of the existing V5.0 syntax and the
proposed syntax with some changes to assist graceful migration
of the Reserved_parameters. I have included parameters that
might be dropped and some others that were originally proposed
but withdrawn in the new BIRD just to keep them visible.
A few technical questions and concerns will arise from this,
and there are probably several mistakes.
The Model_specific portion still needs more development since
the (tree) structure might support a very general hierarchical
structure.
So I expect to revise this file as we decide and clarify
what we want.
Bob
--
Bob Ross
Teraspeed Consulting Group LLC Teraspeed Labs
121 North River Drive 13610 SW Harness Lane
Narragansett, RI 02882 Beaverton, OR 97008
401-284-1827 503-430-1065
http://www.teraspeed.com 503-246-8048 Direct
bob@xxxxxxxxxxxxx
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
--
Bob Ross
Teraspeed Consulting Group LLC Teraspeed Labs
121 North River Drive 13610 SW Harness Lane
Narragansett, RI 02882 Beaverton, OR 97008
401-284-1827 503-430-1065
http://www.teraspeed.com 503-246-8048 Direct
bob@xxxxxxxxxxxxx
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
