RE: SCE-MI 2.0 and Recursion

Hi all, 

Before it fades away, some comments on points raised at the end of the call
today.

1) Limits on recursion

  My view on this, after working extensively on several test cases in pure
simulation, is that Per's list of cases, items A) through D) is adequate.
Maybe it can be rephrased to make it clearer:
  -- exported functions can be called without restrictions
  -- an exported function  cannot call an imported function
I believe this results in the same specification, am I right?


2) Equivalence/non-equivalence of exported function calls with return values
to exported function calls that call imported functions.

  I think John dismissed this point too fast. Many times, it is useful to do
a "read" of something in the HDL world from C. In SCEMI 1.1, this was
suprisingly complicated. There were 2 types of "reads" we ended up
implementing:
  -- a blocking read: a Send() to an InputPort; a "local" ServiceLoop loop
is entered into until:
                      a callback from the OutputPort returning read data
permits exiting the SL loop
  -- a queued read: Send() and forget; the state of "being in a read" must
be kept track of at
                    higher levels so the "global" ServiceLoop event loop
will handle the ensuing
                    Output port callback's read data correctly.

  A way of translating these "read" operations to SCEMI 2.0 terms: 
  -- a blocking read: an exported function call with a return value
  -- a queued read: a void exported function call; state changes to be kept
track of by higher level C

  (Having a "local" SCEMI 1.1 ServiceLoop called apart from the main SL
could easily get the user into trouble if he wasn't careful, so the extra
complexity in C of a queued read was actually preferred.)

  In SCEMI 2.0 it is convenient to allow an exported function call with a
return value to effect a blocking read operation. But really, the equivalent
SCEMI 1.1 operation looks more like a SCEMI 2.0 sequence of an exported
function calling an imported function. But (I think) allowing the exported
function call with the return value and not allowing imported function calls
within exported functions is a neat way of providing a mechanism for the
blocking read, while allowing a simple 2-rule set for limiting recursion
(and simplifing the task of IFL generation for vendors). That was the point
I was going to make in the call today.


3) Duaine's comments at the end about spawned threads from an initial
imported function calling exported functions are not the same as exported
functions being called by active imported functions 

  This is an important consideration, but not for the subject of recursion:
using the 2-rule syntax I posited above, it doesn't matter if the exported
function calling entity is in the stack space of an imported function or
not.

  It does open the discussion about streaming, concurrency, etc. (still have
to arrive at a strict terminology about these things understandable to
everyone). If a spawned thread is throwing out exported function calls to
the DUT, it may be engaging in streaming. Or, it may be in a purely
concurrent (non-deterministic) system mode (a blind mode without a
throttling mechanism to stop the transfers), which I would argue, is not
streaming since streaming is by definition deterministic. This does
illuminate the linkage between streaming and multi-threading.


---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------



> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf 
> Of Per Bojsen
> Sent: Wednesday, August 24, 2005 2:58 PM
> To: itc@eda.org
> Subject: SCE-MI 2.0 and Recursion
> 
> 
> Hi,
> 
> We are planning to start discussion recursion or more 
> generally mutual calling of DPI functions.  Here are some 
> thoughts on the subject.
> 
> 1) Pure DPI
> 
> By pure DPI, I mean a SCE-MI 2.0 application that does not 
> use the old SCE-MI 1.x message passing mechanism, just DPI.  
> I believe we are considering whether to limit the patterns of 
> mutual calls that are to be allowed and how to limit it if we 
> decide limits are warranted.  Here are some of the scenarios 
> that one could think of (note I am not considering the 
> trivial cases of no mutual calling):
> 
>   a) BFM calls an imported function which calls an exported
>      function or non-time consuming task.
> 
>   b) BFM calls an imported function which calls two or more
>      exported functions or non-time consuming tasks sequentially.
> 
>   c) BFM calls an imported function which calls a time consuming
>      task.
> 
>   d) BFM calls an imported function which calls two or more
>      time consuming tasks.
> 
>   e) Imported function calls exported function calls imported
>      function.
> 
>   f) Imported function calls exported function calls two or
>      more imported functions sequentially (non-time consuming
>      since the exported Verilog function by definition runs
>      in zero time).
> 
>   g) Imported function calls exported time-consuming task calls
>      imported function.
> 
>   h) Imported function calls exported time-consuming task calls
>      two or more imported functions with each call at a different
>      time.
> 
>   i) Imported function calls exported time-consuming task calls
>      two or more imported functions with two or more of those
>      calls at the *same* time.
> 
>   j) Ad nauseam ...
> 
>   k) Unlimited.
> 
> I did not list cases that start with an exported function or 
> task since as far as I understand DPI, the only way the C 
> side can run is as a result of an imported function being 
> called from Verilog. Is this a correct understanding?  If 
> yes, are we retaining this in SCE-MI 2.0?
> 
> Zaiq would like to see support for at least (a) through (d).
> 
> 2) Non-DPI
> 
> Non-DPI is a SCE-MI 2.0 application that uses only the old 
> SCE-MI 1.x features.  Here the issues of mutual calling and 
> recursion include:
> 
>   a) ServiceLoop() calling a Receive() or IsReady() callback which
>      directly or indirectly calls ServiceLoop().
> 
>   b) ServiceLoop() calls a Receive() or IsReady() callback which
>      blocks internally causing a thread switch followed by an
>      eventual call of ServiceLoop() again from some other thread.
> 
> I believe (b) can be viewed as a special case of (a), but it 
> is worth mentioning this case as one may not intuitively see 
> it as similar and potentially problematic.
> 
> Does anyone see other potential recusion issues in SCE-MI 1.x?
> 
> c) Mixed DPI/non-DPI
> 
> We discussed this some time ago and I think we decided to 
> rule this out but I'm mentioning it for completeness.  This 
> is where exported DPI functions are called from Receive() or 
> IsReady() callbacks, for example.  Or SCE-MI 1.x API 
> functions such as Send() are called from imported DPI functions.
> 
> One question about limits if we decide to put them in.  
> Suppose we limit the support of pure DPI mutual calling to 
> (1.a) through
> (1.d) above.  Would we consider such a limit a minimum, i.e., 
> a compliant implementation must at least implement this but 
> is free to implement more or would a compliant implementation 
> be required to issue errors if a user was trying to do (1.e), 
> for example? The C and C++ standards have many examples where 
> the standard only mandates minimums.  This can lead to 
> portability issues if users depend on compilers that support 
> more than those minimums.  On the other hand, it can cause 
> complications for the implementors if required to check for 
> strict compliance.  What does the committee think?
> 
> Thanks,
> Per
> 
> 
> -- 
> Per Bojsen                                Email: <bojsen@zaiqtech.com>
> Zaiq Technologies, Inc.                   WWW:   
> http://www.zaiqtech.com
> 78 Dragon Ct.                             Tel:   781 721 8229
> Woburn, MA 01801                          Fax:   781 932 7488
> 
> 
>