RE: [sv-cc] vpiHandle on DPI method port proposal

In that case open arrays are infracting this rule, but I understand that
multiplying such cases makes direct programming interface more complicated.
Thanks, for all of You for opinion about this idea.
 
Regards,
Radek

  _____

From: Amit Kohli [mailto:akohli@cadence.com]
Sent: Wednesday, October 05, 2011 2:26 PM
To: Radoslaw Nawrot; 'Andrzej Litwiniuk'; Jim Vellenga; sv-cc@eda.org
Subject: RE: [sv-cc] vpiHandle on DPI method port proposal

I do not think it is a good idea to pass vpiHandles from DPI import
functions. In my opinion, the intent of a direct programming interface
between SV and C is lost if we pass handles for objects to the called import
function.

a. If the user does want to access the arguments as VPI handles then
VPI provides user defined system tasks and system functions for invoking PLI
applications

b. If the user wants to use the VPI interface from within a called DPI
import function, then this can be achieved by declaring the function context

By introducing creation of VPI handles inside of a DPI import function the
simplicity of a direct interface is lost.

I want to understand the functionality that will be achieved by the proposal
below, which is not available today.

Regards,

--amit

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Radoslaw
Nawrot
Sent: Wednesday, October 05, 2011 12:27 PM
To: 'Andrzej Litwiniuk'; Jim Vellenga; sv-cc@eda.org
Subject: RE: [sv-cc] vpiHandle on DPI method port proposal

Andrzej ,yes, that was on my mind when I wrote that proposal. I understand
that defining new type isn't good idea, but a new keyword (only input, only
on imported DPI-C).

Jim, if I pass "1" on getInfo I will receive vpiConstant. It should work
similar to vpi_handle_by_name so all errors should we check by user : if (
vpi_chk_error( &SInfo ) )

Sorry for let anwser, it case by time difference,

Regards,

Radek Nawrot

  _____

From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
Sent: Tuesday, October 04, 2011 8:32 PM
To: Jim Vellenga; Andrzej Litwiniuk; Radoslaw Nawrot; sv-cc@eda.org
Subject: RE: [sv-cc] vpiHandle on DPI method port proposal

My guess is that Radek's proposal was that SV compiler would create a handle
for the actual argument (that is, would generate the code to do this) and
pass that handle in lieu of the actual argument. So for the call getInfo(i);
the function would get the handle created for i.

Regards,

Andrzej I. Litwiniuk

From: Jim Vellenga [mailto:vellenga@cadence.com]
Sent: Tuesday, October 04, 2011 1:26 PM
To: Andrzej Litwiniuk; Radoslaw Nawrot; sv-cc@eda.org
Subject: RE: [sv-cc] vpiHandle on DPI method port proposal

Radoslaw, while I'm puzzled by the specific example (there is no guarantee,
for example, that "1" would be a legitimate handle value for any vendor), I
will note that in vpi_user.h, vpiHandle is a typedef for PLI_UINT32, which
is in turn a typedef for "unsigned int". One can certainly pass an "int" as
an argument to a DPI-C function, so I'm puzzled as to why there needs to be
another type for passing the same value.

Regards,

Jim Vellenga

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Andrzej
Litwiniuk
Sent: Tuesday, 4 Oct 2011 12:23 PM
To: Radoslaw Nawrot; sv-cc@eda.org
Subject: RE: [sv-cc] vpiHandle on DPI method port proposal

I don't think this is a good idea.

First, "vHandle" is not defined in SV. Was "vHandle" a typo that actually
should read "vpiHandle" ?

In either case it's not defined in the language. Do you want it to be a new
keyword? Otherwise the name could be redefined by the user.

If your intent was to introduce a new primitive type to SV then could it be
used in another context?

What would be the rules/restrictions for its use? Type-matching rules? Etc.

Then, the arguments' type used to specify what could be passed as an actual
argument rather than what is intended to be used on the other side of the
interface.

Regards,

Andrzej

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Radoslaw
Nawrot
Sent: Tuesday, October 04, 2011 11:24 AM
To: sv-cc@eda.org
Subject: [sv-cc] vpiHandle on DPI method port proposal

Hi All,

I'd like to propose constructon that will imporve integration between DPI
and VPI. Many project uses vpi methods inside imported DPI function/tasks. I
think it would be nice feature to let user pass signal on SV side and have
vpiHandle to this signal on DPI side.

In example:

SV :

module top;
import "DPI-C" context task getInfo(vHandle h);
int i=1;
initial #1 getInfo(i);
endmodule

Cpp:

#include <iostream>
#include <fstream>
#include <svdpi.h>
#include "vpi_user.h"
#include "veriuser.h"

std::ofstream file("results.txt",std::ios::out | std::ios::app );
std::ofstream err_log("results_err.txt",std::ios::out | std::ios::app );

extern "C" void getInfo(vpiHandle hnd) {
  s_vpi_error_info SInfo;
         if ( vpi_chk_error( &SInfo ) )
           err_log<<SInfo.message <<std::endl;
  file <<"Type := "<< vpi_get_str(vpiType, hnd);
  file<<std::endl;
  file <<"Name := "<< vpi_get_str(vpiName, hnd);
  file<<std::endl;

}

Any type can be passed on the same DPI context method. User can decide what
to do with signal using information from vpiHandle and/or other arguments
from task/function port (value or information from open arrays handle)

Advantages:

    - The same method can be reused with different types

   - User can simply use VPI method to signal passed directly to foreign
language layer

Disadvantages:

    - New type is needed (or some special keyword on port) because this pass
is not type dependent

Plase note that this affect only context methods and vpi_chk_error should
be check at first on method call

Thanks,

Radek Nawrot

Radoslaw.Nawrot@aldec.com.pl

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.