Very odd issue

[John Chaparro]

Found an issue with systemC model naming:

if you have 

 

class testMod: public sc_module
{
    public:
    testMod( string  name ) : sc_module(name.c_str() )
    {
        cout << this->name() << endl;
    }
};

instead of the preferred

class testMod: public sc_module
{
    public:
    testMod( sc_module_name  name ) : sc_module(name )
    {
        cout << this->name() << endl;
    }
};

 

if you instance two of them

testMod t1("test1");

testMod t2("test2");

 

the name of t2 would be test1.test2  instead of test2.   I can't say I've ever run across this issue before.  Has anyone else seen then?

[John Chaparro]

usually the above naming would only happen if the model was instanced within TG and the next mem was instanced inside the 1st mem, but clearly I am not doing this.

[John Chaparro]

I am running into this issue currently though even when I use sc_module_name in my modules.   I haven't figured out what is going on there.  I thought maybe the above was the cause but it seems to not be.  

[John Chaparro]

Found the issue:  it seems that if anywhere someone uses a string in their constructor, it will cause odd name behaviors.   Found in another's code they used string on name.   Somehow maybe this should be addressed?

[Eyck]

Can you provide a complete example for the issue to reproduce it? Either as tar-archive or on https://www.edaplayground.com ?

[karthickg]

12 hours ago, John Chaparro said:

Found the issue:  it seems that if anywhere someone uses a string in their constructor, it will cause odd name behaviors.   Found in another's code they used string on name.   Somehow maybe this should be addressed?

Not using `sc_module_name` in the SystemC module constructor is illegal as per the standard.

So your code is not correct. It will also not work if any other module in the system does the same.

From the standard:

Quote

5.3.3 Constraints on usage

Class sc_module_name shall only be used as the type of a parameter of a constructor of a class derived from
class sc_module. Moreover, every such constructor shall have exactly one parameter of type
sc_module_name, which need not be the first parameter of the constructor.

In the case that the constructor of a class C derived directly or indirectly from class sc_module is called
from the constructor of a class D derived directly from class C, the parameter of type sc_module_name of
the constructor of class D shall be passed directly through as an argument to the constructor of class C. In
other words, the derived class constructor shall pass the sc_module_name through to the base class
constructor as a constructor argument.

On why it is illegal, you need to understand how the implementation constructs the module hierarchy with `sc_module_name`. One way of doing that is explained in 5.3.4 Module hierarchy and following sections of the LRM.

[David Black]

The reason was to allow the following syntax:

SC_MODULE( MyModule ) {
  SC_CTOR( MyModule, int var = 10 )
    : my_var{ var }
  {
    /* Body */
  }
private:
  int my_var;
};

Which would expand to become:

struct MyModule : sc_module {
  MyModule( const sc_module_name& instance, int var = 10 )
    : my_var{ var } // Oops, missing sc_module{ instance }
  {
    /* Body */
  }
  SC_HAS_PROCESS(MyModule);
private:
  int my_var;
};

If they inserted the sc_module{ instance } into the macro, then you would have the awkward syntax of:

SC_MODULE( MyModule ) {
  SC_CTOR( MyModule, int var = 10 )
    , MY_VAR{ var } //< Comma looks wrong and is awkward
  {
    /* Body */
  }
private:
  int my_var;
};

So to get around this, they stuck a static variable inside sc_module_name (e.g., latest_str). When you construct an sc_module_name instance, it copies your string into the static. When you call the sc_module() default constructor, it uses the sc_module_name::latest_str. This is a very ugly approach, but works.

If you want a module that takes a string for a module constructor, the following works, with the caveat that if somebody inherits from your class, they will not be able to pass in an sc_module_name unless you provide an alternate constructor (i.e., overload):

struct MyModule : sc_module {
  explicit MyModule( const std::string& instance, int var = 10 )
    : sc_module{ sc_module_name{ instance.c_str() } }
    , my_var{ var }
  {
    /* Body */
    SC_HAS_PROCESS(MyModule); //< if needed, this is the best place
  }
private:
  int my_var;
};

Don't forget that since C++11, you can also delegate constructors (DRY principle).

Parting comments:

1. Proficiency in C++ makes you a better SystemC programmer
2. Don't ignore *any* warnings. Compile with -Wall -Wextra -pedantic and don't settle for anything less than zero warnings.
   • 99% of warnings are disguised errors
   • You can suppress individual warnings inside the code if you can convince your coworkers.