UVM and SystemVerilog prosess semantics

[Erling]

Is it correct to assume that SystemVerilog processes are scheduled cooperatively, i.e a conforming simulator excludes preemption and there is never more than one active process, even on a multi core system, and the active process runs until it executes an explicit blocking statement?

UVM seems to depend on this being true, for example in the handshake between a sequence and a driver, where both ends of the handshake calls grant_queued_locks() without an explicit mechanism (that I can find) preventing this from happening concurrently.

My understanding was that SV processes are similiar to VHDL processes, but PJ Ashenden's introduction to so called protected types in his book "The Designer's Guide to VHDL" seems to indicate otherwise: "Problems with shared variables potentially arise when the processes in the model are executed on a parallel computer ..., they can also occur on a single-processor computer if the simulation kernel preemptively switches between processes".

One should think that SV semaphores was introduced to solve the same problems, but if there is never more than one active process in SV, then what service does a semaphore offer that a plain int does not?

Hope someone can shed some light on this.

Regards

Erling

[uwes]

hi,

>Is it correct to assume that SystemVerilog processes are scheduled cooperatively, i.e a conforming simulator excludes preemption and there is never more than one active process, even on a multi core system, and the active process runs until it executes an explicit blocking statement?

this is incorrect. the VLOG2001LRM (which is used as base for SV) states in section 5.4.1 & 5.4.2

5.4.2 Nondeterminism

... At any time while evaluating a behavioral statement, the simulator may suspend

execution and place the partially completed event as a pending active event on the event queue. The effect of

this is to allow the interleaving of process execution. ...

>One should think that SV semaphores was introduced to solve the same problems, but if there is never more than one active process in SV, then what service does a semaphore offer that a >plain int does not?

even when not stated in the SV-LRM the semaphore needs some 'atomic' operation. if this would be not the case a semaphore could not check the lock and acquire the key without the possibility that another process is doing that exactly at the same time. with #1 (above) an vlog/sv-int solution would be hard to accomplish.

/uwe

[Erling]

>>Is it correct to assume that SystemVerilog processes are scheduled

>>cooperatively...

>

>this is incorrect. the VLOG2001LRM (which is used as base for SV) states in

>section 5.4.1 & 5.4.2

>

>5.4.2 Nondeterminism

>... At any time while evaluating a behavioral statement, the simulator may suspend

>execution and place the partially completed event as a pending active event on

>the event queue.

>The effect of this is to allow the interleaving of process execution. ...

I have read this many times now and have come to the conclusion that this section does not and never will apply to SV and can be safely ignored. If this type of nondeterminism is added to SV at some time in the future, it will not be to implement interleaving, but to solve a real problem, and the language would need better support at that time to deal effectively with the consequences. What the simulator does to optimize is another matter. I would guess that some sort of process overlapping is possible on a multi core machine, as long as the program works is as if overlapping didn't happen.

Please correct me if I am wrong.

>even when not stated in the SV-LRM the semaphore needs some 'atomic' operation.

>if this would be not the case a semaphore could not check the lock and acquire

>the key without the possibility that another process is doing that exactly at

>the same time. with #1 (above) an vlog/sv-int solution would be hard to >accomplish.

If it was possible, in practice, for multiple processes to do anything exactly at the same time and this could change the meaning of the program, then one should think that there would be many a semaphore in UVM, but a search gives just one hit. That particular semaphore also demonstrates a problem that comes with this construct: the semaphore is taken at top of task, and then released at end of task. But there are several return paths in the task where the semaphore isn't released. Not that it matter in this case, but it shows that it would be an unfortunate development if folks start protecting things all over the place to solve problems that can't happen in practice. This does not mean, of course, that there aren't situations where the SV semaphore is useful.

Regards,

Erling

[uwes]

hi,

ieee1800-2009 ch. 4.7 has the exact same statements:

At any time while evaluating a procedural statement, the
simulator may suspend execution and place the partially completed event as a pending event in the event
region. The effect of this is to allow the interleaving of process execution, although the order of interleaved execution is nondeterministic and not under control of the user

i'm not sure what you mean with "that it does not apply"? the whole point is that there is no "guarantee" that line+1 is executed after line in a sequential context even if the simulators most of the time stick to it.

[Erling]

With "does not apply", I mean the section does not apply in practice. Anything else would seem to open a can of worms for no valid reason. Anyone who knows the hows and whys this section made it into the standard? What signficant problems call for radically different runtime models?

Regards

Erling

[jscheid]

At least one vendor references this Nondeterminism section when the "cooperative multitasking" model does not hold for their product. Not that I'm happy with that...

[Erling]

What product is that? It seems to be relevant, since the product appears to be incompatible with UVM.

[jscheid]

What product is that?

Still trying to resolve this with them. But the standard needs to get refined if the community feels the scope of interpretations of "Nondeterminism" is too broad.

[Erling]

Still trying to resolve this with them. But the standard needs to get refined if the community feels the scope of interpretations of "Nondeterminism" is too broad.

It seems the program construct is meant to deal with the nondeterminism. In section section 16 of the 2005LRM, the two major sources of nondeterminism in Verilog are said to be events processed in arbitrary order, and statements not executed as one event. The section presents the program construct as the solution to both types of nondeterminism, because "it provides a syntactic context that specifies scheduling in the Reactive region", and it "specifies specialized execution semantics in the Reactive region...".

So why isn't the program block used in the UVM examples? Everything goes into modules there without exception. It is as if the UVM distribution has been run through a filter to make sure that program blocks does not go into the release.

Regards,

Erling

[uwes]

hi,

the -2005 semantics of program blocks were badly broken. the semantic had to be fixed for the -2009 ieee1800 standard release. unfortunately the specified -2005 and -2009 do differ in some cases potentially leading to simulation mismatches depending upon which language revision you choose. as a result of the -2005 program blocks issue it was the safe route in the past to encapsulate the whole environment in module-endmodule. these environments continue to perform with the same semantic in -2005 and -2009 and should not cause nasty surprises. also to note is that all the 3 vendors support the module semantic while the -2009 semantic may not be yet supported completely by all three. so again so far this was the safe route - once full support for -2009 is present you may use it.

/uwe