Logie Ramachandran wrote: > Hi Team, > > This took much longer than I expected. I have put > together the combined questionnaire making sure that > we get a consistent look and feel across the sections. > I have merged the DPI questions into the SystemC and VHDL > section. > > I have also tried to keep this as a txt file so that > it can be parsed by a script easily. > > Please review the sections and make sure that I have > captured all the feedback so far. Suggest any changes > in format/questions over email. > Might be useful to have people say whether they have an immediate need or not, e.g. at Sonics we could use C++/SystemVerilog now, but with my AMS committee hat on I would say that some of the AMS stuff is essential but not likely to be immediately useful. Also, Spice isn't any kind of real standard but has support through Verilog-AMS (which is a standard) , so I'd recommend not considering any direct Spice support and just go through Verilog-AMS for it. Kev. PS: You could set up a (closed) Yahoo! group for this and run the polls there - might be easier to manage. > Thanks > > Logie. > > > ------------------------------------------------------------------------ > > > 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? > > > > > > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Feb 5 10:27:54 2007
This archive was generated by hypermail 2.1.8 : Mon Feb 05 2007 - 10:27:56 PST