maehne
-
Posts
365 -
Joined
-
Last visited
-
Days Won
43
Content Type
Profiles
Forums
Downloads
Events
Posts posted by maehne
-
-
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.
-
-
@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.
-
Quote
This is the code taken directly from the SystemC-AMS User Manual
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?
-
Use “::” instead of “:.” To separate the namespace “sc_dt” from the type name.
-
You cannot instantiate modules in an SC_METHOD, as it will only execute during simulation. You have to do the instantiation in the constructor, so that it is done during elaboration. Also, multiple instances of a module are best instantiated using an sc_vector as container.
-
@kcai1107: Thanks for sharing the code snippet. A minimal self-contained example exposing the issue would be helpful to replicate the issue on our side though -- especially if it is a real issue to be addressed in the SystemC proof-of-concept implementation. sc_mutex are derived from sc_object and therefore, it is recommended to manage a collection of such objects using sc_vector. The minimum benefit would be the possibility to give them a good (hierarchical) instance name, which would facilitate debugging. Have you tried to modify your implementation to use the non-blocking trylock() + wait in your dynamic process instead of the blocking lock() to work around the issue?
-
I concur with @Bas Arts, you need to declare the destructor of mm_ready_valid_in to be virtual. Depending on your class hierarchy, this may make sense also for its base class(es).
-
As for SystemC, you have to pass for SCV the right include path, library path and link flags. The error message indicates that the linker is not finding the implementation of `scv_startup()`, so you have to find the location of libscv.a or libscv.so on your system, add the the appropriate `-L` and `-rpath` flags and then tell the linker to also link against it. Note, the order is important: first `-lscv` and then `-lsystemc`.
-
@DavidC: Thanks for reporting these cross-compilation issues. Indeed, cross-compiling has not been tested. We are aware of the inconsistencies between the autotools-based compilation flow vs. the CMake flow. I reported your findings to the LWG for consideration.
-
Thanks for the issue report and suggested fix @raku99. I reported it to the SystemC VWG for consideration.
-
Thanks @raku99 for reporting this issue. Could you please have a look to accellera-official/systemc#3 on GitHub to check whether it is the same issue? If yes, it would be nice if you would add any additional information, you may have on it. If not, please open a new issue and provide some more details about the exact platform and toolchain you are using as well as instructions how to reproduce your issue. MSYS2 provides nowadays already 6 environments with different toolchains, so we require that information to reproduce your issue.
-
SystemC 2.3.3 unfortunately causes problems when adress sanitizer is used, see this GitHub issue for details. Maybe, @LukasJuenger can provide some further feedback, as he did some work to make the SystemC PoC implementation compatible with address sanitizer.
-
Sorry, but I have used Visual Studio only a few times (to check whether my CMake build files yielded correct project files for Visual Studio). So, I don't have any experience regarding its compilation performance accross multiple versions of Visual Studio.
-
-
The SystemC PoC implementation includes a subset of the Boost libraries. The stackoverflow question, you found, points clearly out the source of the error (`visualc.hpp`). In the SystemC PoC implementation, this header is located in `src/sysc/packages/boost/config/compiler/`. At the end of that file, it is stated that the "last known and checked version is 19.16.27032.1 (VC++ 2017, Update 9)". Your version of Visual Studio is probably newer and therefore, you receive this warning. Until the Boost version packaged with SystemC is updated, you can either live with it or patch the responsible header to not print the message. In fact, Boost has itself commented out the warning in the header since March 2018, as they were not anymore able to keep up with the pace of Visual Studio releases.
I will report the issue to the Language Working Group so that this can be addressed in the next release.
Quick Threads assembly for aarch64
in SystemC Language
Posted
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.