RE: [sv-cc] fork join VPI access

Francoise, in discussing 27.5 (the Mantis item is 447 rather than 441), 
you say that "values of the property vpiAccessType that are applicable 
to a vpiInterfaceTfDecl object are vpiForkJoinAcc, vpiExternAcc, 
vpiDPIImportAcc, vpiDPIExternAcc."  Help me understand this.  I thought 
that the interface tf decl was a way to refer to the function 
prototypes that occurred in interfaces and modports.  If so, how can 
one of these be declared as a DPI import or export function?  Wouldn't 
that declaration go on the actual task or function declaration, rather 
than on the prototype?

Regards, 
Jim

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd 
Chelmsford, MA 01824-4179 
"We all work with partial information." 
---------------------------------------------------------- 
  
 

] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
] Behalf Of francoise martinolle
] Sent: Tuesday, March 21, 2006 11: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.
] 
]  
]  
]