Re: SCE-MI initialization and binding during SystemC constructors

Per,

Right now we use a slightly different form of sc_module
construction than what you show below (and what the original
'Routed' example shows) that solves this problem.

Basically we use,

class my_sc_module : public sc_module {

   public:

     void one_of_my_threads();

     SC_HAS_PROCESS( my_sc_module );

     my_sc_module( const char *name, <additional custom args> ){
         SC_THREAD( one_of_my_threads() );
         ....
     }
}

I think this is becoming a fairly recommended way
of using SystemC modules rather than the SC_MODULE()
which I think was originally intended for SystemC
novices.

You are correct in assuming the original intent of
the ::Bind() call was to circumvent use of the
inflexible SC_MODULE() macro.

With the above more flexible constructor form, ::Bind()
is totally unecessary.

As for port binding within SystemC constructors, I think
this is a good practice as long as non-static sc_module
instantiations are used.

That confines it to automatics or new'ed instances
that come into scope after SceMi::Init() has been called.

Generally, the sequence should go as,

1. SceMi::Init() should be called

2. Then the root sc_module object should be new'ed or
    instantiated as an automatic.

3. Then the SystemC kernel is started.

I don't think any implementation should stipulate whether
binding is allowed in sc_module constructors or not.

The only stipulation is that SceMi::Init() must be called
before any port binding can occur.

The SystemC users must then do what it takes to guarantee
that using techniques like those described above.

Call to bind ports that occur before SceMi::Init() should
result in an error.

-- johnS

Bojsen, Per wrote:
> 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
>

-- 
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________