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 information over to some global function/object first, which processes further the information before storing/outputting it.

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 the SystemC can be reimplemented in some future version in a portable way using C++'20 coroutines once they become more widely available.

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 impression was less popular among SystemC users on Windows. The same holds true for the much younger MSYS2 environment. Few of the developers, which contribute to the proof-of-concept implementation of SystemC are using it on Windows and then usually with MSVC. The last person, who had a look at this problem was @ralph.goergen back in 2016. Therefore, we are lacking experience with the particularities of the Cygwin and MSYS2 environments to support you in finding the cause for the remaining issue related to exception handling. As you may have noticed, the co-routines code is very old dating back to 2001. @Andy Goodrich, @Philipp A Hartmann, and @jeromecornetst did touch to some extend the concerned source files, so I don't know to which degree they may be able to help you. Could you provide besides your patch to the SystemC implementation also a small test case illustrating your remaining issues? That may help to motivate someone else to have a look to the issue, too.

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 need two element creators, which can be coded on site as lambda functions, one to create an sc_vector for each row and the other to create each rc instance. That creator may pass any additional value besides the module name to the module's constructor. These arguments you have to either fetch from some value array or calculate on the call site. For this, you will have to keep track of the row and col index. The creator of the row vectors gets passed the current index of the row as second argument. The inner creator for the module gets passed the current index within the row, i.e., the col as argument. The current row can be passed to that inner creator by simply capturing it by value (or reference) when defining the lambda function for that inner element creator. An array with component parameters is also best passed through the creators by capturing it by refer I suggest that you make yourself more familiar with Modern C++ and also to have a look at @ralph.goergen's and @Philipp A Hartmann's paper on the topic presented at DVCon Europe 2015.

The primary reason is that the SystemC Proof-of-Concept (PoC) implementation uses some global data structures, which get constructed during elaboration, which are not fully cleaned up when sc_stop() is called. These data structures are only freed by the OS when the application quits. There have been some efforts improve the PoC implementation in this area, but these are currently stalled. Unfortunately, partially due to bad code examples, bad habits, and laziness, many SystemC models also not cleanly deallocate their dynamically allocated resources, as they still use manual resource allocation using the new operator, but never release that memory using delete as they don't implement a destructor out of laziness. Since the general availability of smart pointers in C++'11, especially std::unique_ptr<T>, managing cleanly dynamic memory management has become much more convenient and there is no justification anymore to write such dirty code. However, there is a lot of legacy code out there making a bad example and hardware engineers often lack a formal education in C++ instead learning the language basically on the job. This will only resolve slowly over time. @David Black's suggestion to launch your multiple simulations from a separate process implemented using your favourite scripting language or even in C++, is the easiest workaround for the above problems.