Arpad: The distinction is that we can support a consistent syntax as an evolutionary goal. But we have come the full circle from trying to elimimate something that is not "consistent" (and not even mentioning it or just considering it legal for one version only) to the statement that everything that is currently legal and being shipped will be supported in V5.1 - without change. One way of doing this is through a Compatibility section. So IBIS can document and officially support two ways of doing the same functionality, if needed. Through public questions, and some private discussions, several vendors are moving forward with V5.0 support for the .ami syntax. We may have made some mistakes, but there is no technical reason why we cannot support the existing syntax and a more pure syntax at the same time. That is why moving Notes 4 and 5 are on my list for movement to a Compatibility section. By defining "Format" to be translated as equivalent to a null string makes Value and Format Value equivalent in the AMI file. It is a little more complicate, but (Model_specific ( ) ( ) ) and ( ) ( ) are equivalent as long as the (M ... ) right parenethesis are at the same level. This is a simple text pre-processing issue for some vendors. That is how we can support existing syntax in the official parser and expect all EDA tools who do not use the official parser to still support backward compatibility. No translation of the file is needed, and the preference for the new syntax will be made over time because it is simplier and some restrictions associated with the existing V5.0 will be relaxed. This Compatibility section can grow if we come up with other special cases or if we simply "retire" a never-used keyword because of a technical defect with another keyword that is corrected and useful. We have accomplished the syntactical purity goal, but have also have officially retained support for all of the existing .ami files AND their corresponding DLL's date. Bob Muranyi, Arpad wrote:
Bob, In this discussion we were not suggesting the removal of any functionality by proposing a consistent syntax... The idea is to be able to make this .ami to parameter string conversion follow simple rules, and not a complicated set of context sensitive rules. Arpad ============================================================= -----Original Message-----From: Bob Ross [mailto:bob@xxxxxxxxxxxxx] Sent: Wednesday, March 17, 2010 7:01 PMTo: Muranyi, Arpad Cc: ibis-macro@xxxxxxxxxxxxx; bob@xxxxxxxxxxxxx Subject: Re: [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@xxxxxxxxxxxSent: Wednesday, March 17, 2010 6:18 PM To: ibis-macro@xxxxxxxxxxxxxSubject: [ibis-macro] Re: question on Model_Specific branch name in input parameter stringHi Ambrish, I recall some e-mail exchanges on this subject several months ago, butIdo 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 theparameter 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 beexplicitly stated. So, are you saying that stripping the two branches(Reserved_Parametersand Model_Specific) is a de-facto standard? RadekFrom: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish VarmaSent: Wednesday, March 17, 2010 12:41 PM To: ibis-macro@xxxxxxxxxxxxxSubject: [ibis-macro] Re: question on Model_Specific branch name in input parameter stringHi 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 Offangyi_rao@xxxxxxxxxxxSent: Wednesday, March 17, 2010 3:32 PM To: ibis-macro@xxxxxxxxxxxxxSubject: [ibis-macro] question on Model_Specific branch name in input parameter stringHi, Experts; Based on the current AMI standard should the Model_Specific branchnameappear in the input parameter string to the AMI Init call? Forexample,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_Specificand 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
-- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@xxxxxxxxxxxxx Teraspeed is a registered service mark of Teraspeed Consulting Group LLC --------------------------------------------------------------------- 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