Survey Qeustionnaire: SystemVerilog interfaces to other HDL languages Purpose: The purpose of this questionnaire is to understand the importance of various topics that deal with SystemVerilog interoperabiility as it pertains to other HDL languages. We focus on three HDL languages in this survey (SystemC, VHDL and AMS). Your inputs will help the SV-XC committee focus on the important items that will have direct impact on your design methdoology. For each of the questions please replace the [] at the beginnng of the line with your importance rating. Use the following codes to make it consistent. [1] Extremely Important [2] Important [3] Not that important [4] Not required There are four sections in this questionnaire. Section 1 addresses "General" questions on interoperability of SystemVerilog. Section 2 focuses on SystemC while Section 3 focusses on VHDL interaction with SystemVerilog. Section 4 addresses AMS issues as it pertains to SystemVerilog. Thanks in advance for your help. If you would like to participate in the SV-XC committee please send email to logie@synopsys.com or somdipta@ti.com. ================================================================ Section 1: General ================================================================ 1.1 Do you see interoperability of languages as an issue that needs to be addressed. If so what kinds of interoperability issues? [] 1.1.1 SystemC <-> SystemVerilog interoperability [] 1.1.2 VHDL <-> SystemVerilog interoperability [] 1.1.3 AMS <-> SystemVerilog interoperability [] 1.1.4 All four interoperating seamlessly (AMS, VHDL, SV, SystemC) -------------------- 1.2 Which of the following needs standardization? [] 1.2.1 SystemC <-> SystemVerilog interoperability [] 1.2.2 VHDL <-> SystemVerilog interoperability [] 1.2.3 AMS <-> SystemVerilog interoperability [] 1.2.4 All four interoperating seamlessly (AMS, VHDL, SV, SystemC) ================================================================ Section 2: SystemC/C++ ================================================================ 2.1 At what levels of abstraction should a SystemC model communicate with a SystemVerilog model ? [] 2.1.1 Algorithmic or behavioral level [] 2.1.2 Communicating processes [] 2.1.3 RTL [] 2.1.4 Cycle-accurate level [] 2.1.5 Other, please specify -------------------- 2.2 What kinds of connections are important across the SystemC/SystemVerilog boundary? [] 2.2.1 Pin Level connection with simple built in types [] 2.2.2 Pin Level connection with complex data types (such as arrays, structs) [] 2.2.3 High level synchronization connection with interoperability of events, mailboxes, semaphores etc [] 2.2.4 Passing parameters across the language boundary [] 2.2.5 Hierarchically referencing external objects defined in one language from the other language. -------------------- 2.3 Would you like DPI extended in order to cover interaction with SystemC. Please provide your input on the following scenarios [] 2.3.1 Extend DPI import to allow calling of SystemC global and member functions? [] 2.3.2 Extend DPI import to allow calling of SystemC tasks? [] 2.3.3 Extend DPI export to enable SystemC tasks/threads to call SystemVerilog tasks and functions. [] 2.3.4 Extend DPI to enable SV testbench to pass high level transactions to a a SystemC model -------------------- 2.4 Would you like DPI extended in order to cover interaction with pure C++ (not SystemC) [] 2.4.1 Extend DPI import/export functions to enable calling of C++ object methods. [] 2.4.2 Make all static methods of a SystemVerilog class available as automatic export functions in DPI, so that they can be called from any C++ domain -------------------- [] 2.5 Would you like to see clear definition of scheduling semantics between SystemC and SystemVerilog [] 2.5.1 Do you require interoperability of events between SystemVerilog and SytemC. If so which ones of the following are important. [] 2.5.2 SystemC is notified instantly about events at the SystemVerilog side [] 2.5.3 SystemVerilog is notified instantly about events in the SystemC side -------------------- [] 2.6 Do you require interoperability of classes between SystemC/C++ and SystemVerilog [] 2.6.1 Do you require to instantiate and use C++ classes within SystemVerilog [] 2.6.2 Do you require to instantiate and use SystemC (sc_modules) in SystemVerilog [] 2.63 Do you require to instantiate and use SystemVerilog classes in SystemC ================================================================ Section 3: VHDL ================================================================ 3.1 What kinds of items would you like to be able to instantiate across VHDL, SystemVerilog boundary [] 3.1.1 Modules and Architectures [] 3.1.2 SystemVerilog Interfaces [] 3.1.3 SystemVerilog Program Blocks [] 3.1.5 Packages -------------------- [] 3.2 Would you like to have an integrated mechanism for configuring instantiations across the language boundary? -------------------- 3.3 What kinds of objects would you like to connect in an instantiation that crosses SystemVerilog-VHDL boundary [] 3.3.1 Parameters/generics [] 3.3.2 Ports that are nets/signals [] 3.3.3 Ports that variables [] 3.3.4 Shared/reference variables -------------------- 3.4 What kinds of data types would you like to see supported on parameters/generics at the SystemVerilog-VHDL boundary [] 3.4.1 Bit [] 3.4.2 4-state logic [] 3.4.3 Real, short real [] 3.4.4 Time [] 3.4.5 Dynamic data types. If so, which ones? [] 3.4.6 Enumerations [] 3.4.7 Arrays of bit/logic [] 3.4.8 Arrays of other data types. If so, what data types? [] 3.4.9 Packed Structs/Records [] 3.4.10 Unpacked Structs/Records [] 3.4.11 Other. Please explain. 3.4b Please list any data type mappings (e.g. VHDL std_ulogic to Verilog logic) that are particularly important -------------------- 3.5 What kinds of data types would you like to see supported on nets/signals at a language boundary? [] 3.5.1 Bit [] 3.5.2 4-state logic with strength [] 3.5.3 Real, short real [] 3.5.4 Time [] 3.5.5 Dynamic data types [] 3.5.6 Enumerations [] 3.5.7 Arrays of bit/logic [] 3.5.8 Arrays of other data types. If so what data types? [] 3.5.9 Packed Structs/Records [] 3.5.10 Unpacked Structs/Records [] 3.5.11 Signed Datatypes [] 3.5.12 Other. Please explain 3.5b Please list any data type mappings (e.g. VHDL std_ulogic to Verilog logic) that are particularly important -------------------- 3.6 What kinds of data types would you like to see supported on variables at the SystemVerilog/VHDL language boundary? [] 3.6.1 Bit [] 3.6.2 4-state logic with strength [] 3.6.3 Real [] 3.6.4 Time [] 3.6.5 Dynamic data types [] 3.6.6 Enumerations [] 3.6.7 Arrays of bit/logic [] 3.6.8 Arrays of other data types. If so what data types? [] 3.6.9 Packed Structs/Records [] 3.6.10 Unpacked Structs/Records [] 3.6.11 Signed Datatypes [] 3.6.12 Other. Please explain 3.6b Please list any data type mappings (e.g. VHDL std_ulogic to Verilog logic) that are particularly important -------------------- 3.7 What network resolution semantics would you like to preserved across the SystemVerilog-VHDL language boundary? [] 3.7.1 2-state [] 3.7.2 Multiple drivers [] 3.7.3 trireg [] 3.7.4 bidirectional transistor networks [] 3.7.5 Verilog strength [] 3.7.6 Other. Please explain. -------------------- 3.8 What kinds of behavioral code would you like to be able to call across a language boundary? [] 3.8.1 Functions [] 3.8.2 Tasks [] 3.8.3 Procedures -------------------- 3.9 What kind of integrated interprocess synchronization would you like to see in a mixed-language simulation (events, semaphores, etc.)? [] 3.9.1 Events [] 3.9.2 Semaphores [] 3.9.3 Mailboxes [] 3.9.4 Queues -------------------- [] 3.10 Would you like an integrated I/0 mechanism? -------------------- [] 3.11 Would you like to have integrated access to timing backannotation (Verilog SDF and VHDL VITAL)? Clocking blocks? -------------------- 3.12 Would you like to see VPI extended for the following reasons. [] 3.12.1 Extend VPI to access objects from VHDL [] 3.12.2 Extend VPI to incorporate access to VHPI -------------------- [] 3.13 Would you like to be able to directly reference objects that are declared in a different language (through a hierarchical reference)? -------------------- [] 3.14 Would you like DPI extended to cover the following scenarios [] 3.14.1 Extend DPI export to enable them to be called from VHDL-VHPI callback functions -------------------- [] 3.15 Would you like to see clear definition of scheduling semantics between VHDL and SystemVerilog ================================================================ Section 4: AMS ================================================================ 4.1 What kind of Analog blocks would you like to instantiate in SystemVerilog [] 4.1.1 SPICE [] 4.1.2 Others. please specify -------------------- 4.2 What kinds of data types would you like to see supported on nets at the SystemVerilog/Analog boundary? [] 4.2.1 Bit [] 4.2.2 4-state logic with strength [] 4.2.3 Real, short real [] 4.2.4 Time [] 4.2.5 Dynamic data types [] 4.2.6 Enumerations [] 4.2.7 Arrays of bit/logic [] 4.2.8 Arrays of other data types. If so what data types? [] 4.2.9 Packed Structs/Records [] 4.2.10 Unpacked Structs/Records [] 4.2.11 Signed Datatypes [] 4.2.11 Other. Please explain -------------------- [] 4.3 How important is the use of interface/modports at the SV-SPICE boundary? -------------------- [] 4.4 Will you need parameter passing across the SystemVerilog - SPICE boundary? [] 4.4.1 from SystemVerilog to SPICE? [] 4.4.2 SPICE to SystemVerilog? -------------------- [] 4.5 Would you like to instantiate SystemVerilog models in Spice? [] 4.5.1 Bit [] 4.5.2 4-state logic with strength [] 4.5.3 Real, short real [] 4.5.4 Time [] 4.5.5 Dynamic data types [] 4.5.6 Enumerations [] 4.5.7 Arrays of bit/logic [] 4.5.8 Arrays of other data types. If so what data types? [] 4.5.9 Packed Structs/Records [] 4.5.10 Unpacked Structs/Records [] 4.5.11 Signed Datatypes [] 4.5.11 Other. Please explain -------------------- [] 4.6 Would you like to be able to instantiate Program blocks and SystemVerilog interfaces in Spice models -------------------- [] 4.7 How important is extending Verilog AMS to allow usage of SV data types inside VERILOG-AMS (analog blocks) -------------------- 4.8 Would you like to see the keyword conflict resolved for the following keywords [] 4.8.1 type [] 4.8.2 logic -------------------- [] 4.9 How important is it to allow SV scalar data type in the connect module? -------------------- [] 4.10 Is it important to define rules for discipline propagation (basic and detailed) through SV objects (net/variable/reg). -------------------- [] 4.11 How important are rules for driver-receiver segregation for mixed signal net with SV data type. -------------------- [] 4.12 Would you like to see clear definition of scheduling semantics between SPICE and SystemVerilog -------------------- [] 4.13 Is it important to clarify the behavior of force/release/deposit/vpi on a mixed signal net -------------------- [] 4.14 Is it important to extend VPI to enable traversing the spice hierarchy? -------------------- [] 4.15 Would you like to see the interaction between bi-directional devices such as tran/rtran when connected to analog net/node clarified -------------------- [] 4.16 Will you use SDF annotation on a mixed signal net. Is it important to extend and define the behavior of such SDF annotation -------------------- [] 4.17 Would you like to see Configurations expanded to cover both the analog (SPICE) and digitial (SystemVerilog) domains -------------------- [] 4.18 Would you like to see SV bind be extended to enable binding of instances within SPICE sub-circuit? -------------------- [] 4.19 How important is it to define the behavior of SystemVerilog testbench with analog net? Should SystemVerilog program be enable to read/write analog net? -------------------- [] 4.20 Do you foresee using SystemVerilog assertions to check analog nets? Should SVA be extended to read values from analog nets? -------------------- [] 4.21 Is it important to extend hierarchical references in System Verilog to span SPICE nets?