[ibis-macro] Re: A general AMI parameter question

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 22 Dec 2011 13:08:57 -0600

Arpad-

I don't suppose I'm letting much of a secret out of the bag by telling you that SiSoft's QCD passes parameters with Usage In and Format Value straight into the model without offering the user any chance to change the value.

Ambrish's description of the application of Format Value is quite accurate. There are a number of models out there for which the DLL is identical, and the only difference between models is the parameters values in the AMI files; and this is for exactly the reason Ambrish describes- it's a lot easier to examine/edit/manage an AMI file than it is to examine/edit/manage multiple DLLs, especially when the only differences are static values in the code.

I submit that we added the AMI file to the specification in order to give model developers a standardized way to tell EDA tools and users what the names, types, and valid values are for parameters to be passed in to a given model. If that is still the role we expect the AMI file to play (and I believe it is), then it would not be appropriate to allow users to change a parameter's value away from the one value that the model developer declared to be valid.

I hope this helps.
Mike Steinberger

On 12/22/2011 12:51 PM, Muranyi, Arpad wrote:

Good point.  I didn’t think of that…

I guess, we could also do something

similar with the upcoming Dependency

Table ideas…

 

But the question remain about what the EDA

tool should do for these types of parameters.

Should the tool let the user change it through

a dialog, or should the tool not even bother

displaying such parameters?

 

Thanks,

 

Arpad

================================================

 

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Thursday, December 22, 2011 12:46 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: A general AMI parameter question

 

Arpad,

Here is a scenario that comes to mind:

The model maker, who also writes the .ami file for that model can send another .ami file with a different value to that Model_Specific parameter should a need arise to do so. This would not have been possible if that parameter was hard coded in the model – and to change the parameter value, the model maker would have to 1) make the edit in the source code, 2) compile 2,3,4 versions of the model based on the platform they support and 3) mail/transfer the model back to the user.

 

Thanks,

Ambrish.

 

 

 

Ambrish Varma   |  Member of Consulting Staff

P: 978.262.6431   www.cadence.com

 

 

 

 


From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, December 22, 2011 1:40 PM
To: IBIS-ATM
Subject: [ibis-macro] A general AMI parameter question

 

Hello,

 

This is just a general question that came to me as I was

looking at an .ami file.

 

What is the expectation from the EDA tool for Model_Specific

parameters of type Usage In when they are single valued,

such as Format Value, or Default?

 

The first reaction to that question is that the EDA tool

should pass that value into the AMI model, right?  But

should the EDA tool display these types of parameters in

a dialog for the user so they can change it, or should

they be passed in without allowing the user to make

changes?

 

Compare this thinking with a Format Range or List which

provides options for the user to select from.  For these,

the EDA tool will provide a dialog for the user so they

can make a selection.  But what about the single valued

parameters using Format Value or Default?  Should the tool

still provide a dialog for the user to perhaps override the

value given in the .ami file with something else and pass

that to the AMI model?  If yes, the parameter should really

be defined as Range or List.  If not, what is the purpose of

even putting such single valued parameters into the .ami

file if the user shouldn’t be allowed to change it?  The

value could have been hardcoded into the model if it is not

supposed to be changed by the user…

 

Based on this, I am almost ready to say that Format Value

with Usage In doesn’t make sense in the spec, if the user

shouldn’t be allowed to make changes to its value, because

as soon as we allow the user to make changes, we should

require to use Range, or List, etc… to put limits to what

the user should be allowed to do…

 

 

Comments, questions?

 

Thanks,

 

Arpad

=============================================================

 

Other related posts: