RE: udpated mentor proposal

Per/John:

After further discussion and thought, I think I can clarify further what
cases out of all the possible function calling recursion possibilities are
and are not important, at least to our use model at BRCM.

Some confusion can result when trying to construct the equivalent case
example using SCEMI 1.x macros, callbacks, ServiceLoops, etc. In doing so I
was neglecting my own preference to deal with a new standard at a higher
level of abstraction. I'm a user and need not concern myself with
implementation details.

The most interesting case is the one where an imported function unblocks C,
and C has a lot of flexibility to do all kinds of things before it returns
from the original imported function. In our testbench environment, the
imported function might activate other threads that were created earlier in
the simulation, thus the scope of the verilog that needs to be "seen" by the
C code can be greater than the scope of the module which called the imported
function, and the C code might need to execute exported functions to
retrieve information from verilog. I can live with the restraint that while
the C is executing (before the original imported function returns), C can
only be permitted to call exported functions that may have return values
(not just void functions). This would provide it a way of fetching
additional data from the verilog side. It could not call exported functions
that in turn call embedded imported functions, because I think this would
really complicate matters.

Rule: Only one imported function can be active at the same time.

In our use model, this one case suffices is sufficient for consideration
since C is only unblocked and running as a result of an imported function
call. However, there are the cases of streaming operation (independent
threads operating and executing DPI calls). If streaming were controlled
from the verilog side (buffer empty/full checking for example), any imported
function calls made by the streaming control logic would be separate from
other imported function calls, they'd be executed sequentially, and the Rule
would hold. If streaming were controlled from the C side, the separate
streaming thread running COULD execute in the middle of an imported function
call -- which would be the "main" thread executing. In this case, however, C
would be doing the talking, and the vehicle for that would be an exported
function call which is allowed.

This isn't an exhaustive analysis by any means but I feel comfortable with
the Rule. I think it's roughly analogous to the sequential servicing of
SceMiOutputPorts in SCEMI 1.x




---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------



> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf 
> Of Bojsen, Per
> Sent: Friday, June 03, 2005 6:27 AM
> To: 'John Stickley'; 'itc@eda.org'
> Subject: RE: udpated mentor proposal
> 
> 
> Hi John,
> 
> > I think it would be useful for you to elaborate a bit on
> > the cases that you're interested in supporting because that would 
> > certainly be good input for the committee.
> 
> Russ already highlighted the most important case I was 
> thinking of: an imported function calling one or more exported ones.
> 
> In terms of your existence proof of the implementability of 
> your proposal, do you have some inherent limitations on the 
> combinations of mutual calling that is supported or is it 
> unlimited?  If unlimited, I'd be inclined to say that we 
> should be very careful about imposing arbitrary restrictions 
> on what the user can do.  If you existence proof does have 
> inherent limitations, I'd want to know if those are just 
> pragmatic, i.e., put in place in order to get the work done 
> in a reasonably amount of time, or if they are more 
> fundamental.  If the latter, I think we should explore this 
> (abstractly, not referring to your particular implementation, 
> of course).
> 
> > I can answer this one quickly. It is not that we think these 
> > restrictions should necessarily go in. We're just a bit 
> surprised that 
> > there has been so much concern about ease-of-implementation that we 
> > felt that putting in some of these restrictions might ease those 
> > concerns.
> 
> I don't think the ease-of-implementation issues are around 
> what is allowed in terms of mutual calling of DPI functions, 
> though.  To me the most complex part in terms of 
> implementation of your proposal is the analysis required of 
> the HDL source.  We can talk about this at the next meeting, 
> if you like.
> 
> Thanks,
> Per
> 
> -- 
> Per Bojsen                                Email: <bojsen@zaiqtech.com>
> Zaiq Technologies, Inc.                   WWW:   
> http://www.zaiqtech.com
> 78 Dragon Ct.                             Tel:   781 721 8229
> Woburn, MA 01801                          Fax:   781 932 7488
>