Jump to content

Matthias Jung

Members
  • Content Count

    12
  • Joined

  • Last visited

About Matthias Jung

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Matthias Jung

    Mingw Compile Issue

    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.
  2. Matthias Jung

    Mingw Compile Issue

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

    Mingw Compile Issue

    When I start this, cmake uses MSVC for compiling, how can i force it to use MinGW? -DCMAKE_CXX_COMPILER -DCMAKE_CC_COMPILER Seems to be ignored
  4. Matthias Jung

    Mingw Compile Issue

    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. Matthias Jung

    Difference between TLM 2 and 2.0.1

    Hi Philipp, thank you, Matthias
  6. Matthias Jung

    Difference between TLM 2 and 2.0.1

    Hi Philipp, sorry my question was misleading. Why the transition from nb_transport_bw/BEGIN_RESP to TLM_COMPLETED has been removed from The OSCI TLM LRM (2009) to the Systemc 1666 LRM (2011). See attached Picture:
  7. Why has the path from nb_transport_bw/BEGIN_RESP to TLM_COMPLETED has been removed from The OSCI TLM LRM (2009) to the Systemc 1666 LRM (2011).
  8. Matthias Jung

    Kahn Process Networks (KPN) with SystemC

    I found a solution: https://github.com/tukl-msd/SCVP.artifacts/tree/master/kpn_artificial_deadlock Indeed it depends on the way how SystemC schedules the processes. Note that it may behave differently w.r.t. scheduling and therefore also w.r.t. FIFO sizes If you call wait(SC_ZERO_TIME) in between.
  9. Matthias Jung

    Kahn Process Networks (KPN) with SystemC

    Dear Philipp, 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. Regards Matthias
  10. 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: Page 63: http://www.edaplayground.com/x/6Mfi Page 42: http://www.edaplayground.com/x/4jLZ 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 Matthias
  11. Matthias Jung

    Question about cout and time

    Hey, is there a way or mechanism such that a cout or printf statement in an SC_METHOD is delayed to the last delta cycle before the time advances? Similar to the VCD traces? Such that only the last stable value is printed to the terminal. Regards Matthias
  12. Matthias Jung

    Compiling SystemC on ARM

    In the context of the gem5 project we discovered that compiling SystemC does not work on ARM 64 bit (i.e. aarch64 has 64 bit longs). It can be fixed by adding this: https://gem5-review.googlesource.com/c/3462/1/ext/systemc/src/sysc/datatypes/int/sc_nbdefs.h Thank you and regards Matthias
×