maehne

Your questions are answered by clause 4.3.4.2 "Function sc_start" in IEEE Std 1666-2011: More details on the simulation cycle, you can find in clause 4.2 "Simulation". Yes, see clause 4.3.4.2 of IEEE Std 1666-2011: Clause 4.5.7 of IEEE Std 1666-2011 lists functions to detect pending activity: sc_pending_activity_at_current_time(), sc_pending_activity_at_future_time(), sc_pending_activity(), and sc_time_to_pending_activity().

The paper on gSysC suggests that it implements a loose coupling by only deriving from the corresponding SystemC ports and signals (Figure 3) and controlling the simulation by calls to sc_start() (section 4). Since the semantics of the ports, signals, and sc_start are still quite similar in IEEE Std 1666-2011 and its proof-of-concept implementation SystemC 2.3.3, it should not be too hard to update this coupling interface to SystemC. If I remember correctly SystemC 2.0.1 did not yet use namespaces and gSysC doesn't seem to use them either. Just using <systemc.h> instead of <systemc> may help, but once you know the coupling still works as intended, I would suggest to invest the effort to reference all SystemC classes with the proper namespace prefixes in the gSysC codebase and also move the gSysC implementation to an own namespace so that the potential for naming conflicts gets minimised. I suspect that you will have to invest more effort on porting the code from Qt3 to Qt5. You may consider contacting the authors of gSysC using the information on the gSysC homepage.

You cannot bind a signal to another signal. Instead, you have to bind one or more matching ports to your signal. Your sc_signal<bool, SC_MANY_WRITERS> implements sc_signal_inout_if<bool>. Therefore, ports of type sc_in<bool>, sc_out<bool>, and sc_inout<bool> may be bound to that signal. Due you specified the SC_MANY_WRITERS policy, There won't be an error to write to that signal from more than one processes during any given evaluation phase (see clause 6.4.4 of IEEE Std 1666-2011). So, declare fifo_full to be of type sc_out<bool>. Then, binding that port to the signal main_full should work as you stated: main_fifo1.fifo_full(main_full); You may also consider using sc_signal_resolved and its ports sc_in_resolved, sc_inout_resolved, and sc_out_resolved, which uses the sc_logic instead of bool (clause 6.13ff in IEEE Std 1666-2011).

I have no experience with the emscripten platform. However, the proof-of-concept implementation uses by default QuickThreads to implement co-routines for enabling SC_METHODs and SC_THREADs, which uses platform-specific assembly code. You may have more success using POSIX threads (Pthreads), which seems to be supported by emscripten. You can find detailed build instructions for SystemC in the INSTALL.md file.

I agree with @AmeyaVS that it would help if you could share the current state of your modifications in form of a .diff file in this forum or as a work-in-progress pull request on the public SystemC repository on GitHub. Then more people can have a look to maybe suggest a fix for the second half of the issue. It would be great if this long-standing issue regarding QuickThreads on Cygwin64 could be finally fixed.

One good resource for understanding the fundamental concepts of SystemC is "SystemC from the Ground Up", 2nd edition, Springer by David Black et al. Of course, IEEE Std. 1666-2011 is the definitive source to be consulted for any semantic details.

Check clause 5.11 of IEEE Std 1666-2011 for the member functions of the sc_time class. sc_time::value() will return the underlying integer representation of the time value, which has to be interpreted together with the set discrete time resolution. sc_time::to_seconds() returns a double value representing the time value in seconds.

Yes, you can simply download and build the proof-of-concept implementation of SystemC by following the contained INSTALL instructions. You just need to install Xcode and its command line tools. Instead of the GNU-autotools-based build system, you may also use CMake to set up the build. You can display VCD trace files with GTKwave.

Could you please be more specific and post the error messages, you are receiving when building SystemC 2.3.3 with VS 2019? Also, have you tried it with the most recent development state from the public SystemC Git repository of Accellera?

Yes, you'll need to add a helper module C, which upsamples your slow signal to the fast rate, i.e., which input rate is 1 and output rate is 60. In the simplest case, you can just duplicate 60 times the same value. However, you may also implement some kind of interpolation. Note: By creating a feedback loop, you will also have to specify a suitable delay and initial samples to restore causality! I suggest that you read the section 2.1 "Modeling fundamentals" of the the SystemC AMS User's Guide to gain further insight.

Thanks for reporting this issue and analysing the cause! I have forwarded your report to the SystemC LWG. Could you please try to make the preprocessor condition more strict by adding "!defined(__MINGW32__)" (see here and here) and report back whether this fixes the issue?

See this thread, SystemC 2.3.1 triggers some known Valgrind reports. Most should be fixed in the latest SystemC release (version 2.3.3) available from Accellera. You may also consider building and using SystemC directly from the official public Git repository. If you search this Forum for "valgrind", you can find several other relevant threads. If the problem persists with the latest SystemC release, it would be nice if you could post a complete reproducer so that we can have a closer look. @Philipp A Hartmann may then be able to make some more comments.

As you are already building your SystemC model using DLLs, I would suggest that you also build SystemC as a DLL and link to it. This most probably should fix your problem as suggested by @Roman Popov.

Thanks @Timur Kelin for reporting this issue! I have forwarded it to the SystemC LWG to investigate how to fix it best in the proof-of-concept implementation of SystemC.

Without any self-contained code example exposing this error, it will be difficult for anyone on this forum to help you. Do you observe the same error, when running your example in the Accellera proof-of-concept implementation of SystemC instead of the SystemC version coming with your vendor tool?