Jump to content

Eyck

Members
  • Content count

    26
  • Joined

  • Last visited

  • Days Won

    5

Eyck last won the day on June 18

Eyck had the most liked content!

About Eyck

  • Rank
    Member

Contact Methods

  • Website URL
    http://www.minres.com/

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

217 profile views
  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. 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
  14. 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
  15. 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
×