From: owner-sv-ec@eda.org on behalf of Stefen Boyd [stefen@boyd.com] Sent: Monday, September 09, 2002 12:47 PM To: sv-ec@eda.org Subject: $sv-ec Minutes of SV-EC on September 4, 2002 Thanks to Zeev Kirshenbaum and Francoise Martinolle for taking minutes. I've tried to merge theirs and my scattered notes. We covered a lot of ground, so review carefully. Thanks, Stefen SV-EC Meeting Minutes 4 September 2002 (--a---) Adam Krolnik (LSI Logic) (---a-a) Alec Stanculescu (Fintronic) (a-aaaa) Cliff Cummings (Sunburst) (-aaa--) Dave Kelf (Co-Design) (aaaaa-) David Smith (Synopsys) (-aaa-a) Dennis Brophy (ModelTech) (---aaa) Francoise Martinolle (Cadence) (aa-aa-) Heath Chambers (HMC) (aaaaaa) Karen Pieper (Synopsys) (aaa-aa) Kevin Cameron (National) (---a-a) Kurt Takara (0-in) (--a--a) Michael McNamara (Verisity) (aaaapa) Mehdi Mohtashemi (Synopsys) (-aaaaa) Neil Korpusik (Sun) (aaa---) Paul Graham (Cadence) (aapaa-) Peter Flake (Co-Design) (a-----) Roy Armoni (Intel) (aapa-a) Simon Davidmann (Co-Design) (-aaaaa) Stefen Boyd (Boyd Technology, Inc.) (aa---a) Steven Sharp (Cadence) (-aaaaa) Tom Fitzpatrick (Co-Design) (-----a) Tim Corcoran (WHDL) (-----a) Stephen Meier (Synopsys) (-----a) Arturo Salz (Synopsys) (-----a) Zeev Kirshenbaum (Verisity) (-----a) Brad Pierce (Synopsys) a => Attended p => Attended by proxy - => Missed Mehdi presented the clarification document (including further ammendments to the clarifications document), and in particular presenting conflicts that were identified between the testbench donation and SV, proposing also resolutions. In most cases, the donation was changed to adopt the SV approach/syntax/semantics. Specific issues of the committee with the clarification: * Proposal for $cast_assign() Questioned by the committee, requires more discussion (e.g. how does it relate to the static casting in SV? Can't the compiler do this automatically?). * Proposal for multi-dimensional arrays int Array[8][32] as a shorthand notation to int Array[7:0][31:0] The shorthand notation has already a meaning in Verilog (a single item, accessed by indexes 8,32). * Proposal for built-in string methods The committee pointed out that these are not consistent with the regular system task syntax in Verilog (the donation was in the spirit of following a class method syntax). * Noted that examples in clarification doc still have brackets around class declaration instead of proposed class/endclass * Proposal for use of typedef for forward referencing of classes The committee pointed out that if this is introduced in SV, it should be applied in other places as well. Cliff - typedef usage seems related to other typedef discusssions. * Mac - Noted that extern is being withdrawn, but that it's related to other discussions in process. * The differences between a class and SV's struct e.g., why can't a class be static too? In particular, in respect to possible synthesis issues. * Inheritance Some comments in the committee about different syntax origins and consistency (C++? Java?) of constructs, e.g. 'super', 'extends'. In particular, there appears to be no reason to use 'local' rather than 'private'. * Class, Object Methods: Mac: page 43: clarification needed on automatic memory management, out of scope can also cause memory to be released * Inheritance needs to be added to the donation: extends, virtual, protected and super keywords * Question TF: How many people in the room are not familiar with OO, C++? Answer: Most are * Question - Tim C. Would classes be in the general language? Would everything migrated to the general language or would unique things remain in the testbench std.? Answer: not sure. TBD * A new revised veralite proposal will be available and will contain all the proposed resolutions. * Virtual classes vs. interfaces Not clear how these relate to each other, and are they the same. Needs further discussion. * local keyword instead of private Mac: local is also used for parameters; private would be better Confusion on virtual section 9.7.7. last paragraph Tim C: question : virtual methods and SV interfaces seem to be overlapping Kevin: a class is not synthesizable. * Linked Lists Why special handling for linked list? It is fairly common to use linked list for stimuli and verification. A list is defined as a macro * fork ... join Questions regarding how this relates to the SV equivalent (process?) * Proposed event to be treated as a superset of SV trigger will turn the event on trigger and sync are a superset of -> and @ * Predefined constants (SEMAPHORE, ON, ONE_SHOT, ...) SB: is a semaphore a keyword? Arturo: No it is a predefined constant. Requires further discussion, as this might in fact introduce new keywords. Appears also in clock domain declarations: CLOCK, PSAMPLE, PHOLD, NSAMPLE etc. * Mailboxes Francoise: Why would mailbox and semaphores not be implemented as classes? Arturo: It was implemented before classes came. Is it a duplicate of SV's queues? Apparent overlap with discussions regarding channels and queues in SV. * Program blocks Entry point for testbench execution Multiple program blocks can be defined Kevin: is this different from $root? Can the port list be overlapping with interfaces? Arturo: no it is more like a module. The Vera program is instantiated with the dut. Mac: With the program keyword, donation does not blend into SV. Program block restricts testbench semantics in 1 block, and makes a program a special construct. Requires further discussion as to how a program block reconciles with a Verilog module, and why do we need that as it creates a difference between the testbench and the design parts. * static variable initialization What is the behaviour of initialization of static variables in Program block ? page 18 of SV3.0: section 5.4: sv initialization of static variables must occur before the initial block. * Scoping rules A program is just like a module clocking_domain replaces the interface keyword (name collision with SV interfaces) * vera interface (clocking_domain) issues: Curly braces "{", "}" in clocking domain declarations Predefined constants (creates reserved words?): PSAMPLE, CLOCK, etc... Ports defined in multiple clock domain: If out1 is defined in 2 clocking domains, can you do out1 = 1? what is the effect? can you do d1.out1 = 1? Skew definition: Is it too restrictive in light of Verilog 2001 negative timing checks? There's no support for a positive skew for sampling values (sampling with NSAMPLE/PSAMPLE allows only negative skew: #-). * Cycle Abstraction The simulation will require test bench execution after all signal propagation just before $monitor * Wrap-up: Alec S: Anything in the donation that will help map the testbench onto a testing equipment to test the actual silicon when it's there? Arturo: No. Some of the members expressed amazement from the flexibility of Synopsys to make all the changes in the sytnax to adapt it to SV, and that this shows Synopsys is really serious about donating this and integrating it with SV. Cliff C - Would users find this useful? Dennis - Is it a "still-born" language addition that wouldn't interest anyone (would they only want full vera)? Mac - Does it provide adequate draw for users for non-Synopsys companies to implement it? Dennis - Is this sufficient? The Sun representative indicated some of the users will not want to use the VeraLite subset since so many VERA constructs were taken out of it. Others said this is a good addition to Verilog, and a clear win to users that write testbenches in Verilog only, though probably not so useful for users of VERA/Specman. This donation will therefore help solve the problem (verification?) for the segment of the market that is not using VERA/Specman. How are the proposed vera modifications to SV syntax going to be received by the user community? This is going to be a big change for the users. A request came up to have something that can be shown to users and get their feedback/alpha, in light of the many changes done to the proposal in the last moment. A comment: More work needed to clean up the proposed language, to clarify differences between testbench parts and design parts, before it's ready to be implemented. Cliff suggested the committee voted today to accept the donation, saying "we like the idea", with full power to change and rewrite any required parts. Cliff wanted to vote on the donation immediately after the discussion however Francoise and others wanted to have the opportunity to review the clarification document before making any decisions. Cliff moved and Niel seconded that we do an email vote, to be completed by Sep 16th. -------------------- Stefen Boyd Boyd Technology, Inc. stefen@BoydTechInc.com (408)739-BOYD www.BoydTechInc.com (408)739-1402 (fax)