Jump to content

Philipp A Hartmann

Members
  • Content Count

    534
  • Joined

  • Last visited

  • Days Won

    129

Posts 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. % g++ -I$SYSTEMC/include test.cpp –L$SYSTEMC/lib-linux64 -lsystemc
    …/systemc-2.3.0/lib-linux64/libsystemc.so: undefined reference to `sc_main' collect2: ld returned 1 exit status
    

    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.

    I wonder if SystemC 2.3.0 disables to use main() at all, which was ok with SystemC 2.2.0. It may cause the compatibility issue, so I would like to know how to remove the link error. Thank you.

    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. I am creating some sc_signal<vector<T> > ports with a user defined T. I have already found a proper link for the same (answer provided by AR/Ravi, inheriting from STL vector).

    But now my question is, I am defining other ports where T will be sc_bv, double etc. So shall I write above code for each of the variable type or is it ok with all? (I am particularly worried about << and ==).

    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.

    P.S. Will next IEEE1666 talk about sc_vector? Will some provision for above scenario provided in later versions?

    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. Just read the linked article, I posted in my earlier reply.

    You just can't use placement new with 'this' inside the constructor, period.

    There is some reasons behind which require me to use "constructor call to constructor".

    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

    And I did get successed with following C++ code. (It should not be C++ 11 in my machine, not exactly sure). I can run it.

    No, you did not succeed. Your code still has "undefined behaviour", which just seems to work correctly.

    So if I use sc_module instead of "my_sc_module", why it not works then?Some magaic inside sc_module?

    Yes, there is quite some magic in sc_module, like handling the SystemC object hierarchy, etc.

    If I just modifiy the previous code to following, it will crash and get "*** glibc detected *** " and " double free or corruption (fasttop): 0x081ffd30 ***"

    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.


  5. It just means, what you already quoted:

    Any of your module has attempted to create an instance of a primitive channel (sc_signal, sc_fifo, etc) after the start of simulation.In systemC primitive channels can only be created before the start of simulation .

    Please search your code for any signal declaration inside a function.

    You can use your Loader_Scheduler, you just can't create new signals (or other primitive channels) dynamically during simulation.


  6. 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)
    {
     // ...
    }
    

×
×
  • Create New...