Subject: [sv-cc] DPI - supported data types
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Mon Mar 31 2003 - 12:57:08 PST
Team,
It's very late, possibly too late for any non-trivial revisions to DPI,
Nevertheless, the parts of DPI LRM that address the supported data types need
to be revised, redefined and re-phrased, I'm afraid.
The phrase "with some restrictions, all/most SystemVerilog types are allowed",
see SV layer 1.1.2, 1.4.6, was deliberately vague.
However, with so many additions to the language (classes, strings, dynamic
arrays, associative arrays, mailboxes, semaphores, event variables, more?)
the number of exceptions is too high to be ignored.
Personally, I was not aware of all those additions, or even if aware of some of
them, my mindset apparently was to exclude and/or ignore them.
I'm not proposing to add any new types to those already accepted to be
supported. All I'm proposing is to specify the set of supported types clearly.
This was, actually, the approach of the original "17 items" proposal (0327.html),
see items 11 and 14.
The definition of supported types may be inductive. Something like this:
============
The following SV types are allowed in DPI:
- basic integer and real types: byte, shortint, int, longint, shortreal, real
- 'handle'
- 'string' interpreted as a const (char* value extracted from a string class
object)
- scalar values of type 'bit' and 'logic'
- packed one dimensional arrays of type 'bit' and 'logic'; note however, that
every packed type, whatever is its structure, is eventually equivalent to
a packed one dimensional array.
Therefore it could be said as well that all packed types are supported,
although their internal structure (individual fields of structs, multiple
dimensions of arrays) will be transparent.
- enumeration types interpreted as the type associated with an enumeration type
- types constructed from the supported types with the help of the constructs:
- typedef
- struct
- unpacked array
- all and only the types listed above are permitted in DPI
============
The above definition should go to "1.4.6 Types of formal arguments",
section "1.1.2. Data types" should contain a reference to that definition.
Note that the above inductive definition excludes several types. This is
intentional as far as my point of view is concerned.
Additionally, more rules may be needed for actual arguments in the case when they
do not match the formal ones exactly, specifically for dynamic arrays.
Are dynamic arrays permitted as actual arguments for sized and unsized (i.e. open)
arrays? Is a single element of an associative array permitted as an output arg?
Etc.
Are dynamic arrays permitted as types of formal arguments of tasks and
functions? Dynamic arrays seem to use the same '[]' notation as open arrays.
How they are mutually related? Is there any conflict?
Your help will be appreciated with answering those and similar questions.
A meticulous cross-checking is something that we really need. (Swapnajit,
is it what sv-ac team is supposed to do for us?)
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Mon Mar 31 2003 - 12:57:52 PST