RE: udpated mentor proposal

John,

I was a little surprised about one of your restrictions that are in Section
5.3.  Specifically, you included: "imported functions can't call exported
functions". I can understand the rationale for this type of restriction
(obviously we don't want exported functions calling imported functions
calling exported functions ad nauseum), but the specific case of this
imported function restriction is a little surprising. Here are two
contrasting case examples:

 1) something happens in verilog that requires a message to C
    an imported function is called (call this an "interrupt")
    the interrupt service routine (the exported function in C) then decides
it needs additional 
      information from verilog so it does a (zero time) "read" (an exported
function call)

 2) something happens in verilog that requires a message to C
    the resulting imported function call is designed so that all possible
information that C could
      ever require is passed via the imported function's parameter list
    the interrupt service routine (the exported function in C) has
everything it needs to do its 
      business, processes and returns


Are you saying that 2) is the only allowed case? It would seem to me that 1)
ought to be allowed because it is the analog of a SCEMI 1.1 callback
function sending messages through SceMiInputPorts to the HDL side (something
that a lot of my transactors do -- or if not the callback functions
themselves, in the application code that runs before the next
ServiceLoop(blocking) is called ).

Having said all that, these kind of restrictions on DPI usage are absolutely
necessary -- we just shouldn't accept all of them by default without some
thought.
    

---------------------------------------
---    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 John Stickley
> Sent: Thursday, June 02, 2005 5:48 PM
> To: 'itc@eda.org'
> Subject: Re: udpated mentor proposal
> 
> 
> Per,
> 
> Bojsen, Per wrote:
> >  >   3) In Section 5.3, on the DPI restrictions, you are proposing
> >  >      some restrictions on how DPI functions can call each other
> >  >      mutually.  Did your proposal always (implicitly) include
> >  >      these restrictions or is that new?  I'm asking because we're
> >  >      interested in exploring some of the cases you're 
> proposing to
> >  >      not support.
> > 
> > To clarify the intent of this question, what I was 
> wondering is what 
> > issues you see that are alleviated by putting in the 
> restrictions you 
> > mention in Section 5.3, especially the ones that restrict mutual 
> > calling of DPI functions.
> 
> johnS:
> 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. That was the 
> intent of the restrictions - to limit the scope of what would 
> have to be supported.
> 
> And again, bear in mind that this is a strawman. We would 
> really like to solicit committee input on this subject.
> 
> 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.
> 
> -- johnS
> 
> > 
> > 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
> > 
> 
> -- 
> 
> This email may contain material that is confidential, 
> privileged and/or attorney work product for the sole use of 
> the intended recipient.  Any review, reliance or distribution 
> by others or
> forwarding without express permission        /\
> is strictly prohibited. If you are     /\   |  \
> not the intended recipient please     |  \ /   |
> contact the sender and delete        /    \     \
> all copies.                      /\_/  K2  \_    \_
> ______________________________/\/            \     \
> John Stickley                   \             \     \
> Mgr., Acceleration Methodologies \             \________________
> Mentor Graphics - MED             \_
> 17 E. Cedar Place                   \   john_stickley@mentor.com
> Ramsey, NJ  07446                    \     Phone: (201) 818-2585
> ________________________________________________________________
> 
>