[ibis-macro] Re: Draft BIRDS107.2 and BIRD108 - Agenda for 4/29/2008
- From: "C. Kumar" <kumarchi@xxxxxxxxx>
- To: msteinb@xxxxxxxxxx
- Date: Tue, 29 Apr 2008 07:50:21 -0700 (PDT)
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.
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.
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?
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.
Other related posts: