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