Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


maehne last won the day on June 21

maehne had the most liked content!

About maehne

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    Burgdorf, Switzerland

Recent Profile Visitors

602 profile views
  1. Sorry for the late reply! I just saw that this post now. The lines containing scv_report_handler::set_actions(...) in the _scv_message::setup() member function implemented in scv_report.cpp were removed by @StS as suggested in my post from 2017-08-08. So you just stumbled again over the same issue.
  2. Because this detects early common errors when describing the behavior of digital circuits, which would be fatal if they get implemented through logic synthesis. If two gates (represented by different processes, i.e., SC_THREAD or SC_METHOD) drive the same signal line, the resulting behavior in hardware is hard to predict and depends heavily from the used technology. Correct logic levels on the signal line are not anymore guaranteed and high currents flowing constantly through the same wires from VDD to GND can damage the IC. If different gates shall drive the same line (common to model signal busses), they need to have tristate outputs and the logic has to guarantee that driving the line is mutually exclusive. If we come to writing test benches, activating SC_MANY_WRITERS in certain selected cases may be necessary to, e.g., easily inject faults inside the DUT. So, IMHO, the default of SystemC is sane and protects the user.
  3. 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.
  4. A strange SystemC warning

    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())
  5. SystemC/TLM Debian packages

    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!
  6. 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
  7. 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.
  8. 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.
  9. openCv systemC

    The SystemC 2.3.2 public preview version fixes many warning by modern C++ compilers. It is definitely worth a try.
  10. 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!
  11. refine Code

    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").
  12. CPU_SystemC

    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.
  13. openCv systemC

    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?.
  14. 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.
  15. Risc_Cpu

    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.