maehne

Since the relicensing of the SystemC reference installation under the Apache 2.0 license, there should be no more legal obstacles for package the SystemC libraries for your favorite Linux distribution. Someone just needs to make the effort. Both, the new experimental CMake-based build system introduced with the SystemC 2.3.2 public preview release as well as the autotools based build system provide the necessary functionality to configure/compile/install SystemC in an unattended way, which is needed to automatically build the usual package formats DEB and RPM. CMake comes even with CPack, which should further simplify the process. However, the current CMakeLists.txt files in the SystemC 2.3.2 public preview release do not yet contain the necessary settings for CPack due to the limited bandwidth/time of the authors. Feedback and suggestions on how to improve the installation of the SystemC libraries as well as actively contributing to their development by becoming a member of the respective Accellera working groups are welcome!

Dear Frank, Thanks for reporting this issue! I have reported your issue to the SystemC Verification Working Group. I agree with you that scv_message should not tamper with the default actions for error/fatal messages. I checked the SCV code base by following your track. The actual setting of the default actions happens at the first call to _scv_message::setup() in src/scv/scv_report.cpp lines 96 and 97. By removing these two lines and recompiling/reinstalling SCV, you should be able to fix this issue. Best regards, Torsten Maehne

Without more details, it is hard to give any more advise. How big is the divergence? What kind of system do you try to simulate? What is the structure of the model? What kind of stimuli do you provide in addition to the initial conditions? A minimum working self-contained example demonstrating the problem would also help.

The syntax for assigning the initial condition is correct. I suspect that the diverging results may be caused by the set time step. SystemC AMS uses by default a constant time step to solve the differential equation system. The solver integrated in the proof-of-concept simulator does not do variable time stepping internally as, e.g., Simulink does, because it is purposely limited/optimized to solve (switched) linear differential equation systems. In consequence, you have to be more careful in selecting an appropriate time step based on the time constants in your system. A good rule of thumb is to select a time_step <= 0.1 * smallest_time_constant as a starting point.

The SystemC 2.3.2 public preview version fixes many warning by modern C++ compilers. It is definitely worth a try.

Both proposed solutions work. The one proposed by the original poster itself is more elegant, as all build variants of the library end up in the same folder hierarchy so that the provided configuration files can pick up all variants. It is currently not automatically done by the SystemC's CMake build system as other build systems usually link blindly to libsystemc.so. The consequence is, that we currently need to install different build variants to separate directory trees. IMHO, it is worth discussing whether the installation of different build variants to a common tree is not the better approach in the long run to facilitate the life of the users who build their applications using CMake. For this, we should settle for good postfixes for all variants. The recommended build variant could either skip the postfix or provide additionally a link libsystemc.so to point to the recommended variant. Feedback is welcome!

There are many issues in your code: You do not instantiate your module ImageProcessing in sc_main(). The member function ImageProcessing::synchronisation() is never used. From the code, you probably want that it shall be executed as a SC_THREAD. You mix C and C++ for memory allocation and IO. I suggest you to use <iostream> instead of <stdio.h> for your input and output needs. Use new and delete instead of malloc() and free() if you really need it. However, it is usually better to use a suitable container, e.g., std::vector instead of raw pointers and manually allocated memory. Prefer to #include <systemc> over <systemc.h>, <cstdlib> over <stdlib.h>, etc. to avoid polluting the public namespace. The variable b, used in your code, doesn't seem to have been declared. If b is an int, the division by 196608 won't yield the floating point result, which you expect as an integer division will be performed. ... These are just the ones, which jump to the eye. It seems you are not only struggling with SystemC, but also with C++. I suggest you to read a good introductory book on C++ (Stroustrup: "Programming: Principles and Practice Using C++" or "The C++ Programming Language") as well as on SystemC (e.g. Black, Donovan et al.: "SystemC from the Ground Up").

Have you read the README file in the risc_cpu example directory? You have to compile your assembler program using the provided simple assembler and store it in the icache.img file, which gets loaded by the instruction cache module upon its construction. However, the instruction set is only documented in the source code of the risc_cpu example (see decode.cpp). It is also a very old example, which might not be easily extensible to achieve the goals of your project. Other platforms (such as the SoClib mentioned in one of my previous posts) are better documented.

Why do you post your messages several times to the forum? It won't help to motivate people to answer you. However, posting the error message in English instead of French and providing a bit more context would certainly help. That said, the SystemC-related warnings during the compilation of your code are probably due to the use of a too recent Visual Studio version. As you can see from the README of SystemC 2.3.1, it has only been tested to work on Visual Studio 2005, 2008, 2010, and 2013. Only the SystemC 2.3.2 public preview version contains the fixes to make it compile without warning on Visual Studio 2010, 2013, and 2015. I suggest you to use it. I suspect that there's a similar issue with OpenCV though I have never used it. Have you tried to follow this guide?.

Roman is right with his statements and suggested solutions. However, you should also reconsider the structure of your test bench. A test bench should primarily interact with the DUT through its public interface. Therefore, composition is the right choice, i.e., instantiate your BIT_ADDER inside your test bench module as a member variable. Then, bind its ports to signals and drive/monitor them from SC_METHODs/SC_THREADs. This setup resembles test benches in VHDL. You may still use single inheritance in this case to overload certain functions. However, you should pay attention that only one sc_module_name object gets constructed during the construction of you class, e.g., by taking it as a const reference (see clause 5.3 in IEEE Std 1666-2011). You may also instantiate the test bench module (or separate stimuli/monitor modules) and the DUT on the same hierarchical level from within sc_main() and then connect them via channels.

CMake is also able to generate a Visual Studio 2015 project. However, the risc_cpu example is maybe not a good starting point for what you want to achieve. It lacks a full C toolchain for compiling code into its machine code. Only a basic assembler is provided. Have a look to, e.g., SoCLib for a platform for modeling microprocessor systems using SystemC.

The installation layout of the SystemC proof-of-concept library deviates from the standard layout commonly used on Linux. Therefore, SystemC is usually installed to a directory under /opt/. This may cause your problem with CPack. However, an experimental CMake-based build system has been added to the SystemC 2.3.2 public review release. Instructions for using it are contained in the text file cmake/INSTALL_USING_CMAKE. When building and installing SystemC using CMake, also the necessary configuration files for locating SystemC are installed. For example, a minimal CMakeLists.txt to compile the simple_perf SystemC example as a stand-alone application would be: cmake_minimum_required(VERSION 3.1) project(simple_perf CXX) set (CMAKE_PREFIX_PATH /opt/systemc) find_package(SystemCLanguage CONFIG REQUIRED) set (CMAKE_CXX_STANDARD ${SystemC_CXX_STANDARD} CACHE STRING "C++ standard to build all targets. Supported values are 98, 11, and 14.") set (CMAKE_CXX_STANDARD_REQUIRED ${SystemC_CXX_STANDARD_REQUIRED} CACHE BOOL "The with CMAKE_CXX_STANDARD selected C++ standard is a requirement.") add_executable(simple_perf simple_perf.cpp) target_link_libraries(simple_perf SystemC::systemc) Please, give it a try and provide feedback so that remaining issues can be resolved. Note though that CPack hasn't been considered so far in the implementation of the CMake-based build system for SystemC. Therefore, feedback on this aspect is even more interesting.

The current SystemC proof-of-concept implementation does not support complete reinitialization of its simulation kernel, which would be needed for the use case outlined by you. Elaboration is done only a single time at which point the design hierarchy gets fixed. I would suggest that you have a look at the object traversal API offered by sc_core::sc_object (see clause 5.16) and all classes deriving from it. This should allow you to easily check your instance names for different test cases.

The type you pass as a template argument to sc_core::sc_fifo<T> has to fulfill a couple of rules, which are described in detail in clause 6.23.3 of the IEEE Std 1666-2011. In summary, your type Transfer needs to provide: a) The output stream operator: std::ostream& operator<<(std::ostream&, const Transfer&); This one is missing, which is hinted to you by the compiler error. b) The assignment operator (not missing as auto-generated by the compiler for a struct): const Transfer& operator=(const Transfer&); c) The default constructor if any other constructor is defined for your type Transfer (not necessary for a pure struct as in your code snippet): Transfer::Transfer();

Thanks for the feedback on how to make SystemC work on the aarch64 platform! At least another party has expressed its interest for support of this platform and offered patches, which are currently under review in the Language Working Group. Regards, Torsten

Simple answer: No. A template is a pattern, which the compiler uses to generate a concrete implementation of a class/function once you use it (i.e., at the place where you either specify the template arguments explicitly or the compiler determines them based on the arguments passed to a function call of a templatized function. Therefore, the compiler has to see at all times the definition of a templated class/function. More information can be, e.g., found in this FAQ: https://isocpp.org/wiki/faq/templates#templates-defn-vs-decl

Once sc_stop() has been called, you are not allowed to call sc_start() anymore (cf. to clause 4.5.3 in IEEE Std 1666-2011). For each unit test involving a sc_start() and sc_stop() sequence, you will have to start an own process to ensure that the SystemC kernel is properly initialized. Testing frameworks, which link together individual unit test into one big executable containing the test runner are to my knowledge not suitable for unit testing SystemC applications. The reason is that the simulation kernel of the SystemC PoC simulator can currently not be restarted due to some implementation constraints. However, you can use script-based test runner approaches, e.g., provided by CMake/CTest. Once you link to libsystemc, you will also have to provide a sc_main() function. Most SystemC functions will only properly work in the context of sc_main(), especially if they manipulate to design hierarchy (anything related to sc_object or control elaboration/simulation), You can check the SystemC regression test suite for examples on how to do unit testing in the SystemC context.

The easiest standard-conformant option I see to get an approximate idea how much time is spent in elaborating your SystemC model, which contains your RC network is by getting a time stamp using gettimeofday() just before calling sc_start() and then another from within the processing() member function of a TDF model attached to your RC network (e.g. via an sca_eln::sca_tdf::sca_vsource(). Note that I would personally prefer to use the std::chrono library introduced with C++'11 and more specifically std::chrono::high_resolution_clock::now() instead of gettimeofday() to time execution of code segments. If you want to more precisely time the RC network setup, you would need to dive into the implementation details of the SystemC AMS extensions PoC simulator. A starting point would be to look into sca_eln::sca_implementation::sca_eln_view::setup_equations(), where the solvers for the different clusters of ELN modules are instantiated.

Have you looked at the functions defined in clause 4.5.7 Functions to detect pending activity of IEEE Std. 1666-2011? Using the simcontext directly is not advisable as its interface is not part of the SystemC standard. It is thus an implementation detail of the Accellera proof-of-concept implementation of SystemC on which you should not depend on if you want a portable solution.

Dear Sumit, I fear that there's no universal solution to register your datatype for any kind of tracing mechanism. You will have to implement the interfaces of each tracing mechanism separately (i.e., SystemC's sc_trace() and SystemC AMS's sca_trace() + all the vendor tools, which don't use the standard mechanism) for your datatype. Be aware that the semantics of tracing may differ from the context, where you use your data type. Regards, Torsten

Yes, you can connect the other connection directly to the input port of the mixer model, but outside your mixer, you will need to instantiate a TDF signal, which is connected to the mixer.in port. That signal then has to be driven by some other signal generator, which output port is connected to that top-level signal. Otherwise, SystemC-AMS will give an error that the input signal is not driven.

SystemC currently does not support to do several distinct simulations from within the same application process. Once elaboration is finished, you cannot instantiate new modules, ports, and channels, as they would modify the design hierarchy. Furthermore, after an sc_stop(), it is an error to call sc_start() again, see IEEE Std 1666-2011, clause 4.5.3: "It shall be an error for the application to call function sc_start after function sc_stop has been called." You may be able to arrange for your design hierarchy to stay constant across all simulation runs. In that case, you could make changes to the parameterization of the module instances in your hierarchy to modify stimuli and behavior each time an sc_start() hands back control to your sc_main(). If you need to do several simulations with divergent design hierarchies, you will have to launch an own process for each simulation case. You could store the parameters for the different simulation runs in one or more configuration files and pass this config file plus possible additional parameters as command line arguments to your SystemC application to easily switch between the different cases. A script file can then automate the execution of all the different necessary simulations.

When implementing your own memory manager for TLM payload objects, you have to follow the rules laid down in IEEE Std 1666-2011 clauses 14.5 and 14.6. When you are leaking memory it is because your new operation to allocate a new tlm_generic_payload object has no matching delete operation. As I understand your implementation, you want to pool the allocated objects once they've been created for the rest of the simulation to reuse them after they've been handed back to the memory manager for another allocation. Therefore, the right moment to delete your payload objects is when the memory manager is deleted itself. To achieve this, you have to traverse your free_list in the mem_manager::~mem_manager() destructor and call delete on each entry. Additionally, you have changed the visibility of your memory manager destructor from public to private. This is not good object-oriented design. Also, the generic payload pointer *ptr should not be a member variable but rather a local variable to mem_manager::allocate(). Clause 14.5e) of IEEE Std 1666-2011 states that you should also call the reset member function of your tlm_generic_payload object in order to delete any extensions marked for automatic deletion. I hope these hints help you to resolve your memory management issues!

Your problem is not SystemC-specific, as you are not following basic rules of C++ programming: To use classes of SystemC like sc_core::sc_interface or sc_core::sc_module, you have to #include the respective header (in our case <systemc>) before. You haven't done so in your headers comm_interface.h and comm_channel.h Also, your headers comm_interface.h and comm_channel.h seem to lack #include guards, which cause the type redefinition errors. I encourage you to not use the header <systemc> and not <systemc.h> to avoid public namespace pollution. Then, you have to prefix most SystemC classes with the sc_core:: namespace prefix. In function scope, you can avoid this by adding "using" declarations for the symbols/namespaces you plan to use in the current scope.

Hello, The warnings, which you observe are due that the SystemC 2.3.1 sources as the underlying IEEE Std 1666-2011 is still based on the C++'03 standard, but your C++-compiler (g++ 6) defaults to the C++'14 standard. To diagnose the failing tests, you should examine the run.log and diff.log files, which have been generated by the test.sh scripts in the directories with the failing tests. Please report your findings here so that we can see whether there are new issues, which need fixing in a future version of SystemC. To more thoroughly test your compiled SystemC library, you can compile the SystemC regression test suite against your installed SystemC library. Best regards, Torsten Maehne