Feedback from Andreas Michael Thanks Logie. ________________________________ From: Schoch, Andreas Michael Sent: Thursday, March 15, 2007 12:50 PM To: Roy, Somdipta Basu Subject: Re: SystemVerilog Interoperability survey Hello Somdipta Roy, attached my modied survey file. With best regards, Andreas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Survey Questionnaire: SystemVerilog interoperability with other HDL languages ============================================================================= Purpose: The purpose of this questionnaire is to understand the importance of various topics that deal with SystemVerilog interoperability 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 methodology. We will do a comprehensive technical analysis, but your requirements and their priority to you will help us. It will allow us make better tradeoffs on usability and phase the development of the standards effectively. You are encouraged to elaborate on your answer to any question or add additional feedback not specifically requested. For each of the questions please replace the [] at the beginning 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. The final Section provides a few open ended questions that will help capture any other feedback. Please send your feedback to the committee at sv-xc@eda.org. You can also send email directly to logie@synopsys.com or somdipta@ti.com We would appreciate receiving your feedback within 2 weeks (Mar 15, 2007). However if you need additional time, please let us know. Thanks in advance for your help. If you would like to join the committee and participate in the SV-XC committee deliberations please review the instructions at http://www.eda-twiki.org/sv-xc. ================================================================3 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.1 SystemC <-> SystemVerilog interoperability [1] 1.1.2 VHDL <-> SystemVerilog interoperability [1] 1.1.3 AMS <-> SystemVerilog interoperability [2] 1.1.4 The digital subset inter-operating seamlessly (SV, VHDL, SystemC) [3] 1.1.5 All four interoperating seamlessly (AMS, VHDL, SV, SystemC) -------------------- 1.2 Which of the following needs standardization? [2] 1.2.1 SystemC <-> SystemVerilog interoperability [1] 1.2.2 VHDL <-> SystemVerilog interoperability [1] 1.2.3 AMS <-> SystemVerilog interoperability [3] 1.2.4 The digital subset inter-operating seamlessly (SV, VHDL, SystemC) [2] 1.2.4 All four interoperating seamlessly (AMS, VHDL, SV, SystemC) -------------------- 1.3 Some aspects of interoperability may be specified by providing a definition of expected behavior while others may require one or more of the base languages to add new features, change simulation semantics, or even change in a manner that is not backward compatible. As guidelines, please rank the following approaches: [4] 1.3.1 strictly preserve the current definition and semantics of all languages [4] 1.3.2 only make changes to SV language as needed [2] 1.3.3 propose interoperability features contingent upon changes to non SV languages [2] 1.3.4 where changes are desirable, always preserve backward compatibility [2] 1.3.5 guarantee that a model behaves the same in a mixed language environment as they do in a single language environment -------------------- 1.4 In the context of interoperability, is it important to have the capability to cosimulate multipe simulators (supporting different languages) from different vendors? [3] ================================================================ Section 2: SystemC/C++ ================================================================ 2.1 At what levels of abstraction should a SystemC model communicate with a SystemVerilog model? Rate your interest for each of the following interoperability paradigms [1] 2.1.1 Algorithmic or behavioral level [2] 2.1.2 Communicating processes [3] 2.1.3 RTL [1] 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.2.1 Pin Level connection with simple built in types [2] 2.2.2 Pin Level connection with complex data types (such as arrays, structs) [2] 2.2.3 High level synchronization connection with interoperability of events, mailboxes, semaphores etc [2] 2.2.4 Passing parameters across the language boundary [1] 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 the level of importance that you would attach to the following requirements. [3] 2.3.1 Extend DPI import to allow calling of non time-consuming SystemC member functions as DPI import functions? (Note: SystemC member function implies a member function from a SystemC module class or abstract interface class) [3] 2.3.2 Extend DPI import to allow calling of time consuming SystemC member functions as DPI import task? [4] 2.3.3 Extend DPI export to allow calling of non time-consuming SV functions from SystemC? [4] 2.3.4 Extend DPI to enable SV testbench to pass high level transactions to a SystemC model -------------------- 2.4 Would you like DPI extended in order to cover interaction with pure C++ (not SystemC) [3] 2.4.1 Extend DPI import/export functions to enable calling C++ functions (including object methods) [3] 2.4.2 Allow static methods of a SystemVerilog class to be declared as export functions in DPI, so that they can be called from any C++ domain -------------------- [3] 2.5 Would you like to see clear definition of scheduling semantics between SystemC and SystemVerilog [3] 2.5.1 Do you require interoperability of events between SystemVerilog and SytemC. If so which ones of the following are important. [3] 2.5.2 SystemC is notified instantly about SystemVerilog events [3] 2.5.3 SystemVerilog is notified instantly about SystemC events -------------------- [3] 2.6 Do you require interoperability of classes between SystemC/C++ and SystemVerilog [3] 2.6.1 Do you require to instantiate and use C++ classes within SystemVerilog [3] 2.6.2 Do you require to instantiate and use SystemC (sc_modules) in SystemVerilog [3] 2.63 Do you require to instantiate and use SystemVerilog classes in SystemC -------------------- 2.7 What is the importance of different use models for designs containing both SystemVerilog and SystemC ? [3] 2.7.1 Abstract, transaction-level SystemC model serves as reference model. It is embedded into a SV testbench. [4] 2.7.2 SV testbench driving RTL-level SystemC model [1] 2.7.3 SystemC testbench driving DUT written in Verilog or VHDL [2] 2.7.4 SystemC models are behavioral synthesis models, embedded into SV testbench [1] 2.7.5 SystemC models are at RT level and used together with other RTL models written in SV, Verilog or VHDL [4] 2.7.6 SystemC model is a wrapper around a model written in C. The SystemC model has an RTL interface. [4] 2.7.7 SystemC model is a wrapper around some model written in C. The SystemC model has an TL interface, is driven by function calls and is cycle accurate -------------------- 2.8 Please list any data type mappings between SystemVerilog and SystemC that are particularly important [2] 2.8.1 SystemC types such as int, sc_[big]int, [big]sc_uint, sc_lv, sc_bv to/from SystemVerilog real [2] 2.8.2 Complex datatypes such as user-defined structures or arrays across the port boundary real, integer, enumeration types, -------------------- ================================================================ Section 3: VHDL ================================================================ 3.1 What kinds of items would you like to be able to instantiate across VHDL, SystemVerilog boundary [1] 3.1.1 Modules and Architectures [1] 3.1.2 SystemVerilog Interfaces [3] 3.1.3 SystemVerilog Program Blocks [1] 3.1.5 Packages -------------------- [3] 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 [1] 3.3.1 Parameters/generics [1] 3.3.2 Ports that are nets/signals [2] 3.3.3 Ports that variables [3] 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 [2] 3.4.1 Bit [1] 3.4.2 4-state logic [1] 3.4.3 Real, short real [3] 3.4.4 Time [1] 3.4.5 Dynamic data types. If so, which ones? pointers, dynamic arrays [1] 3.4.6 Enumerations [2] 3.4.7 Arrays of bit/logic [1] 3.4.8 Arrays of other data types. If so, what data types? integer real, even 2D and 3D arrays [3] 3.4.9 Packed Structs/Records [3] 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? [2] 3.5.1 Bit [1] 3.5.2 4-state logic with strength [1] 3.5.3 Real, short real [3] 3.5.4 Time [1] 3.5.5 Dynamic data types pointers, dynamic arrays [1] 3.5.6 Enumerations [2] 3.5.7 Arrays of bit/logic [1] 3.5.8 Arrays of other data types. If so what data types? integer real, even 2D and 3D arrays [3] 3.5.9 Packed Structs/Records [3] 3.5.10 Unpacked Structs/Records [3] 3.5.11 Signed Datatypes [1] 3.5.12 Other. resolution functions for VHDL and SV data connects !!! 3.5b Please list any data type mappings (e.g. VHDL std_ulogic to Verilog logic) that are particularly important real or analog type, types to drive with different strength, like in Verilog to resolve different sources -------------------- 3.6 What kinds of data types would you like to see supported on "variables" at the SystemVerilog/VHDL language boundary? [2] 3.6.1 Bit [1] 3.6.2 4-state logic with strength [1] 3.6.3 Real [2] 3.6.4 Time [1] 3.6.5 Dynamic data types pointers, dynamic arrays [1] 3.6.6 Enumerations [2] 3.6.7 Arrays of bit/logic [1] 3.6.8 Arrays of other data types. If so what data types? integer real, even 2D and 3D arrays [3] 3.6.9 Packed Structs/Records [3] 3.6.10 Unpacked Structs/Records [3] 3.6.11 Signed Datatypes [1] 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 be preserved across the SystemVerilog-VHDL language boundary? [2] 3.7.1 2-state [2] 3.7.2 Multiple drivers [1] 3.7.3 trireg [2] 3.7.4 bidirectional transistor networks [1] 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] 3.8.1 Functions [3] 3.8.2 Tasks [3] 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.)? [2] 3.9.1 Events [3] 3.9.2 Semaphores [3] 3.9.3 Mailboxes [3] 3.9.4 Queues -------------------- [2] 3.10 How important is an integrated I/0 mechanism between VHDL and SystemVerilog? -------------------- [4] 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. [4] 3.12.1 Extend VPI to access objects from VHDL [4] 3.12.2 Extend VPI to incorporate access to VHPI -------------------- [1] 3.13 Would you like to be able to directly reference objects that are declared in a different language (through a hierarchical reference)? -------------------- [4] 3.14 Would you like DPI extended to cover the following scenarios [4] 3.14.1 Extend DPI export to enable them to be called from VHDL-VHPI or Verilog-VPI callback functions -------------------- [2] 3.15 Would you like to see clear definition of scheduling semantics between VHDL and SystemVerilog -------------------- 3.16 Both VHDL and SV support strong typing and type safety for user-defined data types such as enumerations, structures,records, unions, and classes. This guarantees that erroneous operations and illegal values for the type do not occur in objects unless specifically intended, e.g., by casting. How important is it to provide mechanisms to preserve type safety: [3] 3.16.1 For enumerations and structure/record types [3] 3.16.2 For all user-defined types, where both languages require it [3] 3.16.3 For all data types that do not have a one-to-one compatible type between the languages -------------------- 3.17 There are various mechanisms that could support type safety, where required. Please indicate which you would like to see: [2] 3.17.1 Sharing of types declared from an inter-operable packages written in SV [3] 3.17.2 Sharing of types declared from an inter-operable package written in VHDL [3] 3.17.3 Sharing of types declared via a hierarchical reference [2] 3.17.4 Explicitly declaring(somehow) that 2 distinct types are equivalent, subject to appropriate rules -------------------- [3] 3.18 There are some kinds of objects that could have no equivalent in the other language, e.g, a multidimensional array in VHDL or a SV class. Is there a need for a mechanism to transparently pass an object of such a kind as a parameter or a port? For example, is there a need to pass a class from SV through a VHDL instance to another SV child instance? -------------------- 3.19 Would you like to extend SystemVerilog bind to work across the SystemVerilog - VHDL language boundary [3] 3.19.1 Bind SystemVerilog modules/interfaces/programs to VHDL [4] 3.19.2 Bind VHDL entities/architecture to SystemVerilog modules/ ================================================================ Section 4: AMS ================================================================ 4.1 What kind of Analog design unit would you like to instantiate in SystemVerilog [1] 4.1.1 SPICE [1] 4.1.2 VERILOG-AMS [2] 4.1.3 Others. please specify : VERILOG-A -------------------- 4.2 What kinds of data types would you like to see supported on nets at the SystemVerilog/Analog boundary? [1] 4.2.1 Bit [1] 4.2.2 4-state logic with strength [1] 4.2.3 Real, short real [2] 4.2.4 Time [1] 4.2.5 Dynamic data types [2] 4.2.6 Enumerations [2] 4.2.7 Arrays of bit/logic [1] 4.2.8 Arrays of other data types. If so what data types? Arrays {of Arrays} of real or integer [2] 4.2.9 Packed Structs/Records [2] 4.2.10 Unpacked Structs/Records [3] 4.2.11 Signed Datatypes [ ] 4.2.11 Other. Please explain -------------------- [3] 4.3 How important is the use of interface/modports at the SV-SPICE boundary? -------------------- [3] 4.4 Will you need parameter passing across the SystemVerilog - SPICE boundary? [3] 4.4.1 from SystemVerilog to SPICE? [3] 4.4.2 SPICE to SystemVerilog? -------------------- [4] 4.5 Would you like to instantiate SystemVerilog models in Spice and what SV port types to be allowed? [4] 4.5.1 Bit [4] 4.5.2 4-state logic with strength [4] 4.5.3 Real, short real [4] 4.5.4 Time [4] 4.5.5 Dynamic data types [4] 4.5.6 Enumerations [4] 4.5.7 Arrays of bit/logic [4] 4.5.8 Arrays of other data types. If so what data types? [4] 4.5.9 Packed Structs/Records [4] 4.5.10 Unpacked Structs/Records [4] 4.5.11 Signed Datatypes [4] 4.5.11 Other. Please explain -------------------- [4] 4.6 Would you like to be able to instantiate Program blocks and SystemVerilog interfaces in Spice models -------------------- [1] 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 [1] 4.8.1 type [1] 4.8.2 logic -------------------- [2] 4.9 How important is it to allow SV scalar data type in the connect module? -------------------- [3] 4.10 Is it important to define rules for discipline propagation (basic and detailed) through SV objects (net/variable/reg). -------------------- [3] 4.11 How important are rules for driver-receiver segregation for mixed signal net with SV data type. -------------------- [1] 4.12 Would you like to see clear definition of scheduling semantics between SPICE or (Verilog-AMS) and SystemVerilog -------------------- [1] 4.13 Is it important to clarify the behavior of force/release/deposit/vpi on a mixed signal net -------------------- [4] 4.14 Is it important to extend VPI to enable traversing the spice hierarchy? -------------------- [1] 4.15 Would you like to see the interaction between bi-directional devices such as tran/rtran when connected to analog net/node clarified -------------------- [1] 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] 4.17 Would you like to see Configurations expanded to cover both the analog (SPICE) and digitial (SystemVerilog) domains -------------------- [4] 4.18 Would you like to see SV bind be extended to enable binding of instances within SPICE sub-circuit? -------------------- [1] 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? -------------------- [1] 4.20 Do you foresee using SystemVerilog assertions to check analog nets? Should SVA be extended to read values from analog nets? -------------------- [1] 4.21 Is it important to extend hierarchical references in System Verilog to span SPICE nets? ================================================================ Section 5: Misc ================================================================ The previous questions are feature oriented. They may not express all your requirements and they may not allow you to explain what use models you envision for developing design and verification models that lead to your need for mixed language interoperability. The following questions suggest ways to complete your feedback. Provide answers if appropriate to express your needs. [] 5.1 What levels of abstraction and role do your existing models have for each HDL language that you use? How do they need to work together today? How do you anticipate this use model changing over time? Analog models are written in different abstraction levels and for this reason in different 'languages'. To check its quality and to adapt the simulation speed the models should be exchangeable. At the moment the analog models are written in VHDL, Verilog, Verilog-AMS, spectre and spice netlists, whereby the digital design is written in Verilog. -------------------- [] 5.2 At a high level, what do you expect to be able to do with more mixed language interoperability that you are currently able to do today? How will it change your design methodology over time? If all aspects on AMS, testbench and maybe the digital core could be integrated one language, the verification would be much easier and reuse of component would be much higer ------------------- [] 5.3 While one can idealize how completely and seamlessly they would like everything to inter-operate, not everything is practical. At some level, the alternative is enhancing one particular language to meet a need, or changing to a different language. Are there some aspects of interoperability that you believe are not appropriate for standardization? Why? ------------------- [] 5.4 Is there anything else on this topic that you would like to say? ------------------- [] 5.5 Can we contact you for additional information. If so please supply email address below. amschoch @ti.com ------------------- Thank you for your time! Thank you for your time!Received on Tue Mar 20 21:51:40 2007
This archive was generated by hypermail 2.1.8 : Tue Mar 20 2007 - 21:51:44 PDT