I agree that some of the functions like the scenario you (Russ) mentioned initially are harmless. It seems like these restrictions are geared towards compiler optimizations, so let's say for example: The compiler detects no context imported functions/tasks. Based on the spec, the compiler knows that there should be no calls to the scope utility functions svPutUserData()/svGetUserData(). Now, the compiler can remove the data structures associated with these utility functions. If you were to call svPutUserData() from a non-context function, you could crash the simulation. This is the only reason why I can see these restrictions being necessary. Regards, Jason ________________________________ From: Russell Vreeland [mailto:vreeland@broadcom.com] Sent: Wednesday, February 01, 2006 1:34 PM To: 'Stickley, John'; Jason Rothfuss Cc: itc@eda.org Subject: RE: breakthrough solution for "vendor induced" pipes deadlock ? It seems like a subset of the SystemVerilog utility functions shouldn't be used outside of context functions, but the rest probably can. I'm guessing svGetScopeFromName(), followed by svPutUserData() or svGetUserData() present no difficulties for use outside of context functions, while svGetScope(), followed by anything, probably does (what would it return without context?) Is this an issue to bring up to the SystemVerilog P1800 group for clarification? --------------------------------------- --- Russ Vreeland (949)926-6143 --- --- vreeland@broadcom.com --- --- Senior Principal Engineer --- --- Broadcom Corporation --- --------------------------------------- ________________________________ From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Stickley, John Sent: Wednesday, February 01, 2006 1:09 PM To: Jason Rothfuss Cc: itc@eda.org Subject: RE: breakthrough solution for "vendor induced" pipes deadlock ? Jason, I'm not sure how this is enforced here by ModelSim (obviously it isn't). But as you'll see none of the functions except for svGetScope() and svGetUserData() are actually used inside the imported functions themselves. All are used outside. I don't believe this is a violation. Also, I'm surprised svGetScope() and svGetUserData() are considered violations of non-context functions. I thought it was only VPI and calls to other interfaces that could cause side effects. Originally did not think these were considered violations. I'll check with our ModelSim team on when this changed and why. -- johnS -----Original Message----- From: Jason Rothfuss [mailto:rothfuss@cadence.com] Sent: Wed 2/1/2006 3:39 PM To: Stickley, John Cc: itc@eda.org Subject: 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. > > -- johnSReceived on Wed Feb 1 13:52:06 2006
This archive was generated by hypermail 2.1.8 : Wed Feb 01 2006 - 13:52:13 PST