SystemC design guidelines

[Weiwei Chen]

I need some expert idea on defining SystemC modules and classes.

Are there any design guidelines on defining SystemC modules, channels and regular C++ classes for the following situations:

1. Define a class drived from sc_module in a class that is also derived from sc_module, e.g

class Top : public sc_module

{

public:

class A : public sc_module

{

};

};

2. Define a regular C++ class in a class that is derived from sc_module, e.g

class Top : public sc_module

{

public:

class A

{

};

};

3. Define a class drived from sc_module in a regular C++ class, e.g.

class Top

{

public:

class A : public sc_module

{

};

};

4. Define a class drived from sc_channel in a class that is derived from sc_module, e.g

class Top : public sc_module

{

public:

class A : public sc_channel

{

};

};

and vice versa, e.g.

class Top : public sc_channel

{

public:

class A : public sc_module

{

};

};

These definitions are technically allowed by C++. I am not sure if they are also considered as good practice in C++ or not desirable according to SystemC design guidelines.

Thank you very much!

[dakupoto]

Hello,

SystemC is basically a standard ANSI C++ library. So whatever

applies to C++, applies to SystemC as well. However, it is not

really a good design practice to have an inheritance hierarchy

more than 3 - 4 levels deep - things become too complicated

to keep track of, correctly.

[Philipp A Hartmann]

As in all C++ code, nested classes should be the exception, not the rule. I recommend the discussion given in the Google C++ Style Guide.

My short SystemC-specific answer:

• In SystemC models, nested classes should not be defined.
  
• In SystemC methodology libraries (e.g. TLM-2.0, or your own support libraries), there are rare, but valid use cases for nested classes.
  

Before discussing some of these exceptions, why do you want to use nested classes in the first place?

/Philipp

[david.wcc]

Please get "systemc 2.0.1 language reference manual" online with google.

In chapter 7 Modules, it will show you how to define a sc_module .

[Weiwei Chen]

Actually, I am working on a SystemC front-end now. I need to know if such case will actually happen in real design so that my front-end parsing/analysis tool will not mishandle it.

From the modeling perspective, it might be handy to have some embedded classes, e.g. define an arbiter class in the class for bus protocols. This should be doable in C++. I'm just curious whether the SystemC design guidelines discourage embedded classes so that my front-end tool can omit such complicated situation, or not.

Thanks!

[Philipp A Hartmann]

As I said in my previous post, nested classes are usually not a very good design pattern. Your example of the arbiter class is not very convincing either, as you may want to reuse (or replace) this arbiter as well. For a "real" use case of nested classes, you inherently need a very strong coupling between the outer and the inner class. Most likely, the inner class won't (or shouldn't) be used outside the implementation of the outer class. But this can of course include the above-mentioned SystemC-specific inheritance relationships as well.

From the frontend/parsing point-of-view, you probably want to support such cases. If you want to (fully) parse the TLM-2.0 convenience sockets, you'll encounter an example of such a use-case.

I'm not aware of SystemC-specific coding guidelines that talk about nested classes explicitly. From the (C++) language point-of-view, it's just another scoped identifier. Still, many widely adopted C++ coding guidelines discourage the use of nested classes.

Greetings from Oldenburg,

Philipp

[Weiwei Chen]

Thanks, Phillipp, I think my tool will need to support nested classes although using such way of coding needs a lot of discretions.

It might happen that some designs need certain type of classes just be private in its parent class, for a clean design perspective.

I'll take a look at the convenience sockets in TLM-2.0 for more details. Thank you very much for directing me to these cases.

Greetings from Irvine!

--

Weiwei