apfitch

For your first question, please refer to Table 59 - Socket Types on page 521 of the standard. For your second question, please refer to section 5.2 sc_module - especially section 5.2.7, 5.2.8 regards Alan

There's a system function $bits which returns the size of certain types in bits - but it's not supposed to be used on dynamic data types (see 1800-2012 20.6.2). But in your case, you know that there is 56 bits of fixed data plus 8 bits * the length of the packet, i.e. (pkt.payload.size) * 8 + 56 The neatest solution would be to add a length method to your transaction class. regards Alan

Ok, that's when you use the Simple Sockets - have a look in the TLM2 documentation (in the SystemC 1666-2011 Language Reference Manual, which you can download from Accellera). There is a summary in there of the utilities that are provided with TLM2, including the "convenience sockets" - see section 16.1 regards Alan

Doulos will be running a webinar on Friday 26th April "The Finer Points of UVM Sequences". Presented by John Aynsley, Doulos CTO Register here! http://www.doulos.com/content/events/easierUVM_The_Finer_Points.php

Hi Mohit, what do you mean by "register transport"? Alan -- http://www.doulos.com

You can't make a non-blocking assignment to a class member - serialin is a member of the class. The easiest solution is to change it to blocking, i.e. serialin = dut_vi.data; Regarding getting your code to work, I think you'll just have to debug it. In class-based code, the single-step / breakpoint features of the simulator are very useful, regards Alan P.S. Actually non-blocking assignment to class members is allowed in 1800-2012 - but that doesn't mean you should use it :-)

Wow, that's a lot of code... If I've understood correctly, surely you just need task sipo (ref serialin); // must be a ref if you want to read it during the task logic [9:0] pout; for (int i = 0; i<10; i++) begin pout = {pout[8:0], serialin}; // assuming called just after a posedge? @(posedge dut_vi.clock); end $display ("Pout is %b", pout); endtask : sipo You may need to mess about with the timing of when you call the task. regards Alan http://www.doulos.com

Have a look at the TLM examples on our website - http://www.doulos.com/knowhow/systemc/tlm2/ especially the "Getting Started with TLM2" tutorial, regards Alan

Just use sc_time_stamp() to retrieve the times at the points you're interested in, then compare the difference in time stamps to your spec, regards Alan

Please ask a specific question - what specifically do you not understand? regards Alan

It's a piece of software code to handle the communication with a socket (not a TLM socket I guess, probably an operating system socket) Alan

When TLM2 was developed, the main requirements were speed interoperability To achieve interoperability, it was decided to standardise the generic payload object. The design of the generic payload was aimed at allowing modeling of memory-mapped busses. A memory-mapped bus uses an address in memory to locate the registers/memories in peripherals attached to a bus. So the generic payload includes a field for address, as well as fields for data. regards Alan

In a loosely timed model you only have two timing points - start of transaction, end of transaction. In an approximately timed model using the base protocol, you have four timing points - start request, end request, start response, end response - hence you can model overlapped (pipelined) transactions, because you can start a new request before you have the response to the previous request. In my example above, you would only be able to send a new transaction every 75 ns using loosely timed, so the model of the timing of the transaction is less accurate - in the loosely timed model I can send a new transaction every 75 ns, in approximately timed every 50 ns using that example. If you do not use overlapped transactions, then you could just use begin request and end response, so as you say the non-blocking (approximately timed) and blocking (loosely timed) models would give the same results, regards Alan

You can connect loosely timed and approximately timed models with care - the Simple Sockets in the TLM utilities do automatic blocking to non-blocking conversion if you use the base protocol. You could call the Simple Sockets adapters if you like, regards Alan

I'm using the phrase "adapter" to refer to translating from one representation of a transaction to another. For instance if you call a blocking write in TLM, and that has to be sent to an RTL model, you would need some code that extracted the data from the write transaction and wiggled the pins up and down on the RTL. That's the code I'm calling an adapter. You could also call it a driver. A particular tool might also need a systemc RTL description to match a VHDL /Verilog RTL description - I guess that's what you mean by a wrapper. regards Alan

Imagine you are modelling a bus-based system. You send a request to a slave on the bus. That request takes keeps the bus busy for 50 ns, and then the peripheral takes 25 ns to process the data. That means you can send a new request on the bus every 50 ns, before you have received the response from the slave. Req1 Req2 ---------|---------|--------- |---------|---------|--------- Resp1 Resp2 If you need to model at that level of detail, then you would use approximately timed modeling, with non-blocking transport. If you don't need that level of detail (perhaps you don't even know what bus you're using yet?) then loosely-timed might be appropriate (and faster) regards Alan

Generally TLM2 is aimed at high speed, so you would not use primitive channels, you would use function calls (TLM). However you might need primitive channels in some places, for instance if you need to connect a TLM model to an RTL model via an adapter. regards Alan

The two coding styles trade off speed vs timing accuracy. The main limitation of the loosely timed coding style is that you cannot model pipelined transactions. So you need to decide how much timing accuracy you need, and if you need to model pipelined transactions, regards Alan

You need to use the macros `uvm_component_param_utils* See the class reference for details, regards Alan

Just one "gotcha" - remember that uvm_tlm_analysis_fifo stores references, so you should make a copy of your transaction to put in the fifo, regards Alan

You should be calling write() in the analysis_port, not write_a - the analysis_imp automatically translates your call to write to write_a and so on, regards Alan

Could you use cfg_mon[i] = chpp_config_monitor::type_id::create($sformatf("cfg_mon%0d",i), this); I haven't tested it... Alan

What command do you use to build your program? Alan

ifstream is part of C++, nothing to do with SystemC. So you may need to learn more C++. As we don't have your complete code, it's hard to tell what's happening. However my basic question would be why are you writing this code in an SC_THREAD? Why not just open the file and load the array in the constructor of the class? regards Alan

The SystemC scheduler is co-operative (though there are now ways in SystemC 2.3.0 for one thread to kill another), i.e. one thread must suspend before another can run. The danger with shared variables is that your code is not deterministic - not only can thread execution order be different between SV and SystemC, it can be different between two implementations of SystemC (or two implementations of SV for that matter). So if you require deterministic simulation with shared variables, you should control the order of execution of your threads explicitly, using e.g. events, regards Alan