Jump to content

Philipp A Hartmann

Members
  • Content Count

    535
  • Joined

  • Last visited

  • Days Won

    130

Everything posted by Philipp A Hartmann

  1. The sc_logic constructor taking a char is marked as explicit. Therefore, you can't pass a char to functions expecting an sc_logic (e.g. initialize). You can either explicitly create (pun intended) an sc_logic from a char, or use the predefined sc_logic constants for assignments and parameter passing: sc_logic a; a = sc_logic('1'); eoc.initialize( SC_LOGIC_0 ); // SC_LOGIC_1, SC_LOGIC_X, SC_LOGIC_Z Greetings from Oldenburg, Philipp
  2. The delayed signal member function (part of global/local "watching") has been deprecated during the standardization of SystemC already for 1666-2005 and is dropped since SystemC 2.2. See http://www.doulos.com/knowhow/systemc/deprecated/ for some more information. Greetings from Oldenburg, Philipp
  3. Pablo, This should just work as is. Here you should use the posedge/negedge functions: if(port_vec[clk_id]->posedge()) //or like this: port_vec[clk_id]->pos() This is equivalent to: if( port_vec[clk_id]->event() && port_vec[clk_id]->read() ) Greetings from Oldenburg, Philipp
  4. As explained in detail in my previous answer, the output you see is as expected. All of these reports (which are no errors in a strict sense) can be seen as false positives. The additional "possible loss" reported (the one with pthread_create in the call tree) is related to the stack allocation of your process. /Philipp
  5. Admittedly, using Valgrind with SystemC has become more involved with 2.3. There are several reasons for this, some of them are new, some apply to SystemC 2.2 already. Let's have a look at your output: In order to reliably use SystemC with Valgrind, you should switch to the pthreads-based process implementation. Otherwise, you'll see many false positives when looking at "real" models. To enable this in 2.3, add "--enable-pthreads" to the configure options and recompile the library: cd objdir ../configure --enable-pthreads (...) make clean && make && make install
  6. Assuming you're using plain signal ports, you can use the event member function to check, whether a specific port has been triggered in the current delta cycle: sc_vector< sc_in< int> > in_vec; // ... SC_METHOD(proc); for( unsigned i= 0; i<in_vec.size(); ++i ) sensitive << in_vec[i]; // ... void proc() { for( unsigned i= 0; i<in_vec.size(); ++i ) if( in_vec[i]->event() ) std::cout << "in_vec[" << i << "] triggered." << std::endl; } Greetings from Oldenburg, Philipp
  7. Your solution looks correct. You may want to consider wrapping all of this together in a single "thread-safe input queue" for better encapsulation (and to remove the pthread stuff from your SystemC model). In this case, you can duplicate the queues internally: At protected one for pushing from the outside and a SystemC-local one, where to store the tokens that you need to process within the SystemC part of the model. With a swap of these queues in the update step, you can keep the locking times minimal. Secondly, if you accept a slight extension beyond the plain 1666-2011 standard, you ca
  8. Oh, sorry. My mistake. The mentioned test has not been part of the 2.3.0 release. There may be some similar test included in the next version of SystemC… For now, you should use David's example as a reference. As in any (host) parallel programming, make sure to properly protect any shared data used in both parts (SystemC and other OS threads). This is not automatically addressed by the async_request_update mechanism. Sorry for the noise, Philipp
  9. There is no real tutorial example available, yet. But you can look at the SystemC regression tests [1], which have a small test included at tests/systemc/1666-2011-compliance/async_request_update/ Greetings from Oldenburg, Philipp [1] http://www.accellera..._2-3_2012-07-02
  10. 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
×
×
  • Create New...