Kevin.Cameron

"So, when I get you right $hook_up_sysc is a user-defined function that hooks up the SystemC module via e.g. DPI-C? If so, how would such a hooking look like?" You also need a process sensitive to the inputs that will invoke the SystemC, or you'll need to use the value-change callback. For the outputs of the SystemC you can use the PLI signal update function - vpi_put_value. There are plenty of VPI/PLI code examples on the web. DPI is newer, but only works with SystemVerilog. If you try doing it with Icarus Verilog you can post questions into their user forum/reflector and the simulator code willl be debuggable.If I remember right the VPI handles in Icarus are just C++ pointers to the relevent class objects, so it's fairly efficient. Kev.

The fundamental problem with doing this kind of thing is that SystemC doesn't have any real concept of drivers and receivers and how to mix driver/receiver types on a wire. Having said that you can usually bridge stuff with PLI/VPI/DPI code - which is more portable anyway. You just hook-up/create your SystemC during initialization rather than doing the "foreign" module thing at elaboration, e.g. paraphrasing Sebs solution: module my_mod(sig_in, sig_out) input[63:0] sig_in;logic[63:0] sig_in; output[63:0] sig_out; logic[63:0] sig_out; initial begin $hook_up_sysc(sig_in,sig_out,<extra args>); end endmodule From my perspective simulation is flat and considering one thing or another as being "on top" isn't really helpful other than it defines the namespace, you should be able to add, subtract and rewire stuff as you go (particularly when it's C++). Verilog has hooks for doing that since the simulators usually have to talk to other applications and things like emulators.