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

From: Muranyi, Arpad <Arpad_Muranyi_at_.....>
Date: Fri Apr 04 2008 - 12:50:49 PDT
Mike,

You raised a bunch of VERY GOOD and VALID questions, most of which
I haven't thought about before!  I think they are very important
topics and we should discuss them (or even mention them in the
spec).

However, I would like to return to Todd's posting (to which you
replied), which brings up the order of execution question.
-------------------------------------------------------------------

All,

If we go with what was proposed on pg. 18 of the presentation
discussed in the last ATM meeting, the EDA tool will convolve
either the output of Init, OR the unmodified channel response
with the input waveform for GetWave's input.  (I know, Kumar
is warning us not to say "convolved" because there may be other
ways to do this, but for the sake of this discussion I will just
use the word convolve).  Note that neither the presentation, nor
BIRD107 distinguishes between Tx GetWave or Rx GetWave, so I
assume that the above has to be done for both (unless we change
the words).  If the channel response (modified or not) is present
in the input of both Tx GetWave and Rx GetWave, aren't we double
counting the channel response?

Todd seemed to indicate that his execution order rule would take
care of that but I don't see yet how.

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

The order in which convolution is done on various data blocks
doesn't change the outcome.  We can only eliminate the double
counting by eliminating the duplicate input of the channel
response (or modified channel response) somewhere in the chain.
So, is the above order of execution rule supposed to mean that
because of that, one of the channel responses are dropped
somewhere in the chain, meaning that the rules on pg. 18 are
different for Tx GetWave and Rx GetWave regarding the usage
of channel response?

If that is what this means, we need to write separate rules for
Tx and Rx GetWave.  If the order of execution does something
I don't understand yet, we need to write a specific section on
that into our BIRD to describe it to those of us to whom this
is not obvious...

Arpad
==================================================================


-----Original Message-----
From: Mike LaBonte (milabont) [mailto:milabont@cisco.com] 
Sent: Friday, April 04, 2008 9:47 AM
To: twesterh@sisoft.com; Muranyi, Arpad; ibis@eda.org; IBIS-ATM
Subject: 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
Received on Fri Apr 4 12:56:53 2008

This archive was generated by hypermail 2.1.8 : Fri Apr 04 2008 - 12:58:01 PDT