Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. It should be fine to use wait(n) in SC_THREADs (with static sensitivity) as well?
  2. For your particular use case, you can just pass in the clock signal directly: SC_CTHREAD(test_cthread, clkgen); // posedge by default for CTHREADs If you need a negedge triggered process, you can also write the equivalent SC_THREAD instead: SC_THREAD(test_cthread); sensitive << clkgen.negedge_event(); dont_initialize(); Allowing plain events for CTHREAD sensitivity was probably just never needed.
  3. There is an example for catching and re-throwing an sc_unwind_exception in IEEE 1666-2011, clause Hope that helps, Philipp
  4. Hi all, Both sc_get_current_process_b() and get_parent() are non-standard functions that may or may not be supported by (future) versions of your SystemC implementation. I recommend to only use standard IEEE 1666-2011 APIs instead: x sc_core::sc_get_current_process_handle().get_parent_object()->name() x sc_core::sc_get_current_process_handle().name() Greetings from Duisburg, Philipp
  5. For example, the missing operator delete was added in C++14 only (quoting from http://en.cppreference.com/w/cpp/memory/new/operator_delete) : void operator delete ( void* ptr, std::size_t sz ); (5) (since C++14) void operator delete[]( void* ptr, std::size_t sz ); (6) (since C++14)
  6. Yes. Most likely, because your clang-7 installation uses an incompatible C++ standard library. /Philipp
  7. Hi Sumit, can you please share some details on your remark that "it does not compile with -std=c++17"? For me, the SystemC 2.3.2 library and examples compile and run fine with GCC 6.3 and -std=c++17 (no 6.2 installation at hand here). Your linker errors look like you're missing the (matching) C++ runtime libraries in your linker call. Do you configure clang to use libc++ instead of libstdc++? Can you link any other C++ library built with GCC 6.2 to an application built with Clang 7? I would expect that this issue is not specific to SystemC and I would recommend to stick to a single compiler for all artifacts in your application, including SystemC. Hope that helps, Philipp
  8. You can have a look at examples/tlm/common/include/models in the Accellera proof-of-concept implementation for an example interconnect model. Hope that helps, Philipp
  9. The purpose of the initialize() function of the signal ports is to set the value of the bound signal at the beginning of the simulation through the given port.
  10. For hierarchical point-to-point binding, just use plain tlm_initiator/target_sockets on the parent module. You can keep using (tagged) convenience sockets at the leaves. Hope that helps, Philipp
  11. 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, Philipp
  12. 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, even for custom protocols. See the different TLM-2.0 compliance categories (IEEE 1666-2011, 9.1). Hope that helps, Philipp
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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 completion of still running processes: std::vector<sc_process_handle> processes; for(int i = 0; i < 10; ++i){ auto process = sc_core::sc_spawn(sc_bind(&My_Class::my_method, this, args)); processes.push_back(process); wait(10, SC_US); } // wait for running processes { sc_event_and_list processes_running; for( const auto& p : processes ) { if ( p.valid() && !p.terminated() ) processes_running &= p.terminated_event(); } wait( processes_running ); } For the second part (crash during process cleanup): Do you see a difference when spawning the thread during end_of_elaboration()? sc_spawn'ed threads from an start_of_simulation() callback a strictly speaking "dynamic threads" in the SystemC terminology, yes. But internally, they are still added to the process table in order to start them in the correct order relative to the rest of the kernel initialization. In the destructor however, only non-dynamic threads are removed from the process table. This means, you may have indeed found a bug in SystemC 2.3.2. I'll check this with the Language Working Group. Thanks and Greetings from Duisburg, Philipp
  18. 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. So in this case, you would just miss the notification. On the second part: Which version of SystemC are you using? Can you confirm this with SystemC 2.3.2? Greetings from Duisburg, Philipp
  19. 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
  20. Thanks for reporting, Eyck! I have submitted the suggested fix to the WG for review.
  21. 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
  22. Have you included "/vmg" in the additional compiler options in your MSVC project?
  23. 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.
  • Create New...