[ibis-macro] Re: Comments on BIRD 107.1

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 10 Apr 2008 18:31:59 -0400

All,

I have incorporated the changes Arpad has suggested in this E-mail. Note
that "Step 4" now says

|  Step 4. The simulation platform takes the output of step 3 and filters
the input
|          bitstream and a unit pulse to produce an analog waveform.

I (and SiSoft) believe that the BIRD can be submitted as enclosed.

Walter

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Thursday, April 10, 2008 3:36 PM
To: IBIS-ATM
Subject: [ibis-macro] Comments on BIRD 107.1

Hello everyone,

I read through the 107.1 draft, and found a couple of minor editorials.
Other than these, we can submit it as far as I am concerned.



1)  Grammar:  in the text of 2.1.6 we should change "pass" to "passes".

2)  Kumar suggested not to use the word "convolves".  Is this something
we would want to eliminate from "Step 4"?

3)  At the end, we should add that this was discussed on the 4/1 and 4/8
meetings:

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



Thanks,

Arpad
=========================================================================
*****************************************************************************
*****************************************************************************

BIRD ID#:        107.1
ISSUE TITLE:     Update to Algorithmic Modeling API (AMI) Support in IBIS
REQUESTER:       Todd Westerhoff, SiSoft and Zhen Mu, Cadence Design Systems
DATE SUBMITTED:  April 8, 2008
DATE REVISED:    
DATE ACCEPTED BY IBIS OPEN FORUM:  PENDING

*****************************************************************************
*****************************************************************************

STATEMENT OF THE ISSUE:

The waveform input to a TX AMI_Getwave call and the filtering function to be
performed by the AMI_Getwave call were ambiguous.  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. 


*****************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:


Modification to section 2

The following secion 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 changed to 

|   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 section 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 changed to 

|  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 in secition 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. 

shalle be changed to

| 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.




Modifications to section 6C:


The following paragraph:

|              Reserved Parameters:
|
|              Init_Returns_Impulse, GetWave_Exists, Max_Init_Aggressors and
|              Ignore_Bits

shall be modified as follows:

|              Reserved Parameters:
|
|              Init_Returns_Impulse, Use_Init_Output, GetWave_Exists, 
|              Max_Init_Aggressors and Ignore_Bits

------------------------------------------------------------------------------

The following paragraph:

|              GetWave_Exists:
|
|              GetWave_Exists is of usage Info and type Boolean.  It tells
|              the EDA platform whether the ?AMI_GetWave? function is
|              implemented in this model.  Note that if Init_Returns_Impulse
|              is set to ?False?, then Getwave_Exists MUST be set to ?True?.
|
|              The following reserved parameters are optional.  If these
|              parameters are not present, the values are assumed as ?0?.


shall be modified as follows:

|              GetWave_Exists:
|
|              GetWave_Exists is of usage Info and type Boolean.  It tells
|              the EDA platform whether the ?AMI_GetWave? function is
|              implemented in this model.  Note that if Init_Returns_Impulse
|              is set to ?False?, then Getwave_Exists MUST be set to ?True?.
|
|                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 have

|                           +------------------------+-------------------+
|                           |  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 paragraph in item 2.2:

| 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 filters 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:

| 3.1.2.6 AMI_parameters (_in and _out)
| =====================================
|
| Memory for AMI_parameters_in is allocated and de-allocate by the EDA.  The
| memory pointed to by AMI_parameters_out is allocated and by the model. 


shall be modified as follows:

| 3.1.2.6 AMI_parameters (_in and _out)
| =====================================
|
| Memory for AMI_parameters_in is allocated and de-allocated by the EDA 
platform. The 
| memory pointed to by AMI_parameters_out is allocated and de-allocated by the 
model. 

------------------------------------------------------------------------------

The following paragraph:

|
| 3.2.2.1 wave
| ============
|
| A vector of a time domain waveform, sampled uniformly at an interval
| specified by the ?sample_interval? specified during the init call.  The
| wave is both input and output.  The EDA platform provides the wave.  The
| algorithmic model is expected to modify the waveform in place.
|
| Depending on the EDA platform and the analysis/simulation method chosen,
| the input waveform could include many components.  For example, the input
| waveform could include:
|

shall be modified as follows:

|
| 3.2.2.1 wave 
| ============
|
| A vector of a time domain waveform, sampled uniformly at an interval
| specified by the ?sample_interval? specified during the init call. The
| wave is both input and output. The EDA platform provides the wave. 
| The algorithmic model is expected to modify the waveform in place by 
| applying a filtering behavior, for example, an equalization function,
| being modeled in the AMI_Getwave call.
|
| Depending on the EDA platform and the analysis/simulation method chosen,
| the input waveform could include many components.  For example, the input
| waveform could include:
|


*****************************************************************************

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.

*****************************************************************************

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

*****************************************************************************

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>




Other related posts: