AmeyaVS

Hello @Shashank V M, That's why you need to use a non-blocking process SC_METHOD to model such behavior. You can find relevant discussion here: Hope it helps. Regards, Ameya Vikram Singh

Hello @zidane, I would recommend the smallest example you can come up with the problem you are facing so as to give you a feedback effectively. You can use https://edaplayground.com/ for submitting the minimal example or as suggested by Dr. @maehne as a zip attachment to the post in the forum. You can also look into the historical posts in the forum discussing the similar issue. Regards, Ameya Vikram Singh

Hello @zidane, Instead of updating the original post with the details it would have been better to just post a new comment so as to read through the new information succinctly. Currently it's difficult to judge what changed between your original post and the edited one. But at a high-level I see that there are no SystemC processes involved, i.e. SC_THREAD/SC_METHOD's in your model design. Also, I don't see any interface definition of your FIR module implementation, i.e. Input/Output (I/O declarations). I would recommend going through some examples of designs implemented with SystemC included as part of SystemC sources. Also, better going through the reference book to understand to concepts for modeling using SystemC. Regards, Ameya Vikram Singh

Hello @zidane, How is the inst method called? What processes are you using(SC_[C]THREAD/SC_METHOD)? In the "inst" method the instance variable i goes through 0 to the value of tap and SystemC kernel only sees the final value of 4 as evident in your VCD Trace. It would be better if you can share a minimal example of what you are trying to achieve. Hope this helps. Regards, Ameya Vikram Singh

Hello @Saikat, Regarding your questions. Since SystemC is written in C++, g++ should be the default. Regarding compiler warning the ones mentioned in your post: Seems a good enough list for now. I would prefer you going through your compiler manual to figure which ones you might need. But, as my personal preference I usually prefer to build my code with various compilers and on various platforms to get the best possible platforms compatible code. It is very easy the write a code which might end up being platform/compiler dependent. Better to stick with standard C++ language compliance to get the most out of your code. Regards, Ameya Vikram Singh

Hello @sumit_tuwien, I am using GCC 11 in Fedora 34 with SystemC library. I am not facing any issues with it. Regards, Ameya Vikram Singh

Hello @Andy Goodrich, Thank you for the update. As also pointed out by @Paul Floyd in his post regarding Helgrind report here: Probably the Pthread threading constructs and implementation in SystemC needs to be looked into. Earlier also around the same time I reported the issue, I also did an analysis and found that the underlying constructs used in, pthread were updated. Something to do with futex updates for pthread in libc and the Linux Kernel. I don't have my notes now, since I have moved out. But one can probably look at differences in various system library versions for the operating system releases e.g. Ubuntu 16.04 vs Ubuntu 20.04 releases or even Fedora releases from the same time frame. Hope it helps. Regards, Ameya Vikram Singh

Hello @Andy Goodrich, Sorry for the delayed response. As per your suggestion removing the call to kill the thread. Let's the tests to completion without test failure. Regards, Ameya Vikram Singh

Hello @Andy Goodrich, Here is the snippet of the log that is generated in my SystemC environment setup with pthreads enabled: SystemC 2.3.4_pub_rev_20191203-Accellera --- Jan 26 2021 22:27:50 Copyright (c) 1996-2019 by all Contributors, ALL RIGHTS RESERVED SystemC Simulation Warning: (W558) disable() or dont_initialize() called on process with no static sensitivity, it will be orphaned: top.target In file: ../src/sysc/kernel/sc_simcontext.cpp:771 Warning: (W558) disable() or dont_initialize() called on process with no static sensitivity, it will be orphaned: top.control.dyn_target In file: ../src/sysc/kernel/sc_simcontext.cpp:1233 In process: top.control @ 0 s Success The test executable never completes it's execution as it hangs due to a race condition. Regards, Ameya Vikram Singh

Hello @DavidA It might be if you are reusing the build directory and cmake has cached the previous configuration. What Generator backend are you using from cmake?(make/ninja or others) Regards, Ameya Vikram Singh

Hello @DavidA It seems your SystemC library was built using C++11 standard. try changing the compile flag for the application to C++11 and see if this errors goes away. Regards, Ameya Vikram Singh

Hello @DavidA Can you post the output of the following command: nm -C $SYSTEMC_HOME/lib/libsystemc.so | grep sc_api_version Regards Ameya Vikram Singh

Hello @DavidA I don't see the "-std=c++14" in your application build command line. Regards, Ameya Vikram Singh

Hello @Paul Floyd, Thank you for the confirmation. I did try out the valgrind tool with helgrind to understand the underlying threading issue. Even I came up to the same conclusion then, but I have lost the references to the underlying changes and discussions in the glibc posix_thread_* constructs. I did spend sometime looking into the issue and the internal implementation in SystemC library. But from what I could gather is that the usage of pthread_cond variable is somewhat inconsistent. As what I understand from earlier comments, people in the working groups probably don't have access to newer Linux systems to reproduce the issue. We switched to using QuickThread Implementation later, but lost a consistent way to analyze simulation threads, and synchronization issues. Currently, I don't even know if there are any plans to modernize the SystemC kernel with C++11 std::thread's, which would ease a lot for platform/tool support. Regards, Ameya Vikram Singh

Hello @Issraa, That good to hear. For completeness you can append at the end of the following file: ".bashrc" # SystemC Install path export SYSTEM_HOME=/home/israa/systemc export LD_LIBRARY_PATH=$SYSTEMC_HOME/lib-linux64 # If echo $LD_LIBRARY_PATH is not empty then the following #export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SYSTEMC_HOME/lib-linux64 This will keep the configuration every time you open a new terminal. For reference: https://askubuntu.com/questions/58814/how-do-i-add-environment-variables Hope this helps. Regards, Ameya Vikram Singh