RE: [sv-cc] fork join VPI access

Jim,

Yes, you are right and this is exactly the conclusion I am getting to
further down
in the email when I also note that vpiAccessType can also occur
for a task or a function and in that later case it would be able to
return the values vpiDPIImportAcc or vpiDPIExternAcc but not for an
interface tf decl.

So vpiForkJoinAcc and vpiExternAcc can be returned for a interface tf decl
vpiExternAcc , vpiDPIImportAcc and vpiDPIExternAcc can be returned for a
task/function
Francoise
    '

-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Jim
Vellenga
Sent: Thursday, March 23, 2006 11:33 AM
To: Francoise Martinolle
Cc: sv-cc@eda.org
Subject: 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.
] 
]  
]  
]