Understood. Thanks.
From: Radoslaw Nawrot [mailto:Radoslaw.Nawrot@aldec.com.pl]
Sent: Wednesday, 5 Oct 2011 2:57 AM
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<mailto:Radoslaw.Nawrot@aldec.com.pl>
-- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Oct 5 05:10:48 2011
This archive was generated by hypermail 2.1.8 : Wed Oct 05 2011 - 05:10:59 PDT