maehne

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?

Thanks for reporting this issue! I think your use case is justified. However, the decision to not installing the header seems to have been made on purpose as utils/sc_stop_here.h is explicitly added to NO_H_FILES in src/sysc/utils/files.am. The behavioural difference between the Automake and CMake-based build flow is probably unintentional. I have reported the issue to the LWG for investigation.

Building SystemC using G++ from MSYS2/MinGW-64 should work as described in the INSTALL file. To diagnose your problem, it would help if you could provide all commands, which you used to configure and build SystemC 2.3.3 and then to run the tests. Please, also provide the log file generated by configure. Did you observe any errors/warnings during the compilation of the SystemC library? You should pass in the CXXFLAGS to your configure call as described in the INSTALL file, section "SystemC Library Configuration Switches": ../configure CXXFLAGS="-DSC_OVERRIDE_DEFAULT_STACK_SIZE=0x80000" You can also try to build SystemC with the latest fixes released in its official public Git repository. You can also try to build SystemC from that repository using CMake as described in cmake/INSTALL_USING_CMAKE.

Thanks @plafratt for providing these additional details. I have reported this issue to the LWG for investigation. The warning can be probably fixed by default-initialising the tmp in line 235 of sc_fifo.h

Your message is not providing enough information about your environment. Which version of SystemC did you compile. I suggest you to start with the latest released version of the SystemC proof-of-concept library. Did you follow all the instructions found in section "Installation Notes for Windows" of INSTALL.md? Did you compile SystemC as a static library or DLL? Where you able to build and execute the examples coming along with the SystemC library? Did you also follow the instructions for "Creating SystemC Applications" when you compiled your test program? If you want to link your application against a DLL build of SystemC, you also have to following the instructions in the section "Building against a SystemC DLL". Especially, when running the simulation, your SystemC DLL needs to be in the PATH!

Have you tried to compile and run a simple hello-world-style C++ program in the same environment, from which you called configure? The config.log shows that your PATH contains the bin directories of many different EDA toolchains. Some of them come before the bin directories of your host OS. This may cause issues as these EDA toolchain installation tend to include a lot of basic libraries, which are normally provided by the host OS. This can cause interferences. You may try configure and build SystemC in an environment, where the PATH got pruned of all the EDA toolchain bin paths.

@plafratt: It would be very helpful if you could provide more detailed information to reproduce your observation as suggested by @Roman Popov. With what version of g++ running on which platform have you observed the warning. A small self-contained code example demonstrating the issue would help us to reproduce the issue on our side so that we can forward the issue with enough information to the SystemC Language Working Group for fixing.

Thanks @Asdruv for reporting this bug! I have forwarded your report to the LWG. Best regards, Torsten Maehne

sc_core::sc_in<T> only allows binding of a single sc_core::sc_signal<T> (cf. to IEEE Std 1666-2011, clause 6.8). However, you may use for in_B a sc_core::sc_port<sc_core::sc_signal_in_if<T>, 3, SC_ONE_OR_MORE_BOUND> (cf. to IEEE Std 1666-2011, clause 5.12) that will accept binding of exactly three signals. The implementation of the OR relation of the three signals can be then handled inside an SC_METHOD of objB. To access the three different signal from in_B, you can use the operator[] implemented by the sc_port. By the way, you may also specify a different number of channels to be bound and also a different port binding policy.

If you don't use the member functions added that were added for convenience to `sc_in`, `sc_out`, and `sc_inout` to, e.g., call `read()`, `write()`, and the event member functions via the `.` operator than via the corresponding member function in the interface accessed via the `->` operator, you might be able to avoid entirely the derivation of new port classes. Instead, you could simply use a template alias, which was introduced with C++'11: template<typename T> using sc_in_opt = sc_core::sc_port<sc_signal_in_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; template<typename T> using sc_inout_opt = sc_core::sc_port<sc_signal_inout_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; template<typename T> using sc_out_opt = sc_core::sc_port<sc_signal_inout_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; If you want to also provide all member functions of `sc_in`, `sc_out`, and `sc_inout`, you will have to derive from the `sc_port` class and implement the full interface as defined in IEEE Std 1666-2011.