Jump to content

Matthias Jung

  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Matthias Jung

  1. C:\Users\...\systemc\src\sysc\packages\qt\md\iX86_64.s: Assembler messages:
    C:\Users\...\systemc\src\sysc\packages\qt\md\iX86_64.s:77: Error: junk at end of line, first unrecognized character is `-'
    mingw32-make.exe[2]: *** [...\systemc\src\CMakeFiles\systemc.dir\build.make:1266: .../systemc/src/CMakeFiles/systemc.dir/sysc/packages/qt/md/iX86_64.s.obj] Error 1
    mingw32-make.exe[1]: *** [CMakeFiles\Makefile2:1006: .../systemc/src/CMakeFiles/systemc.dir/all] Error 2
    mingw32-make.exe: *** [Makefile:129: all] Error 2

    SystemC was build with CMAKE in the context of a CMAKE project. Under Linux and macOS its works, but on windows I get this assembler error shown above. It can be fixed by using pthreads but I think qt are much better. 

    Commenting out the last 3 lines in the .s file helps:

    //#if defined(__linux__) && defined(__ELF__)
    //.section .note.GNU-stack,"",%progbits

    I assume that MinGW is still detected as linux.

    Any ideas to fix it? 

  2. So I can build sucessfully SystemC with QtCreator under Windows with MinGW that is provided with QtCreator using CMake. So it should now be pretty save that the SystemC compiling process is correct.

    However, when I use the SystemC Library withing one of my projects, I have again this error:

    C:/<...>/Qt/Tools/mingw530_32/bin/mingw32-make -f Makefile.Release
    mingw32-make[1]: Entering directory 'C:/<...>/Programming/SCVP.artifacts/build-tlm_at_1-Desktop_Qt_5_10_0_MinGW_32bit-Release'
    g++ -Wl,-s -Wl,-subsystem,console -mthreads -o release\tlm_at_1.exe release/main.o release/memory_manager.o -LC:\Users\jung\Programming\systemc-2.3.2\build-systemc-2.3.2-Desktop_Qt_5_10_0_MinGW_32bit-Default\src -lsystemc
    C:\<...>\main.cpp:-1: error: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)'

    This are the Flags used by CMake 

      "directory": "C:/<...>/Programming/systemc-2.3.2/build-systemc-2.3.2-Desktop_Qt_5_10_0_MinGW_32bit-Default/src",
      "command": "C:\\<...>\\Qt\\Tools\\mingw530_32\\bin\\g++.exe  -DSC_BUILD -DSC_ENABLE_ASSERTIONS -DSC_ENABLE_EARLY_MAXTIME_CREATION -DSC_ENABLE_SIMULATION_PHASE_CALLBACKS_TRACING -DSC_INCLUDE_FX -DWIN32 @CMakeFiles/systemc.dir/includes_CXX.rsp -O3 -DNDEBUG   -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -std=gnu++98 -o CMakeFiles\\systemc.dir\\sysc\\communication\\sc_clock.cpp.obj -c C:\\<...>\\Programming\\systemc-2.3.2\\systemc-2.3.2\\src\\sysc\\communication\\sc_clock.cpp",
      "file": "C:/<...>/Programming/systemc-2.3.2/systemc-2.3.2/src/sysc/communication/sc_clock.cpp"

    Here is the qmake project example:

    TARGET = tlm_at_1
    TEMPLATE = app
    CONFIG += console
    CONFIG -= app_bundle
    CONFIG -= qt
    INCLUDEPATH += C:\<...>\Programming\systemc-2.3.2\systemc-2.3.2\src
    LIBS += -LC:\<...>\Programming\systemc-2.3.2\build-systemc-2.3.2-Desktop_Qt_5_10_0_MinGW_32bit-Default\src -lsystemc
    HEADERS += ../tlm_memory_manager/memory_manager.h
    HEADERS += initiator.h
    HEADERS += target.h
    HEADERS += util.h
    SOURCES += main.cpp
    SOURCES += ../tlm_memory_manager/memory_manager.cpp

    It seams that Systemc was build with -std=gnu++98 also adding this flag to the qt-project does not help to solve the issue.

  3. 15 hours ago, Roman Popov said:

    If you want to build SystemC inside QtCreator you can use CMake project bundled with systemc 2.3.2 ( Open Project, select CMakeLists.txt) .  There is no need to create a qmake project.

    I tried that before and it was not working. However, now its working thanks for the hint!



  4. Im setting up SystemC with qmake:

    TARGET = systemc
    TEMPLATE = lib
    CONFIG += staticlib
    CONFIG -= qt
    QMAKE_CXXFLAGS = -Wall -O3 #-std=c++11
    QMAKE_CFLAGS = -Wall -O3
    INCLUDEPATH += src/
    SOURCES += $$files(src/sysc/communication/*.cpp, true)
    SOURCES += $$files(src/sysc/datatypes/bit/*.cpp, true)
    SOURCES += $$files(src/sysc/datatypes/fx/*.cpp, true)
    SOURCES += $$files(src/sysc/datatypes/int/*.cpp, true)
    SOURCES += $$files(src/sysc/datatypes/misc/*.cpp, true)
    SOURCES += $$files(src/sysc/kernel/*.cpp, true)
    SOURCES += $$files(src/sysc/tracing/*.cpp, true)
    SOURCES += $$files(src/sysc/utils/*.cpp, true)
    HEADERS += $$files(src/sysc/communication/*.h, true)
    HEADERS += $$files(src/sysc/datatypes/bit/*.h, true)
    HEADERS += $$files(src/sysc/datatypes/fx/*.h, true)
    HEADERS += $$files(src/sysc/datatypes/int/*.h, true)
    HEADERS += $$files(src/sysc/datatypes/misc/*.h, true)
    HEADERS += $$files(src/sysc/kernel/*.h, true)
    HEADERS += $$files(src/sysc/packages/boost/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/bind/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/config/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/config/compiler/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/config/platform/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/config/stdlib/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/detail/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/mpl/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/mpl/aux_/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/mpl/aux_/config/*.hpp, true)
    HEADERS += $$files(src/sysc/packages/boost/utility/*.hpp, true)
    HEADERS += $$files(src/sysc/tracing/*.h, true)
    HEADERS += $$files(src/sysc/utils/*.h, true)
    HEADERS += $$files(src/sysc/qt/qt.h, true)
    SOURCES += $$files(src/sysc/qt/qt.c, true)
    !contains(QMAKE_TARGET.arch, x86_64) {
        message("x86 build")
        SOURCES += $$files(src/sysc/qt/md/i386.s, true)
    } else {
        message("x86_64 build")
        SOURCES += $$files(src/sysc/qt/md/iX86_64.s, true)

    Under Windows I have this compilation issue when I use Mingw as compiler:

    ..\systemc-2.3.2-qmake\src\sysc\kernel\sc_ver.cpp:166:1: error: specialization of 'sc_core::sc_api_version_2_3_2_cxx201103L<DisableVirtualBind>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy) [with const int* DisableVirtualBind = (& sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_)]' after instantiation

    Has somebody an idea whats going on here?


    I assume that it has something to do with the order of the building?

  5. Dear Philipp,


    IIRC, KPNs require that inputs are available on all incoming connections for an actor to fire. 

    That is unfortunately not the case :( . When a process reads from a queue, the read is blocking. If the queue is empty, then the process will suspend until there is enough data in the queue. This allows even data dependent control flow or control flow depending on internal variables:

    process f(in int u, in int v, out int w) {
        int i; bool b = true;
        while (true) {
            i = b ? wait(u) : wait(w);
            printf("%i\n", i);
            send(i, w);
            b = !b;

    This is an example form Kahn's original paper in a C syntax. Alternately u and v is read. So it is not necessary that all incoming connections are required to fire the process.

    When a process blocks, the scheduler will not unblock the process until enough data becomes available on the blocking input port. Writes to the queues are non-blocking because the queue size is infinite. 

    For the example that you show, you peek into the FIFOs which is not allowed for KPNs actually.



  6. Hey,

    Kahn Process Networks are defined by the usage of unbounded FIFOs with blocking reads and non-blocking writes.
    I read on several sources that KPN with bounded FIFO size (i.e. blocking read and blocking write) can be implemented with SystemC (e.g. Grötker et al).

    It seams that the event based scheduler in SystemC behaves different like data-driven scheduler or a demand-driven for KPNs.
    I simulated the networks of Park's Dissertation shown on page 36 and 42 which should end up in an artificial deadlock (deadlock which occurs because of blocking write).

    A global artificial deadlock in SystemC would result in no scheduled events, and therefore, the simulation should be stopped.

    However, even with buffer size 1 for all FIFOs both examples from Park are continuing with execution:

    Note that edaplayground exits because of to much output. If you want to test it you better download it and run it on your PC.

    Apparently, the SystemC scheduler finds automatically a schedule for the KPN such that no artificial deadlocks occur.
    My question: is there an example where I could also see an artificial deadlock in SystemC?

    Thanks and Regards


  • Create New...