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
0002642 [SystemVerilog P1800] SV-BC minor 2009-04-06 14:02 2009-07-10 09:00
Reporter chas View Status public  
Assigned To
Priority normal Resolution reopened  
Status feedback   Product Version P1800-2009/D8 Ballot
Summary 0002642: Ballot comment #151 Need a similar rule for disabled SystemVerilog functions in section 9.6.2
Description Item d, of the disable protocol states "d) Once an imported subroutine enters the disabled state, it is illegal for the current function call to
make any further calls to exported subroutines."

See page 859 (893) in clause 35.9 from the 2009 ballot draft 1.
Additional Information Proposed change from the ballot comment:
A similar rule should be defined for disabled SystemVerilog functions in Section 9.6.2, Page 167(201). The rule should say: "A disabled SystemVerilog function should return immediately without executing any further statements." Currently, this section states that the behavior for a disabled function is undefined.
Tags No tags attached.
Type Enhancement
Attached Files

- Relationships
related to 0002643feedback Ballot comment #152 Section implies that a SystemVerilog function cannot be disabled 
related to 0000219new disable/return and fork-join/join_any/join_none 
child of 0002685new Master issue for SV-BC Ballot comment issues 

-  Notes
User avatar (0007956)
shalom (manager)
2009-04-06 23:42

 9.6.2 currently says,

"The disable statement can be used within blocks and tasks to disable the particular block or task containing the disable statement. The disable statement can be used to disable named blocks within a function, but cannot
be used to disable functions. In cases where a disable statement within a function disables a block or a task that called the function, the behavior is undefined."

Should this comment be transferred to SV-BC?
User avatar (0008104)
mmaidment (manager)
2009-05-03 23:42

 On April 27, 2009 the SV-BC read and considered this feedback. The committee believes it is too broad for the scope of the draft to implement at this time but may be considered for future revisions.
User avatar (0008277)
Neil Korpusik (administrator)
2009-05-16 19:31

 The resolution of "open" was unanimously approved by the
Champions in the email vote that ended on May 14th, 2009.
User avatar (0008428)
Neil Korpusik (administrator)
2009-06-01 10:29

 The resolution of "open" was unanimously approved by the
Working Group in the conference call of May 28, 2009.

Closing this mantis time.
User avatar (0008890)
Dave Rich (manager)
2009-07-10 09:00

 Rather than create a new mantis issue, this will be left in the feedback state for the committee to deal with in the next PAR.

- Issue History
Date Modified Username Field Change
2009-04-06 14:02 chas New Issue
2009-04-06 14:02 chas Type => Errata
2009-04-06 23:18 shalom Issue Monitored: shalom
2009-04-06 23:42 shalom Note Added: 0007956
2009-04-06 23:44 shalom Relationship added related to 0002643
2009-04-10 08:52 chas Category SV-CC => SV-BC
2009-04-13 03:44 shalom Relationship added child of 0002685
2009-04-27 09:57 Brad Pierce Relationship added related to 0000219
2009-05-03 23:42 mmaidment Type Errata => Enhancement
2009-05-03 23:42 mmaidment Note Added: 0008104
2009-05-03 23:42 mmaidment Status new => resolved
2009-05-16 19:31 Neil Korpusik Note Added: 0008277
2009-06-01 10:29 Neil Korpusik Note Added: 0008428
2009-06-01 10:29 Neil Korpusik Status resolved => closed
2009-06-01 10:30 Neil Korpusik Resolution open => fixed
2009-06-01 10:31 Neil Korpusik Resolution fixed => open
2009-07-10 09:00 Dave Rich Note Added: 0008890
2009-07-10 09:00 Dave Rich Status closed => feedback
2009-07-10 09:00 Dave Rich Resolution open => reopened

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