Re: Transaction Pipes and Threading

Jason,

Thanks for starting to review this stuff. Your continued input will
be valuable in seeing it through to its final form.

Answers embedded.

Jason Rothfuss wrote:
> Hi John and ITC techies,
> 
> I was looking over the description of transaction pipes and was 
> wondering if the use of a preemptive threading package (like pthreads) 
> is intended with this API?

johnS:
It is intended to be used with a cooperative multi-threading
scheme, not a preemptive one. In that sense it should be usable
with an underlying package like pthreads as it is possible to
use pthreads in a cooperative multi-threading use model.

In fact, as you probably know there is an implementation of
OSCI-SystemC that is built over pthreads that uses it in a
non-preemptive (cooperative) use model.

Because cooperative mutli-threading is the basic model
inherent in SystemC, Vera, e and traditional Verilog and VHDL
simulators, we make the assumption here that that is
this is a valid use model for DPI pipes as well, since they
are intended to be used in conjunction with traditional
HDL-simulation environments.

The implementation of the pipes would need the basic ability
to suspend the calling thread to allow implicit yields - such
as the case when a pipe's buffer might fill.

> 
> If the answer is "no", there is no need to continue reading.  If the 
> answer is "yes", I have a problem with the current definition of the 
> C-side API. 

johns:
So as you see from above the answer is no. But I'll keep
reading anyway ! :-) ...

> 
>  
> 
> I noticed in the example that the user's C-code calls:
> 
>  
> 
> svSetScope(hdlContext);
> 
> dpi_pipe_c_send(…);
> 
> …
> 
> svSetScope(hdlContext);
> 
> dpi_pipe_c_flush(…);
> 
>  
> 
> I assume that *svSetScope()* is called so that the *dpi_pipe_c_send()* 
> and *dpi_pipe_c_flush()* reaches the correct pipe.  The problem that I 
> have is that if you're using a preemptive threading package (like 
> pthreads), another thread could change the scope between the call to 
> *svSetScope()* and *dpi_pipe_c_send()*, therefore sending a message to 
> the wrong pipe/module.  I would suggest adding a *svScope* argument to 
> the *dpi_pipe_c_** functions, so that the infrastructure will have a 
> better chance of ensuring that the message reaches the correct pipe.
> 

johnS:
Yes the assumption is correct. These calls are treated like any DPI
call and require proper scope setting for the possiblity that DPI
calls might be used underneath or that at least the scope handle can
in some other way be used to derive an HDL context for the opposite
endpoint of the pipe.

And I hope from my explanation above it is clear that they assume a
non-preemptive use model. I agree with your analysis that if preemption
is allowed, the model breaks down as you now get into issues of having
to worry about thread safety, etc. But I believe this is all beyond
the scope of the problem space we're addressing here.

Rather, we just want to fit within the conventional HDL simulator
use model that has been used for years, where threads (or processes
or always blocks) execute until they yield for whatever reason.

This all said, I'm OK with the idea of passing the scope as an
argument to a pipe call. In the early days of DPI I actually
strongly pushed to require that scope be the 1st argument of any
exported DPI call in general. But this was knocked down for a number
of reasons and, to make a long story short, you technically need
to preceed any exported function call with an svSetScope() unless
that call is being made in the default scope such as would be
the case if an exported function is called from inside an
imported function. In such cases, the default scope is assumed
to be that of the imported function.

In the case of pipes, since we as the developers of the standard
have the freedom to reinstate this, I think it is not a bad idea.
The only reason I kept it out was for consistency with plain DPI
calls but that is not necessarily a good reason.

-- johnS

>  
> 
> Please let me know what you think.
> 
>  
> 
> Regards,
> 
> Jason
> 
>  
> 
>  
> 
> *Jason Rothfuss*
> /Cadence Verification Division/
> 
> 
> *Cadence Design Systems, Inc.*
> 16279 Laguna Canyon Road
> Irvine, CA 92618
> 
> Office:
> 
> 	
> 
>  
> 
> 	
> 
> +1 (949) 790-7181
> 
> Mobile:
> 
> 	
> 
>  
> 
> 	
> 
> +1 (310) 210-2754
> 
> 
> 
> rothfuss@cadence.com <mailto:rothfuss@cadence.com>
> www.cadence.com <http://www.cadence.com>
> 
> 	
> 
>  
> 
> 	
> 
> C a d e n c e <http://www.cadence.com>
> 
>  
> 

John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_