[sv-cc] fork join VPI access

I was looking at the fork join VPI access and I found several issues.
I am sending this email to communicate the issues and open up discussion for
potential solutions.
I can enter mantis items for those issues once we have recognized that there
are indeed problems.
 
 
First of all, let's look at the diagram 27.9 (scope diagram which contain
vpiFork and vpiNamedFork).
I do not see any way to find out the kind of fork join flavor for a vpiFork
or vpiNamedFork handle.

Indeed an enumerated property which would identifiy which kind of forkjoin
is missing. I would propose a 

property named vpiForkJoinType returning the following values:

- vpiForkJoinAny  (new in SV)

- vpiForkJoinNone (new in SV)

- vpiForkJoin  (normal Verilog 2001 behaviour)

This property needs to appear on diagram: 27.9 (scope diagram) under vpiFork
and vpiNamedFork. 

We may need to create an unamed class for vpiFork

and vpiNamedFork in order to attribute it with the property vpiForkJoinType.

 

Let's look at diagram 27.5 (interface tf decl)

Notes 1 and 2 of diagram 27.5 (interface tf decl) were modified by mantis
441.

These notes talk about vpiForkJoin and vpiExtern being values of the
property vpiAccessType but the 

values of the property vpiAccessType that are applicable to a
vpiInterfaceTfDecl object are 

vpiForkJoinAcc, vpiExternAcc, vpiDPIImportAcc, vpiDPIExternAcc.

Let's look at diagram 27.26 (task function decl)

Investigating further, I also found that vpiAccessType was available for a
handle of type vpiTask 

or vpiFunction (diagram 27.26). However there are 3 more boolean properties
defined for a

task or function: vpiExtern, vpiDPIImport vpiDPIExtern. They seem to be
redundant with the 

enumerated values of the property vpiAccessType: vpiExternAcc,
vpiDPIExternAcc, vpiDPIImportAcc. 

When defining vpiAccessType, did we fail to remove these?

The boolean property vpiExtern also appears on the constraint diagram
(27.23) and denotes 

an external declared constraint.

I think that the vpiDPIExternAcc or vpiDPIExtern is supposed to represent a
SV function or

 task which is exported to DPI and would represent the following task
declaration:

export "DPI" task my_sv_task; (similar for import)

If that is true, vpiDPIExternAcc should be changed to vpiDPIExportAcc

In the sv_vpi_user.h file, I found the definition of vpiAccessType and its
enumerated values 

and I did not find the properties vpiExtern, vpiDPIImport or vpiDPIExtern.

vpiAccessType:

#define vpiForkJoinAcc 1

#define vpiExternAcc 2

#define vpiDPIExternAcc 3

#define vpiDPIImportAcc 4

I asked myself if the enumaration values were correct because they cannot
represent multiple values.

EX: we could have a DPI exported task be defined as extern forkjoin.

The value of vpiDPIExternAcc ' 3 'does not allow to have the DPI extern task
to also be defined as 

vpiExternAcc or vpiForkJoinAcc. 

Such a task would be declared as:

extern forkjoin DPI export tf; (Only tasks can be declared as forkjoin).

I also noticed that the BNF (see below) does not allow it either.

So I think that probably the answer to my question is that you cannot
combine the DPI export and extern forjoin 

declaration in an interface. 

Even though I think you can have an extern forkjoin interface tf decl which
refers to a task declared as export DPI in 

the module from which the task is exported to the interface. This requires
to have 2 declarations: one in the 

interface (extern forkjoin task mytask)

and one in the module which exports the task (extern DPI export mytask).

Which makes me believe that the property values vpiDPIExportAcc,
vpiDPIImportAcc cannot be 

returned for an interface tf decl and 

can only be returned for a vpiTask or vpiFunction.

Similarly vpiForkJoin can only be returned for a vpiInterfaceTfDecl. So if
that is correct, the value ' 3' 

assigned to vpiDPIExternAcc is fine.

My conclusion is also supported by the BNF :

A.1.6 Interface items

interface_or_generate_item ::=

{ attribute_instance } module_common_item

| { attribute_instance } modport_declaration { attribute_instance } 

| extern_tf_declaration

extern_tf_declaration ::=

extern method_prototype ;

| extern forkjoin task_prototype ;

 

 

dpi_import_export ::=

import dpi_spec_string [ dpi_function_import_property ] [ c_identifier = ]
dpi_function_proto ;

| import dpi_spec_string [ dpi_task_import_property ] [ c_identifier = ]

dpi_task_proto ;

| export dpi_spec_string [ c_identifier = ] function function_identifier 

| ; export dpi_spec_string [ c_identifier = ] task task_identifier ;

dpi_spec_string ::= "DPI-C" | "DPI"

dpi_function_import_property ::= context | pure dpi_task_import_property ::=
context

dpi_function_proto8,9 ::= function_prototype

dpi_task_proto9 ::= task_prototype

 

 

Here is a summary of the issues:

1) Access to the type of fork is missing: vpiForkJoin, vpiForkJoinNone and
vpiForkJoinAny 

=> add a vpi property vpiForkJoinType returning either one of the values:

vpiForkJoin, vpiForkJoinNone, vpiForkJoinAny.

2)Does vpiDPIExternAcc represent an export DPI task/function?

=> if yes, change vpiDPIExternAcc to vpiDPIExportAcc

3) Why do we have several properties? int vpiAccessType, bool vpiExtern,
bool vpiDPIExtern, bool vpiDPIImport

=> eliminate redundant properties if necessary.

4) Inconsistency between diagrams and header file (vpiForkJoin instead of
vpiForkJoinAccess, 

vpiDPIImport instead of vpiDPIImportAcc, etc...)

=> consolidate.