Logie, Here is another question missing from the SC-SV section. This is based on Ulli's first comments on SC-SV. Maybe this will be section 2.8: 2.8 What kind of problems did you encounter so far when connecting SystemC with SystemVerilog? [] 2.8.1 Converting datatypes int, sc_[big]int, [big]sc_uint, sc_lv, sc_bv to/from SystemVerilog [] 2.8.2 Converting complex datatypes such as user-defined structures or arrays [] 2.8.3 Scheduling semantics were not as expected, e.g. value changes came too late or processes were executed too late [] 2.8.4 Calling blocking (=consumes simulation time) SystemC methods from Verilog did not work as expected or was difficult to do [] 2.8.5 Calling blocking (=consumes simulation time) SystemVerilog tasks from SystemC did not work as expected or was difficult to do [] 2.8.6 Differences in timescale (time resolution / time units) -Arnab -----Original Message----- From: Ulrich Holtmann [mailto:Ulrich.Holtmann@synopsys.com] Sent: Tuesday, February 06, 2007 2:42 AM To: Logie Ramachandran Cc: Saha, Arnab; Shields, John; mckinley@cadence.com; akohli@cadence.com; Roy, Somdipta Basu; sv-xc@eda.org Subject: Re: Survey Questionnaire: Draft version Hi Logie, overall feedback: the questionaere is easy to read and the style of questions is homogenous, so this looks good. Below is some detailed feedback regarding the SystemC section. Ulli Section 2.3, DPI<->SC I think question 2.3.1 should be relocated to 2.4. If a function is not part of a SC module or interface class, then what connects it to SC? Let's say "calling some C++ function" and move it into part 2.4 instead. It is important to distinguish calling a time-consuming task/member function versus one that does not consume time. I feel this distinction should be clearer. Below is a proposal to modify the questions. I tried merging Amit's and your questions together. 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 non-time consuming SystemC member functions as DPI import functions? Note: "SystemC member function" means a member function from a SystemC module class or abstract interface class. [] 2.3.2 Extend DPI import to allow calling of time consuming SystemC member functions as DPI import task? [] 2.3.3 Extend DPI export to allow calling of non-time consuming SV functions from SystemC? [] 2.3.4 Extend DPI export to allow calling of time consuming SV task from a SystemC thread? Section 2.4, DPI<->C++ [] 2.4.x Extend DPI import/export functions to enable calling C++ functions Section 2.5, scheduling semantics I fear that the term "instantly" is too unclear. Section 2, SV-SC: The use models disappeared. Please re-insert as 2.7, below is a proposal with the same style and format. 2.7 What is the importance of different use models for designs containing both SystemVerilog and SystemC ? [] 2.7.1 Abstract, transaction-level SystemC model serves as reference model. It is embedded into a SV testbench. [] 2.7.2 SV testbench driving RTL-level SystemC model [] 2.7.3 SystemC testbench driving DUT written in Verilog or VHDL [] 2.7.4 SystemC models are behavioral synthesis models, embedded into SV testbench [] 2.7.5 SystemC models are at RT level and used together with other RTL models written in SV, Verilog or VHDL [] 2.7.6 SystemC model is a wrapper around some model written in C. The SystemC model has an RTL interface [] 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 Section 2, TLM Rob Slaters suggestion to cover TLM is missing. I think that his question overlaps somehow with SV/SC use models and DPI, but asking for the importance of a smooth, native support of SC TLM models stands in its own rights. Here a proposal for the question: Section 2.8, Transaction-Level Modeling (TLM) [] 2.8.1 Do you require to directly instantiate a SystemC transaction-level model within SV? Perhaps Rob can refine it :-) 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. > >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 Wed Feb 7 07:51:16 2007
This archive was generated by hypermail 2.1.8 : Wed Feb 07 2007 - 07:51:18 PST