Working Group members, Attached is a copy of the results from the most recent Champions email vote. I believe that this email vote is what prompted Yossi to send out his email on February 5th which expressed his concerns with the Champions feedback. Do note that this was an email vote and not a conference call. All of the Mantis items that received no-votes will be up for discussion in the next Champions meeting, which will be held on February 14th. It only takes one no-vote in an email vote to prevent a proposal from passing. In a conference call it takes a majority to cause a proposal to fail. It is also possible that after holding a discussion on a particular Mantis item, previous no-votes can be retracted. This has happened in the past. Sometimes one Champion will try to talk another Champion out of voting no. We will need to wait for the conference call to see what happens. I agree with Yossi that the PAR allows the sv-ac to make enhancements to the language. This point was also raised and discussed in the previous Champions conference call. We do allow Champions to vote no on any proposal for whatever reason they chose. It is then up to the Working Group to take that input into consideration. Neil -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. FYI, Attached is a detailed summary of the Champions 8.5-day email vote that ended on Feb 4th. There were 4 Champions that voted and 3 that didn't. I have updated the bug notes for these Mantis items with all of the feedback. We needed 4 votes on a Mantis item in order to pass it. There were several Mantis items that did not receive enough votes and will need to be addressed in the next conference call (along with the 6 that had no votes). The next Champions meeting will be held on Feb 14. I will send the official agenda out tomorrow. There will most likely be a few additional Mantis items on the agenda. Neil 6 - with 1 or more no-votes 10 - with 1 or more abstains (doesn't pass) 12 - passed without any feedback given ------------------------------------------------ 28 - total Mantis items voted on 1. Dave - no on 1447, 1858, 1995, 1728, 1900 abstain on 1846 2. Shalom - no on 1447, 1846, 1900 abstain on 2181, 1858, 2016, 2009, 1952, 1741, 1729, 1668, 1667, 1456, 748 Note to editor 1995 3. John H. - abstain on 1900 Friendly amendments on 1995, 1728 4. Surrendra - yes on all 5. Brad - didn't vote 6. Stu - didn't vote 7. Francoise - didn't vote List of Mantis items that passed (4 yes and 3 not voting) --------------------------------------------------------- 1. 2227 SV-EC Incorrect comparison of $random and $urandom 2. 0958 SV-EC dynamic array size method unclear when empty 3. 0520 SV-EC examples of queues assignments are not legal array 4. 2003 SV-EC Old statement on foreach for wildcard indexed associative 5. 2221 SV-BC "unpacked array reference" is ambiguous 6. 2193 SV-CC Need to clarify vpiValid flag 7. 2190 SV-CC Standard does not say what should happen when putting value 8. 2086 SV-CC Deprecated vpiArray still used with vpi_register_cb() 9. 2063 SV-CC Three minor typos in sections 36.15, 36.21 and 36.25 10. 1826 SV-BC JEITA: Annex B Add keyword list by LRM version 11. 1711 SV-BC Rules for unique case evaluation 12. 1549 SV-AC add missing formal argument types List of Mantis items that did not pass due to a lack of votes ------------------------------------------------------------- 1. 2181 SV-EC Ambiguity in implicit declaration of production variables in 2. 2016 SV-CC vpiClassType should apply to class typespec rather than to 3. 2009 SV-CC HDL example shown in detail 3 section 36.14 (Reference 4. 1952 SV-CC "Null argument" to mean "omitted argument" may be confusing 5. 1741 SV-CC 1800-2005 Section 27.50 Issues with foreach diagram 6. 1729 SV-AC Introduce immediate assume and cover statements 7. 1668 SV-AC Local variable initializers. 8. 1667 SV-AC Local variable arguments for sequences and properties. 9. 1456 SV-CC Clarify, circumscribe restrictions on use of DPI context 10. 0748 SV-CC vpiParent of var select can only be array var List of Mantis items that failed with one or more no votes ---------------------------------------------------------- 1 . 1447 SV-EC Contradictory stmts about unsized array dimensions 2 . 1858 SV-EC Name binding in inline constraints 3. 1995 SV-AC Allow concurrent assertions and checkers in for loops 4. 1846 SV-BC D3 21.13: add 1800-2008 to `begin_keywords 5. 1728 SV-AC Introduce "let"statement 6. 1900 SV-AC Add new 'checker' construct to SVA Details for each of these failing Mantis items is shown below: 1 . 1447 SV-EC Contradictory stmts about unsized array dimensions Failed with 2 no-votes - Dave - Comments were posted to sv-ec (copied below) I am reviewing the revised sentence in section 7.4.2 of the proposal: "Unpacked fixed-size arrays can be made of any data type, and whereas dynamic arrays, associative arrays and queues can only be made of variable data types." The use of the word "variable" is confusing on a few accounts: 1. "Variable" is the antonym of ?fixed,? and quickly read, makes me think that you are trying to restrict dynamic arrays to being made up of variable-sized elements 2. The data types allowed for group of data storage called Variables is un-restricted, whereas the data types allowed for group of data storage called Nets is restricted, so what is being restricted here? 3. It's not possible to specify the element type of an array as belonging to variables or nets. May I suggest making a friendly amendment and leaving that sentence in its original form, an making a small modification in 6.6 Certain restrictions apply to the data type of a net. A valid data type for a net shall be one of the following: a) A 4-state integral type, including a packed array or packed structure. b) A fixed-size unpacked array or unpacked structure, where each element has a valid data type for a net. - Shalom - agreed with Dave's comments - without further review 2 . 1858 SV-EC Name binding in inline constraints Failed with 1 no-vote - Dave - Need to get consensus on this issue. 3. 1995 SV-AC Allow concurrent assertions and checkers in for loops Failed with 1 no-vote - Dave - This proposal is essentially creating a generate block within a procedural context. I'm fine with limiting this to assertion statements for now, but that does alleviate addressing all the issues surrounding generated code. For example each assertion statement is replicated in the loop (including nested loops) and a generate block label needs to be created for every instance of each. The loop iterator should be treated as a genvar constant within each instance of the assertion statement. - Shalom - note to the Editor: In "For loop control variable value 1, the assertion will pass, and the pass action block will be generated," change the last word to "executed". - John - friendly amendments: - Editorial: I think that the parenthetical exception in the change to 16.4 should be at the end of the sentence. - In the change to 16.14.3, I'm not sure that shall count each possible set of loop control variable values as one attempt is really clear. Based on the sentence that follows, I think that what is intended is something like shall count distinct valuations of loop control variable values as separate attempts - Editorial: At the bottom of p. 2, the comma following the bold courier "continue" should be in non-bold roman. - Editorial: Do not use smart quotes in the courier examples. - p. 3, change "generated" to "executed" in "the pass action block will be generated". - p. 4. In the example above, ac1 will always be checking the sampled value of variable ok. Since this will be equal to (my_bits[3] == 0) by the end of any time step, it will always pass The declaration and initialization of "ok" are not shown, so we do not know its sampled value in timesteps prior to and including the first timestep in which posedge clk occurs. Similar comments apply to other statements in this paragraph. 4. 1846 SV-BC D3 21.13: add 1800-2008 to `begin_keywords Failed with 1 no-vote - Shalom - Superceded by 1826 5. 1728 SV-AC Introduce "let"statement Failed with 1 no-vote - Dave - It seems very odd that the let statement is allowed on an immediate assertion, which is no more complex than a 'if' statement, but not allowed in any Boolean expression. I understand the SV-AC rush to add features to the language and limiting those features to assertions, but limited this kind of feature to assertions does not serve the end user and the language very well. If there are issues preventing wider adoption of this feature, let then be flushed out now. - John - friendly amendment: p. 3, I think that there is a parenthesis mismatch (too many ")") in the let in the package pex_gen9_common_expressions. 6. 1900 SV-AC Add new 'checker' construct to SVA Failed with 2 no-votes - Dave - This proposal needs to be addressed when it can have the full attention of all the committees as effects every part of the language. Otherwise, I feel that this enhancement goes beyond the level of enhancements authorized by the P1800 PAR in embedding a new language with SV. The number of keywords and statements being introduced can not be thoroughly reviewed with the resources we have for the current par. A suggestion would be to call a join meeting to have the SV-AC present this proposal to members of all the other committies as part of a design review. - Shalom - Sent a lot of feedback to the sv-ac (in 5 parts). - John - Friendly amendments: Rationale for Abstain: I collected too many friendly amendments below to justify a clear "Yes" vote, and I'm still going carefully though the last 10 pages of the proposal. Friendly Amendments: - 16.18.1, p. 8. I'm not sure that the following sentence is precise enough to interpret what "remains valid" means: If the fact that the abstract model is indeed an abstraction of a concrete model can be formally proven then the reasoning about the abstract model behavior remains valid for the behavior of the concrete model. Presumably, there is a correspondence between the behaviors. In any case, I don't think this statement is needed in the LRM. - 16.18.2, p. 11. In If a formal argument is written in the checker body, its corresponding actual argument shall be a checker variable or a formal argument in another checker. I recommend changing "formal argument is written" to "formal argument is assigned a value". This is for consistency with the other sentences in this paragraph. - 16.18.4, p. 14. There is a type mismatch in the example with check_in_context. The formal argument enable is of type logic, but the instance my_check1 binds to it the sequence expression "en1 ##1 en2". One solution is to change the actual to something like "en1 || en2" and also change the parenthetical clause: note also that a sequence has been passed to the checker as its enabling condition Alternatively, the type of the formal argument should be changed. - 16.18.5, p. 16. The following sentence As regular variables, checker variables can be packed or unpacked aggregates of other types (see 6.5). should be reworded for clarity. The phrase "as regular variables" could be omitted entirely or changed to something like "as in the case of regular variables". - Editorial: 16.18.5, p. 16. Change "show" to "shows" in "The following example show". - 16.18.6, pp. 16-17. The intuitive descriptions of the assumptions imposed on the free checkvar bit flag seem reasonable for a formal tool in which $global_clock ticks at every point in time. In simulation, however, $global_clock may not be at the granularity of a timestep and a simulator may apply chaotic values for flag in timesteps that are not ticks of $global_clock. In this situation, the intuitive descriptions do not seem accurate. I recommend either 1. Stating that it is assumed that $global_clock ticks at every timestep, or 2. Qualifying the intuitive descriptions in a way that makes it clear that they apply only in the timesteps in which $global_clock ticks. - 16.18.6, p. 18. If a simulator cannot assign a right value needs to be reworded to clarify what "assign a right value" is intended to mean. - 16.18.6, p. 18. which in turn implies that the corresponding legality of data transfer through that transaction is being checked. The legality might not be checked in simulation because the simlator might choose the wrong value for mem_data. I think this sentence needs to be worded in a way that does not suggest that checking of legality is ensured in simulation. - Editorial: p. 19. Change "as opposite to" to "as opposed to". - 16.18.6.1, p. 19. In Example 1, the constant "3'b3" should be something like "3'd3" or "3'h3". Similarly with "3'b5". - 16.18.6.1, p. 20. I would change "the clock of the sequence" to "the ending clock of the sequence" in In nonblocking assignments the matched method provides synchronization between the clock of the sequence I would also change "when the sequence clock" to "when the ending clock of the sequence" in the sentence that follows (2 places). In the examples that follow, the second "endsequence : s1" should be "endsequence : s2". Also, we don't really have enough information to conclude the following: On the contrary, the value of u at time 90 will be 0 since there is no match of s2 at time 90. This statement assumes that there is not another match of s2 ending at 90. - 16.18.6.1, p. 20. I recommend deleting "Thus," from Thus, an unpacked structure or array can have one element assigned procedurally and another element assigned continuously. This conclusion does not follow from the preceding. Also, "can" should probably be "may". - 16.18.6.1, p. 21. I'm not sure how the SAR is interpreted when the check bit to be assigned may be determined dynamically. In Example 4, the discussion says that there is a SAR violation for counter[0]. Is this just because i may take the value 0? Is the following legal free checkvar bit [5:0] counter; free checkvar bit [1:0] i; assign counter [5:4] = foo; always_check @clk counter[i] <= !counter[i]; ? - 16.18.6.4, p. 26. The shifting of the NBA when future value functions appear in the RHS may produce counterintuitive results in simulation if the $global_clock is not the fastest.Received on Sat Feb 9 16:50:59 2008
This archive was generated by hypermail 2.1.8 : Sat Feb 09 2008 - 16:51:10 PST