apfitch

You could try the Accellera bus locking tutorial http://www.accellera.org/resources/videos/tlm20extensions/ together with the code examples on Doulos http://www.doulos.com/knowhow/systemc/tlm2/locking_and_snooping/, but be warned, it is an advanced topic, regards Alan

I don't believe there is a difference, though I'm happy to be corrected. UVC seems to be the preferred terminology of Cadence. regards Alan

Can you give an example of the words "configuration space"? Where did you see them? regards Alan

That's just because declarations need to be first in procedural code. Try this: virtual function void Configure_PKT(string s); // My_Packet mp; super.Configure_PKT(s); begin My_Packet mp; $cast(mp, PB[s]); mp.C = 2; PB[s] = mp; end endfunction : Configure_PKT virtual function void printP(string s); // My_Packet mp; super.printP(s); begin My_Packet mp; $cast(mp, PB[s]); $display("My_test::PB[%s].C is %d", s, mp.C); end endfunction : printP (note the extra begin/end to create a new scope) regards Alan

Another way to understand it is that $cast lets you assign a base class reference to a derived class reference - but the base class reference must refer to an object of the derived class type (which is what fbochud has done above - in his example P1 does actually refer to an object of type My_Packet). It doesn't make sense to put a BasePacket into My_Packet. With inheritance, I always use "is a" to remind myself what's going on. So a My_Packet IS A BasePacket. But a BasePacket is *not* a My_Packet. Even better use examples like fruit An Apple is a Fruit but a Fruit is not an Apple (but a variable of type Fruit can hold a reference to an Apple!) regards Alan

The sc_port does have to be bound, but it is bound when you bind the initiator socket to the target socket. Binding the initiator socket to the target socket binds the initiator port with the target export; and the target export is bound to the target tlm_transport_fw_if. The result is that an initiator may call functions via the port in the initiator socket, via the export in the target socket, which are ultimately implemented in the target. The reverse is true for the target socket. See the introduction to section 13.2.1 in the 1666-2011 LRM. regards Alan P.S. Remember you can download the 1666-2011 standard for free.

There's a summary on this page: http://www.doulos.com/knowhow/sysverilog/uvm/ regards Alan

For your first question, try reading this Wikipedia article on constraint programming: https://en.wikipedia.org/wiki/Constraint_programming The solver is the part of a SystemVerilog simulator that solves the constraints (produces a set of values for random variables that satisfy the constraints). For your second question, the SystemVerilog standard states "If a solution exists, the constraint solver shall find it. The solver can fail only when the problem is over-constrained and there is no combination of random values that satisfy the constraints." Which you could argue means the constraint solver is "powerful". regards Alan

OK, two answers - firstly, it'll probably work without that, assuming you have a c++ compiler installed, so you could just leave that out completely. Second answer - setenv is specific to c-shell. You're probably running bash, in that case the equivalent command is export CXX=g++ regards Alan

The instructions in the INSTALL file should work. If they don't, please post the error message you get, regards Alan

sc_int is a (template) class, hence takes more space Alan

The other perhaps obvious point is - have you got a loop in your thread(s)? If you haven't they will only run once then die. Even with a loop, you could miss the first event for the reasons Ralph points out, regards Alan

Also sc_int has lots features, for instance the ability to select a range of bits; concatenation operators; bit select; various type conversions; and so on. See the 1666-2011 Language Reference Manual for details, regards Alan

Hi Dakupoto, you can still use dynamic sensitivity. For instance a typical TLM2 loosely-timed model would use SC_THREADs with no sensitivity. The events are used dynamically as part of set_and_sync() (for instance), kind regards Alan

Hi Darrenxu, the code you've written in green won't work because SystemC has no shorthand for a concurrent signal assignment (VHDL) or assign (SystemVerilog). One solution is to write a helper process, e.g. void assemble_proc() { num1_t=num1; num1_s1=num1_t[0]; num1_s2=num1_t[1]; num2_s1=num2_t[0]; num2_s2=num2_t[1]; sum2_t[0]=sum_s1; sum2_t[1]=sum_s2; sum2=sum2_t; } // in the constructor SC_METHOD(assemble_proc) ; sensitive << sum2_2 << sum_st << sum_s1 << num2_t << num1_t; Another solution would be to use sc_vector (available in 1666-2011, Proof-of-Concept simulator 2.3.0). Instead of using sc_uint, you could then create a vector of sc_in<bool> and sc_signal<bool> for instance, and assemble and dis-assemble the vector. kind regards Alan P.S. I am also tempted to say "do it in VHDL or SystemVerilog instead" but that's not very helpful if you're trying to learn SystemC :-)

Hi Dakupoto, every systemc process will run at time 0 regardless of sensitivity. However as Philipp points out, using both dont_initialize() and no sensitivity would cause a process to never run, regards Alan

You can convert the range object to and from sc_int, e.g. SC_MODULE(Slice){ sc_in<sc_fixed<42,12> > input; sc_out<sc_fixed<14,14> > output; void do_slice(){ // sc_int<14> temp = sc_int<14>(input.read().range(41,28)); output.write( sc_fixed<14,14>(temp) ); } SC_CTOR(Slice){ SC_METHOD(do_slice) sensitive<<input; dont_initialize(); } }; The allowed conversions are shown in IEEE 1666-2011. regards Alan

Hi Patrick, to a large extent "it's a tool issue". There are various ways of connecting SystemC and other languages in the tools. For instance you can leave out sc_main and mark the SystemC top level with a proprietary macro (the technique used in Questasim and Cadence). I can't remember the details in VCS or Riviera, but it's also possible. There's no standard way to communicate via TLM, but each vendor has some solution. Mentor have UVM Connect (which connects UVM to SystemC) - it is open-source, and should run on all UVM and SystemC compliant simulators - you can download it from Verification Academy. Synopsys have TLI, Cadence have UVMSC and variants. If you don't have UVM or SystemVerilog, you could create a SystemC TLM-to-pins adapter yourself (which would be straightforward for b_transport), and then instance the VHDL inside SystemC. Again the process of instancing the VHDL in the SystemC is proprietary, regards Alan

Hi Ram, at the moment there isn't a newer one, but the VWG are working on it as I write. If you can join the VWG you could download the beta latest version, but I'm confused (!) by the rules over who can join and who can observer a working group. regards Alan

That looks like the error you used to get with SystemC 2.2 - are you installing 2.2 or 2.3? 2.3 should work, Alan

Hi Cam, the simple_sockets behave in the same was as the standard sockets, in the sense that an initiator may *call* the four functions (b_transport, nb_transport_fw, get_direct_me_ptr, transport_dbg) and the target *must* implement those functions. On the reverse path the target may *call* nb_transport_bw and invalidate_direct_mem_ptr, and the initiator implements them. The only difference with the simple sockets is that they have the bodies of the functions for you. In other words the simple_target_socket implements the tlm_fw_transport_if, it contains function bodies for b_transport, nb_transport_fw, get_direct_mem_ptr, and transport_dbg. However to tell those functions exactly what to do, you register your *own* function with the required behaviour. To do this, you call register_b_transport etc. So if the initiator calls b_transport in the target with a simple socket, the b_transport function *in the simple socket* is called. That then in turn calls the function you registered with b_transport. That compares to the standard sockets, where the implementation of b_transport is *in the target* not *in the simple target socket*. I hope that's a bit clearer, regards Alan

Hi Cam, you can use the simple sockets if they do something useful for you. If you can't work out why you want to use them, then you probably don't want to use them. The key features of the simple sockets are described in the LRM section 16.1.2.1 The comparison of the socket types is in tables 59 and 60 in section 16.1.1.1. If the LRM description is unclear, you probably need to ask a more specific question. For instance if you asked me "what is the advantage of using callbacks in the simple socket" I could answer that question. regards Alan

There are no built-in ways of connecting to a semaphore (no ports or built-in channels). The easiest solution would probably be to pass a reference to the semaphore into each module via a constructor argument, regards Alan

The methods of sc_fifo are described in the LRM, see section 6.23.2. If you look at that, there are no functions for clearing a fifo. However it would be quite easy to write a helper function, e.g. void function reset_fifo (sc_fifo<int> & f) { int dummy; while ( f.nb_read(dummy) ) ; } regards Alan P.S. Making it a template function is left as an exercise for the reader :-)

If you're happy to use a Gnu extension with gcc, you can use a "computed include", e.g. #define fred "testcases/testcase_001.cpp" #include fred However then you'd have to also write #define test testcase_001 to make the code compile when it declares the class. Perhaps you can do something like #define test testcase_001 #define testinc "testcases/#test" #include testinc (again gnu only) regards Alan