Jump to content


  • Content Count

  • Joined

  • Last visited

About katang

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Maybe this is the intention, but it does not do so: when I run it in the first time, it simply leaves CMAKE_INSTALL_PREFIX undefined, since the settings you mention are only read inside this if-protected lines. In my eyes a very bad idea to leave and undefined initial value in a code, by intention. Yes, it is. And is is also time-wasting. BTW: it is the first time I saw that the CMAKE_INSTALL_PREFIX is to be set manually. The readme attached to the library mentions that it is one one the very important variables, but does not mention it shall be set manually. It does not help a lot. It is a long time to hunt down that this is the reason, and after that I see that environtal variables are only read inside these protected lines. No warning, no docs. Maybe good for developers (just seconds to use), but days for users to figure this out.
  2. Then my bet is that on your system CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is defined somehow. Otherwise line 541 if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) prevents to define, among others CMAKE_INSTALL_PREFIX After that I commented out that conditional, I also succeeded. BTW: what that conditional makes there? I do not think it is properly used According to CMake docs, that is, when I run CMake for the first time, it will not set CMAKE_INSTALL_PREFIX at all, that is it will be installed to the default path, independently of whether I have defined my own (initially obviously experimental) path. So, my initial attempt with a new version will fail. I would suggest to make an install attempt on a virgin system, before making a new release public.
  3. Hello Ameya Vikram Singh , this issue really makes me crazy. I am compiling SystemC from source. (I made a clean build, both for SystemC and my own app) I do have in the main CMakeLists file the line set (CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to build all targets. Supported values are 98, 11, and 14.") I make ../configure, too. When I make the build, I receive tons of absolutely obsolete messages, but I cannot find out this crucial parameter: which standard was finally utilized? BTW: why? And why today a 20-years old standard is the default? What else shall I do to compile for standard other than the default? Why it is an issue for 2.3.>1, while it is not for 2.3.1, which I can install with no problem? ( I mean to build it together with libraries like gtest and Qt) Is there any option to build in the same way as 2.3.1? Is it only me who uses also another libraries in combination with SystemC? I make two debug prints in my root CMakeLists file, it says My C++ standard is ;98 Despite that I have changed to 14. Also, in my application directory My C++ standard is ;98 It looks like I cannot overwrite the default. What else shall I do? Is there any way to find out which standard uses a library I installed? Thanks for your help.
  4. Yes, probably you are right. But, I am finding SystemC in the root CMake file, and the printout comes from the leaf and it seems to be correct. BTW: what was the intention of with introducing such a degree of incompatibility with the compiler version? Was not enough the confusion with the different versions of the libraries? What if I use 6-8 different libraries with different (sometimes incompatible) versions per project, and now I must maintain also which version of which library was compiled with which standard?
  5. You know, in the makefile I use (as advised) set(CXXFLAGS -DCMAKE_CXX_STANDARD=${SystemC_CXX_STANDARD}) message("My C++ standard is " ${CMAKE_CXX_STANDARD}) The corresponding message on the screen is My C++ standard is ;98 Which is the default of the SystemC package. What else shall I do? The option in the main makefile mentions the incompatibility with TLM, but not any more potential issues.
  6. When I build my app with 2.3.3, I receive the error message in phase of linking: /usr/local/systemc/include/sysc/kernel/sc_ver.h:182: error: undefined reference to `sc_core::sc_api_version_2_3_3_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_3_cxx201103L(sc_core::sc_writer_policy)' However, I am not (yet) using TLM, neither bind() in this simple test. What effect option "(DISABLE_VIRTUAL_BIND "Disable the definition of bind() member functions of ports and exports as \"virtual\", which is incompatible with old TLM library implementations (< 2.0.2)." OFF)" has? Shall I switch it on, or how otherwise can I eliminate its effect?
  7. Maybe you are right, but I have not yet seen "sensitive" in a loop. I am not used to that style, that is all. BTW: In this way the bits of a word are changed in a concurrent way. As the single bits from the submodules are connected individually to the bits of the word in the module, I guess there might not be any hazard in the electronic implementation. Also, as long as SystemC routines are executed in one thread, similarly no problem in the simulator. Am I right? In the future multithread versions of SystemC, may this change?
  8. You are right, but I have a high number of modules, and it is a very ugly code to be sensitive to so many signals. If my submodules (working concurrently) are manipulating sc_uint, I have synchronization issues.
  9. My submodules have status bits like sc_out<bool> Pooled;// If this module is in the pool in the module, I have sc_in< sc_dt::sc_uint<No_OF_SUBMODULES> > Pooled;//status bits of the modules What is the best way of connecting the individual bits to the corresponding bits of the word? (I want to activate the main module upon status change in any of the submodules)
  10. katang

    Support for C++11/14 in SystemC 2.3.2

    Surely not, I emptied directory "build". The problem here is that I need to use some 3rd-party components. This error message comes up when I attempt to combine some of them with SystemC. BTW: if SystemC builds with any of the C++ standards, what is the reason of enforcing a certain standard? The rest of the world typically does not use it,and as I see, it causes several issues, and at least needs to understand and edit foreign packages, which without this enforcing cooperated perfectly? If you like, you can use compiler switch when configuring SystemC. If you like.
  11. katang

    Support for C++11/14 in SystemC 2.3.2

    In SystemC's CMakeLists.txt file I set set (CMAKE_CXX_STANDARD 11 CACHE STRING "C++ standard to build all targets. Supported values are 98, 11, and 14.") In my own CMakeLists.txt file I set set(CMAKE_CXX_STANDARD "11") However, my system keeps telling In function `__static_initialization_and_destruction_0(int, int)': /usr/local/systemc-2.3.2/include/sysc/kernel/sc_ver.h:182: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)' I have a newly installed Ubuntu 18.04, and I attempted all variants and tips, for one and a half day. I give up and going back to the previous version.
  12. katang

    Build error with 2.3.2

    Is there any specific reason to test SystemC with a 15-years old standard? And, not testing if at least the "Hello World" can be built with, as given by the example setup test? I do not want either to hunt down and downgrade my sources updated for the new standard or find out if those strange link errors come from version mismatching or they are my own mistake. I have spent some hours with experimenting, then I returned to 2.3.1.
  13. katang

    Build error with 2.3.2

    In my CMake I have the line set(CMAKE_CXX_STANDARD 11) and I did not configure SystemC before building it. I will try to do so. BTW: If that version works with standard 11 only, why is it not preconfigured?
  14. I want to simulate a module, the input signal of which changes externally. In the object I have a port sc_in<int> Address; and in the constructor I have SC_THREAD(InputChanged); sensitive <<Address; dont_initialize(); and the method is void XXX:: InputChanged(void){ wait(SC_ZERO_TIME); // Be sure value asserted cerr << '@' << sc_time_stamp() << ' ' << Address<< endl; } In my testbench file I have sc_signal<int> Address; ... XXX->Address(Address); ... testbench_i->Address = 12; ... wait(150,SC_US); This latter instruction triggers execution of InputChanged, as I wanted. However, if I write out the value of the signal, it prints out the old value, until I precede it with a ' wait(SC_ZERO_TIME);' My questions: 1) at this point, the method is triggered signaling that the value of the input has changed, but reading the value results in the old value. How is it conceptually? (I understand that the effect of writing needs time, so it happens at the end of the delta cycle. But, why triggering of the member occurs earlier, immediately, and specially not synchronized with the change of the value? I myself expected to put ' wait(SC_ZERO_TIME);' after writing the signal, and that InputChanged() is triggered only after that.) 2) To circumvent the problem I used ' wait(SC_ZERO_TIME);' Is it acceptable, or I shall use some rise-time instead? Any better idea? (It is something like a noisy ADC, so reading the exact value is not so critical) 3) May it raise issues that I use SC_THREAD (beause of the wait()), triggered multiple times, rather than SC_METHOD
  15. katang

    Build error with 2.3.2

    Well, I was even not aware of that I am using standards. Even that I can mix them ? BTW: I generated a new system, with the recent G++ and SystemC. I did not expect that I need to edit my source. Thanks for the hint