Roman Popov

  • Content count

  • Joined

  • Last visited

About Roman Popov

  • Rank
    Advanced Member
  1. 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.
  2. It is possible if you know expected template parameters in advance. This technique is quite often applied in mathematical libraries to reduce compile time.
  3. 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!
  4. 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: Since I've tested it only with my design, it may be buggy. Please report any issues on github.
  5. 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.
  6. 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.
  7. 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: On GreenSocs Git there are examples of integrating CPU models with SystemC/TLM
  8. 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).
  9. Do you want it to be synthesizable? Or you just need an ISA simulator?
  10. 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.
  11. 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.
  12. Probably, you will need to dig into amba_slave_socket source code.
  13. Yes, you can fix SystemC source code. Just comment it out in SystemC header.
  14. 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.
  15. 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 ).