SystemVerilog and pthreads

[nizam.ahmed]

Hi champs,

 

I have a specific use-case where i would like to drive signals into the test-bench, but they are coming from different pthreads. I see that my implementation works. My deeper question is, is this allowed by the SystemVerilog LRM? 

 

In effect, the SystemVerilog and the simulation engine runs.... As it runs, asynchronously a pthread pushes a stimulus into the test-bench. We do the set_context and so on before driving into the system. But, still we would like to hear from horse-mouth!

 

BR/Nizam

 

[uwes]

hi,

 

i think this isnt really a question for the SV LRM. it defines that one can interact with the simulator/signals via vpi_put_value() BUT it also defines as to when you can interact with the simulator. I dont think that the simulator is prepared that the vpi functions are invoked at any time, re-are entrant, thread-safe etc (almost everything can happen when you try to operate from a threaded system a potentially not thread aware system (at point the system isnt aware of).

 

another point in the whole discussion is "repeatability". when you rerun a simulation is then thread order, thread timing the same? im not sure if the standard thread implementations care for this ...

 

/uwe 

[dave_59]

Nizam,

 

You were not really clear on which C interface you were using, DPI or VPI. For DPI, one thing that is clear in the LRM: you cannot call an DPI exported SV routine from a thread that was not created by calling a DPI imported C routine.

 

But in any case, there are issues beyond the thread-safe issues that Uwe mentioned. There needs to be a global synchronized concept of time in an SV simulation. SystemVerilog has no built-in mechanism to understand calls that could be from another point in simulated time.

 

All this is not to say your application cannot use pthreads - it's just that the interaction between the SV kernel and C must be performed within a single thread.

 

Dave