Subject: Re: [sv-cc] extern/export function declarations
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 05 2003 - 08:45:36 PST
> Francoise wrote;
>
> For providing function prototypes for external functions, I like to have:
>
> c) the extern declaration can appear multiply in any declarative scope
Multiple declarations are needed only when all extern declarations must occur
in $root scope. (The rationale was that a design may be built up from pieces,
such that each of them comes with its own external declaration, and eventually
all those declarations end up together in the same scope. This rationale
does not exist if extern declarations may be encapsulated in modules.)
I don't see a need for multiple declarations in the same scope if they may
be put inside any scope.
> but at least an extern declaration is required in the scope where SV calls
> the C function.
I'm not sure I understand this. Can I use an extern declaration from an outer
scope? Regular visibility rules are not sufficient?
> d) extern declaration equivalence checks done by the SV compiler
Do you mean that multiple extern declarations must be equivalent?
That requirement was a must in the previous version, with externs restricted
to $root scope.
=== Comment: what a can of worms got opened with that supposedly innocent relaxation of rules! Watch out: the best is coming now! ====
Actually, all that is really required is that every global, i.e. coming from
the outside of SV, function has a unique signature. So, it is only cname that
matters! The ability to specify cname different than SV name for an external
function - yet another recent addition! - allows to both, use different SV names
for the same C function, and to use the same SV name for different C functions,
because scope nesting allows for local definitions of names.
Example:
========= start of SV code ========
import extern A = void foo(); // A is C name
initial begin foo; end // calling A();
... // module or block or whatever ...
begin
import extern B = void foo(int); // B is C name
import extern A = void foo2(); // A is C name
...
foo(1); // calling B(1);
foo2; // calling A();
end
begin
import extern B = void foo(int i = 5); // B is C name
import extern B = void foo2(int j = 2);
...
foo; // calling B(5); with default arg
foo2; // calling B(2; with default arg
end
...
========= end of SV code ========
There are three extern declarations of foo, with different signatures,
and there are two extern declarations of foo2, also with different signatures,
but there should be no conflict since they are in different scopes.
> e) an alias declaration used separately (because using a cname =
> SVfunction_name is not
> an alias declaration but a new syntax for aliasing names; we need to reuse
> the already designed components of the SV language and not reinvent another
> way of doing it.
> The alias declaration must be in the same scope as the extern
1. New (or they already do exist?) restrictions are needed:
same cname cannot be aliased with more than one SV name, although different
SV names can be aliased with the same C name.
2. Are multiple yet equivalent alias declarations allowed?
3. Separation of aliases from the external declarations may have serious
consequences; perhaps it will be a welcome functionality?
For $root extern declarations, with a simple switch of a file containing just
aliases, it will be possible to re-map SV names on absolutely different
C functions!
> extern [pure|context] function return_type SVfunction_name (ansi-style
> arguments with mode, type, argument names and default value);
> alias cname = SVfunction_name;
> 2 extern declarations are equivalent iff:
> . their signature are identical (both parameter types and result types
> of the respective 2 extern
> declarations must be identical)
> note: is it lexically identical or statically identical.
> for example, an integer number (3) can be used to specify the
> left range in one
> declaration and a binary value 2'b11 could
> specify the left and right ranges of the
> other declaration, or even a parameter
> which value is 3.
I think that the eventual size matters, so [1+1:0], [2'b10:0], [2:0] are all
equivalent.
> . the number and order of the parameters is identical
> . the name of the parameters can differ and are optional, they are all
> required if SV calls by name
> and the names must match the names in the visible extern declaration.
Why? Couldn't the same function be redeclared in nested scopes with different
names of formal arguments but otherwise the same signature?
> . default values are identical.
Ditto.
>
> For the export declaration, if the export declaration has to be in the same
> scope as the SV function declaration then no need for full path name or
> prototype.
> If I want to be able to put the export anywhere in the design, I need the
> instance pathname and full prototype because this would help in generating
> the C code to call the SV function (allocation of space
> for passing actual values to the SV function must be done in C, the return
> value of the SV function
> may be used in the C code).
> If the full prototype is given, then we must define the equivalence between
> an export and the real
> function declaration and between 2 exports.
> The advantage of being able to put the exports anywhere and in particular
> to put all of them
> in a separate verilog file allows to change your C application which would
> call additional SV functions without having to recompile the module which
> contains the called SV function.
Not really. Very likely the SV compiler will have to know whether a function is
exported before translating this function. Perhaps a function can be totally
eliminated if not used, or inlined, etc.
Andrzej
This archive was generated by hypermail 2b28 : Wed Mar 05 2003 - 08:46:18 PST