Hi Bob,
It is not really a distinction of two different syntaxes. The
input/output DLL string is simply reduced do the name/value pairs, yet
still in the hierarchy specified by the *.ami file. The choices for the
values must be consistent with what is specified in the *.ami file. What
I am saying is that the parameter hierarchy, data types, usage, format,
etc., is (should be) governed by the content of the *.ami file alone,
and the DLL should be compliant.
The only freedom in handling the input/output DLL strings (as I recall
it) is (should be) that not all the parameters from the *.ami files need
to be included, and the parsers (at both ends: EDA platform and DLL)
should simply ignore unknown parameters. This way, the *.ami file can
describe a superset of parameters that go in to or out from the DLL.
Radek
-----Original Message-----
From: Bob Ross [mailto:bob@xxxxxxxxxxxxx]
Sent: Wednesday, March 17, 2010 6:00 PM
To: BIERNACKI,RADEK (A-Sonoma,ex1)
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: question on Model_Specific branch name in
input parameter string
Radek:
The distinction is on two levels
The .ami syntax has elements that have different functions.
Some of these to my understanding are not supported in the
EDA to DLL interface. So a single value for an input that
as part of the input string to the dll such as <par_name 5)
might be expressed in a 1-to-1 way with a different
syntax in the .ami file ((Format Value 5) (Type Integer)
(Usage In) (Description "integer 5") (Default 5)
But 5 could also can be the consequence of a Range selection
through a user interface where 5 is selected, but not
explicitly specified. So the syntaxes can be different,
and the In parameter source may from outside the .ami file.
Bob
radek_biernacki@xxxxxxxxxxx wrote:
Bob,
I disagree. As far as the content of AMI_parameters_in and
AMI_parameters_out in DLL calls is concerned, the *ami file is (should
be) the only source of information on how the DLL expects to
communicate
with the EDA platform.
Radek
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Wednesday, March 17, 2010 5:01 PM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: ibis-macro@xxxxxxxxxxxxx; bob@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: question on Model_Specific branch name in
input parameter string
Arpad and Radek:
The confusion is that we are talking about two different syntaxes.
The syntax between the DLL and the EDA tool appears to be
a rigidly defined syntax, and succinctly based on fairly good
BNF principles. Not so for the .ami syntax.
All the documents to date do an insuffient job of explaining
the process. The .ami syntax was intended to be a similar
type syntax, but in practice we have so many exceptions
(e.g., context-sensitive stuff) that it can be viewed as
a totally different syntax. It happens to be somewhat
similar to the DLL to EDA syntax in that there might
be a similar hierarchy structure of branches to branches.
At the extreme, these are just two different syntaxes and
this should be stated clearly and up front. Special rules
are added .ami syntax. The EDA tool is in the middle and does the
translation of the .ami content to interact with the DLL. We
could have used IBIS keywords or some other language for
the .ami syntax.
That is why we need the context diagram, and we need to
be careful everywhere in the text when we talk or refer
to parameter tree issues. The answer to any simple
question could be different with respect to DLL syntax
and .ami syntax.
Syntactical purity has never has existed, and never can be
a reason for removing existing funtionality that is
well-established in the industry.
Bob
Muranyi, Arpad wrote:
Radek,
Thank you for bringing this up. I was equally confused about this
topic many moons ago, and tried to ask the same questions. They
are probably in the archives if our email reflector has one...
When I asked questions about this, the answers I got made me feel
a little that I was mentally retarded because they made it seem
that this was clearly described in the spec and it was totally
obvious how the EDA tool had to formulate the parameter string
for the DLL. I am glad to hear that I am not the only one who
is lost and all of the sudden I am starting to feel normal again...
:-)
I agree that it would be a lot more consistent to do it the way you
described it (without removing those branches and moving things up
a level). The question after all these months and released models
is whether we can make a change for the sake of consistency at the
expense of braking existing models... Since this procedure is not
described in the existing specification (or not adequately), part
of me says that we have the freedom to describe it now any whichever
way we feel is right, since the models which were released up to now
were made based on non existing or speculative rules.
Thanks,
Arpad
======================================================================
------------------------------------------------------------------------
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
radek_biernacki@xxxxxxxxxxx
Sent: Wednesday, March 17, 2010 6:18 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: question on Model_Specific branch name in
input parameter string
Hi Ambrish,
I recall some e-mail exchanges on this subject several months ago, but
I
do not remember the conclusions.
What you are saying sounds like another flaw in the current spec. I
would expect the input/output DLL strings to conform COMPLETELY to the
parameter tree hierarchy specified in the *.ami file. The reason is
simple: by the principles of a parameter tree we can have exactly the
same leaf or sub-branch name in two or more branches. Therefore,
stripping a branch (removing it and bringing the entire sub-tree one
level up) should not be allowed. Any exceptions from this rule must be
explicitly stated.
So, are you saying that stripping the two branches
(Reserved_Parameters
and Model_Specific) is a de-facto standard?
Radek
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Wednesday, March 17, 2010 12:41 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: question on Model_Specific branch name in
input parameter string
Hi Fangyi,
It will be
(mySampleAMI
(ntap 5)
)
The keywords Reserved_Parameters and Model_Specific are meant for
organizing the parameters in the ami file only and not supposed to be
passed to the model.
Thanks,
Ambrish.
------------------------------------------------------------------------
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Wednesday, March 17, 2010 3:32 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] question on Model_Specific branch name in input
parameter string
Hi, Experts;
Based on the current AMI standard should the Model_Specific branch
name
appear in the input parameter string to the AMI Init call? For
example,
for the following .ami file
(mySampleAMI
(Reserved_Parameters
?
)
(Model_Specific
(ntap (Usage In) (Type Integer) (Format Value 5))
)
)
Shall the input parameter string be
(mySampleAMI
(Model_Specific
(ntap 5)
)
)
or
(mySampleAMI
(ntap 5)
)
I understand that if the proposed BIRD is accepted then Model_Specific
and Reserved_Parameter branchs will disappear. But for models written
based on the current standard it?s not clear which format EDA tools
should feed to models.
Thanks in advance.
Fangyi
