Jump to content

maehne

Members
  • Content Count

    286
  • Joined

  • Last visited

  • Days Won

    34

Everything posted by maehne

  1. 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.
  2. 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().
  3. Thanks @Lukas Steiner for reporting this issue! I have forwarded it to the SystemC LWG for investigation.
  4. 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.
  5. 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.
  6. @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.
  7. For the record, @mo_ayman posted about the current state of his fixes to QuickThreads on Win64 in this separate thread.
  8. 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.
  9. Thanks for reporting this issue for the edge case INT64_MIN! I have forwarded it to the SystemC LWG for investigation.
  10. 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.
  11. 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.
  12. @David Black answered this above: The sc_signal_in_if provides member function event(), which "shall return the value true if and only if the value of the channel was written or modified in the immediately preceding delta cycle and at the current simulation time." [IEEE Std 1666-2011, clause 6.13]. I.e., instead of accessing the event and calling triggered(), you could directly call port->event() to check whether an event happened.
  13. Your questions are answered by clause 4.3.4.2 "Function sc_start" in IEEE Std 1666-2011: More details on the simulation cycle, you can find in clause 4.2 "Simulation". Yes, see clause 4.3.4.2 of IEEE Std 1666-2011: Clause 4.5.7 of IEEE Std 1666-2011 lists functions to detect pending activity: sc_pending_activity_at_current_time(), sc_pending_activity_at_future_time(), sc_pending_activity(), and sc_time_to_pending_activity().
  14. The paper on gSysC suggests that it implements a loose coupling by only deriving from the corresponding SystemC ports and signals (Figure 3) and controlling the simulation by calls to sc_start() (section 4). Since the semantics of the ports, signals, and sc_start are still quite similar in IEEE Std 1666-2011 and its proof-of-concept implementation SystemC 2.3.3, it should not be too hard to update this coupling interface to SystemC. If I remember correctly SystemC 2.0.1 did not yet use namespaces and gSysC doesn't seem to use them either. Just using <systemc.h> instead of <systemc> may help, but once you know the coupling still works as intended, I would suggest to invest the effort to reference all SystemC classes with the proper namespace prefixes in the gSysC codebase and also move the gSysC implementation to an own namespace so that the potential for naming conflicts gets minimised. I suspect that you will have to invest more effort on porting the code from Qt3 to Qt5. You may consider contacting the authors of gSysC using the information on the gSysC homepage.
  15. You cannot bind a signal to another signal. Instead, you have to bind one or more matching ports to your signal. Your sc_signal<bool, SC_MANY_WRITERS> implements sc_signal_inout_if<bool>. Therefore, ports of type sc_in<bool>, sc_out<bool>, and sc_inout<bool> may be bound to that signal. Due you specified the SC_MANY_WRITERS policy, There won't be an error to write to that signal from more than one processes during any given evaluation phase (see clause 6.4.4 of IEEE Std 1666-2011). So, declare fifo_full to be of type sc_out<bool>. Then, binding that port to the signal main_full should work as you stated: main_fifo1.fifo_full(main_full); You may also consider using sc_signal_resolved and its ports sc_in_resolved, sc_inout_resolved, and sc_out_resolved, which uses the sc_logic instead of bool (clause 6.13ff in IEEE Std 1666-2011).
  16. I have no experience with the emscripten platform. However, the proof-of-concept implementation uses by default QuickThreads to implement co-routines for enabling SC_METHODs and SC_THREADs, which uses platform-specific assembly code. You may have more success using POSIX threads (Pthreads), which seems to be supported by emscripten. You can find detailed build instructions for SystemC in the INSTALL.md file.
  17. I agree with @AmeyaVS that it would help if you could share the current state of your modifications in form of a .diff file in this forum or as a work-in-progress pull request on the public SystemC repository on GitHub. Then more people can have a look to maybe suggest a fix for the second half of the issue. It would be great if this long-standing issue regarding QuickThreads on Cygwin64 could be finally fixed.
  18. One good resource for understanding the fundamental concepts of SystemC is "SystemC from the Ground Up", 2nd edition, Springer by David Black et al. Of course, IEEE Std. 1666-2011 is the definitive source to be consulted for any semantic details.
  19. Check clause 5.11 of IEEE Std 1666-2011 for the member functions of the sc_time class. sc_time::value() will return the underlying integer representation of the time value, which has to be interpreted together with the set discrete time resolution. sc_time::to_seconds() returns a double value representing the time value in seconds.
  20. maehne

    SystemC

    Yes, you can simply download and build the proof-of-concept implementation of SystemC by following the contained INSTALL instructions. You just need to install Xcode and its command line tools. Instead of the GNU-autotools-based build system, you may also use CMake to set up the build. You can display VCD trace files with GTKwave.
  21. Could you please be more specific and post the error messages, you are receiving when building SystemC 2.3.3 with VS 2019? Also, have you tried it with the most recent development state from the public SystemC Git repository of Accellera?
  22. Yes, you'll need to add a helper module C, which upsamples your slow signal to the fast rate, i.e., which input rate is 1 and output rate is 60. In the simplest case, you can just duplicate 60 times the same value. However, you may also implement some kind of interpolation. Note: By creating a feedback loop, you will also have to specify a suitable delay and initial samples to restore causality! I suggest that you read the section 2.1 "Modeling fundamentals" of the the SystemC AMS User's Guide to gain further insight.
  23. Thanks for reporting this issue and analysing the cause! I have forwarded your report to the SystemC LWG. Could you please try to make the preprocessor condition more strict by adding "!defined(__MINGW32__)" (see here and here) and report back whether this fixes the issue?
  24. See this thread, SystemC 2.3.1 triggers some known Valgrind reports. Most should be fixed in the latest SystemC release (version 2.3.3) available from Accellera. You may also consider building and using SystemC directly from the official public Git repository. If you search this Forum for "valgrind", you can find several other relevant threads. If the problem persists with the latest SystemC release, it would be nice if you could post a complete reproducer so that we can have a closer look. @Philipp A Hartmann may then be able to make some more comments.
  25. As you are already building your SystemC model using DLLs, I would suggest that you also build SystemC as a DLL and link to it. This most probably should fix your problem as suggested by @Roman Popov.
×
×
  • Create New...