RE: breakthrough solution for "vendor induced" pipes deadlock ?

Hi John,

I downloaded the scemi2_demo package and started to review the example.
So far, I have two questions:

1) Shouldn't imported DPI functions: ResetComplete,
dpi_pipe_hdl_try_receive, dpi_pipe_hdl_try_send, should be designated
'context' functions if they intend to use the svGetScope() function or
call VPI or exported DPI functions (see IEEE 1800-2005 section
26.4.1.3)?

2) In the SystemVerilog spec (Annex F.8, paragraph 2), it is mentioned
that if the scope utility functions (svGetScope(), svSetScope(),
svPutUserData(), svGetUserdata(), etc.) are used with any non-context
function, a system error shall occur.  The "Testbench" constructor uses
svGetScopeFromName() and svPutUserData() to store a handle to itself.
Is this in violation of the spec because the Testbench constructor is a
non-context/non-imported function?  

Regards,
Jason

> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John
> Stickley
> Sent: Friday, January 27, 2006 7:31 AM
> To: 'itc@eda.org'
> Subject: breakthrough solution for "vendor induced" pipes deadlock ?
> 
> Greetings and ITC Techies,
> 
> I think I might have a breakthrough for our "deadlock"
> on pipes. :-)
> 
> That thing that seems to be bothering Shabtay the most,
> and perhaps with some justification, is that the pipes do
> not have a thread neutral API that can be used to aid
> implementations in adapting the user friendly pipe functions
> implementation to arbitrary threading systems on the C side.
> 
> So, after thinking about it and looking at what we have
> so far, it occurs to me that what we really need is *both*
> of the following
> 
> 1. A user-friendly, but thread-aware pipe interface
>     (which we already have).
> 
> 2. A lower level implementation-friendly, but thread-neutral
>     pipe interface - essentailly implementation "hooks" to
>     facilitate easy creation of adapters that allow implementation
>     of the user-friendly API in selected C threaing environments
>     (which Shabtay wants).
> 
> Shabtay, ye ask and ye shall receive !
> 
> Here's a solution I believe can be made to work that is,
> 
> 1. Compatible with the existing easy-to-use API at the user level
> 
> 2. Provides thread neutral "hooks" that implementations can
>     choose to use to create adapter layers.
> 
> 3. Easy to demonstrate a reference implementation of the blocking
>     pipe calls that uses the hook functions. In fact, the examples
>     I'm providing today show a working source code example of such
>     an implementation for the HDL side.
> 
> So what I've done is kept the blocking user-friendly pipe
> functions on the C side as is:
> 
> User-friendly C callins:
> dpi_pipe_c_send()
> dpi_pipe_c_receive()
> dpi_pipe_c_flush()
> 
> A user would use only these functions.
> 
> But I've added 4 new "hook" functions that only a thread
> specific implementation would use:
> 
> C hook functions:
> dpi_pipe_c_try_send() - C callin
> dpi_pipe_c_try_receive() - C callin
> 
> dpi_pipe_c_notify_ok_to_send() - C callback
> dpi_pipe_c_notify_ok_to_receive() - C callback
> 
> The try_send() and try_receive() functions are essentially
> non-blocking sends that return a status as to whether there
> was room in the pipe (try_send()) or at least one transaction
> in the pipe (try_receive).
> 
> The notify_ok_to_send() and notify_ok_to_receive() functions are
> callbacks that can be called directly or indirectly from within
> the thread-neutral implementation code to nofify the thread-aware
> implementation code (but not user code !) on the C side
> when it is OK to send or receive. By implementing the bodies of
> these functions a vendor can put in thread specific code that takes
> some action such as posting to an sc_event.
> 
> So the key here is that the 1st 2 hook functions have thread
> neutral code. And the 2nd 2 hook functions are callbacks
> called from within thread-neutral code that can be filled in
> by some implementation wishing to create a thread-aware adapter
> that implements the send() and receive() functions.
> 
> I've also defined the same functions on the HDL side for
> full symetry:
> 
> User-friendly HDL callins:
> dpi_pipe_hdl_receive()
> dpi_pipe_hdl_send()
> dpi_pipe_hdl_flush()
> 
> HDL hook functions:
> dpi_pipe_hdl_try_send() - HDL callin
> dpi_pipe_hdl_try_receive() - HDL callin
> 
> dpi_pipe_hdl_notify_ok_to_send() - HDL callback
> dpi_pipe_hdl_notify_ok_to_receive() - HDL callback
> 
> I've attached the C and Verilog header files that provide
> precise declarations of all of these functions.
> 
> In fact, in there you'll also find an actual source code
> reference model showing how, on the HDL side, the hook functions
> can be used in "adapters" that implement the user friendly
> functions.
> 
> A very similar scheme can easily be applied to any threading
> system on the C side.
> 
> I've also uploaded the complete working example that actually
> uses all the new hook functions (on both sides) and simulates
> on any ModelSim 6.1/Linux installation.
> 
> You'll find it on anonymous FTP at ftp.ikos.com under,
> 
>     outgoing/scemi2_demo.tgz
> 
> The 32 bit binaries are built for Linux that runs on either
> i386 or x86_64 platforms. It was tested on an RHEL 3.0
> machine. Env.script and Makefile explain setup.
> 
> I hope this breaks the deadlock allows us to move forward
> with pipes.
> 
> -- johnS