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 -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Friday, April 19, 2013 8:51 AM To: 'IBIS-ATM' Subject: [ibis-macro] BIRD 160.1 draft3 is posted on the ATM website Hello everyone, This is to inform all of you that draft3 of BIRD 160.1 has been posted on the ATM website: http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20130419/arpadmuranyi/BI RD%20160.1%20draft%203/BIRD160_1_draft3.docx In this draft I removed all dependencies on BIRD 153 by removing the possibilities to have parameter trees in the .ibs file itself. Consequently I also deleted the [Begin Parameter Trees] / [End Parameter Trees] example at the end. After thinking about the other concern Bob raised about Usage In, I think this turns out to be a non-issue. Here is why: Parameter assignments in the [External ***] section of the .ibs file are resolved in the EDA tool by following the "fully qualified" path in the parameter reference to the location of the parameter. This means that the EDA tool is not passing the parameter to the [External ***] model based on what its Usage type is in the parameter tree. The EDA tool simply looks for it based on the path provided in the assignment. The EDA toll will find it regardless of what the parameter's Usage is, or whether it is a Reserved_Parameter or Model_Specific. Also, while it is true that a (Usage In) parameter in an .ami file will be passed into the AMI DLL, we need to remember that the DLL may ignore it if it doesn't recognize it or need it. So there is no harm in having Usage In parameters in the .ami file which are designed to be used with [External ***] models only. However, in this version of the BIRD, I also allow Usage Info for such parameters, and the Usage Info parameters are not passed into the AMI DLL. I believe these changes address all of the concerns raised in our discussions on the previous drafts of BIRD 160.1. Please take a few moments before the next ATM meeting to review draft3 so we could finish the discussions on it and take a vote for a recommendation to the Open Forum. 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