Jump to content

Eyck

Members
  • Content count

    26
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Eyck

  1. 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
  2. Eyck

    Non Constructible but Copyable !

    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
  3. Eyck

    VCD dump with Hierarchy systemc-2.3.2

    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
  4. Eyck

    Implement sc_trace for std::string

    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
  5. 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
  6. 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.
  7. 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
  8. Eyck

    beginner problems on fifo waveform

    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
  9. Eyck

    clock generation in system c

    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
  10. 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
  11. 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
  12. Eyck

    When exactly an event is servicd

    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
  13. 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
  14. Eyck

    Timing Annotation

    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
  15. 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
  16. 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
  17. 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
  18. Eyck

    Changing the width in sc_bv<W>

    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
  19. 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
  20. 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
  21. Eyck

    wait in SC_CTOR()

    Hi, if you want to map the Verilog initial block you can use the start_of_simulation() callback function. This one us called automatically by the kernel at simulation start. But you cannot call wait() either in this function. If you need to execute somethin delayed you can post a sc_event in the start_of_simulation() function and register a method/trhead being sensitive to this event. Cheers
  22. You may use a temporary object: My::My(sc_core::sc_module_name nm, int ID) : sc_core::sc_module(sc_core::sc_module_name((string(nm).append(1,ID<26 ?'A'+ID : 'A'+ID +6)).c_str())) But I would move the stuff into a free function: sc_core::sc_module_name concatenate(sc_core::sc_module_name nm, int ID){ std::string res(nm); res.append(1,ID<26 ? 'A'+ID : 'A'+ID+6); return res.c_str(); } My::My(sc_core::sc_module_name nm, int ID) : sc_core::sc_module(concatenate(nm, ID)) This makes the whole code easier to understand and more maintainable... Cheers
  23. Hi Sumit, both options will forward your transaction only to the first bound initiator socket of your multi_passthrough_target_socket as it just calls the operator->() of the underlying port. What you want to do is: for(unsigned int i=0; i<In.size(); ++i) In[i]->invalidate_direct_mem_ptr(...) But here you forward the call to all initiator sockets. In case of invalidate_direct_mem_ptr() this might be ok but for nb_transport_bw() it isn't as the call is part of the AT phases protocol and then you send e.g a BEG_RESP to a socket which never sent a BEG_REQ thus violating the TLM protocol as specified in the TLM 2.0 LRM (e.g. section 8.2.6) Cheers -Eyck
  24. Hi Sumit, you can use the size() method on both sockets to get the number of bound sockets. Cheers -Eyck
  25. Hi Sumit, of course it is allowed to bind an initator to a target socket, otherwise you would not be able connect an initiator to a target. But a can only once do this so usually you do it at the top level of connectivity. The picture below illustartes this, between module1 and module2 you have a binding of intor to target. +------------------------+ +----------------------+ | +---------------+ | | | | | | | | +-------------+ | | | | | | | | | | | intor | | | | target | | | | module +-+-+ +-+-+ intor to +-+-+ +-+-+ module | | | | | I +--+ I +-----------+ T +--+ T | | | | | +-+-+ +-+-+ target +-+-+ +-+-+ | | | | | | | | | | | | | | | | | | | +---------------+ | | +-------------+ | | module1 | |module2 | +------------------------+ +----------------------+ HTH -Eyck
×