Jump to content

Bas Arts

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Bas Arts

  1. You seem to incorrectly use the sc_start function. Please read up on sc_start (paragraph of 1666-2011 (https://ieeexplore.ieee.org/document/6134619)) and post your code afterwards, if still necessary.
  2. Just out of curiosity: did you consider/discuss to use XML as a data modeling language i.s.o. JSON, for example to ease integration into or connection with IP-XACT?
  3. It is (typically) part of your vendor's tool installation. Inside the installation, look for "ubus" and/or "integrated". For example: $ find <path_to_vendor_installation> -name *ubus* If $UVM_HOME has been set correctly, you can also use $ find $UVM_HOME -name *ubus* Or simply use your favorite search engine on the web with terms "integrated", "ubus" and "uvm".
  4. Hi Sumit, I cannot test with gcc 9.3.0, but with SystemC 2.3.3 and gcc 9.1.0 using c++14 the following code doesn't give any problems: int sc_main(int argc, char* argv[]) { Blah myblah {"myblah"}; myblah.LetsWrite(); myblah.ThisOneFailsToo(); return 0; }
  5. It seems that you are mixing compiler versions and/or settings between the different packages you use. At least, your SystemC installation has not been built with the default GCC 4.8.5. Although not strictly necessary, I'd recommend to build SystemC, UVM-SystemC and SCV with the same compiler version and -options. I can confirm that with GCC 4.8.5, the SCV 'make check' also runs successfully.
  6. Hi Josep, After building SCV, did you run 'make check'? Did all tests pass? If so, could you share a small example that reproduces your problem? For me, 'make check' runs successfully using SystemC 2.3.3 and g++ 9.1.0. Thanks
  7. In addition, if your SystemC model contains ports of type double, you need to convert them in the test harness to 64 bit vectors first.
  8. On a side note, you might also consider moving to SystemC 2.3.3; SystemC 2.3.1 is fairly old.
  9. I guess the return value reflects either successful (zero) or non-successful (non-zero). E.g. the following code prints a non-zero value (in my case, 256 although I would have expected 1): module foo; int val; initial begin val = $system("test -f thisfileprobablydoesnotexist"); $display(val); end endmodule
  10. 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 */
  11. (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
  12. 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.
  13. 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.
  14. 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.
  15. You could use an optional command line parameter to sc_main and propagate that to the "real" test.
  16. See https://docs.microsoft.com/en-us/visualstudio/debugger/debugger-feature-tour?view=vs-2019 for basic information regarding application debugging.
  17. You also need to include -I, -L and -l for uvm-systemc in your compilation.
  18. Forget that last post, it seems that brackets etc. are not displayed in the posts.
  19. I guess you need some extra changes: firnodes = new FirNode(...) firnodes->data_in(...) accu->mul_in(mul_sig) etc.
  20. 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.
  21. 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").
  22. 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?
  23. From the standard: "Tagged? Incoming interface method calls are tagged with an id to indicate the socket through which they arrived."
  24. 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
  • Create New...