Jump to content

sc_report_handler affects the simulation itself


Recommended Posts

Dear all,

i am designing a network simulator where a lot of messages are flying around. For logging and debugging the states of the modules and the simulation i use the sc_report_handler class.

In main.cpp i set the following options:

sc_report_handler::set_actions(SC_INFO, SC_LOG);
sc_report_handler::set_actions(SC_WARNING, SC_LOG);

verbosity is a variable passed from a configuration file.

In my files/modules etc i have usually code like this to print into the log file:

std::stringstream ss;
ss << this->name() << " some message, maybe with variables like x: " << x;
SC_REPORT_INFO_VERB(msgId, ss.str().c_str(), sc_core::SC_DEBUG);

I use the stringstream to format like i want and set the verbosity. I have a lot

Before i start the simulation i read a configuration file with lots of parameters. There is also the verbosity level inside:

# Verbosity level
# None, Low, Medium, High, Full, Debug
verbosity = None

In my code i have several SC_REPORT_INFO_VERB commands with different verbosity levels, so that i can track different information on my needs for debugging.

Now to my problem/question:

Depending on the verbosity i get different simulation results. How the sc_report_handler can affect the simulation? Maybe i am doing something wrong, bit this behavious is really confusing for me.

Thank you very much.

Link to comment
Share on other sites

One reason I've seen in the past quite often are uninitialized local variables being used in the control flow:

int a;
unsigned b = a;
} else {

Although b seems to be initialize it gets its value uninitialized. Hwo would logging effect this? Depending on the configuration the stack being used has different residual values (from previous funcion executions). Therefore 'a' gets different -unitialized- values which are later used to steer the control flow. Therefore my mantra is always: initialize variables upon declaration. In C++11 this becomes quite easy:

int a{0};
// or better:
auto a=0;

The use of auto requires an initialization whioch is enforce by the compiler then which is quite handy.

Aside of that: maybe you would want to have a look at https://github.com/VP-Vibes/SystemC-Components/blob/master/incl/scc/report.h and https://github.com/VP-Vibes/SystemC-Components/blob/master/src/report.cpp which provide a more convenient logging interface on top of the plain SystemC report infrastructure.

Link to comment
Share on other sites

Thank you for your fat reply.

I think some uninitialized variables could be the problem. I trying to check this, but this is really hard, because the code is quite big now. Is there a easy way to test such things automatically?

Thank you for the links, i will a look at it.

Link to comment
Share on other sites

  • 1 month later...


1. use stricter compilation rules such as -pedantic -Wall -Wextra and require all compilations to have zero warnings. This methodology will catch most errors. Use Ptah as to make exceptions around specific warnings you allow but only when you are certain and only for short code segments. 
2. Switch from g++ to clang++
3. Run static analysis and lint tools on your code 

Consider using Jetbrains’ CLion toolset. Inexpensive for what it does. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...