AMI_dll_parameters_out is a pointer to pointer. By convention and common practice the eda tool is the one which should be responsible for deallocating the memory. Notice this conventions is really followed in the matter of AMI_dll_memory_handle as well. That memory is freed only when the eda tool remakes the close call. ie the memory is destroyed on behalf of the eda tool at its choosing again when a caller gives a pointer to pointer he is really responsible for the memory. "Mirmak, Michael" <michael.mirmak@intel.com> wrote: The enclosed BIRD, "Update to Algorithmic Modeling API (AMI) Support in IBIS," is submitted on behalf of Todd Westerhoff, SiSoft and Zhen Mu, Cadence Design Systems. It will be introduced and discussed at an upcoming IBIS Open Forum teleconference. All resolved and pending BIRDs can be found at http:// <> www.eda.org/ibis/birds/. - Michael Mirmak Intel Corp. Chair, IBIS Open Forum -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ***************************************************************************** ***************************************************************************** BIRD ID#: 107 ISSUE TITLE: Update to Algorithmic Modeling API (AMI) Support in IBIS REQUESTER: Todd Westerhoff, SiSoft and Zhen Mu, Cadence Design Systems DATE SUBMITTED: April 3, 2008 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: PENDING ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: The waveform input to a TX AMI_Getwave call and the filtering function to be performed by the AMI_Getwave call were ambiguous. The analysis flow when an AMI model contained filtering in both the AMI_Init and AMI_Getwave calls was not clearly stated. These issues were causing simulation differences when the same TX model was run in different IBIS-AMI toolkits. The existing text did not make it clear that the AMI model was responsible for deallocating memory used for AMI_parameters_out. ***************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following paragraph: | | 3.2.2.1 wave | ============ | | A vector of a time domain waveform, sampled uniformly at an interval | specified by the ‘sample_interval’ specified during the init call. The | wave is both input and output. The EDA platform provides the wave. The | algorithmic model is expected to modify the waveform in place. | | Depending on the EDA platform and the analysis/simulation method chosen, | the input waveform could include many components. For example, the input | waveform could include: | shall be modified as follows: | | 3.2.2.1 wave | ============ | | A vector of a time domain waveform, sampled uniformly at an interval | specified by the ‘sample_interval’ specified during the init call. The | wave is both input and output. The EDA platform provides the wave. | The algorithmic model is expected to modify the waveform in place by | applying a filtering behavior, for example, an equalization function, | being modeled in the AMI_Getwave call. | | Depending on the EDA platform and the analysis/simulation method chosen, | the input waveform could include many components. For example, the input | waveform could include: | ------------------------------------------------------------------------------ The following paragraph: | Reserved Parameters: | | Init_Returns_Impulse, GetWave_Exists, Max_Init_Aggressors and | Ignore_Bits shall be modified as follows: | Reserved Parameters: | | Init_Returns_Impulse, Use_Init_Output, GetWave_Exists, | Max_Init_Aggressors and Ignore_Bits ------------------------------------------------------------------------------ The following paragraph: | 3.1.2.6 AMI_parameters (_in and _out) | ===================================== | | Memory for AMI_parameters_in is allocated and de-allocate by the EDA. The | memory pointed to by AMI_parameters_out is allocated and by the model. shall be modified as follows: | 3.1.2.6 AMI_parameters (_in and _out) | ===================================== | | Memory for AMI_parameters_in is allocated and de-allocated by the EDA platform. The | memory pointed to by AMI_parameters_out is allocated and de-allocated by the model. ------------------------------------------------------------------------------ Add the following paragraph after Init_Returns_Impulse | Use_Init_Output: | | Use_Init_Output is of usage Info and type Boolean. When Use_Init_Output | is set to "True", the effects of the AMI_Init and AMI_Getwave calls are | chained together in the EDA platform by convolving the impulse response | returned by AMI_Init with the input waveform. The resulting waveform | is then presented to the AMI_Getwave call. | | If Use_Init_Output is set to "False", the EDA platform will present the | input waveform directly to the AMI_Getwave call (i.e. without convolving | the waveform with the impulse response returned by AMI_Init). | | The algorithmic model is expected to modify the waveform in place. | | The default value for this parameter is "True", instructing the EDA tool | to use the output impulse response from the AMI_Init function | when creating the input waveform presented to the AMI_Getwave function. | | If Use_Init_Output is False, GetWave_Exists must be True. ***************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION Comparisons of simulation results from the reference toolkits revealed differences that were due to different assumptions about the input waveform presented at a TX AMI_Getwave call, and the relationship of the outputs from AMI_Init and AMI_Getwave calls. Further discussion identified two different styles of modeling were possible and should be supported. In the default case, the AMI_Init and AMI_Getwave calls represent filtering performed by sequential stages of a device, and the results should therefore be chained together. In the second case, the AMI_Init and AMI_Getwave calls each represent the overall device. For example, the AMI_Init call could provide an LTI model for the device while the AMI_Getwave call provides a time-varying model. In this case, results from the AMI_Init and AMI_Getwave calls should be treated as independent. ***************************************************************************** ANY OTHER BACKGROUND INFORMATION: The thoughts captured in this BIRD were discussed at the April 1, 2008 meeting of the IBIS ATM Task Group. A slide presentation of this material is available as IBIS_ATM_BIRD_Update_040108.pdf in the following web directory: http://www.eda.org/pub/ibis/macromodel_wip/archive/20080401/toddwesterhoff/IBIS-AMI%20Correlation%20and%20BIRD%20Update/ (http://tinyurl.com/28ouvx) ***************************************************************************** --------------------------------- You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Thu Apr 3 20:21:44 2008
This archive was generated by hypermail 2.1.8 : Thu Apr 03 2008 - 20:22:20 PDT