-
Posts
547 -
Joined
-
Last visited
-
Days Won
135
Content Type
Profiles
Forums
Downloads
Events
Everything posted by Philipp A Hartmann
-
Why sc_signal<T>::trace() is deprecated ?
Philipp A Hartmann replied to Roman Popov's topic in SystemC Language
Hi Roman, This would be something to discuss in the Accellera SystemC LWG (or the IEEE P1666 WG). In practice, most/all commercial simulators provide much more advanced tracing mechanisms already, beyond what the current sc_trace() API allows to support. My guess would be, that this part of the standard is something where it is difficult to reach consensus, as it touches the core distinguishing features of commercial SystemC offerings. Moreover, the sc_trace()-based API is a costly "pull" interface, which effectively loops over all variables at each time step and does a value comparison. This is also pretty inefficient for e.g. signals, which already "know" if they changed. So I think, a plain sc_interface::trace() addition is not sufficient to bring real additional value here. Last, but not least, this function would have to have a default (empty) implementation to not break existing models and would require some extension mechanism to add support for custom types. Greetings from Duisburg, Philipp -
What is SystemC library special in?
Philipp A Hartmann replied to katang's topic in SystemC Language
SystemC supports pkg-config as well and generates a corresponding systemc.pc file. Of course, you still need to have the systemc.pc file somewhere in your PKG_CONFIG_PATH. For manual Makefiles, you can check the templates in examples/build-unix as a starting point. Greetings from Duisburg, Philipp -
Your consumer process is wrong: void do_reads() { char c; while (true) { if ( in->nb_read(c) ) { // only print valid characters cout << c << flush; } // wait for the next clock wait(); } } Hope that helps, Philipp
-
tlm_socket_base_if
Philipp A Hartmann replied to Guillaume Audeon's topic in SystemC TLM (Transaction-level Modeling)
Hi Guillaume, thanks for the background! For the time being, I guess you need to work around this issue in your custom sockets then by providing your own implementation of this function in SystemC >= 2.3.2. Greetings from Duisburg, Philipp -
Hi Tibor, the stack_protect function is called upon creation and destruction of the thread. Upon creation, a special guard page after the end of the stack is allocated and protected against accesses to catch (some) stack overflows. Upon deletion of the thread, this protection is removed. Quoting https://danwalsh.livejournal.com/6117.html (highlighting mine): Therefore, I agree that we probably don't need to try adding PROT_EXEC to the page's permissions and can only keep the read/write settings: // Revert the red zone to normal memory usage. else { ret = mprotect( redzone, pagesize - 1, PROT_READ|PROT_WRITE); } Can you try with this change again? Thanks and Greetings from Duisburg, Philipp
-
tlm_socket_base_if
Philipp A Hartmann replied to Guillaume Audeon's topic in SystemC TLM (Transaction-level Modeling)
Hi Guillaume, I agree, that the new pure-virtual functions in tlm_base_(initiator/target)_socket are not compliant to IEEE 1666-2011. However, I'm curious what use case you have to use these classes directly instead of inheriting from tlm_(initiator/target)_socket, where the functions are implemented? Regarding the implementation on the base socket level, I suggest to add a typedef to the fw/bw interface classes, and use these typedefs in the socket base class then. Something like: template <typename TYPES = tlm_base_protocol_types> class tlm_fw_transport_if // ... { public: typedef TYPES protocol_types; }; // tlm_base_target_socket virtual sc_core::sc_type_index get_protocol_types() const { return typeid(typename FW_IF::protocol_types); } Theoretically, these types could mismatch between FW_IF and BW_IF in manual socket implementations. Therefore, I'd suggest to refer to the FW_IF in the target and BW_IF in the initiator socket. Greetings from Duisburg, Philipp -
I'm not aware of any executable heap usage in SystemC either. However, there is a known issue around executable stacks in the QuickThreads implementation on some SELinux-enabled machines. Quoting the RELEASENOTES file: - When building the SystemC library with QuickThreads support, the resulting shared library is marked as requiring an executable stack by certain compilers/assemblers (or rather not marked as not needing one). As a result, some system security systems (like SELinux) might refuse to load the library. As a workaround for GNU (compatible) assemblers, pass the assembler flags variable with the option CCASFLAGS="-Wa,--noexecstack" to the `configure' script call before building the SystemC library. In case you can reproduce the effect again, can you try the suggested flag on the configure script? Hope that helps, Philipp
-
tlm_fifo nb_peek
Philipp A Hartmann replied to vasu_c's topic in SystemC TLM (Transaction-level Modeling)
Alternatively, as you don't seem to require the debug interface, you can change the port to: sc_port<tlm::tlm_get_peek_if<int> > target_port; -
Short answer: You can't. See this thread for a related discussion: Greetings from Duisburg, Philipp
-
Hi Roman, I can give some background here, as I'm guilty of the current implementation. The kernel also needs to handle exceptions that are escaping SystemC thread processes. These are originally thrown in a different stack and still need to be propagated to sc_main, i.e. the main thread in order to be able to still catch the exceptions there in user code. The propagation across stacks has to be done by catching in one stack and rethrowing in another. That said, exception handling not only covers sc_report, but also arbitrary exception types escaping sc_main or a SystemC thread. We don't want to cause std::terminate to be called in case of uncaught exceptions, but want to properly propagate, catch and wind down the simulation. Therefore, all exceptions are translated to standard sc_report objects before cross-stack propagation and are finally handled outside of sc_main. For consistency, the translation to sc_report is done for both, thread and method processes: It's an error, if an exception escapes a SystemC process and errors are reported as sc_report (and routed through the report handler) in SystemC. Users can catch the original exceptions themselves by adding catch blocks to sc_main and their SystemC processes. Hope that helps, Philipp
-
Possible Bug/Regression in SystemC 2.3.2: Race Condition
Philipp A Hartmann replied to AmeyaVS's topic in SystemC Language
Hi Ameya, thanks for testing. As said before, unfortunately I cannot reproduce this on my end. I would need more details on the current behavior: The backtrace looks like there is something broken during model teardown. Have you seen other cases? Are all simulations with processes hanging in a similar way? (e.g. can you provide a full regression result?) Greetings from Duisburg, Philipp -
Possible Bug/Regression in SystemC 2.3.2: Race Condition
Philipp A Hartmann replied to AmeyaVS's topic in SystemC Language
Hi Ameya, I currently don't have access to such new Linux platforms, but I may have a suspicion about a potential root cause. Can you please check, if it helps to change the sc_process_b::delete_process function in src/sysc/kernel/sc_process.cpp as follows: // if ( this != sc_get_current_process_b() ) if ( NULL == sc_get_current_process_b() ) Thanks and Greetings from Duisburg, Philipp -
risc_cpu example in systemc package
Philipp A Hartmann replied to Khushi's topic in SystemC TLM (Transaction-level Modeling)
This example still uses the positional binding feature of SystemC, which is deprecated as per IEEE Std. 1666 (see Annex C (h), emphasis mine): hth, Philipp -
TLM2 endianness conversion functions
Philipp A Hartmann replied to Khushi's topic in SystemC TLM (Transaction-level Modeling)
The full data length is independent of the word length. The rules for DATAWORD are defined by the standard as follows (see 14.20.3): From your example below, you seem to be using four byte word, so "unsigned" (or uint32_t) could be a used as a DATAWORD parameter. -
TLM2 endianness conversion functions
Philipp A Hartmann replied to Khushi's topic in SystemC TLM (Transaction-level Modeling)
Hi Khushi, the best is to look up the definition in the IEEE 1666-2011 standard, section 14.20(.3). The different conversion functions have different constraints associated with them, allowing for more performant implementations for the _word, _aligned, and _single specializations. The _generic one covers arbitrary cases. The DATAWORD template parameter allows for optimizations as well (and endianness is always specific to the notion of a word). Hope that helps, Philipp -
SystemC Simulation Semantics and Scheduler Steps
Philipp A Hartmann replied to Ivan's topic in SystemC Language
Hi Ivan, instead of referring to the very old 2.01. LRM, I suggest to check the IEEE Std. 1666-2011 for SystemC, which could can download at no cost (sponsored by Accellera) via https://standards.ieee.org/findstds/standard/1666-2011.html. This document includes the normative answers to all of your questions. Yes, see section 5.10.8 of the aforementioned standard. Kind of, yes. This is called "time out", see section 4.2(.1) of the standard. The order to execution of processes in the runnable queue is entirely implementation-defined. See section 4.2.1.2. Hope that helps, Philipp Disclaimer: I haven't checked all of your post for correctness and focused on the questions instead. . -
Hi Sumit, I re-checked the LLVM issue and it now refers to C++ CWG issue #7 (http://www.open-std.org/Jtc1/sc22/wg21/docs/cwg_closed.html#7), which clearly describes our situation here and shows that the current implementation of tlm_req_rsp_channel<...> is invalid C++ in SystemC (even though only Clang rejects it so far). Without changing the inheritance pattern, the only fix would be to add "friend" declarations to all (indirect) virtual base classes of tlm_put_get_impl<...>, including sc_interface. This is not an option, so I think the internal implementation of the tlm_req_rsp_channel<...> needs to be refactored to avoid the private virtual inheritance. I have opened an issue in the SystemC Language WG bug tracker for this. Greetings from Duisburg, Philipp
-
SystemC 2.3.2 has been tested successfully with C++03, C++11, C++14 (and even C++17) with various compilers. As mentioned in this thread, the selected C++ standard needs to match between the library build and the application build. This is enforced by the linker error you see. If you continue to run into these errors, make sure to build the SystemC library with the matching C++ standard selection compared to your application (see INSTALL or cmake/INSTALL_USING_CMAKE how to do that).
-
The 'CMAKE_CXX_STANDARD' is specific to cmake. When you use automake/configure, you can configure the build by passing the '-std=c++11' flag directly to the configure call: ../configure ... 'CXXFLAGS=-std=c++11' Hope that helps, Philipp
-
SystemC 2.3.2 works fine with C++03, you just need to configure the C++ standard consistently between your application and the library build. In the (experimental) SystemC Cmake build setup, the selection always defaults to C++03, regardless of the default of the compiler. In your application build, you might not explicitly set the C++ standard on the command-line, giving you a different default version from your compiler. The behavior of the SystemC CMake setup could be improved here. Greetings from Duisburg, Philipp
-
Hi all, you may want to try the attached sc_semaphore.h (requires C++11 to avoid the use of sem_init on MacOS). Hope that helps, Philipp sc_host_semaphore.h
-
Passing event to SC_CTHREAD macro
Philipp A Hartmann replied to Roman Popov's topic in SystemC Language
It should be fine to use wait(n) in SC_THREADs (with static sensitivity) as well? -
Passing event to SC_CTHREAD macro
Philipp A Hartmann replied to Roman Popov's topic in SystemC Language
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.