basarts

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

If your testbench environment wasn't limited to SystemC, I'd advice to use UVM-SV with a vendor solution. It would bring you, among other things, standard interface UVCs and constraint-random possibilities. In your case, you will have to implement a.o. your AMBA UVC(s) which can take quite some effort and can be quite complex. Next to that, the current UVM-SystemC 1.0-beta2 release does not yet contain constraint-random functionality, although the combination of UVM-SC with CRAVE (Constraint RAndom Verification Environment) has been presented at DVCon Europe 2018.

The release contains a file docs/scv/scvref/vwg_1_0e.pdf which (sort of) clarifies this.

Hi Maxim, After reading some SCV documentation, it looks like we're not allowed to use smart pointers in your preferred way. E.g. we need to use "addr()" (without specific member functions like "range(int, int)") as a basis for building the expression we are using in a later stage. In your case, a practical solution would be to have no constraint on the generated address but to mask the 2 LSB after generation. -- greetz, Bas

Hi RC, There are a lot of different options to create a SystemC testbench. UVM is of course broadly used, but might be too heavy or not perfectly suited for your case. Depending on the answers to the questions below, you will get a different recommendation: Which interfaces does the DUT have? What is the complexity of the DUT? Do you need a register model? Does the DUT contain mixed signal functionality? What kind of test scenarios do you envision? Directed / constrained-random? Do you build the testbench from scratch or are you reusing verification components / tests? Do you plan to reuse the tests and/or testbench in other environments, like HDL simulations or in a validation/lab environment? etc. -- greetz, Bas