Subject: [sv-cc] Problems in 3.1 official BNF for DPI
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Jul 10 2003 - 23:50:43 PDT
SV-CC Team,
Well it looks like my subconscious must have been thinking that
our first SV-CC meeting revival was too non-technical, because
look what I just dug up tonight! (Warning: long mail coming,
but important, so all you implementors out there, please readon...)
After Andrzej's "function" find last week, I studied DPI import
functions in the formal BNF this week. (export looks fine;
it is perhaps too simple to go wrong :) )
Here are some issues I can see. At the end are suggestions
for grammar rework that may clear the issues.
The main problems stem from the high level "dpi_function_proto".
It has two terms:
dpi_function_proto ::=
named_function_proto
| [ signing ] function_data_type function_identifier (
list_of_dpi_proto_formals )
The first term is extremely general - it allows all syntax one would
use to describe a native SV function. The second term is highly
restrictive, to the point of not being useful.
Let's look at each of these two terms separately.
1. In the "list_of_dpi_formals" production, the only allowed objects
are of type "dpi_proto_formal". Here is the grammar:
list_of_dpi_proto_formals ::=
[ { attribute_instance } dpi_proto_formal { , { attribute_instance }
dpi_proto_formal } ]
dpi_proto_formal ::=
data_type [ port_identifier dpi_dimension { , port_identifier
dpi_dimension } ]
Elsewhere appears the definition of "dpi_dimension":
associative_dimension ::=
[ data_type ]
| [ * ]
variable_dimension ::=
{ unpacked_dimension }
| [ ]
| associative_dimension
dpi_dimension ::=
variable_dimension
| { [ ] }
There are several problems in this branch of the grammar:
1a. There is no possibility of defining formal parameter modes.
i.e. no "input", "output", or "inout" is allowed. This doesn't
appear useful - we need to know parameter modes when processing
dpi import function declarations. If we keep this grammar branch,
what would be the default mode? "input"?
1b. The dpi_dimension production doesn't make sense.
By including variable_dimension, it lets in "associative_dimension"
and hence the "[ data_type ]" syntax permitted by associative_arrays.
This should not be permitted in dpi_import functions; at least it is
nothing we ever agreed or voted upon.
1c. The use of "data_type" in the dpi_proto_formal is too general.
See below for more on how and why.
2. The "named_function_proto" term at least allows us to specify formal
parameter modes such as input, output, and inout. However, it is too
general in that it allows "ref" parameters, as well as the use of
every single possible SV data type(!)
named_function_proto ::=
[ signing ] function_data_type function_identifier (
list_of_function_proto_formals )
list_of_function_proto_formals ::=
[ { attribute_instance } function_proto_formal { ,
{ attribute_instance } function_proto_formal } ]
function_proto_formal ::=
tf_input_declaration
| tf_output_declaration
| tf_inout_declaration
| tf_ref_declaration
tf_input_declaration ::=
input [ signing ] { packed_dimension }
list_of_tf_port_identifiers
| input tf_data_type list_of_tf_variable_identifiers
tf_output_declaration ::=
output [ signing ] { packed_dimension }
list_of_tf_port_identifiers
| output tf_data_type list_of_tf_variable_identifiers
tf_inout_declaration ::=
inout [ signing ] { packed_dimension }
list_of_tf_port_identifiers
| inout tf_data_type list_of_tf_variable_identifiers
tf_ref_declaration ::=
[ const ] ref tf_data_type list_of_tf_variable_identifiers
tf_data_type ::=
data_type
| chandle
data_type ::=
integer_vector_type [ signing ] { packed_dimension } [ range ]
| integer_atom_type [ signing ]
| type_declaration_identifier { packed_dimension }
| non_integer_type
| struct packed [ signing ] { { struct_union_member } } {
packed_dimension }
| union packed [ signing ] { { struct_union_member } } {
packed_dimension }
| struct [ signing ] { { struct_union_member } }
| union [ signing ] { { struct_union_member } }
| enum [ integer_type [ signing ] { packed_dimension } ]
{ enum_identifier [ = constant_expression ]
{ , enum_identifier [ = constant_expression ] } }
| string
| event
| chandle
| class_scope_type_identifier
There are just all kinds of problems for DPI in the above productions.
2a. I've already covered the use of "ref" allowed by
"tf_ref_declaration".
2b. The use of "data_type" is against the normative text Andrzej wrote
about allowable datatypes on the inter-language boundary.
For example, what does it mean to pass an "event" to C?
Or a "class_scope_type_identifier", such as MyClass::MyType?
2c. Further, note that tf_data_type isn't event a necessary grammar
element.
chandle is already present in plain old data_type. So every use of
tf_data_type in the grammar could be replaced by data_type.
Now that I have exposed all these problems, let's start seeing how we
can fix things up. My intuition tells me that we need to rework the
dpi_function_proto by turning it into something that looks like
named_function_proto, but with alternative sub-productions that
squeeze the grammar into the elements allowed by DPI import functions.
This might be a pretty big job, and I'm going on vacation for four weeks
starting this weekend. (Hey - my wife is french, what can I say?)
Here is a starting stab at it. Perhaps someone else into details can
pick this up and work it through to the end. (Assuming this entire email
is not entirely off the mark for some reason).
dpi_import_export ::=
import "DPI" [ dpi_import_property ] [ c_identifier = ]
function dpi_function_proto ;
| export "DPI" [ c_identifier = ] function function_identifier ;
dpi_function_proto ::=
[ signing ] function_data_type function_identifier
( list_of_dpi_function_proto_formals )
list_of_dpi_function_proto_formals ::=
[ { attribute_instance } dpi_function_proto_formal { ,
{ attribute_instance } dpi_function_proto_formal } ]
dpi_function_proto_formal ::=
dpi_input_declaration
| dpi_output_declaration
| dpi_inout_declaration
dpi_input_declaration ::=
input dpi_data_type list_of_dpi_port_identifiers
dpi_output_declaration ::=
output dpi_data_type list_of_dpi_port_identifiers
dpi_inout_declaration ::=
inout dpi_data_type list_of_dpi_port_identifiers
dpi_data_type ::=
integer_vector_type [ signing ] { packed_dimension } [ range ]
| integer_atom_type [ signing ]
| type_declaration_identifier { packed_dimension }
| non_integer_type
| struct packed [ signing ] { { struct_union_member } } {
packed_dimension }
| union packed [ signing ] { { struct_union_member } } {
packed_dimension }
| struct [ signing ] { { struct_union_member } }
| union [ signing ] { { struct_union_member } }
| enum [ integer_type [ signing ] { packed_dimension } ]
{ enum_identifier [ = constant_expression ]
{ , enum_identifier [ = constant_expression ] } }
| string
| chandle
list_of_dpi_port_identifiers ::=
port_identifier { dpi_dimension } [ = expression ]
{ , port_identifier { dpi_dimension } [ = expression ] }
dpi_dimension ::=
{ unpacked_dimension }
| [ ]
Remarks:
A. "non_integer_type" allows "time" and "realtime".
We didn't discuss those in committee (that I recall), but they
seem straightforward. Comments anyone?
B. It might be more efficient to factor dpi_data_type and data_type
separately,
making data_type a super-production of dpi_data_type. However, this
would
murk up more basic areas of the overall SV grammar. Comments?
Maybe we can just reserve this factoring for our yacc/bison files :)
C. That third-from-the-bottom "enum" production looks wild.
What's going on with that???!
D. Possible errata for SV-BC to consider:
In the "tf_input_declaration" (and output, inout, ref variants),
I think that there should be a "port_type" element right in front of
list_of_dpi_port_identifiers. If this is not necessary, it would be
interesting to hear an explanation of how things are supposed to work.
After discussion within SV-CC (to make sure I'm just not wrong-headed
here), we should forward my comment 2c and my remark D to SV-BC.
Thanks and regards,
Doug
This archive was generated by hypermail 2b28 : Thu Jul 10 2003 - 23:52:53 PDT