Subject: Re: [sv-cc] reminder: updated svc.h, svc_src.h needed - Separate concerns!
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Mar 18 2003 - 07:35:11 PST
> 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 - 07:35:52 PST