EDA.org Mantis
Mantis Bugtracker
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
0001468 [SystemVerilog P1800] SV-BC major 2006-05-11 16:28 2008-06-22 10:48
Reporter Brad Pierce View Status public  
Assigned To Thomas R Alsop
Priority immediate Resolution fixed  
Status closed   Product Version
Summary 0001468: always_latch has same restrictions as always_comb (11.3)
Description Doug asks in http://www.eda-stds.org/sv-bc/hm/1878.html [^]
 whether all of the restrictions of always_comb also apply to always_latch. I think they do, but this is not clear from the text of 11.3.

For example, it needs to be clearly stated that variables written on the LHS of assignments in always_latch cannot be written by any other process.

For example, it needs to be clearly stated that only the same subset of statement kinds is allowed in always_latch as in always_comb.
Additional Information
Tags No tags attached.
Type Errata
Attached Files htm file icon 1468_always_latch.htm [^] (40,556 bytes) 2007-08-31 15:50
htm file icon 1468_always_latch_V2.htm [^] (13,023 bytes) 2007-09-17 11:46
htm file icon 1468_always_latch_V3.htm [^] (12,776 bytes) 2007-09-21 13:35
htm file icon 1468_always_latch_V4.htm [^] (10,242 bytes) 2007-10-01 10:38
htm file icon 1468_always_latch_V5.htm [^] (10,163 bytes) 2007-10-15 09:42

- Relationships
related to 0000225new Definition of term "blocking statement" 
related to 0002031new 9.2.2.2.2: 'contents of a function' 
related to 0002081new Not clear enough which kinds of statements are prohibited in always_comb 
related to 0001828closedmmaidment JEITA: 9.2.2.3, 9.2.2.4 should/can and mandatory statements 

-  Notes
User avatar (0002827)
shalom (manager)
2006-08-05 19:50

 The statemeent in 11.2 that, "Statements in an always_comb shall not include those that block", could be misinterpreted to forbid blocking assignments.
User avatar (0002829)
Brad Pierce (developer)
2006-08-05 23:59

 The phrase "blocking statement" is used several times in the LRM without a definition. The language in this section about "those that block" was proposed in

    http://www.eda-stds.org/sv-bc/hm/1345.html [^]
User avatar (0002830)
shalom (manager)
2006-08-06 00:48

 In 1364, the term "blocking" is used only to refer to blocking assignments. In 1800, it is used in additional contexts.

Looks like this should be an additional Mantis, i.e., "What does blocking mean?"
User avatar (0003256)
shalom (manager)
2006-11-15 22:40

 See 225, 1561
User avatar (0004626)
Thomas R Alsop (administrator)
2007-09-17 11:49

 I have updated the proposal to more clearly word in the always_latch clause that all statements in the 9.2.2.2. (always_comb) apply to it as well and then I emphasize the design intent distinction.
User avatar (0004632)
shalom (manager)
2007-09-18 02:49

 I would be wary of writing, "The always_latch procedure is identical to the always_comb procedure," because of the difference in how tools should relate to their intents.

Also note that there is one statement in 9.2.2.2.2 that does not appear in 9.2.2.2:

"Statements in an always_comb shall not include those that block, have blocking timing or event controls, or fork–join statements."

It really should appear in 9.2.2.2.

Actually, I think a 5th-order sub-clause is really exaggerated. I would prefer to fold 9.2.2.2.1 and 9.2.2.2.2 into 9.2.2.2.
User avatar (0004945)
shalom (manager)
2007-10-14 05:46

 Cliff Cummings vote comments: SVDB 1468 Minor No
I would vote yes with the friendly amendment of replacing the personal pronoun "they" with "tools": "... , tools may check and warn if the behavior ..."
User avatar (0004958)
Thomas R Alsop (administrator)
2007-10-15 09:43

 Friendly update changing "they" to "tools" done at Cliff's request.
User avatar (0004998)
mmaidment (manager)
2007-10-22 00:00

 On October 15, 2007 the SV-BC unanimously approved the attached proposal.
User avatar (0005357)
Neil Korpusik (administrator)
2007-11-21 07:58

 The Champions approved the proposal in the Nov 8 conference call
(with 1 abstain - Stu didn't get a chance to review ahead of time).
User avatar (0005358)
Neil Korpusik (administrator)
2007-11-21 07:59

 The proposal was unanimously approved by the Working Group in the
November 15th, 2007 conference call.
User avatar (0006918)
shalom (manager)
2008-05-30 08:21

 The last "always_latch" in the proposal should be bold Courier.
User avatar (0006953)
Stuart Sutherland (manager)
2008-06-03 01:05

 The font error noted in bug note 6918 was corrected in Draft 6.

- Issue History
Date Modified Username Field Change
2006-05-11 16:28 Brad Pierce New Issue
2006-05-11 16:28 Brad Pierce Type => Errata
2006-05-12 08:57 shalom Issue Monitored: shalom
2006-06-25 07:11 Brad Pierce Description Updated
2006-08-05 13:05 Brad Pierce Status new => assigned
2006-08-05 13:05 Brad Pierce Assigned To => Brad Pierce
2006-08-05 19:50 shalom Note Added: 0002827
2006-08-05 23:59 Brad Pierce Note Added: 0002829
2006-08-06 00:48 shalom Note Added: 0002830
2006-11-15 22:40 shalom Note Added: 0003256
2007-02-05 11:28 mmaidment Status assigned => resolved
2007-02-05 11:28 mmaidment Resolution open => duplicate
2007-02-05 11:28 mmaidment Relationship added duplicate of 0000225
2007-02-05 11:30 mmaidment Status resolved => feedback
2007-02-05 11:30 mmaidment Resolution duplicate => reopened
2007-02-05 11:30 mmaidment Note Added: 0003394
2007-02-05 11:31 mmaidment Note Added: 0003395
2007-02-05 11:33 mmaidment Status feedback => resolved
2007-02-05 11:33 mmaidment Resolution reopened => duplicate
2007-03-05 01:11 mmaidment Status resolved => feedback
2007-03-05 01:11 mmaidment Resolution duplicate => reopened
2007-03-05 01:11 mmaidment Note Added: 0003505
2007-03-05 01:12 mmaidment Status feedback => assigned
2007-03-05 01:13 mmaidment Note Deleted: 0003395
2007-03-05 01:13 mmaidment Note Deleted: 0003505
2007-03-05 01:13 mmaidment Note Deleted: 0003394
2007-07-29 01:20 shalom Relationship deleted 0000225
2007-07-29 01:20 shalom Relationship added related to 0000225
2007-08-31 15:50 Brad Pierce File Added: 1468_always_latch.htm
2007-08-31 15:51 Brad Pierce Priority normal => immediate
2007-09-11 00:44 shalom Relationship added related to 0002031
2007-09-17 09:33 Brad Pierce Assigned To Brad Pierce => Thomas R Alsop
2007-09-17 09:33 Brad Pierce Priority immediate => normal
2007-09-17 11:46 Thomas R Alsop File Added: 1468_always_latch_V2.htm
2007-09-17 11:49 Thomas R Alsop Note Added: 0004626
2007-09-18 02:49 shalom Note Added: 0004632
2007-09-21 09:49 mmaidment Priority normal => immediate
2007-09-21 13:35 mmaidment File Added: 1468_always_latch_V3.htm
2007-10-01 10:38 Thomas R Alsop File Added: 1468_always_latch_V4.htm
2007-10-04 12:42 Brad Pierce Relationship added related to 0002081
2007-10-14 05:46 shalom Note Added: 0004945
2007-10-15 09:42 Thomas R Alsop File Added: 1468_always_latch_V5.htm
2007-10-15 09:43 Thomas R Alsop Note Added: 0004958
2007-10-22 00:00 mmaidment Note Added: 0004998
2007-10-22 00:00 mmaidment Duplicate ID 225 => 0
2007-10-22 00:00 mmaidment Status assigned => resolved
2007-10-22 00:00 mmaidment Resolution reopened => fixed
2007-11-21 07:58 Neil Korpusik Note Added: 0005357
2007-11-21 07:59 Neil Korpusik Note Added: 0005358
2007-11-21 07:59 Neil Korpusik Status resolved => approved
2008-02-04 11:03 mmaidment Relationship added related to 0001828
2008-04-15 22:11 Stuart Sutherland Status approved => completed
2008-04-15 22:11 Stuart Sutherland Fixed in Version => P1800-2008/D5
2008-05-30 08:21 shalom Note Added: 0006918
2008-05-30 08:21 shalom Status completed => editor
2008-06-03 01:05 Stuart Sutherland Status editor => completed
2008-06-03 01:05 Stuart Sutherland Fixed in Version P1800-2008/D5 => P1800-2008/D6
2008-06-03 01:05 Stuart Sutherland Note Added: 0006953
2008-06-22 10:48 Brad Pierce Status completed => closed

Mantis 1.1.7[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker