Hi Mike, I think it is OK for a model to kick information out with Usage Out, or even to take in something, modify it, and kick it back out as Usage InOut. It does not seem like we should limit that. But the EDA tool should not be expected to do anything with that information coming from the Model_Specific Out or InOut parameter, other than maybe present it to the user. These Model_Specific outputs are not "standard" IBIS parameters, they are model-specific outputs. If there are things coming out of a model that all the EDA tools need to process and do something active with, then I think we need to add a Reserved_Parameter for that. Then it can be well-defined and model makers can count on that data being folded into the analysis. I think it is important to keep Reserved_Parameters for the tools to do standard things with, and Model_Specific parameters to give model makers the flexibility to give unique inputs or generae unique outputs from their algorithmic model. Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte Sent: Thursday, February 17, 2011 8:47 AM To: Arpad Muranyi; IBIS-ATM Subject: [ibis-macro] Re: Question about Model Specific parameters Although the tool may not know the meaning of the Model Specific parameters, it knows the name and type of each and it has the opportunity to simply present them to the user in a display or report. The model may wish to have some non-essential outputs presented to the user. For example, it could report confidence metrics on how accurate the model is believed to be with the given tap settings. That would justify usage Out. Usage InOut might be justified if the model requires a set of inputs that have some complex relationship defining the allowable ranges, which AMI is unable to support. For example one parameter might allow a value up to 15 in most cases, but only up to 12 if some other parameter has crossed some threshold. In that case the tool is unable to understand and enforce the rules exactly. The model will have to check and I'm sure it would like to report back any adjustments it had to make. An alternative would be to adopt the rule that Model Specific can not be InOut, and model makers could add "Actual_..." Out Model Specific parameters to report back to users. But to have a control that has built-in feedback the InOut type would be best. Think of the f-stop control on a camera lens, which can only go down so far based on what the zoom level is. Walter's Dependency Table BIRD 124 is related, but I'm not sure it covers all possible internal dependencies. It seems to be mostly about automatically setting some parameters based on how others are set. Limits are a different matter, and of course models could want to report any kind of metric that is non-essential to simulation. Mike On 2/16/11 7:02 PM, "Arpad Muranyi" <Arpad_Muranyi@xxxxxxxxxx> wrote: > Hello everyone, > > I stumbled on a situation with an .ami file which has > a few Model Specific parameters of Usage InOut. Our > customer is wondering why we don't do this and that > with the data that is returned by the model in those > parameters. This triggers the following thoughts in > my mind. > > Model Specific parameters are specific to the model and > their meaning is not described by the AMI specification. > Therefore no EDA vendor has the knowledge on how to > interpret or post process these returned parameters > because there is simply no way of knowing what to do > with them. > > For this reason, I would suggest that we make a rule in > the IBIS AMI specification that Model Specific parameter > must be Usage In, and Usage Out or InOut should not be > allowed. > > Any Comments? > > Thanks, > > Arpad > ======================================================== > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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