ralph.goergen

Hi. 'Unfortunately', there is no randomness in the execution order of processes within the same delta cycle. http://forums.accellera.org/topic/5052-accellera-kernel-process-order/#entry12122 When the two threads start at the same time and have the same period, they will run always in the same order. This is part of the SystemC implementation and cannot be changed without changing the SystemC kernel. There are some approaches about this, patches for the SystemC kernel to add randomness in the execution order, but I do not know the current status of them. E.g.: http://www.teisa.unican.es/HetSC/downloads/SC_kernel_Improvements/uc_rand_sched/Patch_Kernel_sc_pseudorandom_sched_Eng.pdf If you do not communicate via signal and you do not have dependencies on the delta cycle, you can move the execution of the threads to the next delta cycle by adding a 'wait(SC_ZERO_TIME)' and execute in random cases. Greetings Ralph

Hi. event.notify() is so-called immediate notification. I.e., the event is notified in the same (current) delta cycle. When you use this kind of notification in a process that is sensitive to that event, this usually makes no sense. The state of signals cannot change during one dalta cycle. Hence, this will (or might) lead to endless executions of this process without reaching the next delta at any time. Greetings Ralph

Hi, I am not sure if the exerpt of your code is incomplete or if it is missing in your design, but teh SC_THREAD requires an infinite loop. SC_METHOD: The according function (argument of SC_METHOD macro) is called whenever an event from the sensitivity list is triggered. Then it runs to completion (until the function call returns). With next_trigger, you are able to change sensitivity dynamically. You can use next_trigger with a time argument as well. This results in sensitivity to an 'imaginary event' that is triggered automatically when the time has passed. Time advances in between two triggers. Assume an event at 2 ns and an event at 4 ns, then, the method will run at 2 ns once and at 4 ns a second time. SC_©THREAD: The according function is called only once and should contain an infinite loop and at least one wait statement. When the function completes (function call returns), this thread is dead and will not wake up anymore (only exception for this is 'reset'). The function runs to the first wait statement and returns controll to the simulation kernel, but the function does not complete actually. When an event this thread is sensitive to is triggered, the execution of the thread continues from that wait statement to the next wait statement. Hope this helps a bit. Greetings Ralph

Hi, I don't think that there is any explicit reason. The actual order depends on the implementation of the simulator kernel. This behaviour is caused by the internal handling of lists of runnable processes, i.e., the answer is somewhere in the simulator's source code. Greetings

Hi, Whenever two processes wait for the same event to appear, they will be triggered and executed in the same delta cycle. The order of execution of processes within one delta cycle is undetermined and implementation (simulator) defined. This is intended because the execution is actally meant to be parallel (at the same time). If you rely on a specific execution order, you should model this explicitly by triggering the processes explicitly in the intended order. Greetings Ralph

Hi. This is because an unbound port cannot be read. A port forwards all read and write calls to the actual interface (signal) it is bound to. In you module constructor, you are still in the model set up and elaboration phase. The port is not yet bound to any signal. Hence, you cannot read from it. Accessing ports should not be done befor end-of-elaboration. Greetings Ralph

Hi. The process 'process' in module controller is declared as SC_CTHREAD but does not contain an infinite loop and wait statement. You counld either add that or declare it as an SC_METHOD (like the other processes). Greetings Ralph

Did you possibly open the file in an editor end change the line endings to Windows style? Line endings should be unix style.

Hi again, is the configure file marked as executable? ls -l ... -rwxr--r-- 1 myuser mygroup 576K Apr 17 2014 configure ... If not, add the executable flag. If yes, you could try sh ../configure Greetings Ralph

Hi. configure is a file to be executed that should reside in your SystemC install directory. Did you create the objdir directory in the SystemC directory? Do you see the the file 'configure' in your SystemC directory? Greetings Ralph

Hi, SystemC tries to preserve you from implementing undefined behaviour as much as possible. There is an option to allow multiple writers but, in general, this is not what you want. If two processes write to a signal or fifo in the same delta cycle, the order of write accesses is not deterministic. In your case, there are several options: Writing your own channel, e.g. a bus model. Writing some kind of de-multiplexer. ... In all cases, you have to think about what happens if more than one process tries to access the component conrurrently. And you have to define some kind of order between the input ports or a communication protocol. Greetings Ralph

Hi. Inside the create_slave method, you can do whatever you want. You can use the name and index arguments passed to the method by the sc_vector infrastructure. If there is no dependency to the index, you can simply ignore it (in this case you can leave out the parameter name in the declaration to avoid compiler warnings: ... create_slave(const char* name, size_t) ... ). Furthermore you can use everything you can use in any other member method of top (because create_slave is a member method of top), i.e. the members of top, global variables, ... Greetings Ralph

Hi. A) Try not to use arrays of SystemC objects. Most of them cannot be copied or assigned. Use sc_vector instead (Section 8.5 in SystemC LRM IEEE 1666-2011). You have an array of sockets. Each element is a socket object. The return value of 'new' is a pointer to a socket. You cannot assign that pointer to an object. Greetings Ralph

Hi, I see two problems here: A) why is your creator function static? I am not sure if this is allowed. The ("slave",k) part in the init/bind call should not be there. The actual arguments are handeled inside the vector init method. The first (sc_unnamed::_1) is the name of the vector (given as constructor argument to the sc_vector). The second (sc_unnamed::_2) is the index of the current element to be created within the sc_vector. Greetings Ralph

Hi. First of all: We are talking about the model construction and elaboration phase here (instantiating components and binding ports). In general, the simulation phase is the way more performance critical part and not the elaboration. To your question: sc_object and all derived classes are not default constructible and copyable. So: it is the port itself and not the array. If you want to instantiate an array of sc_ports or a std::vector of sc_ports, you need to assign actual values (i.e. sc_port objects) to the individual members of the array or vector. To do so, you would need to copy sc_port objects and this is not allowed. (In fact, this is somehow possible in C++14, but not in an easy and convenient way.) Regarding performance: There is no significant overhead of sc_vector and it is all in the elaboration phase. You will not be able to measure any slow-down. Greetings Ralph

Hi, It seems like sc_vector is exactly what you are looking for. SystemC LRM IEEE 1666-2011 Section 8.5 sc_vector It solves the problem that you cannot have an array or std::vector of sc_objects (signals, modules, ...) because they are not default constructible, assignable, copyable. Another option would be 'the old way': using an array of pointers to sc_signals and instantiating the signals dynamically. But sc_vector is the much better and easier way. Greetings Ralph

Hi. a) for signals, you should use methods 'read' and 'write' instead of assignment. you are using sc_lv which is a vector of sc_logics together with sc_bit. Maybe, you should think about using sc_bv (vector of bits) instead of sc_lv or sc_logic instead of sc_bit. c) ctrl_ac.write(ctrl.read()[0]); Greetings Ralph

You are right here. The old simcontext object is not deleted in the proposed hack and that results in memory leaks. But so what. We are living in the 64-bit-and-tons-of-memory era. You can try to delete the old simcontext, but I am not sure what happens than. It may result in errors. Actually, the simcontext object is not meant to be deleted. Greetings Ralph

Hi, unfortunatelly you are moving in the area of undefined behaviour. During the running simulation (exactly after the completion of the elaboration phase), you are not allowed to instantiate modules, signal, etc. AFAIK, SystemC (or at least the Accellera PoC simulator) does not support resetting of the simulation kernel and restarting the evaluation phase. A possible 'solution' might be re-initialising the simulation kernel by instantiating a new one. But please take care: The following is dangerous and not conforming to the standard. Its a hack that uses implementation details and will not work in all SystemC simulators. There are two global variables called sc_curr_simcontext and sc_default_global_context When your simulation run is over, do sc_curr_simcontext = new sc_simcontext(); sc_default_global_context = sc_curr_simcontext; After that, the elaboration and simulation can be started again by calling sc_start again (after you instantiated your model again). Greetings Ralph

'To disable deprecation, use _CRT_SECURE_NO_WARNINGS.' Have you tried this?

Hi, not sure if this is what you are searching for but how about the following: template < typename T > class my_sig_type : public sc_core::sc_signal<T> { typedef sc_core::sc_signal<inner_type> base_type; my_sig_type(const char * name) : base_type(name) {} }; Greetings Ralph

Sorry, but I cannot see other problems in the code you posted. Could you maybe strip down your design to a minimal example showing the erroneous behaviour? PS: I did mean ... & (bitwise and) or && (logical and) ...

First: Since C++11, std::vector allows construction from an initializer list (and std::map as well). std::vector< std::vector< int > > my_vec = {{0,1},{2,3}}; std::map< int, int > my_map = {{0,1},{2,3}}; Second: 'and stops' allows a wide range of problems. Infinite Loop? Any exception? I think, we can assume that the problem is not in the STL. So, please try to analyze the last portion of user code before the program steps down to the STL function. Third: Do you mean & (bitwise or) or && (logical or) here?

Why are you using C arrays? How about vector or map? e.g.: std::vector< std::vector< uint64_t > > What do you mean with 'simulation stops'? Did the simulation end? Is there any error message? The code posted above does not show any processes. Maybe you can post a bit more (minimum working example)? Greetings Ralph

Hi. You can write your own constructor (see section 5.2.6 in the SystemC LRM IEEE-1666). SC_MODULE(M) { M(sc_module_name n, int a, int : sc_module(n) {} ... }; Please note that you have to add SC_HAS_PROCESS to your module if it contains any process and ont uses the SC_CTOR macro. Greetings Ralph