Kumar-The questions are not as simple as you imagine, and there are options you apparently haven't considered. Detailed responses below.
Mike S. C. Kumar wrote:
There are 2 comments
Ummm... 3 comments?
You are only assuming one particular flow. In point of fact, there are multiple flows possible, some of which use an impulse response output from AMI_Init in ways which have nothing whatever to do with AMI_GetWave. The use_init_output helps to allow all of these flows to be possible.1. The init processing is still too confusing and has unnecessary flag like Use_init_output the impulse matrix is passed by the eda platform. The only time the model should modify this data is when it intends the eda platform to use the modified impulse response. If it has to modify the impulse response for its own use later on (ie. during its getwave processing) then it should CREATE a COPY for its own use. It has no business modifying the original impulse response data provided by the eda platform.so i do not see why you need an extra and confusing use_init_output flag
2. The model is mandated to have only the init function. The getwave and and close calls are optional. The eda platform can open the dll and see whether getwave and close exists. It does not need any extra directives beyond the existence or non existence of these getwave and close function calls
What are you therefore proposing?
That's one point of view, but not at all the only view held within the C/C++ programming world. A very popular point of view (and the one I happen to hold) is that while the owner of the memory needs to be clearly defined, it is not automatically the case that the caller must be the owner of the memory. For example, the EDA platform (that is, the caller) can't be the owner of the Model's memory because it doesn't even know how much memory to allocate or when to de-allocate it, which is why we have **AMI_memory_handle and AMI_Close().3. regarding 'msg' and 'parameter_out' memory-- In c/c++ programming when a function passes a pointer to pointer , usually the convention is that the caller is responsible for the memory. here in parameters_out you intend to go against this convention, ie the model is responsible for this memory. If that is true does the same rule apply for the message too? (if there are multiple messages you can see that the model will be soon burdened with keeping track of all these memory)
I believe that the really important principle is that the owner of the memory be clearly identified, and that whichever object owns the memory does all of the allocation, modification, and de-allocation of that memory. That, after all, is the most fundamental principle of object oriented programming.
*/Bob Ross <bob@xxxxxxxxxxxxx>/* wrote: To All: We introduced BIRD107.1 at the April 25 meeting, but we noticed some nomeclature inconsistency in Table 1 and 2 regarding using underbars instead of spaces. BIRD107.2 fixes this problem. BIRD107 is scheduled for a vote at the May 16 meeting. Also, as a review comment on the draft Version 5.0 IBIS Specification, the nomenclature regarding the underbar versus space for impulse_matrix Section 3 of NOTES ON ALGORITHMIC MODELING INTERFACE AND PROGRAMMING GUIDE. BIRD108 proposes a fix. Both draft BIRDs are attached and available for comments on the April 29 meeting. Bob-- Bob RossTeraspeed 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 ***************************************************************************** ***************************************************************************** BIRD ID#: 107.2_draft 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: April 24, 2008, April 29, 2008 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. This was causing simulation differences when the same TX model was run in different IBIS-AMI toolkits. The analysis flow when an AMI model contained filtering in both the AMI_Init and AMI_Getwave calls was not clearly stated. This was 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. The existing text has three different definitions of the modified impulse response generated by AMI_Init in sections 2.1.6, 2.2.6 and 3.1.2.1. The existing text did not make clear that if Init returns a modified impulse that the modified impulse response represents the filtered response. ***************************************************************************** Modifications to section 6C: The following paragraph: | Init_Returns_Impulse, GetWave_Exists, Max_Init_Aggressors | and Ignore_Bits shall be modified as follows: | Init_Returns_Impulse, Use_Init_Output, GetWave_Exists, | Max_Init_Aggressors and Ignore_Bits ----------------------------------------------------------------------------- The following paragraph: | The following reserved parameters are optional. If these | parameters are not present, the values are assumed as “0”. shall be modified as follows: | Use_Init_Output: | | Use_Init_Output is of usage Info and type Boolean. When | Use_Init_Output is set to "True", the EDA tool is | instructed to use the output impulse response from the | AMI_Init function when creating the input waveform | presented to the AMI_Getwave function. | | If the Reserved Parameter, Use_Init_Output, is set to | "False", EDA tools will use the original (unfiltered) | impulse response of the channel when creating the input | waveform presented to the AMI_Getwave function. | | The algorithmic model is expected to modify the waveform in | place. | | Use_Init_Output is optional. The default value for this | parameter is "True". | | If Use_Init_Output is False, GetWave_Exists must be True. | | The following reserved parameters are optional. If the | following parameters are not present, the values are | assumed as “0”. ----------------------------------------------------------------------------- The following tables: | +------------------------+-------------------+ | | General Rules | Allowed Usage | | ======================================================================== | | Reserved Parameter | Required Default | Info In Out InOut | | +-------------------------+------------------------+-------------------+ | | Init Returns Impulse | Yes NA | X | | | GetWave Exists | Yes NA | X | | | Ignore Bits | No 0 | X X | | | Max Init Aggressors | No 0 | X | | | Tx Jitter | No No Jitter | X X | | | Tx DCD | No 0 | X X | | | Rx Receiver Sensitivity | No 0 | X X | | | Rx Clock PDF | No Clock Centered | X X | | +-------------------------+------------------------+-------------------+ | | Table 1: General Rules and Allowed Usage for Reserved Parameters | | | +-------------------------------------------+ | | Data Type | | ======================================================================= | | Reserved Parameter | Float | UI | Integer | String | Boolean | | +-------------------------+-------+------+---------+--------+---------+ | | Init Returns Impulse | X | | | GetWave Exists | X | | | Ignore Bits | X | | | Max Init Aggressors | X | | | Tx Jitter | X X | | | Tx DCD | X X | | | Rx Receiver Sensitivity | X | | | Rx Clock PDF | X X | | +-------------------------+-------------------------------------------+ | | Table 2: Allowed Data Types for Reserved Parameters | | | +---------------------------------------+ | | Data Format | | =================================================================== | | Reserved Parameter | V | R | C | L | I | S | G | D | D | T | | | | a | a | o | i | n | t | a | u | j | a | | | | l | n | r | s | c | e | u | a | R | b | | | | u | g | n | t | r | p | s | l | j | l | | | | e | e | e | | | s | | D | | e | | | | | | r | | | | | i | | | | | | | | | | | | | r | | | | | | | | | | | | | a | | | | | | | | | | | | | c | | | | +-------------------------+---+---+---+---+---+---+---+---+---+---+ | | Init Returns Impulse | X | | | GetWave Exists | X | | | Ignore Bits | X | | | Max Init Aggressors | X | | | Tx Jitter | X X X X | | | Tx DCD | X X X | | | Rx Receiver Sensitivity | X X X | | | Rx Clock PDF | X X X X | | +-------------------------+---------------------------------------+ shall be modified as follows (Note, Use_Init_Output is inserted and underbars are inserted in the other Reserved Parameter listings to be consistent with the text.): | +------------------------+-------------------+ | | General Rules | Allowed Usage | | ======================================================================== | | Reserved Parameter | Required Default | Info In Out InOut | | +-------------------------+------------------------+-------------------+ | | Init_Returns_Impulse | Yes NA | X | | | GetWave_Exists | Yes NA | X | | | Use_Init_Output | No True | X | | | Ignore_Bits | No 0 | X X | | | Max_Init_Aggressors | No 0 | X | | | Tx_Jitter | No No Jitter | X X | | | Tx_DCD | No 0 | X X | | | Rx_Receiver_Sensitivity | No 0 | X X | | | Rx_Clock_PDF | No Clock Centered | X X | | +-------------------------+------------------------+-------------------+ | | Table 1: General Rules and Allowed Usage for Reserved Parameters | | | +-------------------------------------------+ | | Data Type | | ======================================================================= | | Reserved Parameter | Float | UI | Integer | String | Boolean | | +-------------------------+-------+------+---------+--------+---------+ | | Init_Returns_Impulse | X | | | GetWave_Exists | X | | | Use_Init_Output | X | | | Ignore Bits | X | | | Max_Init_Aggressors | X | | | Tx_Jitter | X X | | | Tx_DCD | X X | | | Rx_Receiver_Sensitivity | X | | | Rx_Clock_PDF | X X | | +-------------------------+-------------------------------------------+ | | Table 2: Allowed Data Types for Reserved Parameters | | | +---------------------------------------+ | | Data Format | | =================================================================== | | Reserved Parameter | V | R | C | L | I | S | G | D | D | T | | | | a | a | o | i | n | t | a | u | j | a | | | | l | n | r | s | c | e | u | a | R | b | | | | u | g | n | t | r | p | s | l | j | l | | | | e | e | e | | | s | | D | | e | | | | | | r | | | | | i | | | | | | | | | | | | | r | | | | | | | | | | | | | a | | | | | | | | | | | | | c | | | | +-------------------------+---+---+---+---+---+---+---+---+---+---+ | | Init_Returns_Impulse | X | | | GetWave_Exists | X | | | Use_Init_Output | X | | | Ignore_Bits | X | | | Max_Init_Aggressors | X | | | Tx_Jitter | X X X X | | | Tx_DCD | X X X | | | Rx_Receiver_Sensitivity | X X X | | | Rx_Clock_PDF | X X X X | | +-------------------------+---------------------------------------+ ***************************************************************************** Modifications to section 10: The following index: | 2 APPLICATION SCENARIOS | 2.1 Linear, Time-invariant equalization Model | 2.2 Nonlinear, and / or Time-variant equalization Model shall be modified as follows: | 2 APPLICATION SCENARIOS | 2.1 Linear, Time-invariant equalization Model | 2.2 Nonlinear, and / or Time-variant equalization Model | 2.3 Reference system analysis flow ----------------------------------------------------------------------------- The following paragraph 2.1.6 | 6. AMI_Init parses the configuration parameters, allocates dynamic | memory, places the address of the start of the dynamic memory in | the memory handle, computes the impulse response for the [Model] | and passes it back to the EDA platform. shall be modified as follows: | 6. AMI_Init parses the configuration parameters, allocates dynamic | memory, places the address of the start of the dynamic memory in | the memory handle, computes the impulse response of the block and | passes the modified impulse response to the EDA tool. The new | impulse response is expected to represent the filtered response. ----------------------------------------------------------------------------- The following paragraph 2.2.6 | 6. AMI_Init parses the configuration parameters, allocates dynamic | memory and places the address of the start of the dynamic memory in | the memory handle. AMI_Init may also compute the impulse response | of the block and pass the modified impulse response to the EDA tool. shall be modified as follows: | 6. AMI_Init parses the configuration parameters, allocates dynamic | memory and places the address of the start of the dynamic memory in | the memory handle. AMI_Init may also compute the impulse response | of the block and pass the modified impulse response to the EDA tool. | The new impulse response is expected to represent the filtered | response. ----------------------------------------------------------------------------- The following paragraph 2.2.10: | 10. The EDA platform uses the output of the receiver AMI_GetWave function | to complete the simulation/analysis. For transmitter, it simply | passes the output to the receiver AMI_GetWave. shall be modified as follows: | 10. The EDA platform uses the output of the receiver AMI_GetWave function | to complete the simulation/analysis. ----------------------------------------------------------------------------- Insert the following text for item 2.3 immediately before item 3, "FUNCTION SIGNATURES" | 2.3 Reference system analysis flow | | System simulations will commonly involve both TX and RX algorithmic | models, each of which may perform filtering in the AMI_Init call, the | AMI_Getwave call, or both. Since both LTI and non-LTI behavior can be | modeled with algorithmic models, the manner in which models are | evaluated can affect simulation results. The following steps are | defined as the reference simulation flow. Other methods of calling | models and processing results may be employed, but the final simulation | waveforms are expected to match the waveforms produced by the reference | simulation flow. | | The steps in this flow are chained, with the input to each step being | the output of the step that preceded it. | | Step 1. The simulation platform obtains the impulse response for the | analog channel. This represents the combined impulse response | of the transmitter's analog output, the channel and the | receiver's analog front end. This impulse response represents | the transmitter's output characteristics without filtering, for | example, equalization. | | Step 2. The output of Step 1 is presented to the TX model's AMI_Init | call. If Use_Init_Output for the TX model is set to True, the | impulse response returned by the TX AMI_Init call is passed | onto Step 3. If Use_Init_Output for the TX model is set to | False, the same impulse response passed into Step 2 is passed | on to step 3. | | Step 3. The output of Step 2 is presented to the RX model's AMI_Init | call. If Use_Init_Output for the RX model is set to True, the | impulse response returned by the RX AMI_Init call is passed | onto Step 4. If Use_Init_Output for the RX model is set to | False, the same impulse response passed into Step 3 is passed | on to step 4. | | Step 4. The simulation platform takes the output of step 3 and combines | (for example by convolution) the input bitstream and a unit | pulse to produce an analog waveform. | | Step 5. The output of step 4 is presented to the TX model's AMI_Getwave | call. If the TX model does not include an AMI_Getwave call, | this step is a pass-through step, and the input to step 5 is | passed directly to step 6. | | Step 6. The output of step 5 is presented to the RX model's AMI_Getwave | call. If the RX model does not include an AMI_Getwave call, | this step is a pass-through step, and the input to step 6 is | passed directly to step 7. | | Step 7. The output of step 6 becomes the simulation waveform output at | the RX decision point, which may be post-processed by the | simulation tool. | | Steps 4 though 7 can be called once or can be called multiple times to | process the full analog waveform. Splitting up the full analog waveform | into mulitple calls minimized the memory requirement when doing long | simulations, and allows AMI_Getwave to return model status every so many | bits. Once all blocks of the input waveform have been processed, TX | AMI_Close and RX AMI_close are called to perform any final processing | and release allocated memory. | ----------------------------------------------------------------------------- The following paragraph in 3.1.2.1 | The AMI_Init function may return a modified impulse response by modifying | the first column of impulse_matrix. If the impulse response is modified, | the new impulse response is expected to represent the concatenation of the | model block with the blocks represented by the input impulse response. shall be modified as follows: | The AMI_Init function may return a modified impulse response by modifying | the first column of impulse_matrix. If the impulse response is modified, | the new impulse response is expected to represent the filtered response. | The number of items in the matrix should remain unchanged. ----------------------------------------------------------------------------- The following paragraph in 3.1.2.6: | 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: | 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. ----------------------------------------------------------------------------- The following paragraph in 3.2.2.1: | 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. shall be modified as follows: | 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. ***************************************************************************** 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 that 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 === message truncated ===***************************************************************************** ***************************************************************************** BIRD ID#: 108_draft ISSUE TITLE: Fixing Algorithmic Modeling API Impulse_matrix Nomenclature REQUESTER: Bob Ross, Teraspeed Consulting Group DATE SUBMITTED: April 29, 2008 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: PENDING ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: In the Section, "NOTES ON ALGORITHMIC MODELING INTERFACE AND PROGRAMMING GUIDE", the paragraphs describing impulse_matrix have inconsistent usuage of the underbar character. The terms "impulse_matrix" and "impulse matrix" are used. The suggestion is to use impulse_matrix when naming the data and other terms when describing the data or the structure. ***************************************************************************** Replace this text: | 3 FUNCTION SIGNATURES | ===================== | | 3.1 AMI_Init | ============ | | 3.1.1 Declaration | ================= | | long AMI_Init (double *impulse_matrix, | long row_size, | long aggressors, | double sample_interval, | double bit_time, | char *AMI_parameters_in, | char **AMI_parameters_out, | void **AMI_memory_handle, | char **msg) | | 3.1.2 Arguments | =============== | | 3.1.2.1 impulse_matrix | ====================== | | Impulse matrix is the channel impulse response matrix. The impulse values | are in volts and are uniformly spaced in time. The sample spacing is given | by the parameter ‘sample_interval’. | | The ‘impulse_matrix’ is stored in a single dimensional array of floating | point numbers which is formed by concatenating the columns of the impulse | response matrix, starting with the first column and ending with the last | column. The matrix elements can be retrieved /identified using | | impulse_matrix[idx] = element (row, col) | idx = col * number_of_rows + row | row – row index , ranges from 0 to row_size-1 | col – column index, ranges from 0 to aggressors | | The first column of the impulse matrix is the impulse response for the | primary channel. The rest are the impulse responses from aggressor drivers | to the victim receiver. | | | The AMI_Init function may return a modified impulse response by modifying | the first column of impulse_matrix. If the impulse response is modified, | the new impulse response is expected to represent the concatenation of the | model block with the blocks represented by the input impulse response. | | The aggressor columns of the matrix should not be modified. | | 3.1.2.2 row_size | ================ | | The number of rows in the impulse matrix. | | 3.1.2.3 aggressors | ================== | | The number of aggressors in the impulse matrix. | | 3.1.2.4 sample_interval: | ======================== | | This is the sampling interval of the impulse matrix. Sample_interval is | usually a fraction of the highest data rate (lowest bit_time) of the | device. Example: | | Sample_interval = (lowest_bit_time/64) | | 3.1.2.5 bit_time | ================ | | The bit time or unit interval (UI) of the current data, e.g., 100 ps, 200 | ps etc. The shared library may use this information along with the impulse | matrix to initialize the filter coefficients. | -------------- With the following text with changes noted by "|*" lines where "impulse_matrix" is used, and "impulse response matrix" is the descriptive version of the variable": | 3 FUNCTION SIGNATURES | ===================== | | 3.1 AMI_Init | ============ | | 3.1.1 Declaration | ================= | | long AMI_Init (double *impulse_matrix, | long row_size, | long aggressors, | double sample_interval, | double bit_time, | char *AMI_parameters_in, | char **AMI_parameters_out, | void **AMI_memory_handle, | char **msg) | | 3.1.2 Arguments | =============== | | 3.1.2.1 impulse_matrix | ====================== | |* 'Impulse_matrix' is the channel impulse response matrix. The impulse values | are in volts and are uniformly spaced in time. The sample spacing is given | by the parameter ‘sample_interval’. | |* The impulse_matrix is stored in a single dimensional array of floating | point numbers which is formed by concatenating the columns of the impulse | response matrix, starting with the first column and ending with the last | column. The matrix elements can be retrieved /identified using | | impulse_matrix[idx] = element (row, col) | idx = col * number_of_rows + row | row – row index , ranges from 0 to row_size-1 | col – column index, ranges from 0 to aggressors | |* The first column of the impulse_matrix is the impulse response for the | primary channel. The rest are the impulse responses from aggressor drivers | to the victim receiver. | | | The AMI_Init function may return a modified impulse response by modifying | the first column of impulse_matrix. If the impulse response is modified, | the new impulse response is expected to represent the concatenation of the | model block with the blocks represented by the input impulse response. | | The aggressor columns of the matrix should not be modified. | | 3.1.2.2 row_size | ================ | |* The number of rows in the impulse_matrix. | | 3.1.2.3 aggressors | ================== | |* The number of aggressors in the impulse_matrix. | | 3.1.2.4 sample_interval: | ======================== | |* This is the sampling interval of the impulse_matrix. Sample_interval is | usually a fraction of the highest data rate (lowest bit_time) of the | device. Example: | | Sample_interval = (lowest_bit_time/64) | | 3.1.2.5 bit_time | ================ | | The bit time or unit interval (UI) of the current data, e.g., 100 ps, 200 |* ps etc. The shared library may use this information along with the |* impulse_matrix to initialize the filter coefficients. | ***************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION This is an editorial correction to use "impulse_matrix" consistently. ***************************************************************************** ANY OTHER BACKGROUND INFORMATION: ***************************************************************************** ------------------------------------------------------------------------Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20>
--------------------------------------------------------------------- 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