SCE-MI initialization and binding during SystemC constructors

Hi,

the SystemC Routed example uses special user-defined Bind()
methods to do message port binding. I was wondering if there
is anything implicitly or explicitly in the SCE-API either
in the intent or in the text that would prevent one from
doing message port binding and even SceMi::Init() from one
or more SystemC constructors? I don't think so myself, but
I wanted the committees view on this and perhaps some
background on why the SystemC example is the way it is. The
only reason I can think of is that it used not to be possible
to define SystemC constructors that can take user-defined
arguments. However, SystemC 2.0 allows that by way of the
SC_HAS_PROCESS macro:

  // SystemC 1.0 style
  SC_MODULE(foo)
  {
    // No user defined constructor arguments allowed.
    SC_CTOR(foo) { }
  };

  // SystemC 2.0
  SC_MODULE(foo)
  {
    // Let SystemC know that our constructor defines processes.
    SC_HAS_PROCESS(foo);

    // Constructor must include sc_module_name argument.
    foo(sc_module_name ModuleName, SceMi *SceMiPtr) :
      sceMiPtr(SceMiPtr)
    {
    }
  };

Using SystemC constructors this way would eliminate the need
for the Bind() methods in the Routed example. Is there anything
inherent in the SCE-API spec that would cause problems for
such an approach?

Given that SCE-API is supposed to work with any multi-threading
system it would appear difficult to put anything in the spec
that talks specifically about integration of SCE-API and SystemC.
However, it is an important issue for users. For instance, if
vendor A's SCE-API implementation for whatever reason does not
allow message port binding from within SystemC constructors
but vendor B's implementation does, then it is easy to see how
the user could get in trouble and end up with a non-portable
application.

Perhap this will have to be resolved at a different layer as
a standard that talks specifically about interoperation of
SCE-MI and SystemC. Similarly, there may be issues with
SCE-MI and SystemVerilog, etc.

Per
Received on Thu May 13 08:39:06 2004