SV-EC Errata Meeting Minutes Monday 22 November 2004 11:00 am. to 1:00pm [Distribued, for approval at next sv-ec errata meeting] Attendees: ---------- (a--AAA) Alex Wakefield (AA-AAA) Arturo Salz (----AA) Bill Paulsen (AAAAAA) Brad Pierce (-AAA--) Cliff Cummings (A-AAAA) Dave Rich (A-----) David Smith (--a-AA) Don Mills (A-----) Dennis Brophy (AAA---) Eugene Zhang (AAAAAA) Francoise Martinolle (A-A---) Karen Pieper (AAAAAA) Mehdi Mohtashemi (AAAAAA) Neil Korpusik (AAAAAA) Ray Ryan (--AAAA) Steven Sharp (A-----) Stu Sutherland (aAAAAA) Surrendra Dudani (-Aa--A) Yogesh Pandey |||||| ||||||_ 22 November 2004 |||||__ 8 November 2004 ||||___ 25 October 2004 ||| |||____ 27 September 2004 ||_____ 13 September 2004 |______ 31 August 2004 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 November 22, 2004: ----------------------------------- 1. Surrendra: replacement for erratum 203, open a new erratum based null bytes in strings. 2. Ray: errata 4, to add the comment with, in the proposal. 3. Ray: 211 and other issues, file a new errata for this. And will modify the pre-post randomize in the example. 4. Francoise: errata 260 Upload an updated proposal with the agreed to wording. 5. Ray: errata 172 write a clarifying paragraph. 6. Arturo: errata 252, prepare a proposal for an email vote. 7. Mehdi: Send ballot for email vote, closing on Tuesday November 30, 2004. Minutes 22 November 2004 taken by Brad Pierce & Neil Korpusik 1) Review the IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt We agreed to assume that the policy was read since everyone is familiar with it. 2) Approve the minutes of the last meeting [November 22 2004 meeting] http://www.eda.org/sv-ec/Minutes.html Motion: to approve minutes of November 8, 2004: Ray Second: Surrendra Abstain: Opposed: Passed 3) Next meeting schedule. Regular meeting schedule is set for Dec 6th, beyond Dec 1st p1800 deadline. consensus was that there is no need for extra meeting next week. Keep the December 6th 2004 for next meeting. 4) Review/discuss and vote on Errata in the database. a) String questions: Errata 203: String data type, Table 3-2: String operators, relational operators Surrendra: Discussion about DPI requiring null byte at the end, c routines will not work for null character, the user has to take care of it. Brad: just like c. Surrendra: it requires null terminated. Dave: from cc it can put any character, we should not put any limitations on it. Arturo: When you pass it to DPI the string should have null ending. Dave: When it is passed to DPI it has a null byte at the end. Ray: The user does not have to put the terminating null byte. Arturo: You can only put in c. Steve: Is this a safety issue. Alex: In the c side the null byte has to be there. Arturo: Is it useful to have null-bytes in the middle of string. Brad: It makes an array of string. Surrendra: null is not a character, printable character. Arturo: To deal with the old usage, it is there, special handling for the null-byte is already there. But it is not usefull to have null bytes in the string. Steve: If you want arrays with null bytes, you can declare it that way. Dave: All the methods can be defined for anything. Brad: To have array of strings. Dave: What is supposed to happen if you have null-byte in the middle of strings. The errata only discusses the string-compare. It includes null-bytes for compare. Register have characters in them, Steve: alot of system tasks deal with it as if the null-byte was not. Arturo: makes sense with the old code verilog, long code with character in it. Dave: They will not be surprised if null-byte is not end of string. Ray: The BC discussion that you can store null bytes in the middle of string. Francoise: We thought it was a c, only terminated with null-byte, we can deal with it. Ray: If string has lenght of 10, passes address of firt character plus the next 10. Francoise: You have to pass the length of string. Arturo: String of length 3, ABC, passing through API, ABC and null character. Francoise: The best way is to pass it through API as is. The c has to be programmed to understand it. Brad: There is no terminating null in Verilog. Arturo: It is not part of string, implementation issue. If you do not allow it, it all works consistenly. Ray: What should the semantics be for null array. Dave: It is very likely in verilog the null byte is there. Steve: You have to create rules for how to deal with them. Surrendra: you have to define the casting rules. Arturo: I would not be objecting to strip the null-bytes. Ray: It looks like we are having a new proposal. Motion: close errata 203 as a no-bug, with a freindly ammendment to open a new erratum for dealing with null bytes in strings. Move: Dave Second: Ray Abstain: Opposed: Passed [AI] Surrendra: to open a new erratum and proposal based on the above. Errata 271 Incorrect example of assigning a string to a register in Section 3.7 Motion: 271 with better instruction to the editor Move: Arturo Second: Ray Abstain: Opposed: Passed Errata 275 Several issues with section 3.7 String data type (Dave Rich action item) Dave: No progress. Could this be a placeholder? Mehdi: this is postponed, it will be a place holder. b) Randomization/constraints/randcase Errata 4 Add rs_rule precedence and example in Section 12.16 (Surrendra, Ray) Ray: Based on discussion, this should work. Arturo: The reason it does not affect it, it is guided by the syntax. Ray: So the precedenc should be ok. Arturo: What should the user read in the LRM. For example. Brad: It would not affect the distribution. Surrendra: you need the explaination. [AI] Ray: to add the comment with, in the proposal. [AI] Mehdi: place it on ballot for email vote. 175 Ambiguous ordering of random variables (Ray) Ray: Proposal adds one bullete to the list of bullets, values for partially ordered, adding to the initial. Motion: To accespt proposal for errata 175 Move: Ray Second: Neil Abstain: Opposed: Passed 211 Add clarifying example to builtin / scope randomize The discussion was on passing class properties to std::randomize(). The following points were made: - It is possible to pass one instance property to std::randomize(). - Class constraints shouldn't apply. Ray: Usage of the term checker, the example did not explicitly use the term checker. The second question was more of general item, two issues. std::randomize is used for variables not in the class, you do not have to be in a class. The second, std::randomize on rand variable, think of as class randomize. If the arguement is a class variable, the rand variables are only randomized. Bill: Does rand/or randc apply to scope randomize random variable of class. Arturo: Is it easier to say that you can not use std::andomize on class. Francoise: You have to copy of the value of classes. Ray: The intent was to as an example, to clarify the other sections, not to change the behaviour of other sections. Just for clarification. Arturo: That would be an enhancement. Ray: I can put this on hold and review it later. Ray: The RNG, currently it should use the thread rng, that was different it is unclear. Arturo: Use built-in randomize instead of std::randomize. for the second item. NOTES: the main questions on this: - Should the next random number come from the class instance random number generator or the thread of the calling scope? Arturo thinks of this as another way to call randomize from the class instance and that the instance random number generator should be used. - What should be done if properties from more than one instance are passed to std::randomize()? It was felt that this would be an enhancement request. There was an email from Ray on 11/20/04 that mentions a separate issue with pre_randomize() and post_randomize(). Clarification as to whether calls are made to pre_randomize() and post_randomize() for object properties that represent handles to class instances needs to be made. This should be addressed in a separate errata. Arturo mentioned that he agreed with the intent of the email. [AI] Ray: file a new errata for this. And will modify the pre-post randomize in the example. We will keep this open, pending more discussions. Errata 260 distributions and constraints solving The issue has to do with solving for constraints in the presence of specified weights (Section 12.4.4 of the LRM). Francoise: Explaination for probabilities, and constraints, add a sentence for 12.2.2, Arturo: A freindly ammendment, those constraint may overwrite the weight if they are contradictory. Bill: The example they are not contradictory. Arturo: We are saying that if there is a weight and Ray: Constraints may cause a weighting that is not satisfiable Arturo: If the constraints cause weiths ..implementation are required to satisfy the constraint. Bill: What about weight of 0. Can this be violated, Arturo: That may cause of failure, it is error. Ray: Some of the weights must be greater than 0. Arturo: zero is special case. Arturo: An exception to this rule is weight of 0 which is trated as a constraint. Ray: That choice is taken out of the list, not equivalent to saying that it can not take on that value. If the same value occurs twice in distribution list it is still legal. Ray: How about non-negative, does it say as evaluated as un-signed. Arturo: It does not say it in the LRM. Ray: I would like to make it treated as unsigned number. Arturo: negative weight is non-sense, if you treat it as unsigned number it would show a bug. If you make it a 0 is ok too. Ray: I can not see any usage for negative number. We can discuss this in the context of the next two errata. NOTES: A negative valued weight is an indication of something wrong. Treating it as an unsigned value would give a large positive value and is most likely not what the user intended. A weight of zero removes a particular value from the solution space. We worked out new text for this proposal. It was agreed that "satisfiable" is a real word. Motion: 260 with the friendly ammendments Move: Francoise Second: Arturo Abstain: Opposed: Passed [AI] Francoise: Upload an updated proposal with the agreed to wording. 261 randcase width rules inconsistent with Verilog (Steven Sharp) 262 randcase unclear on negative weights (Steve, Bill) Combined the two since the proposal text is dealing with both errata. Steve: expressions to be self-determined, you do not do it this way in verilog, context-determined. Arturo: It only makes a difference if you allow negative numbers. Steve: No, because you may have overflow. Ray: If you are getting overflow it does not matter. Steve: The question is the intermediate computation overflows.. Arturo: Two cases, if users see it or not, the intermediate values is not seen. Steve: All expressions are context-determined not to overflow. Evaluation requires knowing the width. Surrendra: the expression is a positive number. Steve: the LRM specifies the exact algorithm. Ray: When you sum the weight you have to add them with a width. Arturo: How are weight expressions evaluated. LRM says it is self-determeined, you want to say they should be context-determeined. and the only observable difference is overflow. Ray: How do I make sure I do not get overflow, use the value that is big enough. It may not be enough. Steve: Individual expressions are self-determined, then it gets converted after. Ray: LRM gives algorithm. Bill: How would you describe what the behaviour. Ray: We have to talk about how you sum them and what the width is. Steve: Verilog does not know how to interrupt them. Ray: If i have variables, weight of 7 or 15, two numbers 4-bit. the language should say 7+15 is 23. Arturo: Should it be self determined or content. How expressions are evaluated. What is the context of the value. it is the corner case. Steve: It is corner case. Ray: It affects those people, weights are literal, ok, but in register that can overflow. Arturo: first issue is for self-determination, the next issue. overflow what is to be done. Ray: this is both discussion of randcase and constraints weights. Surrendra: Once you specify it outside of verilog. has to do with number evaluation, that is not context dependent. Steve: yes, when those numbers do not interact with any other numbers. Bill: you need to change the wording to constraint weights. Steve: The other component of it is unsigned value. You can follow the normal rule unsigned all then unsigned one. Arturo: If the expression is signed then Ray: The expressions are all un-signed, the expressions should be evaluated by themselves then the Arturo: It is not a case statement, Steve: interact with each Arturo: if there is one unsigned if sub-expression, you would not be to get consistent value. NOTES: Some of the points that were made as arguments against this errata: - The proposal doesn't ensure that there won't be overflow. - In a regular case construct there is a case expression that each case item expression is compared to. There is no such comparison in the randcase. - The proposal requires all weights to be taken into account. - This is a corner case that isn't that important. Some of the arguments in favor of the proposal were: - The possibility of overflow will be reduced. - Is consistent with most other parts of the LRM as far as determining interim results are concerned. - An expression implies an operation is taking place. - Reduces the likelihood of getting unintended results. Motion: 261/262 To accept the proposal (variant 2) text Move: Steven Second: Francoise Abstain: Dave, Don for: Steve, Francoise, Bill, Neil Opposed: alex, arturo, ray, brad, surrendra The proposal failed to pass. 4 in favor, 2 abstain, 5 against. 263 wide randcase weights Enhancement Request 270 User need more information when the randomize method fails Enhancement Request c) Coverage 6 Description of query and inst_query methods [AI] Mehdi: place on ballot for email vote 172 assignment of values to fixed bins is not specified Arturo: when the user calls twice, you count it twice. Francoise: Count this thing twice, the user wants to say, it. Arturo: It is a corner case again, I do not see any use for it. Ray: In which case, fixed or non-fixed case. [AI] Ray: write a clarifying paragraph. [AI] Mehdi: place on ballot for email vote 251 multiple user defined bins for cross Enhancement Request 252 default bin of a coverpoint in cross The issue is whether the default bins of a coverpoint participate in a cross of that coverpoint. [AI] Arturo: prepare a proposal for an email vote. [AI] Mehdi: Place on ballot for email vote. Dave Rich requested to place 317 on ballot for email vote. (data base ref: http://www.eda.org/svdb/ ) 5) Next Meeting Monday December 6, 2004. 11:00 am-1:00pm. [AI] Mehdi: send the logistics, agenda. 6) Meeting adjourned at: 1:07 p.m.