Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. Philipp A Hartmann

    Selling tool written in SystemC 2.2.0

    To me, an Internet forum doesn't look like the best place to ask for legal advice. You might want to consult a lawyer instead. Greetings from Duisburg, Philipp
  2. Philipp A Hartmann

    -D_GLIBCXX_DEBUG makes systemc-2.3.0 crash

    I did a quick local check and can reproduce the issue on SystemC 2.3.0 (Debian GNU/Linux, X86_64, GCC 5.3.1). However, on SystemC 2.3.1, ../configure CXXFLAGS='-D_GLIBCXX_DEBUG' make -j4 check completes successfully. Can you try on SystemC 2.3.1 again? Please note, that not all changes are explicitly listed in the RELEASENOTES and the release includes quite some cleanups and might have accidentally "fixed" the bug along the way. Thanks for your report, Philipp
  3. Philipp A Hartmann

    Error with a large number of SC_THREAD

    You're welcome! I just wanted to do the search myself, as I vaguely remembered this discussion. Greetings from Duisburg, Philipp
  4. In your main.cpp, change lines 48-50 to call the function sc_trace, instead of trying to instantiate an object of type sc_trace_file. sc_trace/*_file*/(wf, initiator->a, "a"); sc_trace/*_file*/(wf, initiator->b, "b"); sc_trace/*_file*/(wf, initiator->c, "c"); hth, Philipp
  5. Philipp A Hartmann

    Further help needed with finding port that is not bound

    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
  6. Philipp A Hartmann

    Read from buffer without removing content

    You can use tlm_fifo<T>::(nb_)peek for that, see IEEE 1666-2011 (17.3). hth, Philipp
  7. 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 count is no longer incremented in such "empty evaluation phases", which you can introduce manually by calling sc_start without anything happening in the model (except for the time advance, maybe). Thanks again for bringing this up, Philipp
  8. 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 today. This way, only users doing such step-wise simulations require to pay the cost of the additional checks. For the next version of the SystemC standard, we should still clarify this behavior in more detail. And yes, there is no standardized API to simplify the implementation of an event()-like functionality in a custom channel. With the corner case you describe, maybe there is now an interest to define such a function, also taking care of the "same simulation time" guarantee. But as I said above, another option might be to relax an implementation's requirements for this check to allow for the corner cases of empty evaluation phases via sc_main between time steps. Greetings from Duisburg, Philipp
  9. Philipp A Hartmann

    Installing systemc on Ubuntu

    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
  10. 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
  11. 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
  12. Philipp A Hartmann

    Modules with optional (configurable) ports

    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(const sc_uint<BITS_FIFO_DEPTH>&) { /* empty */ } }; template< bool HasMorePorts > SC_MODULE( async_fifo ) , public async_fifo_optional_ports<HasMorePorts> { // ... }; hth, Philipp
  13. 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
  14. Philipp A Hartmann

    Retrieve a pointer to an interface of a port

    You can try s = dynamic_cast<sc_signal<bool> *> (v->at(0).get_interface()); Hth, Philipp
  15. Philipp A Hartmann

    Integrating SystemC in MinGW software project

    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
  16. Philipp A Hartmann

    SystemC stack overflow on large system

    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
  17. Philipp A Hartmann

    Runtime sc_spawn exception

    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
  18. Philipp A Hartmann

    Building A Third Party Application which uses TLM 2.0

    You can pass the option --host=i686-linux-gnu to the configure call: mkdir objdir32 cd objdir32 ../configure --host=i686-linux-gnu --prefix=/usr/local/systemc230 # ... You need to make sure to have the g++-multilib package installed on Ubuntu. As a side note: You might want to install SystemC 2.3.1 instead, which includes some bug fixes. hth, Philipp
  19. Philipp A Hartmann

    make check failure while installing SystemC

    Ok, it seems that the test itself fails to run (diff output indicates a missing run.log, not a missing golden.log). Can you please post the full output of running the test.exe in the objdir/examples/sysc/simple_bus manually? Maybe you can also attach a debugger and provide more information on the crash (if there is one)? That said, cygwin64 has never been tested and is not really supported by the Accellera proof-of-concept implementation. If possible, please report the results of running the full regression package (available at http://accellera.org/downloads/standards/systemc) on that platform, too. Thanks, Philipp
  20. Philipp A Hartmann

    Using a shared object file

    Why do you need SystemC 2.2? Starting from SystemC 2.3.0, shared libraries are automatically built for the proof-of-concept implementation (on supported platforms). hth, Philipp
  21. Philipp A Hartmann

    Modeling packets age using sc_time_stamp()

    First of all, "default time units" and all related functions are not part of the IEEE 1666 SystemC standard and are sometimes provided as deprecated features in the SystemC implementations. You should not use them. If you want to compute the number of cycles since the start of the simulation, you can store the clock period as sc_time value and divide the current simulation time by this period: sc_time now = sc_time_stamp(); sc_dt::uint64 cycle = static_cast<sc_dt::uint64>( now / clk_period ); Assuming that your package won't get older than 2^32-1 cycles, you should be able to store the lowest 32-bit of this cycle number and check for overflows during the age computation (i.e. new time is smaller than start time). hth, Philipp
  22. An initiator socket is first of all a SystemC port, enabling access to its bound interface (here of type tlm_fw_transport_if) via the operator->. Did you notice, that you call "socket->b_transport()", not socket.b_transport()? hth, Philipp
  23. Philipp A Hartmann

    make check failure while installing SystemC

    Can you check, if the golden.log file has been copied correctly to the objdir/examples/sysc/simple_bus directory? On Cygwin, the symlinking detection is sometimes not realiably working... Alternatively, you can try passing 'LN_S=cp -a' (including the quotes) as option to the configure call. hth, Philipp
  24. Philipp A Hartmann


    As you've noticed and David confirmed, exports need to be bound to an interface implementation before they can be bound hierarchically. I've noticed that you implement the interface already in your "E_top" module (side note: you may want to inherit publicly from sc_module). In this case, you probably intend to bind this implementation to the export? in_port(*this); // <-- bind E_top implementation to export m_C_top.in_port(in_port); This is a fairly well-known modeling pattern together with exports. hth, Philipp NB: I would recommend to avoid using std::vector<bool>.
  25. Philipp A Hartmann

    is it possible to use "virtual public sc_module"?

    As a final remark: No, you can't use sc_module as a virtual base class, not only due to the required casts to start/create the embedded SystemC processes. Your solution to split the implementation is correct. hth, Philipp