Roman Popov

Members
  • Content count

    82
  • Joined

  • Last visited

Everything posted by Roman Popov

  1. Hello, Is it possible to install two builds of SystemC (-DCMAKE_BUILD_TYPE=Release and -DCMAKE_BUILD_TYPE=Debug) simultaneously into a filesystem? So that find_package(SystemCLanguage) will link one of two, depending on CMAKE_BUILD_TYPE of application? (I know that there is a RelWithDebInfo option that tries to serve both release and debug purposes, but it does not work really well for debug because of enabled optimizations)
  2. Yes, both are just C++ libraries.
  3. If you are using CMake build, then just pass -DBUILD_EXAMPLES=ON and all bundled examples will be built. Including risc_cpu example. You can run examples using general CTest flow (check documentation on cmake website https://cmake.org/Wiki/CMake/Testing_With_CTest )
  4. No, multiple inheritance is not supported in this case Here is quote from IEEE 1666-2011 So you have two options: Use composition instead of inheritance : in SystemC case this means you need to instantiate modules and bind their ports In some cases you can put some sc_objects in pure C++ classes (not sc_modules). This technique is commonly used for "port bundles". For example: struct clock_reset_if { sc_in_clk clk{"clk"}; sc_in<bool> rstn{"rstn"}; } struct some_module: sc_module, clock_reset_if { // ... } Unfortunately this approach does not work with SC_METHOD/SC_THREAD macros. But I think it should work with sc_spawn.
  5. It turned out you need not to modify anything in CMake scripts. There is a "secret" option -DCMAKE_DEBUG_POSTFIX . Here is the procedure: 1) Build and install SystemC in Debug mode: mkdir build_debug && cd build_debug cmake ../ -DCMAKE_CXX_STANDARD=11 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_DEBUG_POSTFIX=d make sudo make install 2) Build and install SystemC in Release mode: mkdir build_rel && cd build_rel cmake ../ -DCMAKE_CXX_STANDARD=11 -DCMAKE_BUILD_TYPE=Release make sudo make install 3) Now you have both debug and release library installed in /opt/systemc : ls -l /opt/systemc/lib/ total 14608 drwxr-xr-x 4 root root 4096 Jun 14 09:08 cmake lrwxrwxrwx 1 root root 18 Jun 14 09:08 libsystemcd.so -> libsystemcd.so.2.3 lrwxrwxrwx 1 root root 37 Jun 14 09:08 libsystemcd.so.2.3 -> libsystemcd.so.2.3.2_pub_rev_20170606 -rw-r--r-- 1 root root 12751464 Jun 14 09:08 libsystemcd.so.2.3.2_pub_rev_20170606 lrwxrwxrwx 1 root root 17 Jun 14 09:12 libsystemc.so -> libsystemc.so.2.3 lrwxrwxrwx 1 root root 36 Jun 14 09:12 libsystemc.so.2.3 -> libsystemc.so.2.3.2_pub_rev_20170606 -rw-r--r-- 1 root root 2196784 Jun 14 09:12 libsystemc.so.2.3.2_pub_rev_20170606 4) Application project will pick required library automatically depending on CMAKE_BUILD_TYPE. Here is example CMakeLists.txt : find_package(SystemCLanguage CONFIG REQUIRED) add_definitions(-DSC_INCLUDE_DYNAMIC_PROCESSES) set (CMAKE_CXX_STANDARD ${SystemC_CXX_STANDARD} ) set(SOURCE_FILES main.cpp) add_executable(sysc_example ${SOURCE_FILES}) target_link_libraries(sysc_example SystemC::systemc)
  6. You see at least two bugs in your code: for (int i = 0; i < N; i++){ SM[i].i_clk(i_clk); SM[i].i_rst(i_rst); SM[i].i_en(s_en); SM[i].o_finish(s_finish[i]); SM[i].o_data(o_data[i]); // <<< here you forgot subscript operator : SM[i].o_data[i](o_data[i]); } I also recommend to use .at(N) instead of [N] during elaboration since it does bounds checking. Performance is not an issue during elaboration, since it is done once. In a TOPMODULE you've forgotten to initialize o_data sc_vector< sc_out<uint_16b> > o_data; // Not initialized in TOPMODULE constructor If you can use C++11, I recommend using in-class initializers, since they are more readable, like : ... sc_in_clk i_clk {"i_clk"}; sc_in<bool> i_rst {"i_rst"}; sc_in<uint_8b> i_type {"i_type"}; sc_vector< sc_out<uint_16b> > o_data {"o_data", N}; ...
  7. I would advice using SC_CTHREADS both for DUT and Testbench when debugging signal-level protocols. This will save you from race conditions (everything will be synchronized to common clock signal) This particular protocol is implemented inside SystemC examples, you can check usage example in systemc_root/examples/sysc/2.3/sc_rvd/*
  8. Thanks! I was not aware of sc_event_queue and even started writing something similar from scratch :)
  9. Hello, I need to port following code from Verilog to SystemC: assign #DELAY out = in; What is the best known method to do this in SystemC? Similar question on stackoverlow https://stackoverflow.com/questions/5566785/specifying-signal-delays-in-systemc-as-clause-after-in-vhdl
  10. The only supported standard channel for synthesis in modern HLS tools is sc_signal. It is pretty low-level. Unfortunately, other high-level communication components are vendor-specific.
  11. It is possible if you know expected template parameters in advance. http://en.cppreference.com/w/cpp/language/class_template#Explicit_instantiation This technique is quite often applied in mathematical libraries to reduce compile time.
  12. Hi, you can debug segmentation fault with debugger. Most likely you have some typo with implicit cast in your program. Fortunately segfaults are easy to debug!
  13. Hello, I've created a script for GDB that automatically calls sc_trace for all signals, ports and plain member variables. It requires a small patch for SystemC library: moving some sc_trace definitions from .h to .cpp so they are not in-lined or garbage collected. Here it is: https://github.com/ripopov/gdb_systemc_trace Since I've tested it only with my design, it may be buggy. Please report any issues on github.
  14. A well known SystemC problem. Unfortunately you will have to create SC_METHOD that will divide your ins port into multiple signals on range basis.
  15. Something is messed up in your simulation, but It's hard to say without source code to debug. Try to track who and when updates process_handle and why there is an sc_method there.
  16. In that case you will need to learn SystemC TLM modeling. You can still write your CPU model in pure C++ but provide some hooks for event notifications and cycle count tracking. Unfortunately, (In my experience) there is no good learning material for beginners. You can check Duolos TLM tutorial: https://www.doulos.com/knowhow/systemc/tlm2/tutorial__1/ On GreenSocs Git there are examples of integrating CPU models with SystemC/TLM https://git.greensocs.com/explore/projects
  17. In that case you don't need SystemC. You can write your ISA simulator in pure C++. First learn your ISA, then write a CPU state model (registers), then write instruction parser (decoder and interpreter).
  18. Do you want it to be synthesizable? Or you just need an ISA simulator?
  19. sc_in<bool> is just a port, it has nothing to do with clock periods. You will need to pass a clock period value to your object some other way.
  20. If you use sc_clock to generate clock signal, it has a period() method that returns sc_time value for clock period: sc_clock clk {"clk", 12, SC_NS}; cout << clk.period() << endl; will print: 12 ns If you design a clock source manually, you will need to create your own API for such queries.
  21. Probably, you will need to dig into amba_slave_socket source code.
  22. Yes, you can fix SystemC source code. Just comment it out in SystemC header.
  23. SystemC issues this warning when multiple objects were given the same name in constructor. However, in your code I don't see an object initialized with "AT_LT_conv_pe" name, so I can't trace down the source of problem.
  24. I think in your example both sensitivities are static, since you create them together with process instance. There should not be a difference in scheduling semantics. You can create sensitivity dynamically using next_trigger( event ).
  25. Yes, however existing SystemC macro like SC_THREAD or SC_METHOD do not support function argument passing. You can use dynamic processes (sc_spawn) to invoke function with different arguments. Check this tutorial for example: https://sclive.wordpress.com/2008/01/10/systemc-tutorial-threads-methods-and-sc_spawn