Jump to content

Philipp A Hartmann

Members
  • Content Count

    537
  • Joined

  • Last visited

  • Days Won

    130

Everything posted by Philipp A Hartmann

  1. As mentioned by the error message, you define a port outside of a module in the line above.
  2. Thanks for the report. I don't fully understand the summary, though. Some questions: Are the changes to the API check and/or the exception handling in sc_simcontext.cpp really needed? I would hope that removing/skipping the assert in sc_cor_qt.cpp is sufficient to work around the mprotect restrictions on CentOS 7+? Your instructions do not include --enable-shared=no, but your description says that you only(?) see it on a static SystemC library. Can you please clarify? To better understand the failing mprotect call in your environment, can you please provide the value of errno af
  3. You have multiple instances of the "bundles" in your monitor class: inherited directly as additional members in the nested classes sim and stub To avoid the name clashes, you can make sim and stub modules themselves via: struct sim : sc_module , if_inputs, if_outputs { SC_CTOR(sim) {} } sim { "sim" };
  4. Exit code 0x103 could indicate an "illegal instruction". Can you try building SystemC with --disable-optimize? As Roman mentioned earlier, Clang 8 is pretty new and SystemC has never been tested with Clang on Windows.
  5. Can you run the failing test manually in a debugger and provide more details on the error? The log looks truncated, as if there is a crash in the test.
  6. I cannot comment on old SystemC versions like SystemC 2.3.1. I recommend to run the same with SystemC 2.3.3 instead.
  7. Fix pushed to the public SystemC repository, see https://github.com/accellera-official/systemc/commit/3e4fc6e0e669c727fcbd46100ee1d7ba58ec5894. This fix will be part of a future release of the Accellera reference implementation. Thanks again for reporting the issue!
  8. Hi Rainer, thanks for your detailed report. The issue seems indeed an incomplete implementation of the CCI 1.0 LRM. I'll forward your finding to the Accellera CCI working group. To achieve the expected behavior, you can locally change the from_json implementation to something like: inline cci_value cci_value::from_json( std::string const & json ) { cci_value v; bool ok = v.json_deserialize( json ); if( !ok ) { // report CCI_VALUE_ERROR instead of using sc_assert v.report_error( "JSON conversion failed", __FILE__, __LINE__ ); } return v; } Local error ha
  9. There is no builtin support for custom-sized floating point types in SystemC. An open-source C++ bfloat16 implementation can be found here: http://half.sourceforge.net. I would expect that this works more or less out of the box in SystemC (maybe you need to implement a custom sc_trace overload). Hope that helps, Philipp
  10. Hi Khushi, just adding to Eyck's answer, the "default" extensions in SystemC 2.3.3 are the following two implementation defined classes: tlm::tlm_endian_context tlm_utils::instance_specific_extension_carrier Greetings from Duisburg, Philipp
  11. Please be aware, that an sc_and_event_list does not imply that the events in the list are triggered at the same time. I would suggest to keep the only the clock sensitivity and act on the triggers in the body of the method instead: SC_METHOD(func2); sensitive << clk.pos(); dont_initialize(); // ... void func2() { if( nreset.posedge() ) { // nreset went high in this clock cycle // ... } } Alternatively, you can be sensitive to nreset.pos() and check for clk.posedge() (as a consistency check), if you don't have anything else to do in the body of the method. With
  12. Port-to-port binding is not tracked by SystemC after elaboration is completed. You can try to restore (or at least approximate) the mapping yourself by checking "overlap" in the get_interface() results across ports and the hierarchical relationship between the ports' parent objects.
  13. Changing the default writer policy requires to be set consistently throughout the whole application, which might be difficult with third-party infeeds. Since SystemC 2.3.2, you can also set the environment variable SC_SIGNAL_WRITE_CHECK=CONFLICT, which effectively enables SC_MANY_WRITERS at runtime (for all signals, though). Quoting the release notes: - [2.3.2] Add support for SC_SIGNAL_WRITE_CHECK=CONFLICT Instead of disabling all runtime signal write checks via the environment setting SC_SIGNAL_WRITE_CHECK=DISABLE, setting the variable to SC_SIGNAL_WRITE_CHECK=CONFLIC
  14. Won't you have multiple drivers anyway as soon as you have a second initiator accessing your transactor? I would recommend to switch your pin interface to use sc_export<sc_signal_*_if<T> > instead of plain signal ports and bind signals with an SC_MANY_WRITERS policy internally. These signals also have constructors that allow initialization to a non-zero value without triggering an event at the start of simulation.
  15. If your company is an Accellera member already, I encourage you to join the SystemC language working group. Otherwise, you can find some documentation about the changes in the RELEASENOTES file of each release (although this particular feature seems to miss an entry :-/).
  16. 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.
  17. 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.
  18. 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 );
  19. 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(); }
  20. 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
  21. 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);
  22. 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.
  23. 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< cl
  24. 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).
  25. 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
×
×
  • Create New...