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

  • From: Essaid BENSOUDANE <essaid.bensoudane@xxxxxx>
  • To: <scott@xxxxxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>
  • Date: Thu, 3 Apr 2008 12:29:41 -0400

All,
I'm far to be an expert in developing AMI model, even though I developed
successfully a full SERDES model recently. If the AMI standard is seen as an
interface between model developers and EDA tools I think the interface
definition where you have an init function were memory are allocated, and
Get_wave function to process data plus a close function to clean memory is
classic and it's the right way to pass data between those functions.

The tree functions should be seen a top level as C++ class with constructor
(init), functions to process data, and close (destructor). In this case
creating a shared memeory space in the heap using malloc or new and
destoryed at the end of simulation is the right way to go. As a model
developer I would like to have control on model memory managments instead of
an automatic grabage collecteur who may slow down my simulation. By
comparing a program written in C++, JAVA or .NET, it's obvious that a C++ is
much faster. 

Designing Get_wave function for a real SERDES requires a more elaborate
programming structure using a form of data flow oriented processing where
communications between design entities are passed using well defined
communication ports. Other model developers may choose to go with a
procedural style programming using pointer everywhere, which reduce model
structure (a bad programming style for an algorithm to be transformed later
to hardware).
I don't think the objective of ATM subcommittee is to define SERDES
programming model style, which depend on the language, but only to define
interface between model developers and EDA tools using the LTI modeling
assumptions. I May be I'm completely out of the loop!!!!

Best regards,

Essaid Bensoudane

  
 

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Thursday, April 03, 2008 11:58 AM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: IBIS-ATM
Subject: [ibis-macro] Re: [!! SPAM] Re: IBIS-AMI Correlation and BIRD Update
- comments

Guys,

As an outside observer, with no stake in this, I'd highly suggest that y'all
enlist the aid of an expert in C++ programming, and get an unbiased opinion
on what the best method for holding open a block of memory for Get_Wave is.
From my perspective, it seems to me that the calling program should be
responsible for all persistent memory needs, and that any called routine
should be responsible only for transient memory requirements, which are
flushed upon return.  A possible solution to the problem would be to have a
call whereby Get_Wave returns it's memory requirements.  Once that is
established, the main program passes a pointer to the allocated block of
memory.

But what do I know?

Scott


Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed® is the registered service mark of Teraspeed Consulting Group LLC



Muranyi, Arpad wrote:
> Todd,
>
> 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 
> **AMI_parameters_out 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.
>
> Thanks,
>
> Arpad
> ====================================================================
>
>
>
> -----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
> To: 'IBIS-ATM'
> Subject: [ibis-macro] Re: IBIS-AMI Correlation and BIRD Update - 
> comments
>
> Arpad,
>
> 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.
>
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh@xxxxxxxxxx
> www.sisoft.com
> ---------------------------------------------------------------------
> 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

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