*/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 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
=== 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>
