Jump to content

maehne

Members
  • Content Count

    307
  • Joined

  • Last visited

  • Days Won

    36

Everything posted by maehne

  1. Maybe your application or one of the libraries it is using creates sc_time objects by initialising some global or static constants/variables?
  2. Any multidimensional array can be mapped to linear storage and thus a one-dimensional array. C/C++ uses row-major order. If your 2d array deviates from that, you need to adjust ist explicitly.
  3. Your approach is also valid. You simply cannot profit with this approach from the infrastructure provided by SystemC, e.g., tracing the communication between the nodes. Whether this may pose a problem in the future is up to you to decide.
  4. Thanks @Andy Goodrich for your additional analysis. We probably should also take into account the recent feedback from @Runip Gopisetty on the datatypes, where he also mentioned the sc_vpool objects as being problematic making the SystemC datatypes not thread-safe.
  5. You'll have to create internal (i.e., private) signals for each member of the bundled class, which you need to connect to sub-blocks. Then, you have to register a SC_METHOD or SC_THREAD, which is sensitive to changes of the bundled input. The method/thread can then assign the correct new values to the internal signals based on the changed bundled input.
  6. You don't provide a minimal self-contained code example that exposes your problem. This complicates for an external the analysis of your problem. Also, a plot of the relevant signals would help to understand better, what wrong behaviour you are observing. Anyway, the calculation of the sine argument for x1 and x2 look suspicious to me: The "+" in front of 100 and 200 should probably be a "*" so that it corresponds to the general form of a wave equation x = A * sin(omega * t + phi). Also, it is wasteful to recalculate the amplitudes and frequencies in param_gen at each time step. If freque
  7. Thanks @Runip Gopisetty for this detailed feedback on the SystemC datatypes! It is highly appreciated! Feel free to report additional issues and suggestions for improvements!
  8. How about connecting all your nodes via the fifos to your communication manager? Then, the communication manager can internally manage how to route data received from the nodes based on your scenario? This would keep the structure of the model static while the actual communication paths change over the course of simulation.
  9. To fix the issue, you can simply create a symbolic link lib-linux64, which points to lib, inside your SystemC installation directory /home/computation/Desktop/systemc-2.3.3-install using: cd /home/computation/Desktop/systemc-2.3.3-install ln -s lib lib-linux64 The experimental CMake-based build system distributed with SystemC provides to this end the setting INSTALL_LIB_TARGET_ARCH_SYMLINK. If enabled (default is OFF), the symlink is automatically created during installation of the SystemC library. Ideally, all SystemC-related libraries would provide a CMake-based build system, which wo
  10. Directly editing the Makefiles generated by the GNU autotools is not recommended. You have to set it prior before doing "configure" to ensure the sources are correctly set up. As C++'11 support is marked as experimental for g++ 5.2.0, it is well possible that its C++ standard library implementation is not complete. I recommend you to try with a more recent C++ compiler, which defaults to C++'11 or later. The accompanying README and INSTALL documents of the libraries list on which platforms the libraries were tested including compiler versions.
  11. GCC 5.2.0 is an old compiler that still defaults to C++'98 even though it contains experimental support for C++'11. "std::enable_if" was introduced in C++'11. Therefore, it may work if you recompile all your SystemC-related libraries and applications with explicitly turned on support for C++'11 by adding "-std=gnu++11" as command line argument to the compiler calls. Most reliable is probably by setting the CXX environment variable.
  12. Happy new year @Paul Floyd! Thanks for the further analysis and proposed patch! We'll have a look on it.
  13. Thanks @Paul Floyd for this additional information and analysis! It is very helpful to be able to reproduce the issues on our side and to fix them.
  14. Thanks @Paul Floyd for reporting the issue! I have forwarded it to the SystemC LWG. Could you please provide some more details about your OS environment, compiler/valgrind versions as well as the version of the SystemC library and regression test suite for which you observed the issues?
  15. Thanks for reporting this issue, I have forwarded it to the SystemC LWG.
  16. 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
  17. 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.
  18. 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".
  19. 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
  20. 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.
  21. 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().
  22. Thanks @Lukas Steiner for reporting this issue! I have forwarded it to the SystemC LWG for investigation.
  23. 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
×
×
  • Create New...