Per, Comments embedded ... Bojsen, Per wrote: > 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. johnS: Sounds good. And, as I said, I think Russ's arguments were sound and we are in agreement. > > 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). johnS: I would say more pragmatic - for ease of adoption. Although if unlimited recursion (which Russ called "ad nauseum") were fundamentally prohibited, I don't think you would be severely restricting the usefulness of the transaction based interfacing use model either. > > > 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. johnS: OK, that's good input. So perhaps we can focus more on the analysis requirements in the next meeting. It is one of the items on Damian's discussion list. -- johnS <eom> > > 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 ________________________________________________________________Received on Fri Jun 3 07:27:09 2005
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2005 - 07:27:11 PDT