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 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
***************************************************************************** ***************************************************************************** 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 from the AMI_Init and AMI_Getwave calls should be treated as independent. BIRD107.2 has an editorial change in Tables 1 and 2 inserting the underline character in the parameters listing. This is to make the terminology consistent with the text. ***************************************************************************** ANY OTHER BACKGROUND INFORMATION: The thoughts captured in this BIRD were discussed at the April 1, 2008 meeting of the IBIS-ATM Working Group. A slide presentation of this material is available at: http://tinyurl.com/28ouvx *****************************************************************************
***************************************************************************** ***************************************************************************** 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: *****************************************************************************