Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. Have you included "/vmg" in the additional compiler options in your MSVC project?
  2. Annex C in the SystemC standard lists some deprecated features. In the SystemC proof-of-concept implementation, you find detailed information about changes in the RELEASENOTES file, but mostly only relative to the previous version.
  3. I agree with your conclusion that the observed behavior of the proof-of-concept implementation does not match the requirements of IEEE 1666-2011. I checked the code and it can be fixed by adding the check for resets to sc_thread_process.h (in the trigger_static() function): diff --git a/src/sysc/kernel/sc_thread_process.h b/src/sysc/kernel/sc_thread_process.h --- a/src/sysc/kernel/sc_thread_process.h +++ b/src/sysc/kernel/sc_thread_process.h @@ -485,5 +486,5 @@ sc_thread_process::trigger_static() #endif // SC_ENABLE_IMMEDIATE_SELF_NOTIFICATIONS - if ( m_wait_cycle_n > 0 ) + if ( m_wait_cycle_n > 0 && THROW_NONE == m_throw_status ) { --m_wait_cycle_n; I'll take this change to the language working group to get it fixed in a future version of the SystemC PoC kernel. Thanks for reporting! Greetings from Duisburg, Philipp
  4. Hi Ameya, thanks for the feedback! Can you please provide the following details: Platform (Cygwin?) GCC version used Logs of verify.pl with -v enabled (to see the full command-lines) The file cci_core/systemc.h is an internal header which is only included through this path. A conflict could only occur, should you add cci_core/ directly to the compiler include path (which is not supported), or if you'd install SystemC below cci_core/ (which would be very weird ;-)). The errors in ex07_Parameter_Information indeed look like the SystemC installation is not correctly resolved. For this, the full command-lines would really help. The error in ex16_User_Defined_Data_Type is indeed a bug (at least before C++14(?)). The fix is to explicitly open the cci namespace around the cci_value_converter specialization in ex16_user_datatype.h. Hope that helps and thanks again, Philipp
  5. Hi Fred, synchronous resets are indeed not triggering the process themselves (that's why it's called "synchronous) and instead are only checked when the process is triggered through other means. Typically, this would be a trigger from the static sensitivity (clk.pos() in your case). As @AmeyaVS correctly pointed out, dynamic sensitivity replaces the triggering behavior (not the reset specs). So your synchronous reset would be checked only, when some_signal is de-asserted. Asynchronous resets continue to fire. A polling loop would be the most accurate way to model your design wrt. resets. If you know the reset signals at the point of that wait statement, you can approximate the behavior by waiting for either the signal or the reset (which will then reset the process) wait( some_signal.negedge_event() | rst_n.negedge_event() ); Of course, this might be one clock cycle off. To be correct, you need to have an event that's synchronous to the clock again: sc_event thread_rst_ev; SC_METHOD(thread_sync_reset); sensitive << clk.pos(); // ... void thread_sync_reset() { if (rst_n == false) thread_rst_ev.notify(); } // ... wait( some_signal.negedge_event() | thread_rst_ev ); By the way: a smart wait_until( some_signal == false ), which supports (synchronous) resets and avoids polling internally would be a very useful feature for writing signal-level protocols. Greetings from Duisburg, Philipp
  6. Oh, and after reading the full compiler error, I see that @AmeyaVS is absolute right about the missing SC_BUILD define.
  7. You need to make sure to select the C++ standard (C++03, C++11, C++14) consistently. See this thread for a detailed explanation: Hope that helps, Philipp
  8. First of all, we need to distinguish between SystemC in general and its synthesizable subset. Whenever something is not explicitly covered by the current synthesizable subset, it's probably best to include the HLS vendors in the discussion. This almost certainly includes sc_signal<sc_uint_base>. Vendors may support this as signal type, if they can derive the width of the signal (statically) during elaboration. But in a fully generic fabric model, this might be difficult. IIRC, the main difference between SystemC and MyHDL or Chisel is that the latter basically create an explicit "netlist" in memory during elaboration. Basically, the synthesis rules/tool is already embedded in the language (kernel) itself, knowing how to generate the elaborated model to Verilog from memory. In SystemC, a synthesis tool is implemented more like a compiler, i.e. working at the language level directly. These are very different approaches with different benefits and limitations. When you refer to "runtime-defined bitwidths", you certainly mean "elaboration-defined", because the widths cannot change once the simulation has started. But sc_uint_base doesn't know about elaboration/simulation. In order to reduce the risk of width mismatches, you would need a custom channel as suggested by Torsten. But as you said, such custom channels are not supported well by HLS tools. Long story short: Having an "elaboration-sized" signal could definitely help for HLS use cases like yours. The simulation model could be implemented quite easily based on a signal specialization for sc_(u)int_base/sc_(u)nsigned. But as long as HLS tools doesn't support it, its usage would be fairly limited. Have you talked to HLS vendors about this already? Last, but not least, I think that C++17 constexpr, especially in combination with if constexpr and auto return type deduction, will provide most of the required features to write generic "hardware construction code" efficiently. Such models would then automatically be synthesizable by an C++17 capable HLS tool, as the code is evaluated during compile time already.
  9. Hi Matthias, I would say, this is just an inadvertent editorial change. The normative text still explicitly includes this transition. I'll forward your finding to the Accellera/IEEE WGs to get this fixed in a future revision of IEEE 1666. Thanks for reporting, Philipp
  10. Can you elaborate a bit more on your question? Figure 28 in IEEE 1666-2011, 15.2.3, shows BEGIN_RESP->TLM_COMPLETED as a valid early completion path? (And yes, 1666-2011 is based on 2.0.1 plus some additional updates).
  11. This question in mostly about how the linker works on your platform, and not really specific to SystemC. Let me try to give a short summary: Yes, the "main" symbol is needed by the final application For every needed symbol, the linker looks in your object files first If the symbol is present there, the linker picks it up If not, the linker looks in the libraries given by the user (order/lookup is platform-specific) Repeat this for all required symbols (including "sc_main") So, if you define your own "main" in your application, SystemC's "main" will not be picked. This is actually a feature, as you can call "sc_elab_and_sim" manually from your "main" as well, if you want. Hope that helps, Philipp
  12. Does is make a difference to explicitly qualify wait() with its namespace? sc_core::wait(); If you happen to call unqualified wait() outside of an immediate SystemC module/channel member function, the compiler might accidentally pick up something else coming from a system header on your platform.
  13. Because your "analyzer" instance is a local variable in the before_end_of_elaboration function, which gets destructed immediately, when the function returns. So there is no analyzer left to call the callback on later (same holds for the local signal sig2, btw.). You would need to allocate the module dynamically instead. You cannot alter/modify/redefine any existing port binding at any time. You can only add new bindings, including during before_end_of_elaboration. Hope that helps, Philipp
  14. I can also add a quote from the Verilog Standard IEEE 1364-2005, $timescale, describing the grammar rules for the timescale support in VCD: So even here, only powers of 10 are allowed.
  15. Quoting IEEE 1666-2011, 8.1.2 (color highlighting mine): So I think, the implementation in SystemC 2.3.2 is in line with the SystemC standard. Instead of failing with an assertion, a more explanatory error message would be helpful, of course. Greetings from Duisburg, Philipp
  16. Hi Jarodw, Thanks for your report. I can confirm and reproduce the issue in SystemC 2.3.2. It looks indeed like a regression compared to SystemC 2.3.0/1 that has been introduced by the fix for optionally unbound sockets, see: It seems, the SystemC regression tests didn't cover the hierarchical binding for the multi sockets, so it wasn't caught before the release. Your example can be fixed by changing line 228 in src/tlm_utils/multi_passthrough_target_socket.h: if (unbound && !m_hierarch_bind) return; // ^-- add check for hierarchical binding here Hope that helps, Philipp
  17. In addition to Thorsten's comments, your main problem is that you call the processes directly instead of invoking sc_start. You should never call process functions manually. They are scheduled by the kernel during the simulation instead. Here's a cleaned up version of your sc_main: int sc_main(int /*argc*/, char* /*argv*/[]) { sc_signal<double> force_main("force main"); sc_signal<double> area_main("area_main"); stimuli_pressure_mech S("stimuli_pressure_mech"); S.force_out(force_main); S.area_out(area_main); pass_on_impulse PI("pass_on_impulse"); PI.force_in(force_main); PI.area_in(area_main); sc_start(); return 0; } I did the following changes: Drop warning suppression - why do you want to allow deprecated features? They are deprecated for a reason. Add names to your signals Drop dynamic allocation of modules in favor of properly cleaned up local variables Drop manual calls to processes Call sc_start to start the simulation (without specific end time, but Thorsten's suggestions is also possible) Hope that helps, Philipp
  18. You can check out the example Makefiles in the installation (examples/build-unix/Makefile.{config,rules} and e.g. examples/sysc/simple_bus/Makefile) as a starting point. The files in examples/build-unix are reasonably generic, and you may "just" need to adjust the settings in Makefile.config. In the project's Makefile itself, you then set the PROJECT variable and your SRCS (to point to your source files). Admittedly, documentation could be better (as usual), but you can ask here, if you have further questions. The CMake support included in SystemC 2.3.2 is still experimental and is mostly targeted for early adopters with CMake knowledge. Greetings from Duisburg, Philipp
  19. Hi Matthias, IIRC, KPNs require that inputs are available on all incoming connections for an actor to fire. In your model, you already consume tokens from some inputs while being then blocked at others. This can be the reason that you don't see the deadlock in your model. But of course, you can also have deadlocks under this approach. Maybe you can trigger it by just switching the order of some of the read statements in your multi-input actors. As a general solution, you need to use a similar pattern as recently discussed in the following thread: Here's an example for one of your processes: void kpn::p7() // merge { static const int f7_n = 1; // number of tokens needed from each input static const int f8_n = 1; while( true ) { while( f7.num_available() < f7_n || f8.num_available() < f8_n ) { // at least one side is blocking, wait for activity on either side wait( f7.data_written_event() | f8.data_read_event() ); } // forwarding possible, process tokens - will not block on inputs unsigned int u = f7.read(); unsigned int v = f8.read(); // ... // may still block out outputs } } Greetings from Duisburg, Philipp
  20. Hi Patrick, You can use every Copyable/CopyAssignable type with sc_fifo or tlm_fifo, as entries are always copied in and out of the fifo slots. There is no special support for e.g. move-only types, yet. It might be a nice to explore options to add such support in order to reduce the cost for passing complex types through fifos. So yes, you can pass std::shared_ptr and std::vector, but e.g. not std::unique_ptr. Greetings from Duisburg, Philipp
  21. The model you describe is not "just" a passthrough model though, as you assume that tokens can be both intercepted (other processes reading from incoming_fifo) and injected (other processes than B writing to outgoing_fifo). From my experience, it is very difficult to design robust models with multiple readers and writers for FIFOs, at least without higher-level synchronization orchestrating the accesses somehow. That said, let's assume these arbitrary FIFO accesses are needed and OK for your use case. I would suggest to indeed use the non-blocking APIs to do the forwarding: while( true ) { if( incoming_fifo.num_available() > 0 && outgoing_fifo.num_free() > 0 ) { // forwarding possible, process token - will never block outgoing_fifo.write( incoming_fifo.read() ); } // at least one side is blocking, wait for activity on either side wait( incoming_fifo.data_written_event() | outgoing_fifo.data_read_event() ); } This will not lead to an additional implicit slot in the passthrough block, but the forwarding is "non-greedy" now, i.e. happens only if a slot is available on both sides. Together with arbitrary other readers/writers on the FIFOs, your passthrough model might never succeed to forward a single token. See above. Minor comment: Your thread_A pseudo code above looks like Java/SystemVerilog and would have a memory leak in C++. You should not put dynamically allocated objects into a FIFO. Hope that helps, Philipp
  22. When you use MSVC 2015/2017, did you make sure to use SystemC 2.3.2? Earlier SystemC versions did not support such recent versions of MSVC. When you say "regression tests", do you mean the SystemC regression test suite? If so, please check the accompanying README_windows.txt for any steps you might have missed. If this still doesn't help, please post some more details on what exact errors you see. Greetings from Duisburg, Philipp
  23. Ok, now I understand your concern: It's also about stack-allocated variables in your threads that are not cleaned up at the end of the simulation, as their stacks are not unwound and dynamic process stacks may not even be explicitly deallocated. I'm not sure, if these cases qualify as real memory leaks, though. Small comment: instead of throwing an (non-standard) sc_halt object, you can simply call : h.kill(SC_INCLUDE_DESCENDANTS); // also kills all child processes There is currently no way to obtain (or kill) all running processes in the simulation, but you can roll your own function to recurse over the object hierarchy via get_child_objects() convert objects to process handles, if valid() and !terminated() call kill(SC_INCLUDE_DESCENDANTS) /Philipp
  24. If you invert the logic and add a function add_initiator to the interconnect, temporarily storing the pointer to the to-be-connected initiator socket (and maybe a name, although this can be derived from the given socket or its parent), you can complete the binding and target socket creation in the interconnect's before_end_of_elaboration hook. Sockets instantiated in this function will be placed correctly in the hierarchy and this approach is fully standards-compliant.
  25. Starting with SystemC 2.3.2, the MSVC project files shipped with the package use the DLL-based runtime library. Therefore it is not necessary (instead rather harmful) to select the statically linked runtime library in your application. Secondly, you should not set the SC_SIGNAL_WRITE_CHECK environment variable to DISABLE (unrelated to your current issue, but suggested in the video above). More instructions on using MSVC with SystemC can be found in the INSTALL file shipped with the proof-of-concept simulator. Hope that helps, Philipp
  • Create New...