[ibis-macro] Re: Draft BIRDS107.2 and BIRD108 - Agenda for 4/29/2008

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: kumarchi@xxxxxxxxx
  • Date: Tue, 29 Apr 2008 09:41:00 -0500

Kumar-

The questions are not as simple as you imagine, and there are options you apparently haven't considered. Detailed responses below.

Mike S.

C. Kumar wrote:
There are 2 comments
Ummm... 3 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
You are only assuming one particular flow. In point of fact, there are multiple flows possible, some of which use an impulse response output from AMI_Init in ways which have nothing whatever to do with AMI_GetWave. The use_init_output helps to allow all of these flows to be possible.

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
What are you therefore proposing?

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)
That's one point of view, but not at all the only view held within the C/C++ programming world. A very popular point of view (and the one I happen to hold) is that while the owner of the memory needs to be clearly defined, it is not automatically the case that the caller must be the owner of the memory. For example, the EDA platform (that is, the caller) can't be the owner of the Model's memory because it doesn't even know how much memory to allocate or when to de-allocate it, which is why we have **AMI_memory_handle and AMI_Close().

I believe that the really important principle is that the owner of the memory be clearly identified, and that whichever object owns the memory does all of the allocation, modification, and de-allocation of that memory. That, after all, is the most fundamental principle of object oriented programming.

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


---------------------------------------------------------------------
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  http://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
 To: ibis-macro-request@xxxxxxxxxxxxx
 Subject: unsubscribe

Other related posts: