[ibis-macro] Re: IBIS-AMI Correlation and BIRD Update - comments
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 3 Apr 2008 10:21:08 -0700
Essaid,
Thanks for your comments. If Init, GetWave and Close would be
designated like you say to act as constructor, method, and destructor,
I would probably be OK. The problem is that Init is not strictly
a constructor. It does have signal processing code, or "method"
in it. And the information between Init's and GetWave's methods
are exchanged "privately" in persistent memory without going though
their function call arguments. (At least in the current Tx example).
I agree, we should probably not get concerned about programming style,
but I think we can be concerned about the interface style...
Thanks,
Arpad
=======================================================================
-----Original Message-----
From: Essaid BENSOUDANE [mailto:essaid.bensoudane@xxxxxx]
Sent: Thursday, April 03, 2008 9:30 AM
To: scott@xxxxxxxxxxxxx; Muranyi, Arpad
Cc: 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: [!! SPAM] Re: IBIS-AMI Correlation and BIRD
Update - comments
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
---------------------------------------------------------------------
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:
