[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 10:08:58 -0500

Kumar-

Responses inserted below.

Mike S.

C. Kumar wrote:
mike:
I understand that there are different flows. but still I do not see why a model will modifying the impulse response sent by the eda tool unless it wants the eda tool to use that impulse response. it does not make sense to me.
The question is not whether or not the EDA platform will use the modified impulse response, but _how_ the Model expects the EDA platform to use the modified impulse response. Ideally, we would have a name for the parameter which more clearly indicates its meaning; however, use_init_output_when_generating_getwave_input seemed a little long at the time. (-;

for the second point i am thinking if a model is just going to modify the impulse response, the dll should not even contain a getwave call.
That's only one of several viable (and important) options. We support valuable flows right now which use the modified impulse response and then call GetWave.

for memory I agree the owner of the memory has to be identified, I was only suggesting that the ownership reside with the eda tools so as to minimize memory management tasks for the model developers. Again if you want the model to own parameter_out memory , does the same rule apply to the 'msg' memory too?
There's an old saying that a programming task must be made as simple as possible, but no simpler than that.

As regards msg, Yes, I believe that the Model should own that memory because it's the only the Model which knows how long the message is going to be. Furthermore, the Model must de-allocate that memory in the Close() function. That is, in fact, what we implemented and published in the SiSoft transmit model.

The other options would either be for the EDA platform to communicate the maximum message length to the Model, or else for the Model and the EDA platform to negotiate the message length. I submit that neither of these two options would make the model developer's life any easier.

*/Mike Steinberger <msteinb@xxxxxxxxxx>/* wrote:

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

    === message truncated ===


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