Jump to content

Philipp A Hartmann

Members
  • Content Count

    497
  • Joined

  • Last visited

  • Days Won

    120

Philipp A Hartmann last won the day on June 15

Philipp A Hartmann had the most liked content!

About Philipp A Hartmann

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Duisburg, DE

Recent Profile Visitors

2,193 profile views
  1. Philipp A Hartmann

    timer with systemC

    The match will occur (almost) at the "correct" point in time during the simulation. However, if you sample the value from an unrelated process, there might be some process evaluation ordering dependency (i.e. whether the update_method had already been run). It depends on your requirements, whether this might be an issue. If you do the checks outside of the simulation, i.e. between sc_start calls, you would need to complete the deltas (as per the loop sketched above) before every check. You cannot call sc_start during end_of_simulation.
  2. Philipp A Hartmann

    timer with systemC

    I don't fully understand the question? My snippet above runs all remaining delta cycles at the current time without advancing the time any further. You can wrap your original sc_start call with the loop in a small helper function (e.g. sc_start_including_deltas(...) , if you find yourself copying the snippet too often.
  3. Philipp A Hartmann

    timer with systemC

    You can run the delta cycles at the current time until everything settles: while( sc_pending_activity_at_current_time() ) sc_start( SC_ZERO_TIME );
  4. Philipp A Hartmann

    function with wait

    sc_get_curr_process_kind´╗┐() is non-standard. You can use something like this: void stop_now() { // Assuming: sc_set_stop_mode( SC_STOP_IMMEDIATE ); to avoid running other processes? sc_core::sc_stop(); auto p = sc_get_current_process_handle(); bool is_thread_or_cthread = p.valid() && p.proc_kind() != SC_METHOD_PROC_; if( is_thread_or_cthread ) sc_core::wait(); }
  5. Philipp A Hartmann

    sc_thread hangs at wait( ) statement

    Generally speaking, it would be a bug if the whole SystemC simulation is hanging inside a timed wait. I suspect that you have in face a separate (set of) process(es) that are running indefinitely without advancing SystemC time (beyond these 4 ns). You can try to find the culprit by setting a breakpoint in a debugger on the affected line above, continue the simulation for a bit and then break, checking in which SystemC process you end up. Maybe you are missing a similar "wait" on the consumer side? Hope that helps, Philipp
  6. Unfortunately, there is currently no way to obtain the name of the affected signals/variables in this message. You can suppress the warning via: sc_core::sc_report_handler::set_actions(sc_core::SC_ID_TRACING_VCD_DUPLICATE_TIME_, sc_core::SC_DO_NOTHING);
  7. Philipp A Hartmann

    sensitivity list

    In SystemC 2.3.2 and later, you can use the sc_event::triggered() member function to query, if an event was triggered (and thus might have caused your method to run): if( event1.triggered() ) { std::cout << "event1 got triggered"; } if( event2.triggered() ) { std::cout << "event2 got triggered"; } Please note that if both events were triggered in/for the same evaluation phase, your method might well be run only once.
  8. I gave it a shot locally and noticed that there are indeed quite some compiler warnings due to differences between __declspec(...) and __attribute__((visibility(...))). Most of these warnings can be ignored for now, but are certainly annoying. Additionally, you need to explicitly mark the following with SC_API as well: // src/sysc/communication/sc_port.h template <class IF> class SC_API sc_port_b template <class IF> class SC_API sc_port // src/sysc/communication/sc_prim_channel.h class SC_API sc_prim_channel_registry // src/sysc/communication/sc_signal.h template< class T, sc_writer_policy POL > class SC_API sc_signal_t template< class T, sc_writer_policy POL > class SC_API sc_signal // src/sysc/datatypes/sc_proxy.h template <class X> class SC_API sc_proxy // src/sysc/datatypes/sc_proxy.h extern "C" SC_API int sc_main(int argc, char* argv[]) // src/sysc/utils/sc_temporary.h template<class T> class SC_API sc_vpool For compiling SystemC itself with -fvisibility=hidden, some further changes to the .cpp files are needed. And some of the above changes might break the Windows DLL support. But for me, the above changes work with the examples in the SystemC distribution (i.e. "gmake check CXXFLAGS='-fvisibility=hidden"). Long story short: The feature to SystemC build models with limited symbol visibility will require more changes and testing. I will forward this topic to the Language Working Group for further discussion.
  9. I'm not suggesting to export all of your classes, but the SystemC class (templates) used in your code. By reusing the macro annotations for Windows, you can try changing src/sysc/kernel/sc_cmnhdr.h and redefine SC_API for your platform # define SC_API __attribute__((visibility("default"))) (with this, you can even try building SystemC itself with -fvisibility=hidden).
  10. This is likely caused by the "hidden" RTTI information, messing with dynamic_cast and typeid usage in SystemC, see e.g. https://gcc.gnu.org/wiki/Visibility. You at least need to export all SystemC (template) classes from your shared library. Greetings from Duisburg, Philipp
  11. Philipp A Hartmann

    send array over tlm 2.0 fifio

    These classes are templates themselves. You need to pass the type of the values as parameter, for example tlm_fifo< std::array<int,4> > // a FIFO sending 4-element arrays of integers /Philipp
  12. Philipp A Hartmann

    send array over tlm 2.0 fifio

    Use an std::vector or std::array as value type in your FIFO instead of a C-style array.
  13. Philipp A Hartmann

    Build error SystemC 2.3.3 with C++17

    The INSTALL notes currently say the following about the SC_CPLUSPLUS preprocessor switch (emphasis mine): This means, that you can explicitly opt-out of some SystemC features, that would generally be supported by your compiler's C++ language support. Selecting a newer C++ standard version than supported by your compiler (setup) will typically not work - as you have experienced. That said, adding a preprocessor flag on the compiler command-line does not affect the language mode of the compiler. How to switch your compiler to C++17 mode is outside of the scope of SystemC. Your compiler (version) seems to require the -std=c++17 switch to enable this mode. The SC_CPLUSPLUS flag is then not needed as it will be set automatically to the selected version. Hope that helps, Philipp
  14. Philipp A Hartmann

    runtime error :- Fatal: (F4) assertion failed: iface != 0

    The issue is likely caused because you access a port (via -> or for example calling functions like .read()) already inside the module constructor. You should only access ports after binding has completed, this means from within a SystemC process or in end_of_elaboration() / start_of_simulation() callbacks. Hope that helps, Philipp
  15. From my understanding, the "before_end_of_elaboration" limitation got fixed in SystemC 2.3.1 (and a regression introduced by this was fixed in 2.3.2/2.3.3). /Philipp
×