0

My question is whether concurrently sampling a coverpoint by multiple threads (after having overridden the buit-in sample method) creates any side-effects.

In more detail, consider the following code:

covergroup p_cg with function sample(bit [1:0] a);
  coverpoint a;
endgroup : p_cg

p_cg cg1 = new;

init cg1.sample(0);
init cg1.sample(1);

My understanding is that two threads are going to compete in order to update the covergroup for coverpoint 'a' and method 'sample' is going to execute for both threads (using separate data stacks). Do you think this is going to create any side-effects when both threads try to update the covergroup/coverpoint at the same time? (if so, the obvious solution is using semaphores of course).

Cheers, Stast

Stast
  • 1
  • 1

3 Answers3

0

No. A sample by its definition is a non-time consuming function.

dave_59
  • 39,096
  • 3
  • 24
  • 63
  • Does it have to do with the 'sample' function being built-in and executed by the simulator in one go or implemented specifically? My understanding is that, in principle, race conditions can occur between two functions which are simultaneously executed and have, for instance, multiple blocking assignments that access the same variables (e.g. class properties). In the example above, both functions will not consume any simulation time of course, however, couldn't context switching between the two simulation threads occur any time while being in the active region of simulation time 0? Thanks – Stast Dec 09 '15 at 16:41
0

SystemVerilog threads are not like native OS threads. They are scheduled in a non-preemptive way. This means that, at any given time, there is only one SV thread running and it will continue to run until it gives back control to the thread scheduler(usually by a time-consuming action) which will then pass control to another thread.

So in your example, the two threads will have atomic access to the the covergroup and its sample method. This means that one thread will not be interrupted by the other while it's running the covergroup's sample method. There will be no interleaved execution with an unpredictable outcome as you would expect when using native OS threads.

The only "side-effect" that you can expect is the order in which the 2 threads access the covergroup. In one simulation, thread A could access the covergroup first and thread B second while in another simulation it could be the other way around. This order should be correlated to the seed of the random generator. So if you run the same simulation with the same initial conditions and with the same seed you should get the same order in which the threads access the covergroup.

Tiberius P.
  • 74
  • 5
0

No. The argument to the sample() is pass by value, not pass by reference. It won't have any side-effect. Based on the way how the coverage bin is collected, the order of execution of the sample function in the two threads won't matter too, since you get the same coverage result at the end regardless of which thread sample first.

hevangel
  • 95
  • 5