• Content count

  • Joined

  • Last visited

About maehne

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    Burgdorf, Switzerland

Recent Profile Visitors

524 profile views
  1. I agree with Roman that UVM-SystemC is the way to go in the long run. In the meantime, you should be able to avoid the observed warnings by passing globally unique module names to the modules and sc_objects you are creating across all tests. This should satisfy the hierarchical name registry of SystemC. To my knowledge, the latter does not keep track of deallocation of sc_objects and thus that its corresponding hierarchical name is not anymore used. Be aware though that you may run into other surprises as the SystemC kernel is currently not able to fully restart from scratch elaboration and simulation.
  2. The root for your problem is not in the implementation of SystemC, but in your code. You forgot that in C, you cannot simply concatenate C string (i.e., arrays of type char) by adding them. Instead of concatenating strings the addition of char(ID+'A') to the string "My_Name_" modified the pointer to the string to point ID+65 positions beyond the start of the original string. At that point in memory is probably only garbage, which was interpreted by the sc_object constructor as an object name thus causing the illegal characters warning. To properly concatenate strings in C, you need to reserve a big enough buffer to hold the concatenated result and then use strcpy(), strcat(), strncpy(), strncat() functions copying / concatenating strings. However, in C++, you can use std::string to simplify your task. The following code should work. Though, it may not be optimal in terms of performance (a std:: string gets temporarily constructed): scMod((std::string("My_Name_") + char(ID+'A')).c_str())
  3. 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!
  4. 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
  5. 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.
  6. 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.
  7. The SystemC 2.3.2 public preview version fixes many warning by modern C++ compilers. It is definitely worth a try.
  8. 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 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 to point to the recommended variant. Feedback is welcome!
  9. 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").
  10. 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.
  11. 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?.
  12. 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.
  13. 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.
  14. 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.
  15. 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.