Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by Eyck

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. Hi Sumit, you can use the size() method on both sockets to get the number of bound sockets. Cheers -Eyck
  13. 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
  14. Maybe a little bit late but there are socket implementations available which do trace tlm transactions int a SCV database. They can be found at https://github.com/Minres/SystemC-Components/tree/master/incl/scv4tlm and are used e.g. at https://github.com/Minres/SystemC-Components/blob/5f7387ab7e3dfc2ff6a7cac6fbe834ed7ec8ae36/incl/sysc/tlmtarget.h which in turn serve as building blocks in https://github.com/Minres/SystemC-Components-Test/tree/master/examples/simple_system The setup given by Kai is put into sysc::tracer where all the tracing setup (VCD & SCV) is impelemted. Best regards -Eyck