Jump to content

Philipp A Hartmann

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. A memory leak would not cause "random results". It would just consume more memory. Can you post some information about these "random results"? Secondly. whether or not a memory leak exists requires more details as well. The reports from Valgrind and Purify could be false positives as well, especially since there are memory pools used behind the scenes. Why do you suspect a memory leak here? Greetings from Oldenburg, Philipp
  2. If you look at the error message more closely, the problem is not caused by the existence of your "main" function, but by the missing sc_main function. The main reason for this is the preferred use of the dynamic library since SystemC 2.3.0. The dynamic libraries needs the sc_main symbol to be present, as you cannot decide during the (dynamic) linking step, if this function is actually called or not. Two solutions are possible link against the static library libsystemc.a (e.g. by moving libsystemc.so out of the way) add an (empty) sc_main Greetings from Oldenburg, Philipp
  3. The "NewVector" class proposed by AR/Ravi in the linked post is a class template already. Therefore, you should be able to define the missing functions (==,<<,sc_trace) for all datatypes T based on T's operations elementwise. sc_vector<T> is meant for vectors of SystemC object (moduls, signals, ports). The element type of a signal is not covered here. I'm not aware of any proposal to add a "signal-aware" element vector class to SystemC.
  4. The method process will be run once in the initialization phase of the simulation. [see 1666-2011, Section 4.2]. NB: Please try to post working code and wrap it in a [code] [/code] block to enable C++ highlighting.
  5. Just read the linked article, I posted in my earlier reply. You just can't use placement new with 'this' inside the constructor, period. You have not shown any reason, why you need to use delegating constructors. You can either use default parameters, or duplicate the constructor body, or use an intermediate base class, which always receives "all" constructor parameters No, you did not succeed. Your code still has "undefined behaviour", which just seems to work correctly. Yes, there is quite some magic in sc_module, like handling the SystemC object hierarchy, etc. That's what I said: you mess up the lifetimes of the internal (sub-)objects. It's just undefinied behaviour in C++ and you can't use this approach.
  6. It just means, what you already quoted: You can use your Loader_Scheduler, you just can't create new signals (or other primitive channels) dynamically during simulation.
  7. The feature you're looking for is called "delegating constructors" in C++11. It is not possible in C++03. Your solution is just plain wrong. You'd run the sub_module contructor twice, but the destructor would be run only once. See this article for a more detailed explanation of what happens. One option could be to use default parameters instead: sub_module( sc_core::sc_module_name n , int a = t1, int b = t2, int c = t3 ) : sc_core::sc_module(n) { // ... }
  8. It's a local problem, not related to SystemC itself. Make sure, that you have 'executable' permissions on this file (chmod a+x ...src/sysc/qt/config) the partition, you're building on, is not mounted with the "noexec" flag Greetings from Oldenburg, Philipp
  • Create New...