Jump to content

Roman Popov

Members
  • Posts

    353
  • Joined

  • Last visited

  • Days Won

    46

Everything posted by Roman Popov

  1. If you want immediate communications between threads, then you should use regular SC_THREADs and wait on event, like wait(some_signal.value_changed_event());
  2. You have 2 clocked processes. Any communication between them will take at least 1 clock cycle. If you need request and response, then you have at least 2 cycle latency.
  3. There is a buffer overflow bug in vcd_sc_signed_trace::write, someone forgot to reserve a space for null terminator in null-terminated string. void vcd_sc_signed_trace::write(FILE* f) { static std::vector<char> compdata(1024), rawdata(1024); typedef std::vector<char>::size_type size_t; if ( compdata.size() < static_cast<size_t>(object.length()) ) { size_t sz = ( static_cast<size_t>(object.length()) + 4096 ) & (~static_cast<size_t>(4096-1)); std::vector<char>( sz ).swap( compdata ); // resize without copying values std::vector<char>( sz ).swap( rawdata ); } char *rawdata_ptr = &rawdata[0]; for (int bitindex = object.length() - 1; bitindex >= 0; --bitindex) { *rawdata_ptr++ = "01"[object[bitindex].to_bool()]; } *rawdata_ptr = '\0'; compose_data_line(&rawdata[0], &compdata[0]); std::fputs(&compdata[0], f); old_value = object; } When you have sc_bigint<1024> , 1024 chars in compdata and rawdata are not enough to store 1024 symbols, because 1 symbol is required for null terminator assigned here: *rawdata_ptr = '\0'; It will also fail with sc_bigint<4096> Can you add + 1 to size of buffer everywhere , rebuild SystemC and rerun your test? : void vcd_sc_signed_trace::write(FILE* f) { static std::vector<char> compdata(1024 + 1), rawdata(1024 + 1); typedef std::vector<char>::size_type size_t; if ( compdata.size() < static_cast<size_t>(object.length()) ) { size_t sz = ( static_cast<size_t>(object.length()) + 4096 ) & (~static_cast<size_t>(4096-1)); sz ++; ... Same problem also with sc_biguint<1024>. Thanks for finding this bug!
  4. Thanks for reporting this. I've reproduced the issue. On my side (VS 2017) it crashes with heap corruption, instead of hanging. But I think this is the same issue. I will debug on this evening.
  5. I can't reproduce, works fine for sc_bigint<1024> on my side. What compiler and OS do you use?
  6. In a current SystemC releases you will have to use Creator (check SystemC standard), that will generate arguments for each element constructor. Quite inconvenient. In next SystemC release sc_vector will have emplace_back() method.
  7. I had the same problem when working on connection visualization tool for SystemC, had to hack SystemC kernel to preserve port-to-port connections after elaboration. What I've found that in many real models some ports are connected through hierarchical boundaries like: input_port.bind ( mod.submod.other_submod.channel ) So I also had to create "virtual" ports, that do not exist in code, just for visualization.
  8. I always change default policy to SC_MANY_WRITERS. In commercial simulators usually there is also a way to change default policy. In verification environments default SC_ONE_WRITER policy is violated way too often. It also does not work well with FORK/JOIN, when you spawn different threads in each test to generate stimulus on same set of ports.
  9. This is not official Accellera repository. But in case your company is Accellera member you can request access to Accellera UVM git repositories.
  10. Independently on thread evaluation order code will output 0x0. Because signal values are updated during "Update phase" of simulation. Check Section "4. Elaboration and simulation semantics" of SystemC standard.
  11. You can start with std::unordered_map<address_t, data_t> and later switch to "paged" solution as swami suggested if performance of unordered_map is not sufficient for your case.
  12. Well, sc_int also support range access, so you could do the same in original code.
  13. Not possible with sc_clock. You will have to write your own clock generating class. This is what we've done in similar case.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. Xilinx HLS tools have very limited SystemC support, you should probably code your FFT in pure C++.
  21. 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; }
  22. You should start with learning your synthesis tool documentation. C++/SystemC synthesis is very tool-specific.
  23. 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.
  24. 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}")
  25. 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.
×
×
  • Create New...