Subject: RE: [sv-cc] reminder: updated svc.h, svc_src.h needed - Separate concerns!
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Mar 18 2003 - 08:38:35 PST
Andrzej,
I don't feel that we need another layer on top of what
we already have in DPI. The current scope handling API
is simple, in my opinion. We just need to make a couple
of twists to handle setting/retrieving context-based
user data, and we will be done.
John has come up with an example application using many
elements of DPI. I like this approach, since it really
puts the API and its functionality to the test for a
real world application of context-based functions.
In order for the example application to work, this
user-data topic must be addressed in SV 3.1.
I think we can keep with the spirit of simplicity
in the API, yet enable complex applications to
be built on top of our simple building blocks.
"Concise yet complete" is another good principal
to base work on.
John,
Will you be sending your example pretty soon?
What about proposals for the twists on the API functions?
Thanks and regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Tuesday, March 18, 2003 7:35 AM
> To: Stickley, John
> Cc: sv-cc@server.eda.org
> Subject: Re: [sv-cc] reminder: updated svc.h, svc_src.h
> needed - Separate concerns!
>
>
> > Also, the svGet/PutUserData functions need some more discussion.
>
> Agree. Whatever the outcome is going to be, the issue
> deserves a discussion.
>
>
> > For the next meeting I would like to add to the agenda to give some
> > serious discussion to this earlier posting of mine:
> >
> > http://www.eda.org/sv-cc/hm/1029.html
> >
> > The more I look at this the more I think it is the right model for
> > handling user context. So, to summarize, I'm recommending
> that the new
> > profiles for the user data functions are as follows:
> >
> > void svPutUserData( const svScope, const char *cname,
> void *userData );
> > // Associates a user context with a specific
> extern'ed function
> > // of a specific module instance scope.
>
>
>
> Professor Edsger W. Dijkstra used to preach: "Separate
> concerns!". In May 2000 The University of Texas at Austin
> hosted Symposium in honor of
> Edsger W. Dijkstra. The symposium was titled "In Pursuit of
> Simplicity".
>
> IMHO we too should pursue simplicity in DPI.
>
> The existing solution that provides one generic pointer per
> SV instance seems absolutely sufficient to built much richer
> a functionality upon it.
>
> There is no doubt that there may be conflicts should
> different applications start directly using a single shared pointer.
>
> It will be futile, however, to try to predict all possible
> needs of applications. An application may need to associate a
> single function with an instance. Or data. Or data per each
> exported or extern function. Or none of the above.
>
> A common approach to defining software protocols is to build
> them in layers.
> So perhaps there is a need for another layer of DPI. Please
> note that such a layer seems to be quite well isolated from
> DPI. Modes of argument
> passing are irrelevant here, so are data types, open arrays,
> specific functions for bit selects, etc. All what matters
> are: SV instances and perhaps functions. So such a layer
> could be possibly build upon VPI (or PLI?) or upon any other
> foreign language layer for DPI. There is no need to embed it
> into C Layer of DPI.
>
> I have two points here:
> - make it a separate layer. (I don't care whether it can make into 3.1
> timeframe or 3.2).
> - consider whether using a function name (char *) as a key
> for instance<-->data
> association is efficient. Perhaps an application may
> register its functions
> and get a unique key for each function pointer. Or there
> may be a unique key
> for each SV instance and than each application will take
> care of itself
> and will provide its own mapping from instances to
> functions and data.
> And there will be no overhead when such functionality is
> not required, no
> isssues of memory leaks, etc.
>
> Make it simple. Separate concerns. Howgh!
>
>
> Regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Tue Mar 18 2003 - 08:39:16 PST