RE: [sv-cc] fork join VPI access

Francoise,
 
It looks like you located some real issues.
You might as well sharpen up your Mantis skills :)
 
Recall, in the really old days, we used to call DPI import tf's "extern
tf's".
That was kind of similar to C "extern" function declarations.
Eventually we decided to rename those as "import", in order to create
a strong duality with "export". 
 
Maybe this can shed some light on the existence of "extern" strings
in those VPI definitions.
 
Regards,
Doug


________________________________

	From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf
Of francoise martinolle
	Sent: Tuesday, March 21, 2006 8:34 PM
	To: 'SV-CC'
	Subject: [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.