Roman Popov

I'm not an expert, but my understanding is that other HDLs built on top of general-purpose programming languages like MyHDL (Python) and Chisel (Scala) support this idea of runtime-defined bitwidths. It is very powerful when you need to create a configurable modules like fabrics,routers, caches etc. Chisel authors even advertise it as "Hardware construction language" instead of "Hardware description language", to emphasize that structure of hardware is created at runtime, instead of being hardcoded manually. SystemC also has hidden hardware construction capabilities like sc_uint_base (bitwidth defined at elaboration time), sc_vector (size can be defined during elaboration time, instead of compile-time). But this approach is not marketed widely yet (and not supported by most synthesis tools).

Well, I want to use it for RTL bus fabric model. Number of bus slaves is parameterizable, and each slave have different address space size. So the other option I have here is to pick some "one size fits all" value for address bus width, like typedef sc_uint<64> bus_addr_t In that case I rely on synthesis tool to optimize bus width based on address decoding logic in slaves. I can help synthesis tool to by explicitly reducing bus address width in slave like this: <template unsigned WIDTH> struct bus_slave : sc_module { sc_in<sc_uint<64>> bus_addr{"bus_addr"}; sc_signal<sc_uint<WIDTH>> effective_bus_addr{"effective_bus_addr"}; SC_METHOD_INST(shrink_addr, sensitive << bus_addr;) { effective_bus_addr = bus_addr; } } But when cross-boundary optimizations are disabled, it will still have to emit 64 wires for address to gate-level netlist. If fabric slave port has a register buffer for address, it will also be 64-bits, instead of some slave-specific width. So sc_uint_base seem to me as the only solution now (if supported by tools). Unfortunately I don't know how to support user-defined channel classes for synthesis. Most tools support only sc_signal<T>. And it is not possible to bind sc_out<sc_uint_base> to sc_signal<sc_uint<W>>, despite sc_uint is derived from sc_uint_base.

You want to write a GUI for C++ debugger? You can check QtCreator source code, it's written in C++ with Qt and it has integration with GDB/LLDB/CDB. You can run your SystemC model in debugger from QtCreator.

Some synthesis tools support shared arrays between modules. So this is vendor-specific. But in general you will need to create a multiport memory module to share memory between multiple consumers.

Hard to say without processes source code. But if you use global variables like inp_image in your processes, this would not be synthesizable.

Depends on what you want. Global state is not synthesizable.

Is it ok to use sc_uint_base directly, instead of template sc_uint<W> ? In particular I need to model a vector of buses of variable length. I'm thinking of modeling it like this: static const int VEC_SIZE = 3; static const int WIDTHS[VEC_SIZE] = {10, 20, 40}; SC_MODULE(top) { sc_vector<sc_signal<sc_uint_base>> sig_vec{"sig_vec", VEC_SIZE, [&](const char *name, size_t i) { return new sc_signal<sc_uint_base>(name, {0, WIDTHS[i]}); }}; sc_vector<sc_out<sc_uint_base>> out_port_vec{"out_port_vec", VEC_SIZE}; SC_CTOR(top) { out_port_vec.bind(sig_vec); SC_THREAD(test_thread); } void test_thread() { for (auto & p : out_port_vec) cout <<"width: " << p.read().length() << " value: " << p << endl; unsigned i = 10; for (auto & p : out_port_vec) p.write({i++, p.read().length()}); wait(1, SC_NS); for (auto & p : out_port_vec) cout <<"width: " << p.read().length() << " value: " << p << endl; } }; Was it supposed to be used like this by SystemC authors?

There are no process-local signals in SystemC.

If you are new to SystemC you should start with some tutorial, for example https://www.doulos.com/knowhow/systemc/tutorial/. Then learn by exploring examples bundled with SystemC kernel. SystemC standard PDF also has lots of useful information for beginners.

This is not true. We use SystemC for RTL when we need to create highly-configurable RTL IPs. Also SystemC RTL has advantage in code sharing with VPs. So for example if I write UART in SystemC I can reuse CSR code between RTL and VP. And SystemC is better for FSMs, because CTHREADs are synthesizable. Unlike Verilog/VHDL where you need to code FSM state explicitly. (This is of course Verilog/VHDL synthesis tools limitation, not languages limitation ) The only major drawback of SystemC is specifying combinatorial circuits, because SystemC has no wildcard sensitivity lists, like always @* in Verilog.

Looks like the error is inside Xilinx libraries internals. I suggest you should ask on Xilinx forums.

http://standards.ieee.org/getieee/1666/download/1666-2011.pdf

Does "Table 60—Permitted socket bindings" in SystemC standard works for you?

Duolos website definetely has examples with mode than two modules or more than two signals: https://www.doulos.com/knowhow/systemc/tutorial/modules_and_processes/ What do you mean by "derived module" ? Word "derived" in C++ and SystemC is used in a context of OOP, i.e. class can be derived from one or more base classes.

Yes. Read about signals and ports. You just trying use brute-force instead of learning before doing.

SystemC does not allow to change structure of design during simulation. Modules and other sc_objects like ports and signals could not be created during simulation. Check IEEE SystemC standard , Chapter 4: " Elaboration and simulation semantics " for more details.

GtkWave renders correctly with 500 ps timeunit. But commercial viewer I have crashes.

I've looked again at VCD generated by 2.3.1. It has no time unit mentioned at all. So it is actually correct : if you substitute 0.5 NS as a timeunit, you will have correct timestamps. Gtkwave renders them as 1ns. But other VCD viewers I've tried just don't show time unit at all in this case.

Thanks a lot for reporting! I can confirm that 2.3.2 does not supports v that it is not a multiple of 10. I agree that set_time_unit API is bad (error-prone), and should be changed. Good news that you've received a runtime error early and did not spent lots of time . Do you need support for fractional timeunits? Or just more clear API? I've also checked 2.3.1. It does not works properly with 0.5 either: int sc_main (int argc, char **argv) { sc_trace_file* tf; tf = sc_create_vcd_trace_file("traces"); sc_signal<int> isig{"isig",0}; tf->set_time_unit(0.5, SC_NS); sc_trace(tf, isig, "isig" ); sc_start(0.5, SC_NS); isig = 1; sc_start(2.5, SC_NS); isig = 2; sc_start(3.5, SC_NS); isig = 4; sc_start(3.5, SC_NS); sc_close_vcd_trace_file(tf); return 0; } VCD is incorrect: $date Dec 05, 2017 11:50:52 $end $version SystemC 2.3.1-Accellera --- Dec 5 2017 11:40:15 $end $scope module SystemC $end $var wire 32 aaaaa isig [31:0] $end $upscope $end $enddefinitions $end $comment All initial values are dumped below at time 0 sec = 0 timescale units. $end $dumpvars b0 aaaaa $end #1 b1 aaaaa #6 b10 aaaaa #13 b100 aaaaa So 2.3.2 is better. But not perfect :(

Hello, SystemC is a C++ library. You should master C++ before learning SystemC, which is just a C++ library. It will be a wisely spent time, since C++ is used in many industries. After you learn C++ you will be able to understand and fix errors in your code.

As I understood, currently only Accellera members have access to SystemC GitHub repos. ( I heard that there are plans to make SystemC development open to general public, but we are not there yet) So if your company is Accellera member, you can ask your account manager to request an access for you. Meanwhile the best thing you can do is to stay on 2.3.1 until bugfix for 2.3.2 will be published.

Looks like specific to multi_passthrough_target_socket. Simple sockets work fine with hierarchical bind.

From my point of view it is a regression. Standard says explicitly that one hierarchical bind is allowed for multi_passthrough_target_socket. I will put a bug to tracker.

I thought about it. There are two issues: 1) Raw arrays do not store size. This is inconvenient: for debugging purposes I often want to visualize contents of RAM. But without knowing a size it is not possible to create a pretty printer. (Except for non-trivial constructible types, that actually store size, as specified by GCC/Clang ABI https://itanium-cxx-abi.github.io/cxx-abi/abi.html#array-cookies ) 2) When modeling ROMs it will require to know memory contents at compile time: std::unique_ptr<const int[]> rom(new const int[3] {1,2,3}); As I understand I can't create initializer list {1,2,3} at runtime. So I can't initialize ROM contents from file.

Hello, I need a data-structure to model RAMs and ROMs that are defined at elaboration time. For example when size and contents of memory are read from file during model construction. I thought that sc_vector can be a solution, but looks like it has no specialization for members that are not sc_objects. Any suggestions? Currently I'm thinking of creating a wrapper over std::vector with following api: template<typename T> class sc_elab_vector : public sc_object { std::vector<remove_const_t<T>> m_vec; //... }; sc_elab_vector<int> ram; sc_elab_vector<const int> rom; SC_CTOR(mod) { // ELABORATION ram.resize(42); // OK ram[0] = 42; // OK, for example models RAM on FPGA, initialized on reset for(int i = 0; i < 42; i++) rom.push_back(i); // OK rom[0] = 42; // OK } void test_thread() { // SIMULATION ram[0] = 42; // OK ram.push_back(1); // Runtime error rom[0] = 42; // Runtime error } Concept looks pretty generic for me, probably something like that should be standardized? Currently for SystemC synthesis we only have Compile-time sized arrays. But elaboration-time programming is more flexible than compile-time metaprogramming