Jump to content

Philipp A Hartmann

Members
  • Content Count

    535
  • Joined

  • Last visited

  • Days Won

    130

Everything posted by Philipp A Hartmann

  1. It looks quite strange to me that the error message states (sc_object) as the kind() info of the unbound port. If the port in question is a "regular" port, it should report (sc_port) or something more specialized than that. Do you use some special/user-defined port here? /Philipp
  2. You can use tlm_fifo<T>::(nb_)peek for that, see IEEE 1666-2011 (17.3). hth, Philipp
  3. You're right: sc_delta_count is in fact intended (and used) for exactly such use cases. Historically (i.e. pre 1666-2011), the delta count semantics were a bit different, as we didn't have sc_pause and the starvation policy for sc_start, yet. So by nature of an event-driven simulator, there simply was no "empty time advance" before. With the extensions added to 1666-2011, we tightened the semantics when the delta count is increased in order to maintain deterministic results of the same simulation, regardless of the "activation sequence" in terms of sc_start calls. Therefore, the delta co
  4. Hi Ivan, thanks for your follow-up and for the updated example. I also do not see a way to trigger this corner-case from within a process, i.e. without jumping to sc_main in-between (and then using event() in sc_main itself). Therefore, I'm not sure if it's necessary to change the current implementation of the sc_signal::event function. An alternative could be to add a way to explicitly check for "empty evaluation phases", i.e. whether sc_delta_count() yields the same value before and after the sc_start call. That said, you can add this check to your sc_main logic manually already t
  5. To me, the incomplete transcript looks like a broken compiler installation. Please make sure to install a C++ compiler, e.g. sudo aptitude install g++-multilib If that doesn't help, please post a full transcript of the installation steps (your listing contains several typos, which are expected to fail). Markus, can you please share some details? The error you describe should have been fixed in SystemC 2.2.0 and later. Thanks, Philipp
  6. As Roman pointed out, these symbol clashes have been avoided since SystemC 2.3 by moving the embedded copy to the sc_boost namespace. In SystemC 2.2, you can try to get away with it by explicitly including all duplicate headers from the recent Boost version first, i.e. before including SystemC (hoping that the include guards have not been changed). For those files, where the include guards have changed, you need to explicitly #define the sentinels as well to hide their duplicate inclusion. There still be dragons, though. hth, Philipp
  7. Hi Ivan, I have some follow-up questions on this issue: Have you been able to reproduce it during a "real" simulation? Do you see a warning about an empty evaluation phase during the simulation? In your special case, you check for 'event()' from within 'sc_main' again and you don't really simulate at all (no processes are running). In this case, the delta count is expected not to advance. Thanks, Philipp
  8. AFAIK, using ports with an "optional" port policy (SC_ZERO_OR_MORE_BOUND) is not well supported by synthesis tools either. But you can try inheriting structs with the port declarations depending on some template parameters (entirely untested): template<bool HasMorePorts = true> struct async_fifo_optional_ports { sc_out<sc_uint<BITS_FIFO_DEPTH> > num_items; protected: void drive_num_items(const sc_uint<BITS_FIFO_DEPTH>& v) { num_items->write(v); } }; template<> struct async_fifo_optional_ports<false> { protected: void drive_num_items(con
  9. Hi Ivan, thanks for your report and your detailed analysis. From my understanding of your quotes of the IEEE 1666-2011 standard, I would say that this is a bug in the Accellera proof-of-concept simulator. IIRC, the wording (and implementation) around the delta count has been refined during the IEEE update to 1666-2011, which was required to ensure determinism under presence of new features like sc_pause. I'll take your report to the SystemC LWG to resolve this issue in the next release. Thanks again and Greetings from Duisburg, Philipp
  10. You can try s = dynamic_cast<sc_signal<bool> *> (v->at(0).get_interface()); Hth, Philipp
  11. Hi Markus, since SystemC 2.3.1, building/running the library with MinGW compilers has been validated (quoting the README): What errors do you see during configure? Greetings from Duisburg, Philipp
  12. I'd guess, that this is not a stack overflow but an out-of-memory issue, where the kernel fails to obtain enough memory for your processes. Maybe, you can switch your modeling style from SC_THREADs to using SC_METHODs, or even decrease the stack size as a first step? hth, Philipp
  13. SC_FORK/SC_JOIN can be used only within an already started process, not within the constructor of your module (SC_JOIN involves a wait as well). You can register the thread via SC_THREAD(my_thread); hth, Philipp
  14. You need to define the preprocessor symbol "SC_INCLUDE_DYNAMIC_PROCESSES" before including SystemC, when you use the TLM-2.0 convenience sockets. The preferred way to do this is to add it to your compiler command-line switches ("-DSC_INCLUDE_DYNAMIC_PROCESSES"). hth, Philipp
  15. The function to set attributes for TDF MoC elaboration is called set_attributes() (plural form). You should be able to find such an error quite quickly by either adding simple debugging messages ("printf-debugging") or by using a proper debugger. Greetings from Oldenburg, Philipp
  16. Usually it is better to start a new topic in this forum, when there is a new question. Secondly, you should always provide the detailed error message given by the compiler. It is not entirely clear to me, what you are trying to achieve, because you do not show the all relevant parts of the code. Irrespectively of any tracing, you always need to connect the ports through appropriate channels (TDF or SystemC signals in your case). Last, but not least, a wild guess regarding the compiler error: In case you've copied the code directly to the browser and depending on your comp
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
×
×
  • Create New...