[ibis-macro] Re: BIRD 160.1 draft3 is posted on the ATM website
- From: "Bob Ross" <bob@xxxxxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 19 Apr 2013 13:51:50 -0700
Arpad:
The revision looks fine. (Usage In) in an AMI file
can mean the parameter vaule is sent to a .dll plus it can be
used as a parameter value in a .ibs file.
Bob
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, April 19, 2013 12:26 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD 160.1 draft3 is posted on the ATM website
Bob,
Thanks for your comments. I keep forgetting about those two sections
at the beginning... I am attaching a draft4 in which those are removed.
I also changed the rule so that only Usage Info is allowed for non .ami
parameter files.
Regarding your suggestion of not restricting the Usage choices, I tend
to disagree. The reason I think it should be restricted is because we
will have problems with Out or InOut parameters because the question
becomes when is this parameter supposed to be read. An analog model
will typically be used in the channel characterization simulation which
is usually done before the AMI models are executed. But if a parameter
is an Out or InOut type, the AMI model might return a different value
from what is in the parameter value before the AMI model is executed.
Which value would be passed into the analog model in this case?
We will deal with other Usage types if and when they are added to the
specification. At that time we will need to remember to pay attention
to these rules and make corrections if necessary.
Thanks,
Arpad
============================================================================
-----Original Message-----
From: Bob Ross [mailto:bob@xxxxxxxxxxxxx]
Sent: Friday, April 19, 2013 1:24 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] BIRD 160.1 draft3 is posted on the ATM website
Arpad:
You need to remove the [Begin Parameter Trees]/[End Parameter Trees]
in the hierarchy diagram and also in the table in the beginning.
----
In you examples change ParamFile.par to its lower case version
paramfile.par since names are case-sensitive and we do not want
to encourage operating system dependencies on name and possible
conflicts.
-----
Regarding Usage choices, another choice is to not restrict the Usage
choices in .ami files for the purpose of passing parameter values.
So Usage Out and Usage InOut could also be included, and also
some any Usage choices without changing the specification.
For other external files such as .par files, we should only accept Usage
Info.
The meaning of Usage In should not be corrupted. There is no interaction
with the .dll, so Usage In is meaningless. The same applies for all the
other Usage choices. Alternatively, we accept all Usage choices,
whether meaningful or not.
BIRDs 150 and future revision of BIRD 155 for dependency tables
propose a new Usage. So we might not want to limit the Usages
in a .ami file to just In or Info.
Usage choices for .ami parameters in BIRD160 (even if this is a
forward reference to rules), but BIRD153 needs to be resolved regarding
what is allowable in a .par file. I would expect this to be checked.
Bob
---------------------------------------------------------------------
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:
