Hi Karandeep,
We presented a paper "A Beginner's Guide to Using SystemC TLM-2.0 IP with UVM" at several European Synopsys User Group (SNUG) meetings in 2012. This included a discussion of using the Generic Payload in a UVM environment which may help. You can download it from the "KnowHow" pages on the Doulos website - http://www.doulos.com/knowhow/sysverilog/SNUG12_uvm_tlm2/
Regards,
Dave

This free webinar will be presented in in English, French and German. To see further details and to register please visit:
http://www.doulos.com/content/events/easierUVM_FirstSteps_English.php
http://www.doulos.com/content/events/easierUVM_FirstSteps_French.php
http://www.doulos.com/content/events/easierUVM_FirstSteps_German.php

Hi Amit,
Pretty much - static processes are created using the SC_METHOD and SC_THREAD macros. Dynamic processes are created by calling sc_spawn. There is one slight complication, calling sc_spawn from a module's constructor will actually create a static process since the LRM defines a dynamic process as one created from "the end_of_elaboration callback or during simulation" (see Glossary B.51). The LRM uses the term "spawned" and "unspawned" to try to avoid this confusion!
Regards,
Dave

Hi Amit,
The scheduling mechanism for sc_mutex and sc_semaphore is very simple and does not have fifo characteristics (i.e. if several processes are waiting for the mutex/semaphore, they are not granted it based on the order in which they requested it - although there is nothing to stop an implementation of SystemC from executing processes in the same order as they are added to the list of runnable processes, the LRM says that the order is implementation defined).
The basic operation of a set of processes using a mutex/semaphore could be like this:
1) a process runs and grabs the free mutex/semaphore, it then hits a wait before releasing it
2) other processes run and attempt to grab the mutex/semaphore. If it is not free, the processes wait (for an event that is within the mutex/semaphore object)
3) the process with that has grabbed the mutex/semaphore wakes up and frees the mutex/semaphore - this issues an immediate notification on the mutex/semaphore's internal event
4) the processes waiting for the mutex/semaphore get added to the list of runnable processes. One of them starts executing and grabs the mutex/semaphore but hits a wait statement before releasing it
5) the remaining processes in the list of runnable processes will each start executing in the same evaluation phase, but now the mutex/semaphore is locked by the process that started in step 4 so they will block again until the next notifcation of the mutex/semaphore event (as in step 3)
Steps 3 to 4 are repeated until the end of the simulation or until every process has completed its access to the shared resource
Hope that is enough to give you the idea!
Regards,
Dave

Hi Amit,
I think you are talking about semaphore and mutex in the context of an embedded, multi-threaded software system here. SystemC does not provide all of the features required to model that kind of system (for example there is no built-in scheduler that supports process priorities and pre-emption.
The SystemC mutex and semaphore classes run in the evaluation phase and use immediate event notifications so cannot be used to control which process gets access to a shared resource if several are waiting for the mutex/semaphore. sc_mutex and sc_semaphore use the same scheduling mechanism.
Regards,
Dave

Hi KS,
By default, proc1 runs once during the initialization phase (unless dont_initialize() is called immediately after SC_METHOD(proc1) in the module constructor).
Once proc1 has executed, the next_trigger statement changes its sensitivity so that from then on it will be called whenever event x is notified, not when clk has an event.
Regards,
Dave

Hi KS,
If you are just starting out with SystemC, you can probably safely ignore dynamic (spawned) processes - just use SC_METHOD or SC_THREAD in the module's constructor. Dynamic processes can be useful for advanced cases (e.g. responding to some condition that is not known at compile time).
Regards,
Dave

Hi Amit,
I would not say that next_trigger is "like a delay element" since it does not hold up execution of an SC_METHOD (which would be illegal). It overrides the static sensititivity of an SC_METHOD and so changes the conditions which next cause the method to execute. There is an example on page 51 of the LRM.
Regards,
Dave

Hi Amit,
A mutex is used to ensure mutual-exclusive access to a shared resource. Think of it as being like having a single key to unlock access to the resource that you pass between processes that request it. Only one process can have it at a time - any other process that wants it will have to wait until the key becomes available.
A semaphore is similar but is more like a bucket containing multiple keys. You can set the number of keys in the bucket when it is created, processes request keys just like the mutex and will have to wait ("block") when no key is available. However, unlike the mutex, you can have multiple processes accessing the resource in the same time interval.
Regards,
Dave

Hi KS,
No, you are mixing up static/dynamic sensitivity with static/dynamic processes. You can for example have a static process (e.g SC_THREAD) that makes use of dynamic sensitivity (e.g wait(x) ) or a dynamic process (sc_spawn) with static sensitivity (using sc_spawn_options - see section 5.5 of the LRM)).
Regards,
Dave

Hi,
Because process 2 has to suspend and wait for event x, and because event x is only notified by process 1, the state of the instructions seen by process 2 when it wakes up will alway depend on what has happened in process 1 or process 3. Once a process is active, it will remain active until either it reaches the end of the function or it reaches a wait statement. Only one process can be active at the same time. The SystemC scheduler does not currently allow one process to pre-empt another (this feature might be added to a future version).
This confirms your assumption above "So the answer to question, that in process P2 does the instruction 3 will get the updated value of instruction 1-2 of the same process P2.?
is NO."
Regards,
Dave

Hi Amit,
Static processes are created before the start of simulation, by calling e.g. SC_THREAD macro or sc_spawn in the constructor or end_elaboration callback.
Dynamic processes are created by calling sc_spawn within another process (which will not be executed until the simulation is running).
Regards,
Dave

Hi KS,
Before answering your question, it is worth pointing out the way the SystemC scheduler works. After inititialization, it advances time to the earliest time step where there is a scheduled event notification. It adds all processes that are sensitive to that event (or other events at the same time step) into a list of "runnable" processes. It then resumes execution of every process in the list of runnable processes (one at a time) in some non-deterministic order. This is known as the evaluation phase. An immediate event notification can add processes to the list of runnable processes within the current time step, provided such processes are currently waiting for that event. Once the list of runnable processes is empty, the scheduler proceedes to the update phase where primitive channels (such as sc_signal) that have been written to, get updated. These primitive channels may be in the sensitivity list of other processes, in which case there is another iteration of the evaluate and update phases known as a delta cycle. This continues until there are no more events to process at the current time step, when the scheduler advances to the next time step.
Now, sssuming all of your processes above are within infinite loops, then after the end of the initialization phase, P1 and P3 will be suspended at their wait() statements and P2 will be waiting for an event on x.
When the event in P1 and P3's static sensitivity list happens, both processes get added into the list of runnable processes in the current time step. P1 or P3 will then run. If P1 runs first, it will notify event x immediately, this will add P2 to the list of runnable processes. The next process to run could be either P2 or P3.
Since P2 always waits for the event notified by P1, it will always run after P1 in any simulation cycle.
It's not clear to me what instruction1,etc are doing. If they are just variables that are being read and written, then P2 could see the values written by P1. However, P3 could be executed after P1 but before P3. In which case P2 would see the values written by P3. We cannot predict what will happen (although the order will always be the same every time the simulation is run). Instruction3 in P2 would see the values of instruction1/2 set by P1 or P3, depending on the order that the scheduler executes the process.
Hope that makes it a bit clearer for you.
Regards,
Dave