-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions meeting minutes of February 14, 2008 Thursday February 14th, 2008 8-10am PST Attendees: ---------- 1. * Stu Sutherland - was traveling - joined at 9:16 2. * Surrendra Dudani 3. * Brad Pierce 4. * Francoise Martinolle 5. * Shalom Bresticker 6. * John Havlicek 7. * Dave Rich 8. * Neil Korpusik 9. * karen Pieper Next Meeting: ------------- Champions Feb 25 - Continuation of the February 14th meeting Monday 8-10AM PST P1800 Feb 28 Mar 27 Review IEEE patent policy ------------------------- ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Brad - assume the patent policy was read Second: John Passed unanimously List of Mantis items ready for review: ------------------------------------- 1. 2181 SV-EC Ambiguity in implicit declaration of production variables in randsequence - Fixed - Approved on December 17, 2007 with 2 abstain votes. Abstain: Mike burns - no time to review Steven - not happy about inability to return multiple values (Ray - it would require creating backward compatibility issues to fix that ) - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. Francoise - questioned example 2, which appeared to be defining a new way to declare variables. - was confused about variables versus productions Shalom - bit [7:0] value : { return $urandom } ; There is a missing ; after $urandom (email was sent to Editor) - arrays usually start with 0, here it starts with 1 Move: Brad - approve the proposal for Mantis item 2181 Second: John Passed unanimously 2. 2016 SV-CC vpiClassType should apply to class typespec rather than to class defn - Duplicate - SV-CC voted to declare this a duplicate of 2094 on 01/16/2008 (unanimous) - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. Move: Brad - approve the resolution of Duplicate for Mantis item 2016 Second: FM Passed unanimously 3. 1952 SV-CC "Null argument" to mean "omitted argument" may be confusing - Fixed - The SV-CC PASSED this on 12/17/2007 (unanimous). - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. Francoise - deals with the special value of null Move: Brad - approve the proposal for Mantis item 1952 Second: FM Passed unanimously 4. 1741 SV-CC 1800-2005 Section 27.50 Issues with foreach diagram - Fixed - Was sent back to the sv-cc for input from the sv-bc Brad sent input that was incorporated. - The SV-CC PASSED this on 12/19/2007 (unanimous). - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. Move: Brad - approve the proposal for Mantis item 2016 Second: Shalom Passed unanimously 5. 1729 SV-AC Introduce immediate assume and cover statements - Fixed - Was sent back to the sv-ac from the Champions The proposal was updated and approved by the sv-ac. - Passed by e-mail ballot 2008-01-14, 9y/0n/1a - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. - Chas mistakenly updated this mantis item, Shalom undid those changes 2/13 Brad - this is a good proposal Move: Brad - approve the proposal for Mantis item 1729 Second: John Passed unanimously 6. 1668 SV-AC Local variable initializers. - Fixed - There was feedback from the Champions. The proposal was updated and approved by the sv-ac. - 2007-11-13 Changes to address Champions' feedback approved by voice vote, 9y/0n/0a. - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. There are 2 parts to the proposal Brad - doesn't understand part 2 (annex F, the part with special symbols) John - We need to align assignments to local variables. If do assignments immediately, you would be getting values that aren't correlated to the starting clock of the starting sequence. Annex F defines the recursive process used for multiply-clocked situations. - Clocked things are defined in terms of unclocked things. They used a proof to verify some of this. John - he can work with the Editor if there are issues with the symbols. Move: John - approve the proposal for Mantis item 1668 Second: Brad Passed unanimously 7. 1667 SV-AC Local variable arguments for sequences and properties. - Fixed - approved by voice vote in the meeting 2007-01-15, 7y/0n/0a - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. This one is also in 2 parts. Francoise - why need to use the 'local' keyword? John - It is used to distinguish different cases. - It is an important proposal. For sequences and properties - local variables may be captured and passed down. - Is is useful to know the value that is being received is being assigned like a local variable and not tracked as a change to an expression. It is also a convenience to the user. - It is a shorthand facility Francoise - so that is why the input and output syntax is used? (yes) - Is it backward compatible? (John - yes) Move: John - approve the proposal for Mantis item 1667 Second: Surrendra Passed unanimously 8. 1456 SV-CC Clarify, circumscribe restrictions on use of DPI context utilities - Fixed - The SV-CC voted on 11/07/2007 to accept the new change (unanimous). - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. Move: Brad - approve the proposal for Mantis item 1456 Second: Francoise Passed unanimously 9. 0748 SV-CC vpiParent of var select can only be array var - Fixed - The SV-CC PASSED this on 01/16/2008 (unanimous). - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. Move: Dave - approve the proposal for Mantis item 748 Second: Brad Passed unanimously Typo on var select ">" versus "->" - email was sent to the Editor. (there are several examples of this same typo in this section) 10. 2009 SV-CC HDL example shown in detail 3 section 36.14 (Reference objects) has errors. - Fixed - The SV-CC PASSED this on 11/07/2007 (unanimous). - The Champions email vote which ended on Feb 4th, 2008 did not have enough participation on this Mantis item to allow it to pass. Move: Francoise - approve the proposal for Mantis item 2009 Second: Brad Passed unanimously 11. 1995 SV-AC Allow concurrent assertions and checkers in for loops - Fixed - The latest proposal contains updates based on feedback from the Champions. I placed the Mantis item into the feedback state since this latest proposal hasn't been approved by the sv-ac. - I would like to determine how much opposition there is to this Mantis item. In the email vote which ended Feb 4th, there was one no-vote. Please review the latest proposal, even though the Mantis is in the feedback state, so that we can provide any additional feedback to the sv-ac. - The one no-vote from the Champions: 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. - 2/9 - Neil placed into feedback state - a new proposal was posted 2/12 - new proposal was re-approved by svac and the Mantis item is back in the resolved state. John - This was discussed in the face-to-face meeting - Gord was there and they took out the generate concept at that time. FM - why not using immediate assertions? Dave - they are still concurrent - the generate block change - was to keep these changes in the assertion portion of the LRM. - the loop is being unrolled. - an independent execution of assertion for each iteration of loop. - need to statically know how many times to iterate for the loop. Shalom - the need to have this capability - is for concurrent assertions John - a parallel generate structure would be an alternative. That gives up one of the key aspects of assertions - good locality to the variables they are watching. Shalom - there don't appear to be any implementation issues. Dave - action blocks that deal with variables. - assert or cover could use the iterator variable. Assumed to be constant within the assertion itself? - if iterate over bits - computed index - ok in a generate can't elaborate out if still an automatic in the assertion. - talked to Gord yesterday - wants it completely isolated from the rest of the language. - Gord - wants to ensure that removing or adding in the assert will not affect the rest of the code. FM - these assertions only allowed to refer to loop control vars. from her reading of it. p. 4 - about 2/3ds down "thus, to achieve ..." Shalom - uses sampled values. - explanation given of how to write assertions to get a desired behavior John - concurrent used to not be able to reference automatic variables. - that has changed such that can only access loop variables. there is another mantis item that describes this (2150 also) - the intent is to limit to loop control variables. - this should be implementable Dave - what about variables declared in the action block? Is there one instance for each iteration of the loop? John - each eval of assertion will cause action block to execute and each has its own copy of the automatics. Dave - looking at 2150 - runtime or elaboration constant? - only relation to concurrent assertion and loop is that creates a separate assertion for each iteration. John - concurrent assertions have multiple evaluation attempts - he can see the issue that Dave is articulating. - There could be an issue if clocked the embedded assertion with a separate clock Dave - believes that the loop needs to be synthesized. Brad - thinks that is technically correct, but what does it mean? Dave - bending a lot of rules about automatic variables to make this not look like a generate. - there were a lot of issues with the generate approach. svac wanted the generate to only apply to the assert portion. John - is there a way to add more restriction to make this more acceptable? Dave - wants to get rid of rules and make it simpler. why not say each assertion created at compilation time and substituted with elaboration constants. Shalom - what about names for the assertions? That was one reason for using a generate. Dave - there does need to be a name for each Shalom - the proposal has one name John - there are multiple attempts starting at the same point Dave - if getting coverage, how know which iteration succeeded? John - believes that that distinction is being given up. - there are restrictions on immediate (not temporal, ...) Shalom - adding concurrent assertions to procedural code and loops are not an issue. Dave - won't get same behavior if had added those assertions to a generate block. Brad - 16.14.3 Shalom - could have nested loops. needs to print out values for each iter. Stu - 16.14.3 - seems ambiguous - one assertion thread started? - sounds like this is beyond the champions role. Brad - for 100% cvg would need to go through all? - can't break out. Dave - generates would create separate assertions. - loops - create separate attempts. Neil - it is a difference but is it a problem? Dave - thinks it is a question of user expectations. (i.e. the difference between these loops and generate blocks) Shalom - the proposal is not perfect but extends the capability. Surrendra - all attempts are combined. The coverage report won't show each attempt separately categorized. John - this is consistent with what we have today. - several attempts of same concurrent assertions - several could end at the same time - could have several action block evaluations at the same time. - No distinction made between them - counters just reflect sums. Dave - need to look at action block message to distinguish between attempts John - yes, a tool could give more information if it wanted to. Brad - this proposal is better than what we have now. Move: Brad - approve the proposal for Mantis item 1995 Second: Shalom Abstain: Dave - see his original email for his reasons Francoise - seems problematic - extra rules being added Stu - concerned that spec is not clear enough - implementations could diverge. Passed with 3 abstain (4 approved) 12. 1900 SV-AC Add new 'checker' construct to SVA - Fixed - 2008-01-21 Revision to address friendly amendments passed by e-mail vote, 6y/0n/4a. - The proposal failed in the Champions email vote which ended on Feb 4th, 2008. 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 committees as part of a design review. - Shalom - Sent a lot of feedback to the sv-ac (in 5 parts). - I would like to discuss this in the Champions meeting to find out how much opposition there is to this proposal (Neil) - Dmitry has placed it into the feedback state - 2/10 (still there 2/13) Shalom - sent a list of changes required (Editor type changes) - saw no inherit technical problems (inconsistencies, typos) Dave - Mantis items 2088, 2089 are also related to this one Neil - wants to get feedback on the level of opposition Dave - philosophical objection - should be done by inter-committee There should be a design review - too much in here unless impl. - a big mistake to just isolate to assertions. - it amounts to a separate language within assertions. - it needs more attention. The schedule doesn't allow for a full review. - As a champion, he doesn't have resources to review at this point - Adding classes to SystemVerilog caused unforeseen interactions even though portions of it had already been implemented. Shalom - part of champions responsibility is to find the resources. - a lot of the parts of this have been implemented. - the people in svac need it. Dave - not questioning the need for it. - read API wasn't implementable as defined. We didn't know that until someone tried to implement it. Shalom - as soon as it is revised by svac - Champions need to review it again. It is a big proposal. Straw poll: ---------- Surrendra, John, Shalom, Brad - in support Dave - opposed Stu - neutral - too much right now (concern) Francoise - briefly reviewed - seems reasonable needs more time. 13. 1858 SV-EC Name binding in inline constraints - Fixed - The proposal was approved by the SV-EC in the conference call held January 22, 2008. There were two people opposed. Opposed: Francoise - redundancy issue. The proposal specifies two ways to do the same thing. - Inline constraints are already complex. - prefers having just local:: Steven - same reason. Passed with 2 no votes, 11 were in favor of the proposal - The proposal failed in the Champions email vote which ended on Feb 4th, 2008. Failed with 1 no-vote - Dave - Need to get consensus on this issue. Dave - now believes that the two techniques described are not completely redundant. - One of them will block out references into the class. Shalom - question on the bnf - there are two other bnf's scope randomize randomize call - the change is just isolated to one of these? FM - the only issue was with scope of class or local scope Brad - going from inline to regular - if referenced them - now need to comment out? Dave - only in the inline call AI/Neil - Open a separate mantis for this question about the bnf. Move: Brad - approve the proposal for 1858 Second: Dave Oppose: Francoise - doesn't like the redundancy Passed with one opposed 14. 1846 SV-BC D3 21.13: add 1800-2008 to `begin_keywords - No change required - On January 7, 2008, the SV-BC unanimously moved that the resolution of this issue is superceded by resolution of issue 1826 and that no action is required to resolve 1846. - The proposal failed in the Champions email vote which ended on Feb 4th, 2008. Failed with 1 no-vote (from email vote) - Shalom - it is superceded by 1826 Move: Dave - close Mantis item 1846 as a duplicate Second: Shalom Passed unanimously 15. 1728 SV-AC Introduce "let"statement - Fixed - Was sent back to the svac by the Champions The proposal was updated and approved by the sv-ac. - Unanimously passed by voice vote 12/04/07. - The proposal failed in the Champions email vote which ended on Feb 4th, 2008. 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. - Dmitry has placed it into the feedback state - 2/10 It is now back in the resolved state - reapproved by svac 2/12 Brad - Dave please give us input on this one. Dave - constructs specific to assertions only thinks it is a bad thing to do. Brad - doesn't want let in the general language. - thinks of assertions as a sub-language. <we ended at this point - and will resume on Monday February 25>Received on Sat Feb 16 17:50:47 2008
This archive was generated by hypermail 2.1.8 : Sat Feb 16 2008 - 17:50:52 PST