Email Ballot Vote, October 7, 2004. SV-Ec Notes =================================================================== >>>> Errata 7 Clarification to 20.4.1, new 20.10 From: Dave Rich ------------------- Please fixed typos addressed in http://www.eda.org/sv-ec/hm/2049.html From: Francoise Martinolle ----------------------------- item 7: a) typo: compued in the sentence: "For automatically generated bins, the coverage of a coverpoint is compued as" b) In the sentence: "its hit count exceeds the maximum of all the at least values of all instances." is it really "exceeds the maximum" or equal or more? c) typo at section 20.4.1: it's "of it's corresponding coverage point" d) in the example and values sample, I think that the explanation for bin b3 is incorrect, there are no 4 in the example, so Don't think we can match that bin. I think that b3 should refer to value 3 and not 4 From: Brad Pierce ------------------------ I agree in spirit, but not in form, because there are still typos that need to be fixed before we can pass this on to the editors. From: Ryan, Ray ------------------- This Yes is for the .pdf version of the proposal. The .html version does not display correctly so as to be readable. From: Neil Korpusik ------------------------------------------------ On page 1 there are a couple of places where a dash is used, this can be confused with a minus sign. On page 2, the example at the bottom, I don't see any values of 4 showing up, yet the description on page 3 says that on the 7th sample we have seen 3 four's. As Ray mentioned, the html didn't come up properly for me either. =================================================================== >>>>> Errata 8 Randsequence grammar issues From: Francoise Martinolle -------------------------------- item 8: A.6.12 I disagree with putting a ; after the endcase. This is completely inconsistent with the rest of Verilog. endmodule, endpackage, endgenerate, even the endcase of a generate is not followed by a ; Frem: Dave Rich ------------------- Note: the semicolon after endcase in the example is a separate issue that appears in the original text. From: Brad Pierce -------------------- In most contexts, such as within a begin-end or fork-join block, a ; after and endcase is legal syntax in SystemVerilog. ============================================================================= >>>>>>>>>>>> 173 Is the order of declaration in a covergroup From: Francoise Martinolle -------------------------------- item 173: I disagree option.auto_bin_max looks like a procedural stmt. option is a struct which member (auto_bin_max) is initialized to a certain value. I don't see this as a declaration. From: Neil Korpusik ---------------------------- I will agree to this if we make a couple of wording changes. Instead of saying "Specifying value for the same option more than once in a covergroup definition shall be an error." it should say "Specifying a value for the same option more than once within the same covergroup definition shall be an error." (i.e. add the word 'a' near the front of the sentence and also clarify that it is referring to the same covergroup definition). ============================================================================= >>>>>>>>>>>>>> 197 Is a String an array From: Dave Rich -------------------------------- This proposal is not in the database and does is not formatted as we agreed it should be A string data type might not be a dynamic array, but is much a like a queue of bytes, which is also a dynamic array in the loose sense of the word "dynamic". ======================================================================== >>>>>> 203 Section 3.7, delete the sentence "and embedded null bytes are From: Dave Rich -------------------------------- This proposal is not in the database and is not formatted as we agreed it should be. I disagree with this proposal as it removes functionality from SV3.1a (like string concatenation) without giving a reason for its removal. SV strings are patterned after C++ STL string classes, which allow null bytes. From: Francoise Martinolle -------------------------------- I would like to add a sentence in section 3.7 that string cannot contain any null bytes. From: Neil Korpusik ---------------------------- I agree with Dave Rich on this one. Since the C++ STL String class allows null bytes, SV should too. From: Arturo Salz --------------------- But, I agree with Ray & Neil that this change needs further clarification. From: Ray Ryan ----------------------- On further thought, System Verilog does allow a string to contain null bytes. That being the case, this proposal only removes the statement that they are included in a string compare - but does not specify how an embedded (not trailing) null byte is treated. Is it just another charater (if so why remove the text). Does it terminate the comparison (as might better match C). ===================================================================== >>>>>>>>> 236 Behavior of the cycle_delay with 'Zero' value From: Dave Rich -------------------------------- This proposal is not in the database and is not formatted as we agreed it should be. Please amend this proposal to address http://www.eda.org/sv-ec/hm/2041.html From: Francoise Martinolle -------------------------------- wording needs to be enhanced as specified in my email msg From: Neil Korpusik ---------------------------- I agree with the intent of the proposal but the wording doesn't seem to be quite right. "When the program execution reaches..." should be modified since this construct applies to more than just program blocks. The first sentence also appears to be redundant with what is already in the LRM. There are also a couple of other minor wording changes that should be made. I can send input on those later. From: Arturo Salz ------------------------- This proposal merits more thorough discussion and review. The sentence "there is a clocking event" is not specific enough. Does it mean the clocking event happened at all? in the current time-step / delta-cycle? ================================================================ >>>>>>>>>> 238 Pipelined value access in clocking block From: Dave Rich -------------------------------- This is clearly an enhancement request. Similar functionalit is availible with $past From: Brad Pierce ------------------------- Unnecessary enhancement to achieve what $past already does. From: Neil Korpusik ------------------------ As Dave mentioned, this is similar to $past From: Arturo Salz, ------------------------- This is an enhancement. And it needs more thorough review. I have several objections to the syntactic elements of this proposal: 1) Use of the additional keyword "depth". 2) It overloads the '.' operator to achieve the same as $past(). How will this work with part selects, multiple dimensions, or structs? Should these be valid? mxbus.data[1].1 // bit select mxbus.data[2].1[3] // multidimensional arrays mxbus.data.(N + 2) // parameterized depth From: Surrendra Dudani -------------------------- The intended functionality is already available via $past system call. From: Ray Ryan -------------------- This and #240 were combined into #255 so these shouldn't be voted on directly. From: Yogesh Pandey -------------------------- The same functionality is provided by $past. =================================================================== >>>>>>>>> 240 Expression evaluation with cycle_delay From: Dave Rich -------------------------------- This is clearly an enhancement request, and I do not agree that having expressions that block is a good idea. From: Brad Pierce -------------------- The enhancement of adding blocking expressions goes far beyond our errata-fixing mandate. From: Neil Korpusik ------------------------- As Arturo mentioned, it seems to be very similar to the existing expect. From: Arturo Salz ---------------------------- This enhancement introduces blocking expressions into the language, which is a radical departure from existing semantics. The semantics of blocking expressions are unspecified. The expressive power of this proposal does not improve upon the expect statement. From: Surrendra Dudani ----------------------------- The semantics of the suggested solution are incompletely specified. It seems to impose complex semantics of parallelism within Verilog expression. From: Yogesh Pandey -------------------------- Semantics are unclear and can have major impact on verilog expression evaluation. ======================================================= ----------------------------------------------------------- The eligible voters: Voted: Arturo, Brad, Dave Rich, Francoise, Neil, Ray, Surrendra, Yogesh DID NOT VOTE: Cliff, David Smith, Dennis, Eugene, Karen, Steven Sharp, Stu. Errata 7: 4 Yes, 4 No Errata 8: 7 Yes, 1 No Errata 173: 6 Yes, 2 No Errata 197: 7 Yes, 1 No Errata 203: 5 Yes, 3 No Errata 231: 8 Yes, 0 No -- passes, approved Errata 236: 4 Yes, 4 No Errata 238: 0 Yes, 7 No -- Francoise did not vote on this Errata 240: 0 Yes, 7 No -- Francoise did not vote on this. --------------------------------------------------------------- 7 Y No No No No Y Y Y 8 Y Y Y No Y Y Y Y 173 Y Y Y No No Y Y Y 197 Y Y No Y Y Y Y Y 203 Y Y No Y No No Y Y 231 Y Y Y Y Y Y Y Y 236 No Y No No No Y Y Y 238 No No No No No No No 240 No No No No No No No ----------------------------------------------------------------