Jump to content

Andy Goodrich

Members
  • Posts

    15
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Andy Goodrich

  1. Defining SC_MAX_NBITS has not been used for many years, it dates to early in SystemC's development, so I am not surprised it fails. The performance issue you are encountering is caused by the fact that malloc is done for each sc_signed or sc_unsigned value created. This issue is addressed in the next release of SystemC. In the mean time, if it is practical, use statically created variables where possible, e.g., static variables in functions/methods, or variables in structures that are allocated once. This should improve your speed for some cases, but does not solve the problem of dynamic intermediate results, e.g., the results of arithmetic and logical operations. Again, this will be addressed in the next release of SystemC.
  2. The form you are using is causing the sc_vector constructor to think it has named elements, that is, it expects the vector elements to have a name field that is passed to the constructor for each element. So it will try to create elements with names test_0, test_1, ..., test_999 by calling the constructor for sc_uint<8> with those names. While the sc_uint class has a constructor that takes a char* argument, that argument is expected to be a character representation of a value. I would suggest you use std::vector for scalar types like sc_uint instead: std::vector<sc_lv<8> > test2(1000); std::vector<sc_uint<8> > test(1000);
  3. 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.
  4. 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.
  5. 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.
  6. 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" a thread within the SystemC simulator.
  7. 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.
  8. 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 MS Visual C++ memset( result_p->digit, 0, sizeof(sc_digit)*result_p->ndigits ); #else result_p->digit[result_p->ndigits-1] = 0; #endif right_non_zero = m_right_p->concat_get_data( result_p->digit, 0 ); left_non_zero = m_left_p->concat_get_data(result_p->digit, m_len_r); What this does not take into account is the high order two bits in words below that highest word. Those bits need to be zeroed in the various concat_get_data() methods, and they are not. I believe that is why the MS Visual C++ work-around was necessary. Thus, the solution to this is to modify the various concat_get_data() methods to include the masking of those bits. I expect the proof of concept simulator to change in the near future to use an implementation that uses all 32 bits in a 32-bit word to store the sc_signed and sc_unsigned values, at that point the zeroing of the high order digit before making the concat_get_data() calls will be sufficient using the existing masks.
  9. 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.
  10. 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.
  11. 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; }
  12. But let me think about it as we have multiple uses...
  13. 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 *result_p; }
  14. 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
  15. 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...