apfitch

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

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

For the signal class, there is an overloaded operator= which calls write(), so you can do either.
Some people find it clearer to use write() so that you can tell that you are assigning to a special class, rather than a plain C variable. In other words it is a matter of style,
regards
Alan

Yes, perhaps that post was too complicated.
 
Have a look at the slides 11-15 in the presentation TLM_2_0_presentation.pdf in the SystemC-2.3.0/docs/tlm/release folder
 
regards
Alan

Temporal decoupling refers to the idea that a process may keep running, but keeping its own local variable to hold the time. This local time may be "in the future" relative to the value returned by sc_time_stamp().
 
Because SystemC is essentially a co-operative scheduler, the process has to wait() at some time to let other processes run. That is the synchronization you refer to.
 
Note that SystemC is a single-threaded application, so when you say "all processes run in parallel" it is still a co-operative scheduler - no other process can run until the currently running process suspends.
 
regards
Alan

Hi Cam,
  the idea of TLM2 was to create a standard API for transaction level modelling, that runs at high speed, and models memory-mapped buses.
 
So the TLM Working group decided to create standard functions for both blocking and non-blocking transport; and a standard payload object.
 
So the first advantage of using TLM2 over plain SystemC is simply that it is a standard API and payload.
 
To model pipelined transactions, the TLMWG decided to use function calls from target to initiator and initiator to target. To allow function calls to be made in both directions needs a port on the calling module and an export on the target (forward), and a port on the target model connected to an export on the initiator. You could of course do this without sockets but you'd have to make two connections - by using a socket, a single bind call connects both export and port. Also you'd have to explicitly declare the initiator port and target export with tlm_transport_fw_if, and the target port and initiator socket with tlm_transport_bw_if - initiator socket is based on tlm_transport_fw_if and the target socket on tlm_transport_bw_if so you get that "for free".
 
Finally, the sockets also have extra template arguments compared to SystemC ports - the Bus Width parameter. This ensures that the user cannot accidentally connect busses of different widths together.
 
kind regards
Alan
 
P.S. There is another answer I could give:
TLM2 *is* SystemC there is no difference. An initiator is a channel that implements the tlm_bw_transport_if. The target is a channel that implements the tlm_fw_transport_if. So the only difference from the "traditional" use of SystemC is the idea of a socket to provide simultaneous binding of the both port and export. If you want to, you could create your own exports and ports, and connect them yourself.

Hi Amit,
  I didn't say "Concept of multiple interfaces in sc_export is a benefit of sc_export over sc_port".
 
I said "You have to parameterize the export by the interface. So if you have two interfaces, and you want them to be exported by a single export, you'd have to create a derived class."
 
You can do that with sc_port as well (i.e. use a single derived class interface that is derived from another set of interface classes) - see the code for sc_inout, for instance,
 
regards
Alan

Hi, declaring a class virtual means that the class itself cannot be instanced - it must be extended. So you can't make an instance of uvm_scoreboard on its own.
 
However uvm_scoreboard is itself derived from uvm_component. uvm_component has a constructor (new function) which needs the two arguments (name and parent).
 
If you derive from a base class and don't write your own constructor in the derived class, then the default constructor will get called. If the default constructor is called, then  the standard says
 
(1800-2012 p145)
 
"super.new call shall be the first statement executed in the constructor. This is because the superclass
shall be initialized before the current class and, if the user code does not provide an initialization, the
compiler shall insert a call to super.new automatically."
 
When the compiler calls super.new for you automatically, it will not supply any arguments. Hence your original error message, which is telling you the call to new in uvm_component is not being given the correct number of arguments.
 
regards
Alan
 
P.S. constructors are not virtual.

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

How do you know the assignment is not working?
When are you printing out the assigned value?
 
Remember that you must wait at least a delta for a primitive channel to update.
 
There's more about user defined types and sc_signal here
 
http://www.doulos.com/knowhow/systemc/faq/#q1
 
regards
Alan

Hi Zarie,
 that's what I meant by "you must wait a delta". If no time passes, a primitive channel does not update. Kocha's solution will work (adding a call to sc_start - in fact even sc_start(SC_ZERO_TIME)  should work.
 
regards
Alan

I guess the main advantage of using SystemC is that ports/modules/channels give you a standard approach. Even if you don't care about time passing, you may well care about the order that things happen in, and then events and time are still useful. Also of course you get a ready to use threading library and scheduler.
 
The disadvantage might be simulation speed compared to pure C++. And of course you have to learn SystemC.
 
The main advantage of C++ is that you can do exactly what you want (you're free!)
The main disadvantage of C++ is that you can do exactly what you want :-) (You're re-inventing the wheel)
 
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

Yes, but you need to write the constructors yourself (don't use the SC_CTOR macro). Something like
#include "systemc.h" SC_MODULE(mod) {    int i;    mod(sc_module_name nm) : sc_module(nm) { // ...    }    mod(sc_module_name nm, int i_) : sc_module(nm), i(i_) { // ...   } }; If you use SC_THREAD or SC_METHOD you must also include the SC_HAS_PROCESS macro.
 
Try looking up SC_HAS_PROCESS in 1666-2011 and you should find an example near there,
 
regards
Alan

Yes, but you need to write the constructors yourself (don't use the SC_CTOR macro). Something like
#include "systemc.h" SC_MODULE(mod) {    int i;    mod(sc_module_name nm) : sc_module(nm) { // ...    }    mod(sc_module_name nm, int i_) : sc_module(nm), i(i_) { // ...   } }; If you use SC_THREAD or SC_METHOD you must also include the SC_HAS_PROCESS macro.
 
Try looking up SC_HAS_PROCESS in 1666-2011 and you should find an example near there,
 
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

Hi Mr SystemCInDepth,
   I think it's important to realise that SC_CTHREAD is special, in that the specified sensitivity is a clock (the rising or falling edge event of a bool or sc_logic).
There's no such thing as a "clock" for SC_METHOD and SC_THREAD - just events on channels such as sc_signal, sc_fifo, or any other channel that implements an event.
So I would not say
because an SC_METHOD or an SC_THREAD does not have a clock. That's what Philipp meant when he said
Does that make it clearer?
regards
Alan

You should be able to view the Call Stack in Visual C++ - that may give you an idea of exactly where the exception is being thrown,
regards
Alan

Hi,
the reason for the error is that you're not binding all your ports. You bind the ports in this loop:
 
for(int i=0;i<n;i++) { for (int j=0;j<=i;j++) { std::cout << i << " " << j << " " << std::endl; test_CHOL0->chol_in_data[i][j](chol_in_data[i][j]); test_CHOL0->chol_out_data[i][j](chol_out_data[i][j]); } } but in the second loop you have j <= i. I've added printing and you can see that you only bind 6 of the 9 ports
 
SystemC 2.3.1-Accellera --- Sep 3 2016 13:00:03 Copyright (c) 1996-2014 by all Contributors, ALL RIGHTS RESERVED 0 0 1 0 1 1 2 0 2 1 2 2 I think you need j < n
 
regards
Alan

I guess first you'd need to add an attribute (extension) to the generic payload to represent the priority.
Then you could write a variant of the PEQ which takes into account that priority.
regards
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

A channel is simply a class that implements a SystemC interface.
 
A primitive channel implements an interface and is derived from from sc_prim_channel, and can thus have access to the scheduler (evaluate update).
 
A hierarchical channel implements an interface and is derived from sc_module, and can thus have all the features of an sc_module (processes, hierarchy etc).
 
There'd be no point in deriving from sc_prim_channel and then not implementing the update/request-update behaviour.
 
If you want a channel that is not a primitive channel, and is not a hierarchical channel, you would typically implement an interface but derive from sc_object.
 
 
regards
Alan
 
P.S. To answer your questions more specifically - request_update and update are not pure virtual, so you could ignore them. Though why would you ignore them? If you don't want them, derive from sc_object instead.
A hierarchical channel is derived from sc_module. sc_module does not have request_update/update, so you can't use them.

The error message implies that you are calling wait() in your SC_METHOD - that's not allowed, wait() can only be called in SC_THREADS,
 
regards
Alan

Could you use set action to set the action for all info messages to uvm_none?
 
Something like
+uvm_set_action=uvm_test_top.*,_ALL_,UVM_INFO,UVM_NO_ACTION Alan

You should be able to use
 
   std::randomize(id_array) with { unique {id_array}; };
 
Untested though,
 
regards
Alan