Hi, Input from a member of the vhdl-ams working group. Regards, John -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
attached mail follows:
Hi I tried my best to complete the survey, in a quick moment. Any things that needed adjustment, please let me know. Thank you. John Shields <John_Shields@mentor.com> wrote: Hi, AS per our discussion at the working group meeting, this is the website for SV-XC: http://www.eda-twiki.org/sv-xc and attached is the email sent to the vhdl user community on the SV-XC survey. Regards, John Shields Mentor Graphics -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Date: Wed, 04 Apr 2007 10:28:24 -0700 From: John Shields <John_Shields@mentor.com> To: 'vhdl ' <vhdl@lists.accellera.org>, vhdl-200x@eda-stds.org Subject: [Accellera:vhdl] Interoperability survey Hi, I have been working on VHDL standardization in recent years and I am also working on subcommittee of the SystemVerilog IEEE standards effort dubbed SV-XC. It's goal is to formalize mixed language interoperability between SystemVerilog, VHDL, System-C, and Verilog-AMS. The perspective of the effort is SystemVerilog and the specifications that result are aimed at the SV LRM. Nevertheless, language changes may be proposed for and brought to other language groups that benefit interoperability. There are current discussions about language enhancements to VHDL and this SV effort is orthogonal to that. It is no coincidence that both efforts are active concurrently as they represent different takes on satisfying the unmet needs of our user community. The first step in the SV effort is gathering requirements and priorities broadly. The SV-XC committee is soliciting your input on SystemVerilog Interoperability. The committee has prepared a survey in order to gather user requirements and help focus the standardization activities based on your requirements. The survey is available at: http://www.eda-stds.org/sv-xc/otherdocs/survey1.0.txt This is a simple text file. You can save it on your desktop and fill it out with your normal editor. The instructions are provided in the survey. Please send your feedback to the committee by emailing to sv-xc_ f rom _eda.org. If you like you can also send your completed survey to logie_ f rom _synopsys.com or somdipta_ f rom _ti.com, the co-chairs of SV-XC. Regards, John Shields Mentor Graphics *~~*~~*~~*~~*~~*~~*~~* Thuy Tran TN President VLSI-AMS 2270 Brown Ave, Santa Clara, CA95051 408 246 1637 (p) 408 421 6283 (c) 408 297 3482 (f) thuytrantn@vlsi-ams.com www.vlsi-ams.com *~~*~~*~~*~~*~~*~~*~~* 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. ================================================================ 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? [2] 1.1.1 SystemC <-> SystemVerilog interoperability [2] 1.1.2 VHDL <-> SystemVerilog interoperability [2] 1.1.3 AMS <-> SystemVerilog interoperability [2] 1.1.4 The digital subset inter-operating seamlessly (SV, VHDL, SystemC) [1] 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 [2] 1.2.2 VHDL <-> SystemVerilog interoperability [2] 1.2.3 AMS <-> SystemVerilog interoperability [2] 1.2.4 The digital subset inter-operating seamlessly (SV, VHDL, SystemC) [1] 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: [1] 1.3.1 strictly preserve the current definition and semantics of all languages [2] 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 [1] 1.3.4 where changes are desirable, always preserve backward compatibility [1] 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? >Absolutely if possible. ================================================================ 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 [1] 2.1.2 Communicating processes [1] 2.1.3 RTL [1] 2.1.4 Cycle-accurate level [1] 2.1.5 Other, please specify -- Objective classes: multidimentional arrays -------------------- 2.2 What kinds of connections are important across the SystemC/SystemVerilog boundary? [1] 2.2.1 Pin Level connection with simple built in types [1] 2.2.2 Pin Level connection with complex data types (such as arrays, structs) [1] 2.2.3 High level synchronization connection with interoperability of events, mailboxes, semaphores etc [1] 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. [1] 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) [1] 2.3.2 Extend DPI import to allow calling of time consuming SystemC member functions as DPI import task? [1] 2.3.3 Extend DPI export to allow calling of non time-consuming SV functions from SystemC? [1] 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) [1] 2.4.1 Extend DPI import/export functions to enable calling C++ functions (including object methods) [1] 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 -------------------- [1] 2.5 Would you like to see clear definition of scheduling semantics between SystemC and SystemVerilog [1] 2.5.1 Do you require interoperability of events between SystemVerilog and SytemC. If so which ones of the following are important. [1] 2.5.2 SystemC is notified instantly about SystemVerilog events [1] 2.5.3 SystemVerilog is notified instantly about SystemC events -------------------- [1] 2.6 Do you require interoperability of classes between SystemC/C++ and SystemVerilog [1] 2.6.1 Do you require to instantiate and use C++ classes within SystemVerilog [1] 2.6.2 Do you require to instantiate and use SystemC (sc_modules) in SystemVerilog [1] 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 ? [1] 2.7.1 Abstract, transaction-level SystemC model serves as reference model. It is embedded into a SV testbench. [1] 2.7.2 SV testbench driving RTL-level SystemC model [1] 2.7.3 SystemC testbench driving DUT written in Verilog or VHDL [1] 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 [1] 2.7.6 SystemC model is a wrapper around a model written in C. The SystemC model has an RTL interface. [1] 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 [1] 2.8.1 SystemC types such as int, sc_[big]int, [big]sc_uint, sc_lv, sc_bv to/from SystemVerilog [1] 2.8.2 Complex datatypes such as user-defined structures or arrays across the port boundary -------------------- ================================================================ 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 [3] 3.1.2 SystemVerilog Interfaces [2] 3.1.3 SystemVerilog Program Blocks [4] 3.1.5 Packages -------------------- [1] 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 [4] 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 [1] 3.4.1 Bit [1] 3.4.2 4-state logic [1] 3.4.3 Real, short real [1] 3.4.4 Time [2] 3.4.5 Dynamic data types. If so, which ones? [1] 3.4.6 Enumerations [1] 3.4.7 Arrays of bit/logic [1] 3.4.8 Arrays of other data types. If so, what data types? [2] 3.4.9 Packed Structs/Records [3] 3.4.10 Unpacked Structs/Records [4] 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? [1] 3.5.1 Bit [1] 3.5.2 4-state logic with strength [1] 3.5.3 Real, short real [1] 3.5.4 Time [1] 3.5.5 Dynamic data types [1] 3.5.6 Enumerations [1] 3.5.7 Arrays of bit/logic [2] 3.5.8 Arrays of other data types. If so what data types?-- defined real [2] 3.5.9 Packed Structs/Records [2] 3.5.10 Unpacked Structs/Records [2] 3.5.11 Signed Datatypes [4] 3.5.12 Other. Please explain .. floating point, multidimentional arrays 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? [1] 3.6.1 Bit [1] 3.6.2 4-state logic with strength [1] 3.6.3 Real [1] 3.6.4 Time [1] 3.6.5 Dynamic data types [1] 3.6.6 Enumerations [1] 3.6.7 Arrays of bit/logic [1] 3.6.8 Arrays of other data types. If so what data types? -- real [1] 3.6.9 Packed Structs/Records [1] 3.6.10 Unpacked Structs/Records [1] 3.6.11 Signed Datatypes [1] 3.6.12 Other. Please explain.. Floating point, multidimentional arrays 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 theSystemVerilog-VHDL language boundary? [1] 3.7.1 2-state [1] 3.7.2 Multiple drivers [1] 3.7.3 trireg [1] 3.7.4 bidirectional transistor networks [2] 3.7.5 Verilog strength [3] 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? [1] 3.8.1 Functions [1] 3.8.2 Tasks [1] 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.)? [1] 3.9.1 Events [1] 3.9.2 Semaphores [1] 3.9.3 Mailboxes [1] 3.9.4 Queues -------------------- [1] 3.10 How important is an integrated I/0 mechanism between VHDL and SystemVerilog? -------------------- [1] 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. [1] 3.12.1 Extend VPI to access objects from VHDL [1] 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)? -------------------- [1] 3.14 Would you like DPI extended to cover the following scenarios [1] 3.14.1 Extend DPI export to enable them to be called from VHDL-VHPI or Verilog-VPI callback functions -------------------- [1] 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: [1] 3.16.1 For enumerations and structure/record types [1] 3.16.2 For all user-defined types, where both languages require it [1] 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: [1] 3.17.1 Sharing of types declared from an inter-operable packages written in SV [1] 3.17.2 Sharing of types declared from an inter-operable package written in VHDL [1] 3.17.3 Sharing of types declared via a hierarchical reference [1] 3.17.4 Explicitly declaring(somehow) that 2 distinct types are equivalent, subject to appropriate rules -------------------- [1] 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 [2] 3.19.1 Bind SystemVerilog modules/interfaces/programs to VHDL [1] 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 [2] 4.1.1 SPICE [1] 4.1.2 VERILOG-AMS [3] 4.1.3 Others. please specify -- C/C++/Python/JAVA -------------------- 4.2 What kinds of data types would you like to see supported on nets at the SystemVerilog/Analog boundary? [2] 4.2.1 Bit [2] 4.2.2 4-state logic with strength [1] 4.2.3 Real, short real [1] 4.2.4 Time [1] 4.2.5 Dynamic data types [1] 4.2.6 Enumerations [2] 4.2.7 Arrays of bit/logic [2] 4.2.8 Arrays of other data types. If so what data types? [1] 4.2.9 Packed Structs/Records [1] 4.2.10 Unpacked Structs/Records [1] 4.2.11 Signed Datatypes [1] 4.2.11 Other. Please explain -- Floating Point;samples/hold -------------------- [1] 4.3 How important is the use of interface/modports at the SV-SPICE boundary? -------------------- [1] 4.4 Will you need parameter passing across the SystemVerilog - SPICE boundary? [1] 4.4.1 from SystemVerilog to SPICE? [1] 4.4.2 SPICE to SystemVerilog? -------------------- [1] 4.5 Would you like to instantiate SystemVerilog models in Spice and what SV port types to be allowed? -- both digital/analog [2] 4.5.1 Bit [2] 4.5.2 4-state logic with strength [1] 4.5.3 Real, short real [1] 4.5.4 Time [1] 4.5.5 Dynamic data types [1] 4.5.6 Enumerations [2] 4.5.7 Arrays of bit/logic [2] 4.5.8 Arrays of other data types. If so what data types? -- continuous characterization [1] 4.5.9 Packed Structs/Records [1] 4.5.10 Unpacked Structs/Records [1] 4.5.11 Signed Datatypes [1] 4.5.11 Other. Please explain -- ability to interface all levels -------------------- [1] 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 -------------------- [1] 4.9 How important is it to allow SV scalar data type in the connect module? -------------------- [1] 4.10 Is it important to define rules for discipline propagation (basic and detailed) through SV objects (net/variable/reg). -------------------- [1] 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 -------------------- [1] 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 -------------------- [1] 4.17 Would you like to see Configurations expanded to cover both the analog (SPICE) and digitial (SystemVerilog) domains -------------------- [1] 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. [1] 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? > The existing models, let say AMS models used HDL for all define, architecture, behavior and testbenches. They need the abilities to communicate interface in order to connect and resolve the components, in which the clock and data lines interacted that result the timing, area, and parasitics within the constraints. Modeling needs the heading documenting blocks, and documenting after each line of codes for purposes of reference, remodeling, and restructure; the use modeling allows to modify, to resolve forming the desired components; OO features, such as pop-up small frame, to show the arrays of bin data when modeling used sv, assist the clarity; the model can be transfered to other designers who may continue or modify or remodel, with a comfort level. -------------------- [1] 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? >The overall inputs and outputs as the desired designs though the underneath include interoperable sv, va, vhdl, open access, other ams open sources. Supposed the design methodology will not change; saying, conditions: design methodology for digital status quo, design for methodology for analog status quo, design methodology for AMS status quo, the interoperability of more mixed languages functions relying upon the interfaced modules that assist the intercommunication of the datas, typedefs, objects, classes, structures, and etcetera. ------------------- [1] 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? > Over time, the standardization will realize for the solutions to approach the practical situation result after the iterated experiments that reach sufficience. Exeperiments and Time will offer the answers for the disappointed idealization. A sole example to prompt the hope reveals in the case verilog extended to verilog-ams; with enough time input into working, sv may have extended to sv-ams. The interoperability, if gave the disappointed results, some time, the capability has been resulted. I hoped that the standardization will endorse. ------------------- [1] 5.4 Is there anything else on this topic that you would like to say? > Elaboration feature: the portable and scalable models may allow altering, instantiating the existing sub-modules within the module/s, for testing purposes, converting into the for-loop, or cases statements, for one instance. > Re : 3.18: On top of my head, may we use the procedure that use in mathematic zero matrix that we create the max zero matrix that can hold the max dimension; also use the for-loop programming in this detecting case; hoped that my participate could assist the large swapped with the small dimensions of arrays and vice versa. > ------------------- [1] 5.5 Can we contact you for additional information. If so please supply email address below. thuytrantn@vlsi-ams.com ------------------- Thank you for your time! Thank you for your time!Received on Thu Apr 19 09:22:20 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 19 2007 - 09:22:22 PDT