basarts

If you separate application code and read/write implementation code, you can keep your C code application and compile it still for your CPU module. Yes, you will need a C++ compiler then, but it also allows you to port your application to e.g. a commercial CPU model which could use plain C. You'd only need to replace your read/write C++ implementation with a C implementation. // C header file #ifndef C_H #define C_H #ifdef __cplusplus extern "C" { #endif /* __cplusplus */ void mywrite(uint32_t address, uint32_t value); void myread (uint32_t address, uint32_t *value); #ifdef __cplusplus } #endif /* __cplusplus */ #endif /* C_H */

(See also https://github.com/OSCI-WG/uvm-core/issues/244) Functions last_req and last_rsp in uvm_sequencer_param_base.svh use "if (n == m_last_[req|rsp]_buffer.size())"; "==" should be replaced by ">=". Bas

What errors do you get? From your question, it is not clear whether you have errors related to your (UVM-)SystemC installation, your Makefile, your application or something else.

The freely available SCML library from Synopsys provides a way to describe registers with optional callback functions that will trigger when a register read or write occurs.

Are you using a commercial simulator for your setup? Then consult its manual; but typically, you can use "-D<macro>[=<value>]" to define a macro.

You could use an optional command line parameter to sc_main and propagate that to the "real" test.

See https://docs.microsoft.com/en-us/visualstudio/debugger/debugger-feature-tour?view=vs-2019 for basic information regarding application debugging.

You also need to include -I, -L and -l for uvm-systemc in your compilation.

Forget that last post, it seems that brackets etc. are not displayed in the posts.

I guess you need some extra changes: firnodes = new FirNode(...) firnodes->data_in(...) accu->mul_in(mul_sig) etc.

To be clear: I cannot use `uvm_blocking_transport_imp_decl(SFX) macros, because I need to use TLM2 sockets at the UVM-SV side.

Thanks David, but I already know about the SystemC side 🙂 I'm looking for possibilities in the UVM-SV space (hence the post in "UVM SystemVerilog Discussions").

In SystemC, we have the possibility to bind a specific b_transport function to a specific target socket. Hence, I can create a module with multiple target sockets that each bind to their own b_transport implementation. Reading the UVM user's guide v1.2 chapter 2.47 (TLM2 - Use Models), I get the impression that there exists an implicit binding between all target sockets of a module and one b_transport implementation. In other words, we can only have one b_transport function per uvm_component. Is that correct, or is there a way to implement and bind different b_transport implementations to different target sockets?

From the standard: "Tagged? Incoming interface method calls are tagged with an id to indicate the socket through which they arrived."

Hi Charan, uvm_(non)blocking_*_port are SystemC TLM-1.0 based UVM-SystemC ports. As stated in your referenced NOTE, UVM-SystemC has not yet defined TLM-2.0 transport interfaces etc.. Hence, in case you need SystemC TLM2.0 based interfaces, you need to use the ones provided by SystemC itself. In case you have a SystemC model with TLM2.0 based interfaces, you have (at least) two options to verify this with a UVM-SystemC environment: create a UVM driver that contains initiator/target sockets in order to connect directly to your model instantiate a signal-to-TLM2 / TLM2-to-signal adapter between a signal level driver and your model P.s. you probably meant "verification" i.s.o. "vitrifaction", but at least I learned a new word 😉 https://en.wikipedia.org/wiki/Vitrification -- Bas