[ibis-macro] Re: Draft BIRDS107.2 and BIRD108 - Agenda for 4/29/2008
- From: "C. Kumar" <kumarchi@xxxxxxxxx>
- To: bob@xxxxxxxxxxxxx, IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 29 Apr 2008 05:56:49 -0700 (PDT)
There are 2 comments
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
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)
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.
Other related posts:
