| Anonymous | Login | 2010-09-02 14:42 PDT |
| Main | My View | View Issues | Docs | Wiki |
| Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Date Submitted | Last Update | |||
| 0001648 | [SystemVerilog P1800] SV-AC | feature | 2006-10-24 08:10 | 2008-12-21 09:01 | |||
| Reporter | Dmitry Korchemny | View Status | public | ||||
| Assigned To | Lisa Piper | ||||||
| Priority | normal | Resolution | fixed | ||||
| Status | closed | Product Version | |||||
| Summary | 0001648: Default reset for assertions | ||||||
| Description | Attached is a default reset proposal for properties (similar to default clocking). The proposed syntax is 'default disable iff' (and not 'default reset') in order not to introduce a new keyword. | ||||||
| Additional Information | |||||||
| Tags | No tags attached. | ||||||
| Type | Enhancement | ||||||
| Attached Files |
|
||||||
|
|
|||||||
Relationships |
|||||||||||
|
|||||||||||
Notes |
|
|
John Havlicek (manager) 2007-06-25 12:50 |
Passed by e-mail ballot 2007-06-19 8y/0n/3a. |
|
Eduard_Cerny (developer) 2007-07-18 13:51 |
To align with 1800-2008 Draft 3a |
|
Eduard_Cerny (developer) 2007-07-18 13:53 |
Aligned with 1800-2008 draft 3a: minimal changes in font color. |
|
Eduard_Cerny (developer) 2007-08-27 14:09 |
updating to address champions' concerns |
|
Eduard_Cerny (developer) 2007-08-28 07:46 |
Answers to comments from the champions' meeting: - Same properties can have different behavior depending on how used. Top-level versus not top-level (e.g. rule b on first page). The default disable applies only to assert, assume and cover property statements, not to property and sequence declarations. A sentence was added to that effect. - The bnf shouldn't be in the text. Done. - 3rd paragraph under syntax box, part about "...on the position of...", doesn't need to say it. "The scope of the... " isn't clear. Tried to explain better in the new text. - There are issues in the other 2 paragraphs as well. Not clear what these are... - First paragraph - should be reworded "One can specify..." --> "A default disabling condition may be..." Done. |
|
Dmitry Korchemny (manager) 2007-08-30 05:44 |
Added VPI diagrams |
|
John Havlicek (manager) 2007-09-01 08:08 |
Proposal default_disable_1648.070830_dk.pdf passed by e-mail ballot on 2007-08-31, 8y/0n/2a. |
|
John Havlicek (manager) 2007-09-06 09:15 |
Coloring fixed to use red bold in syntax even in a blue colored section. |
|
Dmitry Korchemny (manager) 2007-09-09 07:21 |
As a byproduct fixed a minor coloring problem in Draft3a: The semicolon that follows "default clocking clocking_identifier" should be in bold red, as in A.1.4. |
|
Neil Korpusik (administrator) 2007-09-10 17:29 |
Sent back to the Technical Committee by the Champions in the July 26, 2007 conference call. Comments from the Champions: - I am against this enhancement at the current time. I believe this feature will be useful in a wider context, such as covergroups, but the committees have not had time to study this. If we add this feature now, it will be harder to address the other areas due to backward incompatibilities. For example, suppose the sv-ec decides that default disable should also disable sampling of covergroups. We can't add that capability later; we must look at all the other areas that could be affected. But due to schedules and merge activities, the other committees have not been able to investigate. - there may be other places that could use it as well. - doesn't think everything is being considered. Same properties can have different behavior depending on how used. Top-level versus not top-level (e.g. rule b on first page). Set of issues: - The bnf shouldn't be in the text. - 3rd paragraph under syntax box, part about "...on the position of...", doesn't need to say it. "The scope of the... " isn't clear. - There are issues in the other 2 paragraphs as well. - First paragraph - should be reworded "One can specify..." --> "A default disabling condition may be..." |
|
Jim Vellenga (developer) 2007-09-12 08:20 |
I noticed that the syntax of 'disable iff' allows the expression to be an 'expression_or_dist' -- for either the default or the explicit version. I'm not sure what this means, but I also notice that the 'dist' part doesn't show up in the VPI object models. Could you all clarify whether the disable can indeed depend on a distribution? Regards, Jim Vellenga |
|
John Havlicek (manager) 2007-11-06 06:35 |
2007-11-05: e-mail ballot failed, 7y/2n/1a. |
|
Dmitry Korchemny (manager) 2007-12-04 02:36 |
Passed by e-mail ballot 2007-12-03 8y/0n |
|
Lisa Piper (developer) 2007-12-04 09:21 |
re-opened to align to 1757. The text to be replaced will differ depending on whether 1757 is previously adopted. |
|
Lisa Piper (developer) 2007-12-04 09:54 |
Voice vote on the change for the 1757 contingiency occurred 12/4 and was passed. Dmitry asked me to move this to resolved again. Lisa |
|
Lisa Piper (developer) 2007-12-04 09:55 |
Voice vote approved the latest change on 12/4. |
|
Neil Korpusik (administrator) 2007-12-23 17:43 |
Was sent back to the SV-EC by the Working Group in the meeting of December 13, 2007. This new construct may also be useful for covergroups. |
|
John Havlicek (manager) 2007-12-24 13:01 |
SV-EC should note that the syntax for this construct was deliberately changed to "default disable iff" so that the syntax "default disable" would remain available for SV-EC. Dave Rich made some comment about this in the Champions meeting of 2007-12-20 that I did not follow. |
|
Neil Korpusik (administrator) 2008-01-12 18:08 |
The following proposal was unanimously approved by the SV-EC in the conference call held January 7, 2008. The SV-EC has considered the impact of default disable on covergroups and decided that at this time it would not be appropriate to adopt the default disable for those constructs. The Category is being set back to SV-AC with a status of Resolved. The current proposal is now ready for review by the Champions. |
|
Lisa Piper (developer) 2008-01-18 17:55 |
reopening to address feedback from the champions: 0001648 adds the following in 16.15: Furthermore, the default extends to any nested module, interface, or program declarations. I think that sentence should include nested generate blocks as well. The effect of a default disable iff item is independent of the position of the declaration within that scope.=20 For consistency, I think "item" should be "declaration" here. Declaring more than one default disable iff item within the same module, interface, program declaration, or generate scope shall be an error. I think 'generate scope' should be 'generate block'. // Disable condition is rst - no explicit specification, inferred from // default disable statement I think the 2nd line of the comment should be // default disable iff declaration |
|
John Havlicek (manager) 2008-01-22 07:45 |
On 2007-10-24, SV-CC sent mail that they had reviewed the proposal and found that version acceptable. |
|
Neil Korpusik (administrator) 2008-01-24 17:48 |
The Champions unanimously agreed to send the proposal back to the sv-ac for review in the Conference call of January 17th, 2008. At a minimum, the first issue needs to be addressed. 1. 0001648 adds the following in 16.15: (page 5) "Furthermore, the default extends to any nested module, interface, or program declarations." I think that sentence should include nested generate blocks as well 2. "The effect of a default disable iff item is independent of the position of the declaration within that scope." For consistency, I think "item" should be "declaration" here. There are 2 sentences there that call it an "item". "item" should be changed to "declaration" 3. "Declaring more than one default disable iff item within the same module, interface, program declaration, or generate scope shall be an error." I think 'generate scope' should be 'generate block'. 4. // Disable condition is rst - no explicit specification, inferred // from default disable statement I think the 2nd line of the comment should be // from default disable iff declaration |
|
John Havlicek (manager) 2008-02-05 10:25 edited on: 2008-02-05 10:25 |
2008-02-05: voice vote to approve the proposal dated 2008-01-31. 8y/0n/0a. This revision addresses all feedback from Champions. |
|
Neil Korpusik (administrator) 2008-04-05 17:32 |
The proposal was unanimously approved by the Champions in the conference call of March 20, 2008. |
|
Neil Korpusik (administrator) 2008-04-05 17:33 |
The proposal was unanimously approved by the Working Group in the conference call of March 27, 2008. |
|
Lisa Piper (developer) 2008-06-25 12:31 |
I have reviewed the changes in draft 6 and have the following comments: 1. Syntax 16-20 “default disable iff clocking_identifier ;” should be “default disable iff expression_or_dist ;” 2. The word “logic” in the following should be bold: module examples_with_default (input logic a, b, clk, rst, rst1); 3. In the following, the word “block” should be on the next line so there is a comment at the start // Only enable condition and clocking event are inferred from an always block // Assertion a8 is equivalent to 4. The word if-else should be in courier bold: “In assertion a8 the inferred enabling condition is from the else clause of the if-else statement,” |
|
Dmitry Korchemny (manager) 2008-07-01 03:20 |
The status was changed to "feedback" instead of "editor". Unrolling the status changes. |
|
Dmitry Korchemny (manager) 2008-07-01 03:24 |
Undoing previous status changes. |
|
Dmitry Korchemny (manager) 2008-07-01 03:25 |
Undoing previous status changes. |
|
Dmitry Korchemny (manager) 2008-07-01 03:26 |
See Lisa's comments above. |
|
Dmitry Korchemny (manager) 2008-07-01 09:10 |
One more note from Lisa. Syntax error in example, p. 400 of Draft 6 The example has default disable rst1; It should be default disable iff rst1; |
|
Dmitry Korchemny (manager) 2008-07-14 07:26 |
End of 16.16 The last comment of the last example has "always block", should be "always procedure" |
|
Stuart Sutherland (manager) 2008-09-01 04:21 |
Corrections noted in bug notes 0007089, 0007155 and 0007206 were added in draft 7, except for item "4". The "if-else" should not be in courier-bold font. It is referring to the decision construct, not the keywords "if" and "else". |
|
John Havlicek (manager) 2008-09-20 13:59 |
Draft 7 Review: 1648 (bug notes 7089 and 7206) . In 16.16, I think that assertion a8, the always procedure that contains it, and the preceding comment should be deleted. This is because concurrent assertions in procedural code have been changed by SV-SC, and this example is not consistent with those changes. |
|
Stuart Sutherland (manager) 2008-10-01 18:52 |
The changes requested in bug note 7535 were implemented in draft 7a. |
|
Dmitry Korchemny (manager) 2008-10-27 01:56 |
The last paragraph should be deleted (see 0002398 bug note 7544): "In assertion a8 the inferred enabling condition is from the else clause of the if-else statement, and thus it has to represent the complementary interpretation of the four-valued expression in the if condition. One such form is as indicated in the comment above a8. Other equivalent forms may be used, such as ((rst != 'b0) !== 1'b1). |
|
Stuart Sutherland (manager) 2008-12-02 21:44 |
The changes requested in bug note 7685 were implemented in draft 8. |
|
Dmitry Korchemny (manager) 2008-12-21 09:01 |
Verified. |
|
Dmitry Korchemny (manager) 2008-12-21 09:01 |
Verified. |
| Mantis 1.1.7[^] Copyright © 2000 - 2008 Mantis Group |