Eyck

Hi Aarthi,
if you just need to get the currently active module when hitting a breakpoint in you C++ code you might use the following command (assuming you use gdb):
x sc_core::sc_get_current_process_b()->get_parent()->name() (see also here: https://stackoverflow.com/questions/18078226/how-to-get-sc-module-name-of-the-current-running-module#18123785)
What it does is it calles the SystemC kernel function sc_get_current_process_b() which returns a pointer to sc_process_b (the base class of of sc_method_process and sc_thread_process). Inheriting from sc_obejt it also has a name() method so you could also do
x sc_core::sc_get_current_process_b()->name() which just returns the full hierarchical name of the process.
HTH
-Eyck

Hi Sumit,
Quoting http://en.cppreference.com:
 
Some member functions are special: under certain circumstances they are defined by the compiler even if not defined by the user. They are:
Default constructor Copy constructor Move constructor (since C++11) Copy assignment operator Move assignment operator (since C++11) Destructor  
So in the code you show you just delete the default constructor and the destructor. Obviously this does not make sense as you cannot construct any object since you do not have a parameterized constructor. But if you have one this declaration makes sense: the user of this class cannot create a default object, he has to provide some parameters. Deleting the destructor prohibits the creation of an object on the stack, you can only create them on the heap (and never release the memory except you use placement new on a pre-allocated area).
But the the standard comittee has a special section on this in the C++ core Guidelines: C.21: If you define or =delete any default operation, define or =delete them all
BTW, if you inherit from a class having a deleted destructor the destructor of the child is also deleted
HTH
-Eyck

Hi Kevin,
if you check here https://github.com/Minres/SystemC-Components/blob/master/incl/scc/utilities.h there are three macros which make live easier:
#define TRACE_VAR(F, X) sc_core::sc_trace(F, X, std::string(this->name()) + "." #X) #define TRACE_ARR(F, X, I) sc_core::sc_trace(F, X[I], (std::string(this->name()) + "." #X "(" + std::to_string(I) + ")").c_str()); #define TRACE_SIG(F, X) sc_core::sc_trace(F, X, X.name()) They can be used with local variables and arrays as well with SystemC objects providing the name() funtion. This way tracing a signal becomes as easy as (assuming _STATE_ being a signal or port):
 
TRACE_VAR(_trace_, top.dpu.idu.weight_reader.m_traffic_gen._STATE_); Pls. note: the first 2 macros are assumed to be used within a sc_module.
HTH
-Eyck

Hi Kevin,
if you check here https://github.com/Minres/SystemC-Components/blob/master/incl/scc/utilities.h there are three macros which make live easier:
#define TRACE_VAR(F, X) sc_core::sc_trace(F, X, std::string(this->name()) + "." #X) #define TRACE_ARR(F, X, I) sc_core::sc_trace(F, X[I], (std::string(this->name()) + "." #X "(" + std::to_string(I) + ")").c_str()); #define TRACE_SIG(F, X) sc_core::sc_trace(F, X, X.name()) They can be used with local variables and arrays as well with SystemC objects providing the name() funtion. This way tracing a signal becomes as easy as (assuming _STATE_ being a signal or port):
 
TRACE_VAR(_trace_, top.dpu.idu.weight_reader.m_traffic_gen._STATE_); Pls. note: the first 2 macros are assumed to be used within a sc_module.
HTH
-Eyck

When reading the signal 'inter' right after writing  to it (line 25 of the referenced code) you read the current value and not the scheduled (new) value. Writes to signals (as part of methods or threads) are executed in the evaluation phase of the simulation kernel while the value is assigned during the update phase of the kernel (see also https://ptolemy.berkeley.edu/projects/embedded/research/hsc/class/ee249/lectures/l10-SystemC.pdf?46).
If you read a signal in the same evaluation phase you are writing to it, you will always get the current value, not the new (scheduled) value. If you have several assignments to the signal the last one will always win. I.e. lets assume you have a signale  and a thread like:
void thread(){ sig.write(42); wait(0, SC_NS); // advance by 1 delta cycle sig.write(1); cout<<"Sig is "<<sig.read()<<std::endl; sig.write(2); cout<<"Sig is "<<sig.read()<<std::endl; sig.write(3); cout<<"Sig is "<<sig.read()<<std::endl; wait(SC_ZERO_TIME); // same as the last wait(), advance by 1 delta cycle cout<<"Sig is "<<sig.read()<<std::endl; } you will get the output:
Sig is 42 Sig is 42 Sig is 42 Sig is 3 because the update to sig will only happen during the wait() call.
I hope this answers your question.

sc_signal only triggers an event if you write a value different from the current one. If you want to trigger events and hence invoke method/sc_thread you need to use sc_buffer instead of sc_signal. It is a drop-in replacement.
Best regards

When reading the signal 'inter' right after writing  to it (line 25 of the referenced code) you read the current value and not the scheduled (new) value. Writes to signals (as part of methods or threads) are executed in the evaluation phase of the simulation kernel while the value is assigned during the update phase of the kernel (see also https://ptolemy.berkeley.edu/projects/embedded/research/hsc/class/ee249/lectures/l10-SystemC.pdf?46).
If you read a signal in the same evaluation phase you are writing to it, you will always get the current value, not the new (scheduled) value. If you have several assignments to the signal the last one will always win. I.e. lets assume you have a signale  and a thread like:
void thread(){ sig.write(42); wait(0, SC_NS); // advance by 1 delta cycle sig.write(1); cout<<"Sig is "<<sig.read()<<std::endl; sig.write(2); cout<<"Sig is "<<sig.read()<<std::endl; sig.write(3); cout<<"Sig is "<<sig.read()<<std::endl; wait(SC_ZERO_TIME); // same as the last wait(), advance by 1 delta cycle cout<<"Sig is "<<sig.read()<<std::endl; } you will get the output:
Sig is 42 Sig is 42 Sig is 42 Sig is 3 because the update to sig will only happen during the wait() call.
I hope this answers your question.

Hi,
you cannot bind interface to e.g. a class implementing those interface. What you can bind are sc_port and sc_export. So you would need to change your declaration to
sc_core::sc_port< sc_core::sc_fifo_out<int> > output1; sc_core::sc_port< sc_core::sc_fifo_in<int> > input1; But this is not going to solve your problem as you cannot trace an sc_core::sc_fifo_out interface. Tracing is only possible for elements having a value semantic which are variables of various types (primitive ones like int or composed ones coming with the SystemC library like sc_int or sc_bv) and signals (since they have also a value semantic).
interfaces (like are sc_core::sc_fifo_in) are essentially description how to manipulate things and therefore not trace with a tracefile. Using SCV it would be possible to do so but requires implementing some glue code.
BR

The clock cycle is determined by the wait(1, SC_NS) statements withing the for loop. This defines the duration of the high and low phase of the clock you are seeing. The timesacel message comes from the VCD trace file (more specifically its writer) saying that the recording resolution will be teh default of 1ps which might be too small for some cases. You may ignore this message or explicitly set the VCD timescale.
What Ameya is refering to is to replace the explicit clock generation with the SystemCs own sc_clock. This would alleviate you from describing the clock changes explicitly.
Actually in my opinion this is a really bad example for several reasons:
it bloats the sc_main function with testbench coder it mixes periodic signal change generation (the for loops) with functional code (writing reset and enable) it does not use SystemC utilities which make coding easier Best regards

Hi Karthik,
you need to provide a constant expression as template argument so that it can be evaluated at compilation time. See http://en.cppreference.com/w/cpp/language/constant_expression. and http://en.cppreference.com/w/cpp/language/template_parameters#Template_non-type_arguments. So it would need to be written as:
const int WDW_SIZE = 2; Best regards
-Eyck

Hi,
maybe I do not get the intent of your question but since SystemC is a C++ class library there is no separation between C++ and SystemC. What usually is separate are functional models and timed models as the latter one introduce a notion of time. As a functional model does not have this notion of time (only of sequence) care has to be taken to integrate a functional model into/with a timed model.
Hope that helps