maehne

Dear Julien, thanks for reporting that issue! I confirm your findings and have forwarded the issue to the SystemC LWG so that it can be fixed. I am sorry for the long delay reacting to your message due to the summer vacation period. Best regards, Torsten Maehne

Deleted message

No, unfortunately not yet. Due to the summer vacation period, no one found yet the time to investigate and find a potential fix for that issue.

Each port of a module needs to be bound to some channel -- in your case of type sc_signal_rv<W> (see IEEE Std 1666-2011, clause 6.17). In you example, you would do this binding in sc_main(). However, you model lacks also stimuli generation. You seem to be just starting with C++ and SystemC: I suggest to read first a good book on C++ and SystemC before trying to write your own models. E.g., check out isocpp.org/get-starte, Doulos, and "SystemC: From the Ground Up, Second Edition".

As you already found out, sc_get_current_process_handle() is not suitable, which is confirmed by IEEE Std 1666-2011, clause 5.6.7: "When called from sc_main during simulation, sc_get_current_process_handle shall return an invalid handle." To my knowledge, the standard does not define a function, which would return directly the information you want to obtain. I would suggest to augment your models with suitable logging code, which might be conditionally activated once your simulation enters an interesting phase. Logging could be done in the simplest case to the console or you might hand the inf

I am not aware of a widely used free PSL implementation for SystemC. However, you can find some research papers discussing using PSL together with SystemC, e.g.: Ali Habibi, et al.: Assertion Based Verification of PSL for SystemC Designs, IEEE, 2004. Wolfgang Ecker, et al.: Implementation of a SystemC Assertion Library, Design & Reuse.

Yes, the simplest way is to write the desired initial bool value to the bound signal using the signal’s write() member function (see IEEE Std 1666-2011, clause 6.4.4), e.g., from sc_main() before starting your simulation with sc_start().

Thanks @Lukas Steiner for reporting this issue! I have forwarded it to the SystemC LWG for investigation.

Thanks @mo_ayman for all the additional information and minimal example demonstrating the problem! Have you tried to reach out to the developers of mingw-w64 and of MSYS2? Over the years, quite some issues were raised relating to exception handling for both projects. The minimal example, which you provide, should be useful to debug it on the mingw-w64 and MSYS2 side. Indeed, QuickThreads is becoming a maintenance burden, as it is abandoned upstream for many years and few people are knowledgeable about its working. Porting it to new platforms has always been a headache. Maybe, this part of

User @mo_ayman posted on 2020-07-15 on the SystemC forum about his effort to fix QuickThreads on Win64. He has created a branch on GitHub containing the current state of his fixes, which is based on SystemC 2.3.2.

@Matthias Jung may be interested in your fixes, as he also stumbled on this issue. He also created a GitHub issue on the official public GitHub repository of the SystemC proof-of-concept implementation.

For the record, @mo_ayman posted about the current state of his fixes to QuickThreads on Win64 in this separate thread.

Thanks @mo_ayman for all your effort in trying to fix QuickThreads on the 64-bit Windows platforms and sharing the current state of your fixes with us! Indeed, SystemC should default to use WinFibers on the Windows platform. Historically, this was only reflected in the MSVC project files, but not in the configure.ac files, as the latter would only work in Unix environments. Much is also handled in the source code itself using conditional compilation based on compiler/platform-specific preprocessor definitions. Cygwin as a POSIX environment for Windows was always a special case, which I got the

Thanks for reporting this issue for the edge case INT64_MIN! I have forwarded it to the SystemC LWG for investigation.

Any two-dimensional array a2d[rows][cols] can be mapped to a one-dimensional array a1d[rows*cols]. Accessing an individual element using row and col requires just mapping the coordinate to the equivalent one-dimensional index i = row * cols + col. If you want to use a nested sc_vector< sc_vector<rc> >, you should adapt the code @Philipp A Hartmann suggested in the second thread, which you mentioned. @T. Zimmermann provided a working example in the same same thread. However, it is not making use of lambda functions to further compact the code. As I wrote in the same thread, you