[ibis-macro] FW: Final review of BIRD 107.1 before it gets submitted to IBIS_ATM
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 8 Apr 2008 09:31:02 -0700
The attached BIRD will be discussed in today's teleconference.
Please familiarize yourself with it before the meeting if possible.
Thanks,
Arpad
====================================================================
________________________________
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, April 08, 2008 9:18 AM
To: Muranyi, Arpad
Cc: Zhen Mu; Todd Westerhoff; Hemant Shah; Brad Griffin; Ambrish Varma
Subject: RE: Final review of BIRD 107.1 before it gets submitted to
IBIS_ATM
Arpad,
Please forward the enclosed updated BIRD 107.1 to the IBIS ATM
distribution. I am prepared to present this to the IBIS ATM meeting
today.
Walter
*****************************************************************************
*****************************************************************************
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 pass 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 optionsal. 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?.
|
------------------------------------------------------------------------------
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 convolves it
with
| 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
*****************************************************************************
Other related posts:
- » [ibis-macro] FW: Final review of BIRD 107.1 before it gets submitted to IBIS_ATM
