Jump to content

basarts

Members
  • Content Count

    9
  • Joined

  • Last visited

  • Days Won

    1

basarts last won the day on February 26

basarts had the most liked content!

1 Follower

About basarts

  • Rank
    Member

Recent Profile Visitors

274 profile views
  1. 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
  2. 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.
  3. The release contains a file docs/scv/scvref/vwg_1_0e.pdf which (sort of) clarifies this.
  4. 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
  5. 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
  6. Hi Maxim, "addr" is a pointer, so you need to access its fields and methods by using operator-> : SCV_CONSTRAINT(addr->range(1,0) == 0); -- greetz, Bas
  7. basarts

    SystemVerilog "program" scope

    From a hardware verification point of view, a simple solution would be to let the SC TB sample on the falling clock edge i.s.o. the same rising edge.
  8. Hi Karthick, Thanks for your reply. I did mean sc_out<double> out_port and sc_in<double> in_port, because I was deliberately using a double channel. The sizeof() operator returns 8 both for double and unsigned long long on my system. In the meantime, I found that it is not related to SystemC anyway: double d = 3.1415926535897931; unsigned long long *ullp = (unsigned long long *) &d; unsigned long long ull = *ullp; // ull = 4614256656552045848 double d2 = (double) ull; // d2 = 4614256656552045568.0000000000000000 !! unsigned long long ull2 = (unsigned long long) d2; // ull2 = 4614256656552045568 double * dp = (double *) &ull2; // *dp = 3.1415926535896688 Hence, the casting of an unsigned long long to a double seems to cause the problem. -- greetz, Bas
  9. I tried to write and read an unsigned long long value over a double channel, using a double value as starting point. Code snippet: double d = 3.1415926535897931; unsigned long long * ullp = (unsigned long long *) &d; out_port.write(*ullp); // sc_out<double> out_port; connected via sc_signal<double> to in_port unsigned long long ull = in_port.read(); // sc_in<double> in_port; connected via sc_signal<double> to out_port double * dp = (double *) &ull; When I print the values of d, *ullp, ull and *dp, I notice the following: d: 3.1415926535897931; *ullp: 4614256656552045848; ull: 4614256656552045568; *dp: 3.1415926535896688; However, plain casting without SystemC (double d -> ull* ullp = (ull*) &d -> ull u = *ullp -> double* dp = (double*) &u -> double d2 = *dp) returns d2 with exactly the same value as d. Any idea what is happening and why the channel of type double seems to loose a bit of its precision when using it in this way? -- greetz, Bas
×