SV-EC Errata Meeting Minutes Monday 25 October 2004 11:00 am. to 1:00pm [Distribued, for approval at next sv-ec errata meeting] Attendees: ---------- (AA-A) Arturo Salz (AAAA) Brad Pierce (-AAA) Cliff Cummings (A-AA) Dave Rich (A---) David Smith (--a-) Don Mills (A---) Dennis Brophy (AAA-) Eugene Zhang (AAAA) Francoise Martinolle (A-A-) Karen Pieper (AAAA) Mehdi Mohtashemi (AAAA) Neil Korpusik (AAAA) Ray Ryan (--AA) Steven Sharp (A---) Stu Sutherland (aAAA) Surrendra Dudani (-Aa-) Yogesh Pandey |||| |||| ||||_ 25 October 2004 ||| |||__ 27 September 2004 ||___ 13 September 2004 |____ 31 August 2004 (a--A) Alex Wakefield A => Attended (Present for both roll calls: beginning and end of meeting) a => Present for roll call at beginning, absent at end meeting roll call - => Missed Action items from October 25, 2004: ----------------------------------- 1. Steve: Will make a formal proposal for 216 (as part of sv-bc) this week. 2. Mehdi: Get the champions to discuss 216 in more detail. 3. Steve: will make a proposal for wild-card inequality (213,243,249) 4. Surrendra: will review and research 236 further, for committee discussion. Action Items from Sept 27, 2004: [Not completed by October 25, 2004] -------------------------------------------------------------------- 1. Surrendra - review errata 4 to make sure nothing else would be impacted. Send an email to sv-ec to that effect. 2. Ray - review errata 6, report if all issues are resolved. 13. Neil - send out a proposal for errata 25. Minutes 25 October 2004 taken by Neil Korpusik 1) Review of the IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Mehdi read the policy. 2) Review Operating Guidelines on member voting rules ref: http://www.eda.org/sv-ec/SV_OperatingGuideline_Aug04.pdf Now that we have had our initial 3 meetings, voting rights will depend on meeting attendance. Mehdi mentioned that everyone should review the guidelines so that they are familiar with them. The guidelines are on the sv-ec web page. http://www.eda.org/sv-ec/ 3) Approve the minutes of 27 September 2004 The minutes are up on the page, http://www.eda.org/sv-ec/Minutes.html Motion: To approve minutes of 27 September 2004: Surrendra Second: Brad Abstain: Opposed: Passed 4) Updates from P1800 WG meeting October 11, 2004. The Data Types Group has moved from the 1364 to the sv-bc. A meeting is tentatively planned for this week. This group will use the sv-bc reflector for its communications. Members of the sv-ec are welcome to participate in this activity. Instructions for joining the sv-bc are on the reflector. http://www.eda.org/sv-bc/ 5) Review/discussion and voting on Errata a) Discuss errata 216 per request from sv-bc. [enums initialization, 4-state and X values: per Steve Sharp's email] Steve: the main use of a "4-state enum" would be for modelling state machines. His proposal is that a "4-state enum" be initialized to x so as to avoid optimism. Neil: The same effect can be obtained by setting the first enum value to all x. This would allow the existing rules for enum initialization to cause a "4-state" enum to be initialized to x. Steve: also 2-state initialized to x, there should be no problem with this. Arturo: expressed objection to this. Ray: for any enum, type of enum, you can define the legal values it could take. Assigning an x would be a range error. Stev: Made the following points. -It is error-prone to have to remember to ensure that the first value is all x. -It would be verbose to have the x value as part of the enum. -You wouldn't want to cycle through an x value when enumerating the values of an enum. Ray: assining an x to it does not create error, for 4-state. 2, 29 range error? if it is range error how can you assign a value x to it. Steve: Having an enum be strongly typed is less important than ensuring that we end up with correct hardware Dave: any result of enum methods is undefined. Steve: Regarding the strong typing, the LRM mentions a few ways to get around the type checking; casting, union and packed struct. Also, an enum net could have driver contention, which should produce an x. Surrendra: you will get a warning? Neil: "The result of any operation on an enumeration variable after the variable has been assigned an out of range value shall be undefined." page 20 end of 3.10.3. Ray: Also, behaviour of use of enum, outside of the range, the action is undefined. Ray: Can you declare an array, whose index is enum, Steve: Nothing as sub-range type in LRM. can be used as an index into an associative array but not other types of arrays. sv-bc is where it should be decided if this is a good or a bad thing for the language Arturo: For randomization you can use 4-state variable, but it has to have 2-state values.it isn't set to x or z Steve: produce enums of 2-state values. Arturo: You can specifically declare one. Users explicitly declare an invalid value. Then add a constraint to not allow the invalid value Then check to make sure that you didn't leave a variable un-initialized Steve: mentioned his view of the Verilog X-state Nice rules for dealing with X are part of Verilog today X is a simulation value only - uncertain state reg, integer and time variables are initialized to an x state Having a 2-state enum start at 0 is not a problem. Arturo: Why would you want to take this on 4-state. Cliff: We always had to define with parameters, now with enums we want to define state machine, engineers want to use state encoding. [AI] Steve: Will make a formal proposal some time this week. [AI] Mehdi asks the champions to discuss this item. b) Brief discussion on wild-card operators (errata, 213, 243 and 249). [These are part of sv-bc, may want to give final inputs] errata 213 - sv-bc; see summary below errata 243 - transferred from sv-ec to sv-bc; ?== and ==? where the placement of the ? specifies which operand has wildcards errata 249 - duplicate of 243 Summary of errata 213 "symmetric" - the current wildcard comparison operators (=?= and !?=) treat x and z as a wildcard in both operands. This could result in overly optimistic simulation, and pre- versus post-synthesis mismatches. To overcome this it is proposed that only one operand allow x and z to be a wildcard. The right-hand side is the most natural place to allow wildcards. The intent is to prevent an x or z from the simulation from being treated as a wildcard. There is also a discrepancy in what is considered a wildcard in sections 7.5 (wildcard comparison - x,z) and 7.20 (inside operator - just z). - The wildcard operator came from the Vera donation. - The wildcard operator is synthesizeable if it is "asymmetric" [Steve] - The 'inside' operator was modified to be asymmetric [Dave] (7.20) The 'inside' operator was originally added for constraints but was later allowed to be used as a general construct within the language. - Surrendra expressed his dissatisfaction with making the wildcard comparison operators asymmetric. He mentioned that synthesis is just one special case to be considered. - Steve felt that the wildcard comparison operator is redundant. The 'inside' operator is more verbose. - Cliff felt that this was a good opportunity to "clean it up". - casex versus casez + casex can be dangerous [Cliff and Don Mills paper] + Steven prefers casez; casex can cause problems due to symmetry. An 'x' from the design by mistake can match. + Shalom prefers casex [Steven] - Steven noted that Shalom had proposed a compare that would exclude bits - Using ?== could be an issue for humans [Steven] - Straw polls [for information purposes only, not binding] A couple of straw polls were taken: 1. Add a new pair of asymmetric wildcard comparison operators (==?, !=?) 8 - in favor 1 - not in favor 2. Remove the existing symmetric wildcard comparison operators(=?=, !?=) 6 - in favor 3 - not in favorn the right hand side also. [AI] Steve to make the proposal. c) Review the errata items in the email ballots: Errata: 7, 8, 173, 197, 203, 236, 238, 240. Errata 7 - The old pdf was still up on the web site. Mehdi will post the updated pdf. An email vote will be held for this errata. Errata 8 - randsequence grammar issues - the ';' after endcase is required for the SELECT production and not for the case. - There is a typo, 'production_identifer' should be 'production_identifier' (missing 'i'). This shows up twice. Motion: To approve Errata 8 after fixing the two typos: Ray Second: Surrendra Abstain: Steve Opposed: Passed Errata 173 - is the order of declaration in a covergroup significant? The following example is shown in the errata. covergroup covergroup1 coverpoint cp1; option.auto_bin_max = 100; coverpoint cp2; option.auto_bin_max = 50; coverpoint cp3; option.auto_bin_max = 30; coverpoint cp4; endgroup The errata fix specifies: Add the following sentence to section 20.6 (After the first paragraph, as a new paragraph) Specifying value for the same option more than once in a covergroup definition shall be an error. Francoise: warning, option is not a declaration, some built-in variable not a declration. Arturo: it is a type a declaration, range of array inside of struct. it is the same Surrendra: not a procedural statement. Francoise: this variable is not defined in the covergroup, Ray: each covergroup has an option structure Francoise: it is initialization, it is not a declartion, Surrendra: it is not a procedural statement, not executed like a procedure. Ray: You can not set a breakpoint. Surrendra: what does it give to the user. Ray: To implement it you have to know what to do in this case. Surrendra: This can be compiled error. Francoise: Is it ok, to have the option, you have 3 definition of it, it would give an error. Neil: A rewording of the update was suggested: "Specifying a value for the same option more than once within the same covergroup definition shall be an error." Motion: To approve Errata 173 after changing the wording as specified above: Neil Second: Brad Abstain: Opposed: Passed Errata 197 - deferred since Dave Rich had to drop off the call early. Errata 203 - deferred since Dave Rich had to drop off the call early. Errata 236 - Behavior of cycle_delay with 'zero' value Arturo: notion an event has not happened. ##0 is not clearly defined. intuitively -- no delay, as opposed to what the proposal says. Brad: What about which region it is. Neil: ##0 immediately asynchrously, may violate cycle nature. Arturo: with ##0, always executes in current time, the cycle counter is not an edge synchronous mechanism. defining it this way keeps things simple, difficulties can arise when you consider all of the regions defined in the scheduling semantics. In program block, always execute in reactive region. Steve: If ##parameter repeat(parameter) @(posedge clk). Arturo: if you are not coincindent with edge you do not wait. Decision is to keep this open for further discussion [AI] Surrendra will review and research this further, for committee discussion. Errata 238 and others - Ran out of time 6) Next meeting times. November 8 -- November 22 -- thanksgiving week? Also ieee1800 swg meeting on that day, perhaps November 23rd or the week following. 7) Next Meeting Monday November 8, 2004. 11:00 am-1:00pm. send the logistics, agenda. 8) Meeting adjourned at: 1:00 p.m.