Matthias Jung

When I want to compile AMS, it stops at the ./configure step: configure: error: "sorry... architecture not supported." For normal SystemC (not the AMS part) I solved it by using CMAKE. Is there already a fix to build AMS on the M1 Macs?

For my SystemC-Lecture, I wrote a simple DES simulator to reduce to the minimal mechanisms that are required to understand the DES concept. (https://github.com/myzinsky/des/tree/main/sw). For that I used C++20 co-routines for the 'processes'. Therefore, I was wondering if somebody has considered these co-routines also as co-routines for SystemC, instead of qt, pthreads or fibers?

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 //#endif I assume that MinGW is still detected as linux. Any ideas to fix it?

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.

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

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

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?

Hi Philipp, thank you, Matthias

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:

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).

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.

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

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

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

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