Jump to content

Andy Goodrich

Members
  • Content Count

    13
  • Joined

  • Last visited

  • Days Won

    1

Andy Goodrich last won the day on March 19

Andy Goodrich had the most liked content!

About Andy Goodrich

  • Rank
    Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

694 profile views
  1. David is correct, another program having issues with Quickthreads is valgrind. With Quickthreads SystemC threads actually all live in a single pthread. When a SystemC thread yields to another one the stack is changed from one piece of storage to another in a discontinuous manner. The stack for that single pthread that SystemC is living ends up being discontinuous. With pthreads enabled each SystemC thread is in its own pthread and those stacks are continuous.
  2. The difference between a run with the kill on thread "target" and not doing that kill is that the sc_process_b object associated with "target" is reduced to a reference count of 1 from 2 by that kill. During tear down a reference decrement occurs and as a result the reference count for "target" goes to 0 causing an actual deletion of its sc_cor_pthread instance. Something about that deletion is causing the issue.
  3. My response ended up in our previous message exchange on my screen, so let me send it again just in case... Thanks for testing, let me look at things a bit, and I'll get back to you. Looks like there is an interaction between the teardown of threads and the code that "kills" a thread within the SystemC simulator.
  4. Interesting, the fact you got the "Success" indicates that SystemC returned to the main thread. That message is from sc_main(). The hang is occurring during tear-down of the "target" thread after exit from sc_main(). The culprit is this kill within the control thread: target_handle.kill(); So could I ask one more favor and have you comment out that call and lets see if things get all the way through. Thanks. Thanks for testing, let me look at things a bit, and I'll get back to you. Looks like there is an interaction between the teardown of threads and the code that "kills
  5. Interesting, the fact you got the "Success" indicates that SystemC returned to the main thread. That message is from sc_main(). The hang is occurring during tear-down of the "target" thread after exit from sc_main(). The culprit is this kill within the control thread: target_handle.kill(); So could I ask one more favor and have you comment out that call and lets see if things get all the way through. Thanks.
  6. The believe the issue here is that the current proof of concept simulator uses the low order 30 bits of each 32-bit word to store sc_unsigned or sc_signed values. The masks generated to store bits into the sc_unsigned value returned from sc_concatref::value() should take that into account and at present they do not. This code in sc_conatref::value() handles the very highest order word, which may need some number of zero bits at the top of it, if that top concatenation word is not a full 30 bits: #if defined(_MSC_VER) // workaround spurious initialisation issue on M
  7. I do have a scheme that should work for that case, but it will definitely tie datatypes to the sc_simcontext instance, so it conflicts with requests to separate data types from the rest of the simulator.
  8. I am assuming his issue is the use of static storage members, whether those members are static class members, or storage within a method/function? If so, things gets a bit ugly, as we need to generate values that are persistent for at least the life of concatenations.
  9. I will try an implementation along the lines of: sc_int_subref* temporary_subref() { static sc_vpool<sc_int_subref> pool(9); return pool.allocate(); } sc_int_subref& operator() ( int left, int right ) { sc_int_subref* result_p = temporary_subref(); result_p->initialize( this, left, right ); return *result_p; }
  10. But let me think about it as we have multiple uses...
  11. It bothers me a bit that we got all the way to sc_int_subref_r::initialize() with a NULL this pointer, rather than having things die in sc_vpool::allocate(). If hoisting the sc_vpool object so that the static initialization is within a method is the way to go I would prefer to place things where the invocation is made: sc_int_subref& operator() ( int left, int right ) { static sc_vpool<sc_int_subref> pool(9); sc_int_subref* result_p = pool.allocate(); result_p->initialize( this, left, right ); return *res
  12. Can you tell me if your regression log file had either of these two messages? Warning: (W558) disable() or dont_initialize() called on process with no static sensitivity, it will be orphaned: top.target In file: /Users/acg/work/sysc/systemc-2.3.2/src/sysc/kernel/sc_simcontext.cpp:766 Warning: (W558) disable() or dont_initialize() called on process with no static sensitivity, it will be orphaned: top.control.dyn_target In file: /Users/acg/work/sysc/systemc-2.3.2/src/sysc/kernel/sc_simcontext.cpp:1219 In process: top.control @ 0 s
  13. I addition to the requirements mentioned by David, you need to define a constructor with 3 arguments for pixel, something like: struct pixel { sc_dt::sc_uint<8> r; sc_dt::sc_uint<8> g; sc_dt::sc_uint<8> b; pixel() :r(0), g(0), b(0) {} pixel( const sc_dt::sc_uint<8>& r_init, const sc_dt::sc_uint<8>& g_init, const sc_dt::sc_uint<8>& b_init ) : r(r_init), g(g_init), b(b_init) {} };
×
×
  • Create New...