Subject: [sv-cc] RE: [sv-bc] function external declarations and prototypes
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Feb 26 2003 - 09:14:28 PST
Danny,
Thanks for sending the latest state of art of the bnf. It helped a little but
I think that we have a few issues in the bnf and some clarifications which
are needed from the BC and EC
committee on the syntax and semantics of function/task prototypes and
extern declarations.
A proposal for function/task prototype syntax and semantic checking of the
conformance of the prototype
with the task/function declaration is needed.
I see several issues in the latest 3.0 draft:
1) the extern keyword is mentioned in several places in the interface
chapter,
but there is no bnf corresponding to the extern fork join task/function.
Section 13.5.1 Tasks and functions in interfaces:
If the tasks or functions are defined in a module, using a hierarchical
name, they must also be declared as
extern in the interface, or as export in a modport.
Tasks (not functions) may be defined in a module that is instantiated
twice, e.g. two memories driven from the
same CPU. Such multiple task definitions are allowed by a forkjoin extern
declaration in the interface.
I see 2 problems in the above paragraph:
a) the only place where I see the extern keyword used in SV3.0 is in
combination with the forkjoin keyword and
this must be used if the task is defined in a module and this module
is instantiated several times, then the interface
must declare the task as "extern forkjoin". Therefore there is no
place in 3.0 that the task could just be declared as:
extern <task_identifier> or extern <function_identifier>
b) The last sentence has the syntax reversed: "forkjoin extern" instead
of extern forkjoin.
2) Clarification on the use and syntax of function and task prototypes.
At the end of section 13.5.1, it is said that:
A function prototype specifies the types and directions of the arguments
and the return value of a function
which is defined elsewhere. Similarly, a task prototype specifies the types
and directions of the arguments of a
task which is defined elsewhere. In a modport, the import and export
constructs can either use task or function
prototypes or use just the identifiers.
we must clarify:
1. when and where is a prototype can be used?
It looks like that (from the above paragraph) a prototype can be
used in conjunction with the import and export
keywords in an interface declaration.
There are some comments in the interface examples, that the import
requires the full prototype (not just the function
or task identifier). This is the only place where I can find a
task/function prototype being used. It is in the
import_export. The production which are used is
"named_task_proto" and named_fn_proto".
There are 2 other productions task_prototype and
function_prototype (which are the same as the
named_task_proto except that the name of the task is not
supplied). The task_prototype
and function_prototype are not used in any productions.
2. Task/function prototype versus extern task/function declarations
Is there a difference between a task function prototype and an
extern declaration
where can extern declarations be specified?
3. how does a function or task prototype is defined to match a function
or task definition.
If there are multiple function and task prototypes, how do they
conform to the function or task definition?
In VHDL, it is allowed to specify a subprogram specification
(prototype) in several places but
there are conformance rules defined which check if the subprogram
specification of the
declaration conforms to the subprogram specification of the
subprogram body.
Both subprogram declaration and subprogram body must appear in the
same declarative region
For example the subprogram declaration can be in a package
declaration and the subprogram
body can be in the package body. There can be many subprogram
declarations.
The check rules for VHDL subprogram conformance are very strict. I
am NOTsuggesting that we made them that
strict in systemVerilog but I like to give them as an example of
what we need to specify.
In short,
VHDL specifies that that 2 specifications conform if (apart form
comments) they are formed by the same
sequence of lexical elements and if the lexical elements are given
the same meaning by the visibility rules.
There are 2 exceptions on the lexical
equivalence : a numeric literal can be replaced by another numeric
literal of the same value
a simple name can be replaced by an expanded
name (hierarchical name)
Therefore 2 subprograms such as procedure P (X, Y: in integer)
and procedure P ( X:
integer; Y: integer) are not conforming.
In System Verilog, the data type of a formal parameter is optional,
the direction is optional, grouping of
formal parameters is allowed:
task mytask3 ( a,b, output logic [15:0] u, v);
a and b have default logic type and default mode in.
u and v are both outputs and v has the same data type as u.
The task can be qualified as automatic in 3.0
The EC committee has added an optional default value and other
qualifiers (local, protected, public or virtual).
Note that the EC committee has added the use of extern for virtual
methods declared in classes.
Extract from the class chapter 11.20 Out of block declarations
Declare, within the class body, the method prototypes
—whether it is a function or task, any attributes (local,
protected, public, or virtual), and the full
argument specification plus the extern qualifier. The extern
qualifier indicates that the body of the method
(it’s implementation) is to be found outside the declaration. Then,
outside the class declaration, declare the full
method—like the prototype but without the attributes—and, to tie the
method back to its class, qualify the
method name with the class name and a pair of colons:
All of the above need to be considered when drafting the conformance
rules for tasks and functions prototypes.
We have somewhat similar but different problems in the CC committee
where we are trying to define the
syntax for extern function declarations which have a C
implementation. Extern function declarations can appear in
multiple places and some conformance rules between multiple extern
declarations must be stated but no conformance
rule can be stated between the extern declaration and the C actual
function definition (data types may not be
be the same). Additionally these C implemented functions are called
in a systemVerilog context and it is desired that
the C function call must not be distinguishable from a call to a
native Verilog function (allowing passing by position
and by name and skipping arguments which would need to have formal
argument names and default values in the
extern function prototype).
I think we should try to harmonize the syntax for extern
declarations, clarify where extern declarations
and/or prototypes can appear and specify the rules for conformance.
May be this would be best handled by some joint participation of all
3 committees members
like it was done for the simulation cycle semantics?
Francoise
'
At 03:17 AM 2/26/2003 +0200, Jacobi, Dan wrote:
>Francoise,
>
>I'm attaching a zipped document (in both MS word and html formats)
>This document also summarizes all the changes in BNF done by SV-BC including
>the extern function declaration.
>(Changes from yesterdays meeting are not included).
>
>Home this helps
>Danny
>
>-----Original Message-----
>From: Francoise Martinolle [mailto:fm@cadence.com]
>Sent: Tuesday, February 25, 2003 6:52 PM
>To: sv-ec@eda.org; sv-bc@eda.org
>Subject: [sv-bc] function external declarations and prototypes
>
>
>I am trying to find in the 3.1 latest draft a specification of the extern
>function declarations.
>I have not found any formal complete description or bnf. Is the BC or EC
>working on creating this definition and resolving this issue?
>The sv-cc committee is using the extern declaration for creating external
>references to
>function implemented in DirectC and there are questions regarding:
>
>- if multiple extern declarations are provided, how should they match
>between each other to be compatible? how would they match to the actual
>declaration?
>
>Specific questions are:
> do default values need to appear in the extern declaration?
> can extern function declarations have different names than the actual
>function declaration
> can multiple extern function exist and be different?
> Should all formal arguments appear in the extern declaration?
>
>francoise
> '
>
This archive was generated by hypermail 2b28 : Wed Feb 26 2003 - 09:17:35 PST