Jump to content

Roman Popov

  • Content Count

  • Joined

  • Last visited

  • Days Won


Roman Popov last won the day on May 21

Roman Popov had the most liked content!

About Roman Popov

  • Rank
    Advanced Member

Profile Information

  • Location
    .Hillsboro, Oregon

Recent Profile Visitors

1,307 profile views
  1. Roman Popov

    Systemc performance

    Real-life simulation performance usually depends a lot on modeling style. For high-level TLM-2.0 models share of simulation time consumed by SystemC primitives is usually much lower, comparing to time consumed by "business logic" of models. Efficiency of simulation kernel (like context switches and channels) is much more important for low-level RTL simulations.
  2. You can enable delta_cycle tracing with sc_trace_delta_cycles(tf, true) and try to find a signal in VCD gui. Since VCD format does not actually support delta cycles, SystemC traces them as 1ps steps.
  3. Probably you talk about cycle-based simulators? Like for example Verilator (https://www.veripool.org/wiki/verilator). Cycle-based simulators are faster than discrete-event simulators if you have a cycle-accurate model like RTL. Also cycle-based simulation is easier to parallelize. Oftern pin-level interfaces are used to integrate some RTL into C++ simulators. Or opposite, integrate high-level C++ simulators into RTL verification environment. Commercial simulators like VCS can automatically generate SystemC pin-level wrapper for Verilog, or Verilog wrapper for SystemC. Then you can do cosimulation. Another usage for pin-level interfaces is High-Level Synthesis. HLS tools from Cadence and Mentor take SystemC models with pin-level interfaces as an input.
  4. Roman Popov

    SC_VECTOR declaration causes Exception thrown.

    Looks like null pointer dereference. I don't immediately see a problem in code samples you provide. Probably bug is somewhere else. Use debugger to identify the root cause of problem.
  5. Roman Popov

    Synthetizable FFT function in SystemC

    From SystemC standard: SystemC requires that you add sc_module_name as a parameter to module constructors, like this: MULT(sc_module_name, int var_a, int var_b); MULT(sc_module_name); This is a hack that allows SystemC kernel to track lifetime of constructor.
  6. Roman Popov

    Synthetizable FFT function in SystemC

    If you code your FFT as a pure C++ function, Vivado HLS will generate inputs and outputs automatically from function parameters and based on INTERFACE pragmas. And you can import generated RTL into Vivado IP integrator. Check out Xilinx documentation, and ask on Xilinx forums. Please also note that you can implement FFT in a various ways (with different micro-architectures), and achieve various performance vs area numbers. And HLS also requires quite a lot of learning to achieve good results.
  7. Roman Popov

    Synthetizable FFT function in SystemC

    Xilinx HLS tools have very limited SystemC support, you should probably code your FFT in pure C++.
  8. Roman Popov

    write different types of data in a custom port

    But even this won't fix your error. Because compiler will still complain about assigning sc_logic to double, even if it is in always false branch. What you need is if-constexpr and std::is_same if you have C++17. Or SFINAE, if you don't. Something like this may work: if constexpr (std::is_same_v<T, sc_dt::sc_logic>) { out = SC_LOGIC_Z; } else { out = 0; }
  9. Roman Popov

    SystemC implementation from C-code sources

    You should start with learning your synthesis tool documentation. C++/SystemC synthesis is very tool-specific.
  10. Roman Popov

    primitive port that responds to sensitivity ???

    Yes, you can design ports that will behave the way you described. Together with special ports I suggest you to also create a special kind of module that will encapsulate power control events. Then you can make power aware ports to be automatically sensitive to power events of module they belong to.
  11. Roman Popov

    What effect option DISABLE_VIRTUAL_BIND has?

    If you run It will install to any directory you want. If you want to to have multiple SystemC versions installed, you can install them in different directories. Then just add all installed directories to CMAKE_PREFIX_PATH and select required version in your application CMakeLists.txt For application using 2.4.0 find_package(SystemCLanguage 2.4.0 CONFIG REQUIRED) message("Using SystemC from ${SystemCLanguage_DIR}") message("Using C++ Standard: ${SystemC_CXX_STANDARD}") For application using 2.3.3 find_package(SystemCLanguage 2.3.3 CONFIG REQUIRED) message("Using SystemC from ${SystemCLanguage_DIR}") message("Using C++ Standard: ${SystemC_CXX_STANDARD}")
  12. In our environment we have one simulator that uses SystemC hierarchy and elaboration, but does not use SystemC scheduler. There is no problem with check-pointing : when we need to restore from checkpoint we just re-run SystemC elaboration and then apply checkpoint state. But using TLM-2.0 without SystemC elaboration is not possible, because internally it has core SystemC objects like ports and exports. So probably you don't need SystemC at all.
  13. At least you need to finish elaboration, using sc_start(SC_ZERO_TIME); But usually TLM-2.0 models cannot be used without SystemC scheduler, since TLM models are allowed to use SystemC primitives like processes and events.
  14. Roman Popov

    What effect option DISABLE_VIRTUAL_BIND has?

    When you don't manually set CMAKE_INSTALL_PREFIX, it tries to install into ${SYSTEMC_HOME} or ${SYSTEMC_ROOT_DIR}. One nasty thing about SystemC CMake build system is that it exports targets from build directory, so you can use find_package even without installing SystemC. This may be very confusing. (But some people find it convenient - you don't need to install, just build and use) This is probably what you are encountering - You have old C++98 SystemC build directory somewhere, and find_package founds it, instead of installed modern C++ SystemC build. So I would recommend to print some informational messages in your application CMakeLists.txt: find_package(SystemCLanguage CONFIG REQUIRED) message("Using SystemC from ${SystemCLanguage_DIR}") message("Using C++ Standard: ${SystemC_CXX_STANDARD}") set (CMAKE_CXX_STANDARD ${SystemC_CXX_STANDARD}) When you run cmake it will print something like this: Using SystemC from F:/work/systemc-2.3.3/cmake-build-debug Using C++ Standard: 17
  15. Roman Popov

    What effect option DISABLE_VIRTUAL_BIND has?

    You don't need to run configure if you use CMake. configure is for autotools, another build system. Most likely you have it in CMake Cache. Read how CMake set(...) works here : https://cmake.org/cmake/help/latest/command/set.html Because SystemC standard is written on top of C++03. Unfortunately it looks like we will have to wait another year or two for next IEEE SystemC standard on top of more modern C++. Because SystemC 2.3.1 had no C++11 features. But Accellera releases after 2.3.1 start to include some features made with modern C++. Thus, SystemC 2.3.3 compiled with -std=c++11 and -std=c++98 may be incompatible. More on that here: http://forums.accellera.org/topic/5738-support-for-c1114-in-systemc-232/ Yes, basically the only thing you need to do is to recompile SystemC library with C++ standard you use for your application. I linked SystemC with GTest without any issues. In general, I understand your frustration, because if you use modern Linux with gcc or clang, you get used to good binary compatibility between compiler and libraries versions. However the rest of the world is not like that. On Windows/MSVC for example you usually have to match compiler versions and flags for all libraries you link. If you are unlucky to work in semiconductor industry, you will soon find out that you are forced not only to use specific C++ standard, but also specific Linux (RHEL) and specific outdated GCC version.