[IBIS] RE: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS

I remember the problems caused by C++ destructors that relied on each
other, and were called in different order on different platforms in the
early days of C++. On the theory that there could be multiple TXs in a
simulation as well as multiple RXs, I would suggest specifying only:

1) All Init()s are called before all GetWave()s, which are called before
all Close()s

2) Within each group (Init, GetWave, Close), no function shall be
written in such a way that it depends on the order in which instances of
the same group are called.

3) There *might* be an additional stipulation about interleaving
GetWave() calls so that one instance is not called multiple times
between calls to another instance. For example, TX GetWave() can't be
called 100 times before RX GetWave() is called once. On the other hand
if that is to be allowed it should be explicit.

My opinion is that each model instance preferably should only use memory
associated with the instance, not global "static" memory that could be
shared among multiple instances. But even if they do, no call order
should be assumed. For example, I don't think we should assume that TX
Init() is called before RX Init(). Knowing that the call order among
instances is indeterminate will warn people to create models that are
safe no matter how memory is shared.

Mike

-----Original Message-----
From: ibis-macro-bounce@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of Todd Westerhoff
Sent: Friday, April 04, 2008 9:28 AM
To: Arpad_Muranyi@mentor.com; ibis@eda.org; 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API
(AMI) Support in IBIS

Arpad,

I have given this one a lot of thought, and realized my changing the
BIRD text was another one of those perspective things.  I'm pressed for
time at the moment, but wanted to get this one the wire before I have to
jump into a meeting ...

If we agree models get called in the following sequence:

TX AMI_Init -> RX AMI_Init -> TX AMI_Getwave -> RX AMI_Getwave

Then the original text was okay and I shouldn't have changed it.  I had
a different perspective that let me to think the text needed to be
changed.  I realized the perspective I had was based on a particular
context, one that didn't really reflect how these models would be
executed in an operating EDA platform.

I can go into detail how I got to that point, but I don't think it
matters.  

If everyone else expected the calling sequence I listed above, then we
should just go back to the original text.  This will have been case of
the editor trying to solve a problem that didn't exist.

My apologies for the confusion.

Todd. 


Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@sisoft.com
www.sisoft.com



---------------------------------------------------------------------
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@freelists.org
  Subject: unsubscribe


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993