Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Thanks for explanation Philipp! But if so, I don't think I understand why sc_delta_count() was introduced. Initially I thought about it as m_change_stamp from current implementation (used to implement event() function). What is its use cases? What does it solves, aside of statistical infomation on how simulation was performing?
  2. Hi, Example you provided works fine for me. I think it is not complete (definetly not, since it has no sc_main or main). And I think it is previous line that throws in your case. Full code (works fine): #include <systemc.h> int sc_main(int, char *[]) { SC_MODULE(test){ SC_CTOR(test){}; }; test testObj("test"); sc_start(1, SC_US); return 0; } This error means that you try to instantiate module after calling sc_start() (so you do this in simulation phase, not elaboration phase). From LRM (5.2 sc_module): You can also check chapter 4. Elaboration and simulation semantics Code that reproduces your error should be: #include <systemc.h> int sc_main(int, char *[]) { SC_MODULE(test){ SC_CTOR(test){}; }; sc_start(); test testObj("test"); sc_start(1, SC_US); return 0; }
  3. I don't see this "m_change_count" anywhere in LRM, so I assume it is non-standard. If so, how custom primitive channels should implement event() function similar to one from sc_signal? Looks like the only "official" way to do so is to save both delta count and time stamp. Pros: - Yields expected results for all cases - Eliminates need for "m_change_count" Cons: - requires more memory (+8 bytes per channel) - event() function requries additional 64-bit comparison, so it will work slower
  4. I haven't seen this in real simulation, that is why I asked if this was made on purpose. Just not what I would expect and it doesn't match LRM (or at least that is how it looks to me). Original example doesn't trigger any warnings since signal is updated from first sc_start() call when elaboration gets completed (per my undestanding). Actually at first I though that delta count is used to check whether event has occured on a signal, now I see that there is a separate counter which is called m_change_stamp that is incremented every time delta count is incremented plus every time simulation time advances - this should solve issue of spurious events for processes. Also please check my next example: #include <iostream> #include <systemc.h> class module : public sc_module { SC_HAS_PROCESS(module); public: explicit module(const sc_module_name &name) : sc_module(name) { SC_METHOD(process); sensitive << ev; dont_initialize(); } public: sc_in<int> input; sc_event ev; private: void process() { if (input->event()) { std::cout << "event at " << sc_time_stamp() << std::endl; } else { std::cout << "no event at " << sc_time_stamp() << std::endl; } } }; int sc_main(int, char *[]) { sc_signal<int> sig; module mod("mod"); mod.input.bind(sig); sc_start(); // complete elaboration sig.write(1); std::cout << "change signal at " << sc_time_stamp() << std::endl; sc_start(1, SC_NS); // doesn't give ant warnings because it advances simulation time mod.ev.notify(SC_ZERO_TIME); sc_start(); return 0; } My output is: This is the only case I come up with when process sees signal change made in the past. Again, this is not a "real world" code. Just now what I would expect. I noticed this when writing and testing my custom primitive channel. PS: Correction: m_change_stamp is not incremented when time gets advanced due to sc_start SC_RUN_TO_TIME policy. If it would do so, I think this would solve this issue. An by the way, I have checked again and it seems that SystemC 2.2 indeed used delta count comparison in event() implementation. This could create spurious events for processes, so I assume version 2.3 tried to fix this by introducing m_change_count.
  5. SystemC LRM says: Then what about following code: #include <systemc.h> #include <cassert> int sc_main(int, char *[]) { sc_signal<int> sig; sig.write(1); sc_start(); assert(sig.event()); sc_start(1, SC_NS); assert(sig.event()); return 0; } In this example signal was changed at 0 ns, but event() function still returns true 1 ns after. Considering the fact that LRM also says and describes delta cycle as Looks like the only way to make mq_signal<T>::event() work is to compare both time and delta count of the last change with current values, but current implementation only compares delta count. So my question is: is this a bug or was it made on purpose for performance reasons?
  • Create New...