As per my action item, the Routed example has been retrofitted 
with the new SC_MODULE constructor forms that allow additional 
arguments to be passed to constructors of sc_module's for a 
more flexible use model. 

Old form: 

SC_MODULE( my_sc_module ){ 
    public: 
      void one_of_my_threads(); 
      SC_CTOR( my_sc_module ) 
      { 
          SC_THREAD( one_of_my_threads() ); 
          .... 
      } 
} 

New form: 

class my_sc_module : public sc_module { 
    public: 
      void one_of_my_threads(); 
      SC_HAS_PROCESS( my_sc_module ); 

      my_sc_module( sc_module_name name, <additional custom args> ) 
        : sc_module(name) 
      { 
          SC_THREAD( one_of_my_threads() ); 
          .... 
      } 
} 

The following sections are affected and the code samples contained 
therein should be replaced with the equivalents found in the 
attached files. 

A.2.4.1 Entire SC_MODULE(System){ } should be replaced with corresponding 
code in attached System.cxx 

A.2.4.2: All code for errorHandler() and sc_main() should be replaced 
with corresponding code in attached System.cxx 

A.2.4.3: Entire SC_MODULE(SceMiDispatcher){ } should be replaced with 
corresponding code in attached SceMiDispatcher.hxx 

A.2.4.5: Entire SC_MODULE(Testbench){ } should be replaced with 
corresponding code in attached Testbench.hxx 

A.2.4.6: Entire SC_MODULE(Scheduler){ } should be replaced with 
corresponding code in attached Scheduler.hxx 

A.2.4.6.2 All this code is now contained inside the ::Scheduler() 
constructor. The explanatory text should be moved to the end 
of A.2.4.6 and this entire section should be removed. 


======================================================


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 
>