**************************************************************************** **************************************************************************** BIRD ID#: 143.1 ISSUE TITLE: Correcting the rules for AMI_Close REQUESTOR: Arpad Muranyi, Mentor Graphics DATE SUBMITTED: June 29, 2011 DATE REVISED: September 6, 2011 DATE ACCEPTED BY IBIS OPEN FORUM: October 7, 2011 **************************************************************************** **************************************************************************** STATEMENT OF THE ISSUE: The IBIS 5.0 specification defines the rules for AMI_Close so that it is optional when AMI_GetWave doesn't exist in the model. This results in unnecessary complications regarding the rules of some other AMI function arguments. Making AMI_Close required for all situations would simplify these rules in the specification and the job of model makers. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: On pg. 181 replace these lines: | The three functions can be included in the shared object library in one of | the three following combinations: | | Case 1: Shared library has AMI_Init, AMI_Getwave and AMI_Close. | Case 2: shared library has AMI_Init and AMI_Close. | Case 3: Shared library has only AMI_Init. | | Please note that the function 'AMI_Init' is always required. with the following lines: | The three functions can be included in the shared object library in one of |* the following two combinations: | | Case 1: Shared library has AMI_Init, AMI_Getwave and AMI_Close. | Case 2: shared library has AMI_Init and AMI_Close. | |* Please note that the functions 'AMI_Init' and 'AMI_Close' are always |* required. **************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Several questions were raised regarding memory allocation and de-allocation while working on BIRD 137, and discussions revealed that making AMI_Close always required would simplify the rules in the specification as well as the rules for the model making process. BIRD 143.1 was issued to document the discussions in the "ANY OTHER BACKGROUND INFORMATION" section below. No other technical changes have been made to the document. **************************************************************************** ANY OTHER BACKGROUND INFORMATION: A request was made in the August 26, 2011 IBIS Open Forum teleconference to link this BIRD with the AMI_Version Reserved_Parameter to make it clear that the changes introduced in this BIRD apply to IBIS models written with AMI_Version 5.1 and above, and a motion was made to further discuss this in the ATM meetings. On August 30, the ATM task group decided the following (quote from the minutes): Arpad showed BIRD 143 - Arpad had added "for version 5.1 and above" language. - Walter/Radek: unnecessary, handle it the same way as 137.1 and for reference, the BIRD 137.1 discussion went as follows: Arpad showed BIRD 137.1 - Arpad said Adge of IBM is concerned that we may be "breaking" existing models. - Radek: no need to modify BIRD, we're defining 5.1 behavior not 5.0 - Walter: (agreeing) EDA tools can gracefully handle 5.0 and 5.1 - Bob: each version of the spec should encompass all previous versions - Walter: need to break with past conventions on backward compatibility in this case - Walter: request Open Forum vote on BIRD as is, we can add section on differences - Bob: can we add a note on 5.0 vs. 5.1 differences (separate BIRD?) - Walter: motion to table discussion until next meeting and work out "differences" section off line. - Radek: second the motion (approved unanimously) Based on this, BIRD 143.1 is submitted to the IBIS Open Forum with no technical changes made to BIRD 143. ****************************************************************************