maehne

The SystemC PoC implementation can be built for ARM using CMake. Instructions can be found here.

Per default, I would recommend you to prefer sc_signal, as it yields optimal performance for the common case, where you want to cause activation of a listening thread/method only when the signal‘s value has actually changed. sc_buffer is primarily useful, when you want to synchronise thread/method executions based on each write - even if the same value got written.

I am not aware of a RISC-V port of QuickThreads. The members of SystemC LWG only minimally maintain it as part of the SystemC proof-of-concept implementation. On unsupported platforms, alternatives (Pthreads, Fibers) can be used.

During initialization, all processes are executed once except those, which have been marked with dont_initialize(). See IEEE 1666-2011, clause "4.2.1.1 Initialization phase" for details.

Check cmake/INSTALL_USING_CMAKE for instructions how to build static libraries using a CMake-based build. Basically, BUILD_SHARED_LIBS needs to be set to OFF.

You don't seem to be familiar with basic C++ concepts: You pass NUM as template parameter to the type sc_uint, i.e., its value needs to be known at compile time. If you want to pass this parameter when you instantiate your My_module, you'll have to make it a templated struct: template<int NUM> struct My_module : public sc_core::sc_module { sc_core::sc_in<sc_dt::sc_uint<NUM>> a{"a"}; //... }; Your Top module is also unsuitably structured: The My_module pointer mod needs to be a member variable. I wouldn't recommend to use C-style raw pointers, but std::unique_ptr for this purpose to automatically handle deallocation. Note that you need to pass NUM as template parameter like you did it for your port a in the sample code. I recommend you to first learn properly C++, before exploring more SystemC.

Meant is GNU M4, an implementation of the traditional Unix macro processor. You can check out a tutorial, e.g. this one, to get a first glimpse on how to use it.

@Diego: What the above replies by @karthickg and @David Black are not taking into account is that you are using the sca_eln:sca_de::sca_rswitch from the SystemC AMS extensions. Its ctrl input will get sampled with the time step associated with the cluster of instantiated ELN modules. Therefore, you need to ensure that the SystemC simulation time advances when executing your embedded software in the TLM/DE part of your model. To this end, you will need to issue wait statements in the appropriate places, e.g., inside the instruction set simulator / CPU model executing your embedded software or inside the API calls, which interact with the hardware. It heavily depends on the modeling style of the rest of your system. Anyway, reading the boolean control signal in the get() member function is the right approach to reflect the state of the sca_rswitch.

Regarding this claim: The code snipped in Example 7.2 on page 87 of the SystemC-AMS User Manual published in January 2020 is correctly using SC_MODULE.

Replace SCA_TDF_MODULE with SC_MODULE and it should work. Your module instantiates other modules to interconnect them. A TDF module is always a primitive module without any inner structure in form of submodules. Instead, it serves to describe the timed dataflow behaviour using the various TDF callbacks.

I suggest that you test whether this problem is present when building SystemC and the example from the official public Git repository and otherwise raise this issue/provide a PR on the GitHub issue tracker so that it gets seen by the people involved in the development of the proof-of-concept simulator.

The nullor is not suitable for modelling a clamped operational amplifier, as it forces the voltage and current at the input terminals (i.e., its nullator side) to zero, but leaves the voltage and current at its output terminals (i.e., the norator side) completely undefined. This only works when a feedback path exists from the outpu to the negative input terminal. The voltage sink attached to the nullor output does not contribute an equation to the equation system. I suggest you replace the nullor with a voltage controlled voltage source with a sufficiently high gain. You may also need to add an artificial load resistance to its output in case the SystemC AMS PoC implementation should still have a problem to establish the equation system.

Why don't you simply use the template parameter T instead of uint32_t?

Thanks for reporting the issue! I forwarded it to the SystemC LWG. If you could provide a small reproducer of the issue, it would help us to reproduce and test the suggested fix. FYI, you can also create issue on the public SystemC repository.

How about constructing an sc_fxval from your integer, shifting then its value to the right by the amount of fractional digits and then constructing your sc_fixed variable with fixed number of bits from it?