Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. I don't see anything wrong with the code, but I don't have access to this platform. The aarch64 platform support has been contributed newly in SystemC 2.3.2 and has only been tested with GCC 4.5.0 so far. Can you provide more more details about the crash? (e.g. backtrace, build logs for library and application - including all command-line invocations, ...) Do you see any compiler warnings during the library/model build? Does it help to switch to the pthreads-based process implementation (../configure --enable-pthreads ...)? Greetings from Duisburg
  2. You cannot bind sockets with different payload classes, as the interfaces are templated over the protocol traits, which include the payload and phase types. So integrating this third-party model would require an adapter in your case. Many use cases can be implemented with (ignorable) extensions, which will avoid this incompatibility and integration burden. As a result, you don't have to write/use a custom adapters, interconnect models, tool integrations, etc. For maximum interoperability with models and tools, you want to follow the (base-protocol) conventions as closely as possible, e
  3. You did nothing wrong. This is an issue with Clang/LLVM-based compilers and their specific treatment of virtual private inheritance, see e.g. https://bugs.llvm.org/show_bug.cgi?id=30916. Other compilers accept this code. Greetings from Duisburg, Philipp
  4. Hi Patrick, right now, there is no official publicly accessible repository of the SystemC proof-of-concept implementation. Both repos you mention above are not owned by Accellera. So applying the patch manually on top of a local source tree is sufficient: cd systemc-2.3.2 patch -p1 < 0001_sc_process_*.patch # usual install steps mkdir -p objdir cd objdir ../configure make make install Thanks, Philipp
  5. In fact, IEEE 1666-2011 already requires an error when calling wait/next_trigger with an empty event list (5.2.17, 5.2.18). This is currently not the case for the proof-of-concept implementation and will be fixed in the next version. Unfortunately, I have not been able to reproduce the crash using your example on any of my setups. Can you please try if the attached patch fixes the crash for you? Thanks, Philipp 0001-sc_-_process-remove-dynamic-processes-from-process_t.patch
  6. IEEE 1666-2011 explicitly allows spawning threads from start_of_simulation, see 4.4.3 (b). I agree. Having some way to decide on the behavior on an empty event list would be helpful. I'll forward your suggestions to the LWG. Thanks for preparing the example! I'll try to reproduce and investigate further. Greetings from Duisburg, Philipp
  7. Some further comments: You don't need to keep handles to processes, if you don't intend to interact with them later. The crash you saw was likely caused by the fact, that the process was killed before you tried to register the sensitivity to it through your sc_event_and_list. Even if you kept the handle alive, you would still miss the notification: the process has already terminated when you run your wait(processes_complete); and the event will not be triggered again. It would be much safer to only store the handles and build up the event list locally to wait for the completi
  8. On the first question: Yes, you do need to keep the handle to the (terminating) process alive, if you continue to reference any related object like the terminated event. Otherwise, when the process terminates without any existing handles to it, the event will be destroyed together with the process instance itself and you're sensitive to a no-longer-existing event, causing the memory corruption. The crash itself is fixed in the master branch of the SystemC proof-of-concept simulator, but not released yet. This fix would then lead to removing the event from any waiting processes, though.
  9. Hi Sumit, The repo is still there, but it is private to the Accellera CCIWG. If you are an Accellera member, you can request access separately. (For GreenSocs-specific parts, you need to contact GreenSocs, of course. The Accellera proof-of-concept implementation doesn't depend on GreenSocs anymore). Greetings from Duisburg, Philipp
  10. Thanks for reporting, Eyck! I have submitted the suggested fix to the WG for review.
  11. This usage of sc_module_name is wrong and will break the module hierarchy. The only thing you are allowed (but not even required) to do with the module name object inside your constructor is to forward it to the sc_module base class. As Roman said, you would have to prepare the name outside of the module instead (or use sc_vector). /Philipp
  12. Have you included "/vmg" in the additional compiler options in your MSVC project?
  13. 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.
  14. 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
  15. 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 corr
  16. 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
  17. Oh, and after reading the full compiler error, I see that @AmeyaVS is absolute right about the missing SC_BUILD define.
  18. 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
  19. 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
  20. 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
  21. 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).
  22. 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" wil
  23. 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.
  24. 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
  25. 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.
  • Create New...