Jump to content

Roman Popov

Members
  • Posts

    353
  • Joined

  • Last visited

  • Days Won

    46

Posts posted by Roman Popov

  1. 6 hours ago, Timur Kelin said:

    Hi Roman

    Could you please recommend a multi-threaded profiler for SC. I tried making use of gprof but with no success. 

    Many commercial SystemC tools have SystemC-specific profilers measuring runtimes of SC processes. On Windows I usually use Visual Studio built-in profiler. I don't have experience with profiling on Linux.

  2. 4 hours ago, David Black said:

    As the error message says, you are missing the required sc_main subroutine. You did not show your invocation line, which could be helpful.

    VCS invokes g++ automatically.  But this is correct, sc_main is missing. 

  3. 2 hours ago, rainer said:

    So, by my understanding, the proposed method would only be safe to use if the list is known to hold a constant amount of values throughout the simulation (including during startup). I'm not sure whether SystemC's tracing mechanism can deal with a is non-constant amount of elements to be traced at all.

    This is correct, you cannot trace dynamic data structure. This is not even a SystemC limitation, but limitation of VCD waveform dump in general. VCD does not allow to add/remove signals to waveform dynamically.

    So usually you have two options

    1) If maximum capacity is known in advance and is small, you can create your own "list" that utilizes statically sized array as a storage:

    template<typename T>
    struct my_list_item 
    {
      bool has_value = false;
      T value;
    }
    
    template<typename T, size_t MAX_SIZE>
    class my_list 
    {
      std::array<my_list_item, MAX_SIZE> storage;
      // ...
    }

    2) If maximum size is large or unknown, but it is sufficient for you to trace only head and tail of the list, you can have a copy of tail and head that is updated on every push and pop:

    class my_list 
    {
    std::list<T> storage;
    my_list_item head_copy;
    my_list_item tail_copy;
    //... custom push pop
    }

     

  4. Interesting, I'm not an expert in CMake, but even with existing CMakeLists.txt when I build my application SystemC include directory is recognized automatically as system headers:

    Quote

    /usr/bin/clang++   -isystem /home/ripopov/distrib/systemc/include  -Wall -Wpedantic -g   -pthread -std=gnu++11 -o CMakeFiles/test_systemc.dir/main.cpp.o -c /home/ripopov/work/personal/test_systemc/main.cpp

    And as a result I don't receive any warnings about issues in SystemC headers.

  5. On 10/24/2019 at 11:15 PM, Oscar_Huang said:

    The issue is with only the static library libsystem.a. If you use the shared library, there is no problem. My example used libsystem.a

    If you configure it with option -enable-shared=no, and rebuild, then "make check" will fail with exactly the same assert error as seen with my example. Here is my test log file:

    I've reproduced the issue on Centos7.  Preliminary it looks like a misuse of mprotect on memory allocated with new. So as a workaround commenting out stack protection section should work. 

    Since I don't have enough linux system programming expertise I will bring it to accellera wg discussion before submitting a fix to systemc repo.

    Thanks a lot for reporting this and spending your time on investigation!

  6. Here is how it is specified by standard:

    Quote

    virtual const sc_event& data_read_event() const;

    Member function data_read_event shall return a reference to an event, the data-read event, that is notified in the delta notification phase that occurs at the end of the delta cycle in which a value is read from the fifo.

    So it notified after each delta cycle where fifo was read. Can it be that your receiver does nb_read from empty fifo?

  7. Quote

    There is a thread saying mprotect may not be reliable on malloc'd memory. See this thread.

    Indeed, quote from that thread:

    Quote

     Longer version: Small malloc()s tend to end up in BSS, and they might overlap with pages mapped from the ELF executable (as rw-p in /proc/self/maps), so you cannot reliably use mprotect() on malloc()'d memory. 

    So it could be that SystemC co-routine stack was allocated in BSS and setting mprotect on redzone failed. And the difference between CentOS and Ubuntu can be explained by difference in malloc implementation.  So indeed can be a bug in SystemC.

    Can you comment-out assert in stack_protect function in SystemC kernel, rebuild it, rebuild your application and check if it works?

×
×
  • Create New...