Subject: DirectC: properties/capabilities of external functions
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Nov 06 2002 - 18:20:10 PST
Last Tuesday we decidied that an external function may be specified
as dirty (or unsafe) if it may call PLI/VPI which could read/write
arbitrary data objects, not only the actual arguments for the particular
directc call.
I tried to put together several characteristics, properties or capabilities
that may be- or will need to be -specified for external functions.
Some of these properties/capabilities are related, some may be mutually
exclusive. Some of them are already present in VCS DirectC, others
will be likely needed for the extensions that have been discussed.
A need and a syntax for some of such properties appeared in a few
discussion threads, public or internal.
These properties have to explicitly specified in order to allow
the compiler to generate the correct code for a directc function/task
call and to allow or prohibit compiler optimizations.
1. "C" or "A" or null - access mode (direct/abstract/default)
2. "pure" - whether function result depends solely on arguments, with
no side effects, "pure" func call may be optimized away
3. function or task
4. "dirty" - may or may not access anything in the design, not only actual
args, via PLI/VPI calls
5. may or may not PLI be called from C function;
compiler may need to set some variables in order to support
further PLI calls
6. may or may not C function/task call SV function/task;
compiler may have to provide somehow SV context (instance)
7. Module qualifier
from which instance a task/function may be legally called;
may be needed if default SV context is to be provided
I may speculate also that calling tasks from the other language
may involve creating and switching threads, what may be done on SV side
or C side; it's possible, that additional properties will be needed
to inform SV compiler who is responsible for thread creation.
With this many characteristics very likely the syntax will be confusing
or clumsy or both. We may use long sequences of keywords
(e.g.: extern "A" dirty task calls_PLI calls_SV owns_thread foo();)
or 'fopen'-like lists of characters (e.g.: extern "ADTPSO" foo();)
but still there are two many properties to be specififed.
Sure, they might be bundled into few sets of capabilities, but then
very likely users will tend to use the most general combination
(like enabling all acc capabilities "just for case").
And this will kill the performance.
Ok, my point is: keep it simple. Do not attempt to solve all problems
via DirectC. VPI/PLI will be still there.
Thanks,
Andrzej
This archive was generated by hypermail 2b28 : Wed Nov 06 2002 - 18:25:09 PST