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