The respective areas for DPI Interoperability are: I. SystemVerilog Interoperability with SystemC Using DPI II. SystemVerilog Interoperability with HDL PLI's (VPI/VHPI) III. DPI Interoperability with C++ IV.Other requirements on DPI Interoperability Questionnaire ============= I.SystemVerilog Interoperability with SystemC Using DPI 1. Do you have requirements for invoking DPI functions/tasks from SystemC? If the answer is yes, please provide inputs for the following questions: A. Do you require invoking SystemC functions as DPI import functions/tasks? What is the typical functionality that you want to achieve in these functions. B. From within the SystemC portions of the design do you require calling SystemVerilog DPI export functions? C. Do you require calling SystemVerilog export tasks consuming time from SystemC threads. II. SystemVerilog Interoperability with HDL PLI's (VPI/VHPI) 1. Do you foresee a requirement for calling DPI export functions from Verilog-VPI or VHDL-VHPI callbacks? If the answer is yes, please provide inputs for the following questions: A. What is the nature of functionality you expect to achieve through such calls? B. What are the callbacks from which you want to make a call to DPI export functions? Are these object callbacks, or simulation phase callbacks (which ones)? III. DPI Interoperability with C++ 1. Interoperability for DPI import functions/tasks A. Does the current use model of allowing execution of DPI import functions defined as C functions in C++ suffice your requirements? Namely, a C function will have to be enclosed inside extern 'C' { } B. Any other requirements you have on DPI Import tasks/functions? 2. Interoperability for DPI export functions/tasks A. Is there a requirement to declare a static method of an SV class as an export function? IV. Other Requirements on DPI Interoperability Please do provide inputs on any aspects that you consider important for DPI interoperability which have not been covered above. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jan 10 08:17:02 2007
This archive was generated by hypermail 2.1.8 : Wed Jan 10 2007 - 08:17:02 PST