Jump to content

Philipp A Hartmann

Members
  • Content Count

    533
  • Joined

  • Last visited

  • Days Won

    128

Everything posted by Philipp A Hartmann

  1. From the code itself, it's not obvious to me, where the unexpected overload of sc_core::wait(int) is called. Can you try attaching a debugger and break on the exception (catch throw in gdb) and check from the backtrace, where from the exception is thrown?
  2. I suggest to move to SystemC 2.3.3, if possible. (The error message indicates, that you seem to be using SystemC 2.3.1). Secondly, can you show the derived class of the fifo as well (including its constructor)?
  3. Which compiler/platform are you using? If you are on MSVC, make sure to include /vmg in your compiler settings as described in the INSTALL file. Hope that helps, Philipp
  4. On MinGW, you would be supposed to use the Windows Fiber-based implementation, e.g. when using the Automake-based build. Maybe the CMake setup for SystemC fails to select this correctly for this compiler?
  5. Looking at the source code of any SystemC implementation is sometimes misleading. Check IEEE 1666-2011, Annex C (deprecated features), item (n):
  6. ... and sc_method_process is a non-standard class, which even is incomplete on the model side when including <systemc(.h)>. So I would not call this clean. Regarding your original solution, it is important to note that you are not supposed to change an sc_event_list object while processes are sensitive to it. In your case, it works because you trigger the process immediately, which then 're-reads' the event list right away and therefore updates the sensitivity without breaking the kernel state What do you want to achieve that makes you want to do this? /Philipp
  7. Valgrind does not play well with the Quickthreads package used for the SystemC threads by default. As Torsten said, please try with SystemC 2.3.3 and configure your SystemC library build with --enable-pthreads to switch to the posix-based thread implementation, see https://github.com/accellera-official/systemc/blob/master/INSTALL.md.
  8. You can check the commit history of the file in the public GitHub repository. The chain of relevant changes are: b276fd3b ff4581f1 41ae779d Here are related discussions from the forum: Hope that helps, Philipp
  9. The only normative reference for SystemC is defined by the IEEE Std. 1666-2011, see http://ieeexplore.ieee.org/document/6134619/. The is_reset() was never part any version of the standard, so one could never rely on its presence. You would to check, why the ReChannel library tries to call this function and then find another way to implement this functionality. /Philipp
  10. Actually, it is expected that you don't have the QuickThreads package built on MinGW. As you can see from your config.log, the threading package to use is But it seems that the source code is missing an explicit check for _WIN64 to catch the MinGW-64 case. Can you try compiling with WIN64 defined (without leading underscore): ../configure CXXFLAGS="-DWIN64" Hope that helps, Philipp
  11. This compiler warning is a false positive. There is a loop in sc_fifo<T>::read(T&) ensuring that the fifo is not empty (and the success of the nb_read(T&) is even guarded by an sc_assert­čś× while( num_available() == 0 ) { sc_core::wait( m_data_written_event ); } bool read_success = sc_fifo<T>::nb_read(val_); sc_assert( read_success ); The check for num_available() is even stricter than the check in buf_read, but I can imagine that some compilers might not be able to prove this invariant. Therefore, unconditionally initializing the local variable to silence the warning might be an acceptable trade-off.
  12. sim_input.h:344 and sim_sync.h:29 points to your code and the issue reported from sc_spawn_object is very likely caused via inlining from your Tasker::MethodFunction<> class. So you will need to look into your code to address these particular reports. For SystemC 2.3.1, the are some known Valgrind reports, most of which should have been addressed in SystemC 2.3.3. Greetings from Duisburg, Philipp
  13. Fix published in 5a94360d in the public repository. Hope that helps, Philipp
  14. You can check against the latest master branch in the public repository, if the warnings have now been fixed. We tried to address at least some of the warnings in recent commits, see 292b25a df7f1f6 9a69d7c 5af8908 Hope that helps, Philipp
  15. Thanks for your detailed follow-up. We have now published a fix in https://github.com/accellera-official/systemc/commit/c1613d47, which will then be included in a future release of SystemC. Hope that helps, Philipp
  16. Fix published in https://github.com/accellera-official/systemc/commit/5a94360d. Thanks for the report! Greetings from Duisburg, Philipp
  17. Hi Wim, Currently, cci_param<T> indeed does not support any of cci_value, cci_value_list, cci_value_map as value type T. The main reason is, that it would otherwise cause ambiguities in the API of cci_value(_list,_map) itself, if the generic conversion functions (which are used by cci_param internally) would support this. However, it might be possible to extend cci_param<T> to support this scenario explicitly. Greetings from Duisburg, Philipp
  18. Short answer: You can't. See this answer from a related discussion: Greetings from Duisburg, Philipp
  19. As the error message says, you have a failing assertion in your testbench code in adder_testbench.cpp, line 30 (emphasis mine): There is not much we can do about this without knowing your testbench and your model. Hope that helps, Philipp
  20. Even better: Use the latest stable SystemC 2.3.3, which fixes several issues in 2.3.2.
  21. You call tf->set_time_unit(1, SC_NS); without initializing tf before. Hope that helps, Philipp
  22. As mentioned by the error message, you define a port outside of a module in the line above.
  23. Thanks for the report. I don't fully understand the summary, though. Some questions: Are the changes to the API check and/or the exception handling in sc_simcontext.cpp really needed? I would hope that removing/skipping the assert in sc_cor_qt.cpp is sufficient to work around the mprotect restrictions on CentOS 7+? Your instructions do not include --enable-shared=no, but your description says that you only(?) see it on a static SystemC library. Can you please clarify? To better understand the failing mprotect call in your environment, can you please provide the value of errno after the call? This can be obtained by adding something like: #include <errno.h> // ... ret = mprotect( ... ); if( ret != 0 ) { int mprotect_errno = errno; printf( "mprotect errno: %d, %s\n", mprotect_errno, strerror(mprotect_errno) ); } IIRC, Linux generally allows calling mprotect on allocated memory. The memory needs to be properly aligned at a page boundary, of course. One option might be to allocate the stack memory via posix_memalign (if available) instead of new. We can also change the implementation to gracefully ignore a failing protection and only restore the permissions if the mprotect(...,PROT_NONE) call was successful earlier. This brings me to my remaining question: Which one of the mprotect calls actually fails: Is it the one removing the protection (PROT_NONE) or the one trying to restore them? Thanks, Philipp
  24. You have multiple instances of the "bundles" in your monitor class: inherited directly as additional members in the nested classes sim and stub To avoid the name clashes, you can make sim and stub modules themselves via: struct sim : sc_module , if_inputs, if_outputs { SC_CTOR(sim) {} } sim { "sim" };
  25. Exit code 0x103 could indicate an "illegal instruction". Can you try building SystemC with --disable-optimize? As Roman mentioned earlier, Clang 8 is pretty new and SystemC has never been tested with Clang on Windows.
×
×
  • Create New...