Re: udpated mentor proposal

Russ,

You have very good arguments here.

Again, my intent was to ease implementation concerns.

Both 1) and 2) below are valid and, I think an especially good
case can be made for 1) as you suggest.

What I had stated in the updated proposal was suggestions
for guidelines to promote quicker adoption by the implementor.

My thinking was as follows:

Initially just use function calls as messaging conduits between
threads running in C and processes running in HDL. If HDL
wants to pass a message to C, call a function. If C wants to
pass a message to HDL, call a function. That's it.

Based on inputs from both you and Per, I'm quickly realizing
the concensus is that at least 1) below should be allowed.
I agree with this and see no reasons to impose this restriction
as long as it is agreeable to the implementors.

And I think we'll get no argument whatsoever from the users,
who, after all is who we're really trying to please, right ? :-)

-- johnS

Russell Vreeland wrote:
> 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
>  > ________________________________________________________________
>  >
>  >
> 
> 

-- 

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
________________________________________________________________