SV-BC, The Champions have sent 1809 and 2097 back to us. We also have to re-approve 2106 and 2163 and to vote on 1772. Thanks, Shalom -----Original Message----- From: Accellera Mantis Bug Tracker [mailto:mantis@server.eda-stds.org] Sent: Friday, January 25, 2008 3:24 AM To: Bresticker, Shalom Subject: [SystemVerilog P1800 0002097]: release/deassign with variables driven by continuous assignments The following issue has been set as RELATED TO issue 0002235. ====================================================================== http://www.eda-stds.org/svdb/view.php?id=2097 ====================================================================== Reported By: Dave Rich Assigned To: shalom ====================================================================== Project: SystemVerilog P1800 Issue ID: 2097 Category: SV-BC Reproducibility: always Severity: minor Priority: immediate Status: feedback Type: Errata ====================================================================== Date Submitted: 2007-10-10 22:09 PDT Last Modified: 2008-01-24 17:23 PST ====================================================================== Summary: release/deassign with variables driven by continuous assignments Description: In section 10.6.1 there is a question from the editor: Does the result of a cont. assign to a variable update immediately when the variable is released? The answer is in 6.5 "A release statement shall not change the variable until there is another procedural assignment or shall schedule a reevaluation of the continuous assignment driving it." and probably should have been moved to 10.6 So the text in 10.6.1 and 10.6.2 is incorrect. It will schedule an evaluation upon release, not wait for the next event that causes an evaluation. ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001132 allow force on memory word or bit-/part... related to 0002235 Clarifications needed for "ref&quo... has duplicate 0002152 Bogus statement re. force/release behav... related to 0002169 part-select terminology fuzzy related to 0002221 "unpacked array reference" is... child of 0002099 DRAFT 4 EDITOR QUESTIONS ====================================================================== ---------------------------------------------------------------------- shalom - 2007-10-11 09:45 ---------------------------------------------------------------------- I agree with your conclusion. But I think the text in 6.5 is unclear. It should say something to the effect that if the variable is driven by a continuous assignment, then as you say, deassign/release of the variable will cause an immediate re-evaluation of the continuous assignment. Actually, is it legal to do a procedural continuous assignment to a variable driven by a continuous assignment? I thought not. And if not, then that entire part of the text in 10.6.1 should be deleted. Note that the extra text in 10.6.1 and 10.6.2, "or the next time a continuous assignment driving the variable is evaluated," was added by the editor in the LRM merge in an attempt to update the 1364 text to SystemVerilog. The editor added his question on the side from the very beginning, so it is not his fault that this text has remained till now. ---------------------------------------------------------------------- Dave Rich - 2007-10-11 13:27 ---------------------------------------------------------------------- It is not legal to use a procedural continuous assignment on a variable that is being continuously assigned. That would be a case of mixing assignments. Proposal moves the text in 6.5 into an updated 10.6.1 and 10.6.2. ---------------------------------------------------------------------- shalom - 2007-10-28 09:13 ---------------------------------------------------------------------- Brad: Is 'singular' being used in the usual LMR meaning here, and, if so, why wouldn't a concatenation of variables need to be a concatenation of singular variables in the following "The left-hand side of the assignment in the assign statement shall be a singular variable reference or a concatenation of variables."? And apparently, {{a,b},{c,d}} would not be a legal target of a procedural continuous assign? ---------------------------------------------------------------------- Steven Sharp - 2007-12-01 15:16 ---------------------------------------------------------------------- Some wording in this proposal seems to be allowing forces of parts of variables, and I have problems with that. Examples of such wording include the removal of "unpacked array reference" from the things that shall not be forced, and the sentence that refers to a force being applied to "the selected part of a variable". Such a change would have severe consequences, and I would oppose it. It definitely should not be slipped in as part of the wording of this proposal. ---------------------------------------------------------------------- shalom - 2007-12-06 06:50 ---------------------------------------------------------------------- I don't think the proposal allows forces of parts of variables. The removal of "unpacked array reference" is handled by adding the word 'singular' in "The left-hand side of the assignment can be a reference to singular variable, a net, a constant bit-select of a vector net, a constant part-select of a vector net, or a concatenation of these." That sentence also seems to make clear that a force to part of a variable is not allowed. I agree that the sentence about "A single force or release statement shall not be applied to the whole or the selected part of a variable that is being assigned by a mixture of continuous and procedural assignments," looks wrong. But that looks like an error in 1800-2005, which says essentially the same, "A single force or release statement shall not be applied to a whole or part of a variable that is being assigned by a mixture of continuous and procedural assignments," and it goes back to SV 3.1. ---------------------------------------------------------------------- shalom - 2007-12-09 00:58 ---------------------------------------------------------------------- I updated the proposal based on the comments at the Oct 29 meeting and recent emails. The changes relative to the original proposal are: (Words between **'s are struck out in the proposal from the current LRM text): 1. In the sentence in 10.6.1, "The assign procedural continuous assignment statement shall override all procedural assignments **or continuous assignment to a variable**," leave in the words "to a variable". 2. In the sentence in 10.6.1, "It shall not **be an unpacked array reference or** a bit-select or a part-select of a variable," leave in the word "be". 3. In 10.6.2, "The left-hand side of the assignment can be a reference to singular variable," add the word "a" before "singular". 4. In 10.6.2, the sentence, "The left-hand side of the assignment can be a reference to ... a constant part-select of a vector net..." remains unchanged. After http://www.eda-stds.org/svdb/view.php?id=2169, the phrase "constant part-select" now has the meaning which is desired here. 5. In 10.6.2, "Releasing a variable that currently has an active assign procedural continuous assignment shall cause an immediate reevaluation and reestablish that assignment.", changed "an immediate reevaluation" to "a reevaluation". 6. In 10.6.2, changed "A single force or release statement shall not be applied to the whole or the select part of a variable that is being assigned by a mixture of continuous and procedural assignments," to "A force or release statement shall not be applied to a variable that is being assigned by a mixture of continuous and procedural assignments." ---------------------------------------------------------------------- Jim Vellenga - 2007-12-10 14:36 ---------------------------------------------------------------------- I disagree with Shalom's interpretation that "a singular variable" does not include a reference to a member of an unpacked array variable. In fact, "6.4 Singular and aggregate types" says that "some functions recursively descend into an aggregate variable until reaching a singular value and then perform an operation on each singular value." Since the preceding paragraph identifies an unpacked array as belonging to an aggregate type, and any integral type as inherently "singular", this implies that a singular variable includes members of arrays when the member is of an integral type. Thus, as Steve Sharp noted, this allows a member of an array to serve as the left-hand side of a force, release, assign, or deassign, and is a major change to currently supported functionality. In fact, if we read it carefully, it also allows members of structs and unions to serve as the left-hand side of such statements. ---------------------------------------------------------------------- mmaidment - 2008-01-07 00:25 ---------------------------------------------------------------------- The SV-BC unanimously approved the attached proposal via e-mail vote that closed December 17, 2007. ---------------------------------------------------------------------- Neil Korpusik - 2008-01-24 17:22 ---------------------------------------------------------------------- The proposal was sent back to the SV-BC by the Champions in the January 17th, 2008 conference call. The latest Email thread concerning Mantis item 2235 needs to be addressed. Issue History Date Modified Username Field Change ====================================================================== 2007-10-10 22:09Dave Rich New Issue 2007-10-10 22:09Dave Rich Type => Errata 2007-10-11 00:17shalom Issue Monitored: shalom 2007-10-11 09:40Dave Rich Relationship added child of 0002099 2007-10-11 09:45shalom Note Added: 0004931 2007-10-11 13:19Dave Rich File Added: 2097_release.pdf 2007-10-11 13:27Dave Rich Note Added: 0004933 2007-10-11 13:27Dave Rich Assigned To => Dave Rich 2007-10-11 13:27Dave Rich Priority normal => immediate 2007-10-11 13:27Dave Rich Status new => assigned 2007-10-11 13:27Dave Rich Additional Information Updated 2007-10-25 13:17shalom Relationship added has duplicate 0002152 2007-10-28 09:13shalom Note Added: 0005038 2007-10-30 09:01shalom Assigned To Dave Rich => shalom 2007-10-30 09:01shalom Priority immediate => high 2007-10-31 02:19shalom Relationship added related to 0002169 2007-10-31 03:35shalom File Added: 2097_D4_release.shalom.htm 2007-10-31 03:40shalom File Deleted: 2097_D4_release.shalom.htm 2007-10-31 03:40shalom File Added: 2097_D4_release.shalom.htm 2007-10-31 03:44shalom File Deleted: 2097_D4_release.shalom.htm 2007-12-01 15:16Steven Sharp Note Added: 0005435 2007-12-06 06:50shalom Note Added: 0005473 2007-12-08 09:06Brad Pierce Relationship added related to 0001132 2007-12-09 00:38shalom File Added: 2097_D4_release.V2.htm 2007-12-09 00:58shalom Note Added: 0005482 2007-12-09 05:51shalom Relationship added related to 0002221 2007-12-09 05:53shalom Priority high => immediate 2007-12-10 11:16Jim Vellenga Note Added: 0005485 2007-12-10 11:18Jim Vellenga Issue Monitored: Jim Vellenga 2007-12-10 14:36shalom Note Edited: 0005485 2007-12-11 08:01shalom File Added: 2097_D4_release.V3.htm 2007-12-13 02:33shalom File Added: 2097_D4_release.V4.htm 2008-01-07 00:25mmaidment Note Added: 0005657 2008-01-07 00:25mmaidment Status assigned => resolved 2008-01-07 00:25mmaidment Resolution open => fixed 2008-01-24 17:22Neil Korpusik Status resolved => feedback 2008-01-24 17:22Neil Korpusik Resolution fixed => reopened 2008-01-24 17:22Neil Korpusik Note Added: 0005796 2008-01-24 17:23Neil Korpusik Relationship added related to 0002235 ====================================================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jan 24 21:38:02 2008
This archive was generated by hypermail 2.1.8 : Thu Jan 24 2008 - 21:38:42 PST