Eyck

Actually this is not going to work as it is quite unlikely that both events fire at the same delta cycle. So you would write something like void do_dff(){ if(enable.read()) q=d; } sc_ctor(){ SC_METHOD(do_dff); sensitive << clk; } The only option to concatenate events is to use sc_core::sc_event_and_list and sc_core::sc_event_or_list but those can only use in dynamic sensitivity (wait() for SC_THREADs and next_trigger() for SC_METHODs). Best

Well, there are several problems in your code: naming and sc_out input is counterintuitive - but this is minor you use a limited range integer and assign values outside this range. sc_in<2> is a 2.bit integer and can hold values from -2 to 1. it seems you did not understand and obey event scheduling, more see below So what you see in line 16-22 of the output is the initial invocation of tb::source(), tb::sink(), and statem::controller(). There tb::source() writes 11 to input_sig and statem::controller() write enable=false. Due to the write to input_sig tb::source(), tb::sink(), and statem::controller() get invoked again (the are sensitive to the value_changed event) as the output line 23-29 show. tb::sink() now writes the same value to input_sig again but this does not trigger any value_changed event. Since no process is sensitive to enable and no other events are left over the simulation kernel stops the simulation. As there is now wait statement in your model you do not see any time advancing, everything happens at time 0 (but in different delta cycles). To my experience you should use SC_THREAD when you have an active component (tb in your case), here you can easily implement an implicit statemachine and advance time. Since SC_METHODs are not allowed to block (call wait()) they are more suited to reacting components. If you describe the intention I can provide you an example on how to do this. Best regards -Eyck

Well, actually the error message from the point of the compiler is quite right: using the '*'-operator you intent to dereference the return value of write() which is 'void'. BR

I agree here with David, best would be to share the basic parts of your code as well as the complete commands and outputs From your description you have your DUT and your testbench in a separate file. You should compile them (inlcuding your main.cpp) into .o files e.g. by running something like g++ -I. -I$SYSTEMC_HOME/include -L. -L$SYSTEMC_HOME/lib-linux64 -c <cpp file here> and then link all .o file into your executable like: g++ -L$SYSTEMC_HOME/lib-linux64 -Wl,-rpath=§SYSTEMC_HOME/lib-linux64 -o main *.o -lsystemc -lm This is a basic C++ compile flow, see also here https://www.cprogramming.com/compilingandlinking.html or here: https://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html BR

Well, this topic could fill an entire book... If you implement a model the first question you should as is: What is the purpose of the model? Which questions should the simulation of the model answer? Looking at architectural exploration which goes quite often hand in hand with performance analysis the question is: does my HW/SW split and my HW partitioning satisfy my perfomance requirements (wrt. latency, thru-put, compute.efficiency, power,...). In this case you usually do not need to implement a particular functionality in detail rather something that 'behaves like' in terms of your requirements. E.g. if you need to check that your communication scheme (buses, arbiters, bridges etc.) fulfills the needed band with you use traffic generators but have a fairly accurate bus model, sometimes even at AT. And you need to implement the mechanisms to observer and extract the needed performance indicators to allow the analysis For software development the requirements are different. Here the maximum simulation speed is required so whereever possible you take short cuts. Bus transaction are not modelled anymore rather DMI is used (of course if functionality allows to do so e.g. when reading from/writing to a memory) and the entire model may run in LT mode which allowes parts to independently advance in time. Peripheral units may be modelled register-accurate but with out real functionality, i.e. a system control unit does not follow the needed scheme if changing e PLL frequency and alike. This might give you some high-level clue. There are many more things to it but all of them depend on the answer to the initial questions. Maybe the DCVon Europe 2017 tutorial on virtiual protorypes might provide a few more answers. You may find a PDF version of it at the MINRES site in the Publications and Papers section or at https://minres.com/downloads/VP_Tutorial_DVCon-2017.pdf as well as at the DVCon Europe website https://dvcon-europe.org/conference/history Best regards -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

Actually Sumit is right, you need to convert the string to a bit vector (sc_bv) of length string.lenght()*8. And here the problem starts: the sc_bv needs to have a constant lenght from the very beginning on and it cannot change during the simulation as the length is store in VCD at the very beginning of the file. In the viewing tool you can then select an interpretation of the bit vector to see a string. Best regards Eyck

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.

You might have a look at https://github.com/Minres/SystemC-Components/blob/master/incl/scc/router.h. This one uses mixins to enhance the functionality of tlm::tlm_initiator_socket/tlm::tlm_target_socket but basically implementes what you are describing. An example how to use it can be found here: https://github.com/Minres/SystemC-Components-Test/blob/master/examples/simple_system/simple_system.cpp Best regards

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, it seems you lack a basic understanding of C/C++ visibility of variables. As fifog32 is declared a local variable in sc_main you can only access it in sc_main, it is unknow in any other function. BR

Hi, These are the command line arguments argc and argv which are propagated from main(). See also https://stackoverflow.com/questions/3024197/what-does-int-argc-char-argv-mean#3024202 Best

Hi, you need to be aware that SystemC does not run threads concurrently rather in an sequential manner. This means other threads and functions are only executed when your Next_event_thread() is suspended i.e. calls wait(). As long as code gets executed in the '-- // intercept here' region the rest of the simulation is suspended. This is no issue at all for the simulation. From your question I derive that you are going to implement a GUI on top of a simulation. Here it is a bad idea to run the GUI in the SystemC simulation (OS-)Thread. It would be better to create an OS-thread running the simulation (essentially the sc_main() function) independent from the GUI thread. But then you need to syncronize the two threads using the usual means (atomic variables, mutexes, semaphores, ...) and let them cmmunicate. This way your GUI will not freeze when the simulation is running. I hope I got your question right and answered it. Best regards -Eyck

Whenever you call a generic protocoll function lile b_transport or nb_transport you supply an sc_time argument as reference so it can changed be the callee. This delay argument is the offset of the begin (when calling the function) or to the end (after the function returns) of this transaction to the current simulation time point. This is called timing annotation... Best regards

Well, usually this describes the simulation timing behavior of a system. Approximately-timed models breakdown communication protocols into the subsquent phases with attached time points and durations. The components of a system adhere to a common or global time base - they execute in sync. In loosly-timed models part of the system are allowed to stick to their own time base which might deviate from the global time base by a given amount (the quantum). Communication transactions a handled as a single transaction with annoteted time points so that the components can react acccordingly. As a simple example let's have a look at an instruction set simulator (ISS). In AT mode it would execute one machine instruction, do all the bus transactions at the correct points in time (related to the global time base). Thus interactions in the system (triggering interrupts, writing GPIO pins etc.) are fairly correct from a timing point of few. But it inccurs quite some overhead as the execution (in the simulation) switches very often from the model to kernel and back (so called context switches). In LT mode the ISS is allowed to execute a whole bunch of instructions without returning the control to the simulation kernel. Usuallay this implies that communication transaction are executed in a blocking fashion without wait() calls. To be able to run-ahead and still have time passing the ISS has to maintain a local time base (the local quantum). In the case of simple memory read and writes this has no effect on the entire system but it saves a lot context switches so it boosts the performance. To make sure that the functionality get not sacrificed each interaction with the system carries an annotated delay so that the reciever of the transaction (e.g. a timer) can decide to stop the ISS execution simulation thread and let the rest of the simulation catch up - it breaks the quantum. In practice you will find mostly mixtures of the 2 apporaches but I hope this gives you an idea. Cheers

Hi shanh, looking at the SystemC LRM: this is what happens in your example. The event is notified while another event is pending since your 2 threads sleep for the same amount of time. You would need to guard the event notification, use 2 separate events or an event queue similar to tlm_utils::peq_with_cb_and_phase. Best regards

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

Hi, when using CCI 0.9.0 with CLang 6.0 I get a compiler error: cci_broker_handle.h:139:42: error: calling 'get_param_handle' with incomplete return type 'cci::cci_param_untyped_handle' return cci_param_typed_handle<T>(get_param_handle(parname)); ^~~~~~~~~~~~~~~~~~~~~~~~~ This can be solved by a #include "cci_cfg/cci_param_typed_handle.h" at line 27 of cci_broker_handle.h. I have no clue how this works when using gcc (and it works :-S) Best regards -Eyck

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

Well, the '\' escapes the newlines at the end of each line so that the compiler treats all lines as a single line. '#define' is a pre-processor command which expects everything to be on a single line. If you do not escape the newlines then your code is one several lines and does not work anymore. HTH -Eyck

Hi katang, I cannot comment on 3./ but item 1./ and 2./ (dynamic_cast) is generally fine (at least from a simulation point of view). Wrt. to item 4./ this is a C++ mechanism which you do not really obey. If you construct the base class the virtual function pointer in the vtable of the class point to MWEbase::Initialize_method(). Hence you register the pointer to this method with the SystemC kernel. But this is easy to work around. Basically you register a dispatch function with the SystemC kernel which calls then the virtual function: void Dispatch_initialize_method(void) { Initialize_method();} virtual Initialize_method(void); In you constructor you register this function then: // This is for synthesis MWEbase::MWEbase(sc_core::sc_module_name nm, bool StandAlone) : sc_core::sc_module(nm) { if(StandAlone) { mME = this; SC_THREAD(print_thread); sensitive << m_request; std::cerr << "MWEbase standalone\n"; } SC_METHOD(Dispatch_initialize_method); std::cerr << "MWEbase created\n"; } This way the call to Initialize_method() will be resolved by runtime polymorphism (the vable mechanism) and the call goes to the correct function. Best regards