Subject: RE: [sv-cc] dynamic arrays and open arrays
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Aug 13 2003 - 10:10:26 PDT
Andrzej,
This is an interesting proposal.
My main concern centers around the original intention
of open arrays. Namely, the ability to do generic
programming in C that could handle different array
variants given on the Verilog side. Such variants
are often given by using parameters as dimensions.
What do you (and others) think about giving this up?
The main effect will be that specific C code will need
to be written for each such variant; no generic code
will be possible.
Of course, your new proposal is simpler to implement
and to conceptualize. But we might find some users
eventually unhappy if they lose the ability to do
generic programming as described above.
Thanks and regards,
Doug
-----Original Message-----
From: Andrzej Litwiniuk
To: sv-cc@eda.org
Sent: 8/12/2003 7:10 PM
Subject: [sv-cc] dynamic arrays and open arrays
Team,
The proposed changes to BNF and LRM for open arrays/dynamic arrays
are at the end of this e-mail. Those changes reflect the current state
of DPI.
When DPI was being designed, dynamic arrays were not in the language
yet,
or at least they weren't taken into consideration while working on DPI.
DirectC donated by Synopsys didn't support multi-dimensional arrays.
Nevertheless, the mechanism of "open array" has been enhanced in order
to allow for multi-dimensional arrays. We took great pains to support
multi-dimensional open arrays. Just recall the huge number of interface
functions for 'abstract access' to multidimensional open arrays. And
some
Accellera members aparently didn't like that abstract access nor that
many
functions.
And now I have some doubts about it. Perhaps it would be better, for the
sake
of language uniformity, to have only one form of arrays with unsized
dimensions
instead of two distinct forms: one-dimensional native dynamic arrays and
multi-dimensional arrays as DPI formals.
I tried to summarize where arrays in DPI are different from native SV
arrays.
The differences between native SV 3.1 arrays and arrays as formals of
DPI
import function are, roughly speaking, in two areas: where unsized
dimension
(denoted by []) is allowed and how arrays are passed as actual
arguments.
Arrays as arguments
-------------------
Arrays as formal arguments of native functions may be passed by
reference
(keyword ref) or by value (keywords input/output/inout).
In the case of import DPI functions, it is intended for the sake of
efficiency
that an implementation may pass arrays by reference.
In the SV layer of DPI it is transparent what is the actual passing
mechanism;
'ref' is not supported. It is the C layer that specifies that arrays are
actually passed by reference, although by input/output/inout in SV
layer.
So there is some difference in array passing between native and DPI
import
functions. It is deliberate and motivated by a performance.
Practically, such difference will seldom be observable as a different
behaviour.
It can happen when the same array is passed for input and output
argument at
the same time (aliases), or when an array passed as an argument of
a context function is also read or written by an export DPI function
called
from that context function. (Scenario such that a context function calls
SV
function which reads output arg of that context function or writes an
input
arg of that context function.)
IMHO there is no compelling reason to change array passing for DPI
functions,
trading a performance for a language uniformity.
Unsized dimension
-----------------
Native arrays, be they variables or formal arguments, may have only one
unsized dimension; unsized dimension is allowed solely for dynamic
arrays,
which are always one-dimensional. Unsized dimension can occur only in
the
unpacked part of an array. There is no way to use both sized and unsized
dimensions in the unpacked part of the same declaration.
Formal arguments of import DPI functions may be declared as arrays which
are
one-dimensional in the packed part and multi-dimensional in the unpacked
part.
Any dimension in either part can be unsized.
Therefore it is possible to have unsized packed part and more than one
unsized dimension in the packed part or both sized and unsized
dimensions in
the unpacked part of the same declaration.
Although this may be perceived as very flexible, at the same time
it may seem inconsistent with native arrays. I'm not sure how much
convenience
is added by more than one unsized dimension or by unsized packed
dimension.
I'm very tempted to propose to impose restrictions on DPI similar
to those for native arrays. Well, very likely it's too late to make such
a major change; anyway, the restriction could be as follows:
- unsized dimension is allowed only in the unpacked part of an
array
- unsized dimension is allowed only for one-dimensional arrays.
In other words, there will be no need for a DPI-introduced concept of
"open array"; instead, a dynamic array would be used. Such restriction
would, however, reduce the functionality.
If such restrictions were accepted, there would be no need for changes
in BNF
and other parts of LRM.
============== Changes in the BNF and LRM ===============
Some changes in BNF are required in order to allow open arrays with
sized and unsized dimensions.
BNF allows only for a single unsized dimension or any number of sized
dimensions, but not both sized and unsized mixed together.
I propose the following BNF changes in A.2.5 Declaration ranges:
1) Remove 'dpi_dimension'.
2) introduce a new nonterminal 'unsized_dimension'
2a) introduce a production:
unsized_dimension ::= '[' ']'
where '[' denotes [ in red, i.e. a terminal symbol
2b) in the production for 'packed_dimension' replace [] with
unsized_dimension
for the sake of consistent naming
2c) add a footnote:
"unsized_dimension is permitted only in declarations
of import DPI functions, see dpi_function_proto."
3) introduce a new nonterminal 'sized_or_unsized_dimension'
3a) introduce productions:
sized_or_unsized_dimension ::= unpacked_dimension |
unsized_dimension
4) Replace the productions for 'variable_dimension' with the following:
variable_dimension ::= { sized_or_unsized_dimension }
| associative_dimension
4a) add a footnote:
"More than one unsized dimension is permitted only in
declarations
of import DPI functions, see dpi_function_proto."
Other changes in LRM.
In section 4.8 Arrays as arguments:
In the second paragraph, replace "and that all dimensions be of the same
size." with:
"and that all sized dimensions be of the same size. Note that unsized
dimension may occur in dynamic arrays and in formal arguments of import
DPI functions. If one of dimensions of a formal is unsized, then any
size
of the corresponding dimension of an actual is accepted."
Add at the end of section:
"An import DPI function that accepts a one-dimensional array can be
passed a
dynamic array of a compatible type and of any size if formal is unsized,
and
of the same size if formal is sized."
Additionally, I suppose that section 26 would benefit from a terminology
change, if "open array" is replaced with "unsized array". Your
sugestions
are welcome.
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Wed Aug 13 2003 - 10:12:11 PDT