maehne

Members
  • Content count

    138
  • Joined

  • Last visited

About maehne

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Burgdorf, Switzerland

Recent Profile Visitors

429 profile views
  1. The SystemC 2.3.2 public preview version fixes many warning by modern C++ compilers. It is definitely worth a try.
  2. 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!
  3. 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").
  4. 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.
  5. 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?.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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();
  11. 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
  12. 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
  13. 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.
  14. 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.
  15. 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.