-
Posts
547 -
Joined
-
Last visited
-
Days Won
135
Content Type
Profiles
Forums
Downloads
Events
Everything posted by Philipp A Hartmann
-
Best practices: SC_HAS process question for experts
Philipp A Hartmann replied to David Black's topic in SystemC Language
Because current C++ features makes it possible to implement SC_THREAD etc. without the SC_HAS_PROCESS helper macro . -
Best practices: SC_HAS process question for experts
Philipp A Hartmann replied to David Black's topic in SystemC Language
In IEEE 1666-2023 (i.e. SystemC 3.0), you can just skip SC_HAS_PROCESS entirely, the SC_THREAD, SC_METHOD macros no longer require it. -
I would think that 7.3 only applies to the conversion to a SystemC datatype. If the literal would be smaller than the target type, the sign extension applies, quoting the very next sentence from the section you quoted: ... unless you omit the prefix: In your example, you pass in a literal with the matching length of the destination type and there should not be any extension anyway.
-
Best practices: SC_HAS process question for experts
Philipp A Hartmann replied to David Black's topic in SystemC Language
Keeping declarations in their smallest required scope is generally a good practice in C++. To me, this applies to SC_HAS_PROCESS as well, which currently is a typedef underneath. I agree, that a repetition in multiple constructors (or before_end_of_ekaboration()) is not a big concern. -
Best practices: SC_HAS process question for experts
Philipp A Hartmann replied to David Black's topic in SystemC Language
Actually, SC_HAS_PROCESS will no longer be needed at all in future versions of SystemC when using C++11 (and maybe the next standard?). -
Using SC_CTHREAD in end_of_elaboration()
Philipp A Hartmann replied to DavidC's topic in SystemC Language
I don't think there's such a way without changing the SystemC library? You can certainly change the aforementioned part to raise a warning/error instead, when calling sc_sensitive for SC_CTHREAD with an event finder during sc_get_status() == SC_END_OF_ELABORATION. -
Using SC_CTHREAD in end_of_elaboration()
Philipp A Hartmann replied to DavidC's topic in SystemC Language
I would assume, it's an oversight as it is currently not supported by the IEEE 1666-2011 standard. You can likely "fix" it by changing line 248 in src/sysc/kernel/sc_sensitivity.cpp: void sc_sensitive::make_static_sensitivity( sc_process_b* handle_, sc_event_finder& event_finder_) { if (sc_is_running() || event_finder_.port().get_interface()) { // line 248, check for already bound port handle_->add_static_event( event_finder_.find_event() ); } else { Greetings from Linz, Philipp -
Running SystemC on new Apple M1 silicon
Philipp A Hartmann replied to William Lock's topic in SystemC Language
A better solution is to compile for C++11 (or later) instead, where sem_* APIs are not required. -
Memory leak when sc_event is notified twice
Philipp A Hartmann replied to Lukas Steiner's topic in SystemC Language
This is not really a memory leak, but a very bad „model“ for the current implementation. I wonder if you saw any such scenario in a real model? „Canceled“ notifications like in your case will still be kept in the kernel‘s internal data structures until the notification time is reached (1ms in your case). You would pile up 999,999,999 of these canceled notifications until they are „deallocated“, each of them taking entries in the event queue and 16 bytes for the notification itself. Which is a lot of memory. I wrote „deallocated“ in quotes, because sc_event_timed uses a very simple memory pool based on a free list to reuse previously allocated structures. So even when the canceled notifications are released, they won‘t be handed back to the OS (not even at the end of the simulation) but will be kept allocated for future notifications. But they do not leak in an unintended way. If you change your example to e.g. have the same number of iterations without piling up billions of pending events, you should see a stable memory consumption: event.notify( 1, SC_NS ); event.notify( 1, SC_PS ); Hope that helps, Philipp -
SystemC 2.3.3 using MSVC causes read access violation
Philipp A Hartmann replied to maarten's topic in SystemC Language
Make sure to include /vmg in your project's compiler settings, see https://github.com/accellera-official/systemc/blob/master/INSTALL.md#creating-systemc-applications -
Bizarre error when doing wait(&event)
Philipp A Hartmann replied to Mark's topic in SystemC Language
From the code itself, it's not obvious to me, where the unexpected overload of sc_core::wait(int) is called. Can you try attaching a debugger and break on the exception (catch throw in gdb) and check from the backtrace, where from the exception is thrown? -
Bizarre error when doing wait(&event)
Philipp A Hartmann replied to Mark's topic in SystemC Language
I suggest to move to SystemC 2.3.3, if possible. (The error message indicates, that you seem to be using SystemC 2.3.1). Secondly, can you show the derived class of the fifo as well (including its constructor)? -
Which compiler/platform are you using? If you are on MSVC, make sure to include /vmg in your compiler settings as described in the INSTALL file. Hope that helps, Philipp
-
Looking at the source code of any SystemC implementation is sometimes misleading. Check IEEE 1666-2011, Annex C (deprecated features), item (n):
-
SC_METHOD Dynamic Sensititivity Modification
Philipp A Hartmann replied to sheridp@umich.edu's topic in SystemC Language
... and sc_method_process is a non-standard class, which even is incomplete on the model side when including <systemc(.h)>. So I would not call this clean. Regarding your original solution, it is important to note that you are not supposed to change an sc_event_list object while processes are sensitive to it. In your case, it works because you trigger the process immediately, which then 're-reads' the event list right away and therefore updates the sensitivity without breaking the kernel state What do you want to achieve that makes you want to do this? /Philipp -
Valgrind does not play well with the Quickthreads package used for the SystemC threads by default. As Torsten said, please try with SystemC 2.3.3 and configure your SystemC library build with --enable-pthreads to switch to the posix-based thread implementation, see https://github.com/accellera-official/systemc/blob/master/INSTALL.md.
-
The only normative reference for SystemC is defined by the IEEE Std. 1666-2011, see http://ieeexplore.ieee.org/document/6134619/. The is_reset() was never part any version of the standard, so one could never rely on its presence. You would to check, why the ReChannel library tries to call this function and then find another way to implement this functionality. /Philipp
-
MINGW64 : undefined symbol in libsystemc.a
Philipp A Hartmann replied to JIBI3731's topic in SystemC Language
Actually, it is expected that you don't have the QuickThreads package built on MinGW. As you can see from your config.log, the threading package to use is But it seems that the source code is missing an explicit check for _WIN64 to catch the MinGW-64 case. Can you try compiling with WIN64 defined (without leading underscore): ../configure CXXFLAGS="-DWIN64" Hope that helps, Philipp -
sc_fifo::read() - g++ gives warning that tmp is unset
Philipp A Hartmann replied to plafratt's topic in SystemC Language
This compiler warning is a false positive. There is a loop in sc_fifo<T>::read(T&) ensuring that the fifo is not empty (and the success of the nb_read(T&) is even guarded by an sc_assert😞 while( num_available() == 0 ) { sc_core::wait( m_data_written_event ); } bool read_success = sc_fifo<T>::nb_read(val_); sc_assert( read_success ); The check for num_available() is even stricter than the check in buf_read, but I can imagine that some compilers might not be able to prove this invariant. Therefore, unconditionally initializing the local variable to silence the warning might be an acceptable trade-off.