[ibis-macro] Re: IBIS-AMI Correlation and BIRD Update - comments

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: Arpad_Muranyi@xxxxxxxxxx
  • Date: Thu, 03 Apr 2008 12:40:20 -0500


It looks like there's still a misunderstanding how persistent memory gets
allocated and used in the SiSoft reference TX model.  Let's take a closer
look at the published code for the TX model.

The persistent memory in IBIS_AMI_Tx is allocated in two steps. First
of all, a structure is allocated to store all of the persistent
variables used by the model. This is a classic object-oriented C
programming technique. The statements in the AMI_Init function in the C
file are

  AtmTxModel *self;
  self = (AtmTxModel*)malloc( sizeof( AtmTxModel ) );

The AtmTxModel data type is defined in the header file.  The statement is

typedef struct {
  double taps[4];        //Absolute values should normalize to 1.
  double swing;          //Peak to peak differential
  double *out_buf;       //Output buffer, including pending outputs
  double last_in;        //Last input sample from previous data block
  int row_size;          //Length of step response
  int buf_size;          //Size of output buffer
  int samples;           //Number of samples per symbol
  int wr_ptr;            //Read/Write pointer to use out_buf as a FIFO.
  double sample_interval;
  double bit_time;
  char *params_out;      //Transmitter configuration echoed back to caller
  char *msg;             //Information message echoed back to caller
} AtmTxModel;

Note that this structure contains the element last_in. As explained in
the comment associated with that element, that data element in the
structure is used to save data from the previous call to GetWave. It is
persistent memory, used exactly as I described in my previous e-mail.

Another, slightly more complex example is the out_buf element of the
AtmTxModel structure. This is a pointer to an array of doubles, and the
array that it points to is allocated in AMI_Init by the statement

  //Allocate the input delay buffer for time domain processing.
  self->out_buf = (double*)malloc( 4*self->samples*sizeof( double ) );

As the associated comment indicates, the out_buf element is used as
persistent memory in time domain processing (i.e., GetWave).

These are basic programming techniques that are universally used by C
programmers.  They may not seem familiar to those without C experience,
but I do expect that any vendor developing a model would have access to
people with the appropriate coding experience.

Hope this helps.
Mike S.

Muranyi, Arpad wrote:

Thank you for your reply.  I would very much like to take the challenge
in the last sentence of your email to write up something on memory
management for discussion, but I have to admit that I can probably not
claim much more C programming experience than you do.  So I can only
make sketchy suggestions.

I looked at the memory management of the SiSoft example Tx to see how
it allocates memory for various purposes.  I don't claim yet that I
understand each malloc statement to the fullest detail, but from what
I can tell now, the Init function does NOT allocate the memory for
GetWave for the sliding window algorithm.  Please correct me if I am
wrong, but to me it seems that GetWave does the memory allocation for
that on its own.

So given the conclusions from my previous message, that with the current
understanding the output of Init is passed to GetWave through the
function arguments (and not through persistent memory as previously
done), AND this observation about GetWave allocating its own memory
for the sliding window algorithm, it SEEMS that we do NOT NEED to
rely on persistent memory to achieve the tasks of these functions.

I don't think we have to put preventive measures into the spec against
using persistent memory, but I would like to have an option to be
able to write (simpler?) models without it.

I think we are very close to be able to do that.  If we had another
*AMI_parameters_in argument for GetWave, it seems that it could be
done without any further changes.

And what if we distributed two versions of the same example Tx model
then?  One that uses no persistent memory and another which does?

So, in summary, both functions return their results in place.  (This
is true for either method, including *clock_times, interesting comment
this morning, Mike).  This ensures that the caller can free the memory
used for the input and output.  The init function takes care of the
parameter tree parsing, and leaves the results in the
argument, which can be passed into the GetWave function through the
proposed *AMI_parameters_in argument when no persistent memory is set
up by Init.  (This could be done through the persistent memory also
if one is so inclined, but wouldn't have to be done that way).

GetWave would allocate its own memory for the sliding window and
pass its address to the caller so that at the end it can be freed
by the caller (or passed on by the caller to AMI_close to be freed
up by AMI_close) through the existing *AMI_memory argument.  If
persistent memory is set up by Init, its **AMI_memory_handle could
be used for this as well as other persistent memory stuff.  (I
hope my understanding is correct on this).

I know this may have some flaws due to my limited C knowledge, but
I hope that we can come up with a working model somewhere along
these lines to support both methods.  Programming experts, please
chime in with your comments.



-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Wednesday, April 02, 2008 9:39 PM
Subject: [ibis-macro] Re: IBIS-AMI Correlation and BIRD Update -


You've made the interesting observation that the convolution performed
by the EDA tool when
"Use_Init_Output = True" is a close parallel to the convolution
performed by the original SiSoft TX
model based on SiSoft's original interpretation of the TX AMI_Getwave
input waveform.  There's more
than a bit of serendipity in that ... it's a point that I didn't try to
make explicitly in the
presentation on Tuesday, partly because it's subtle, and partly because
it relies on intimate
knowledge of the reference model not that many people have.

The moral of the story is - convolution is convolution.  Whether it's
done by the EDA tool or inside
the model's AMI_Getwave call, the answer should the same - and that is,
in fact, what we saw.

Thanks for your suggestions on clarifications for the BIRD - that's the
next thing on my plate, and
I'll try to incorporate them.

As far as the persistent memory discussion goes - I don't think I'm a
good judge for the merits of
one technical implementation or another.  The existing spec allows
AMI_Init to allocate whatever
amount of memory it wants based on the way the model developer has
written AMI_Getwave and the block
size in question.  There are other ways to allocate memory, as you point
out, but I'm not sure if it
ends up being simpler than what we have now, or just different.  I don't
claim to be a competent "C"
programmer, nor do I play one on TV.  I'm going to leave comments on
different styles of memory
allocation to others who know more than I do.

I think we've come to the point where we need to be talking about a
specific memory management
scheme and how it compares to what we have now.  Do you want to write
something up for discussion?


Todd Westerhoff
VP, Software Products
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe

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

Other related posts: