Subject: Re: More issues
From: Dave Rich (David.Rich@synopsys.com)
Date: Thu Dec 26 2002 - 11:22:22 PST
Steven,
As I mentioned in an earlier post, for good or bad, SystemVerilog
follows all the semantics of an established and well documented ANSI C
standard except pointers and bit fields. Trying to place restrictions on
certain features will only make matters more complicated for the user.
See my comments below. Where I think everyone will agree, I will
propose LRM changes in separate posts so we can quickly get them out of
the way.
Dave
Steven Sharp wrote:
>I finally got around to continuing my review of SV 3.0 beyond Section 5.
>
>Steven Sharp
>sharp@cadence.com
>
>
>------------------------------------------------------------------------
>
>Issues with System Verilog Specification (cont.)
>
>
>Comments on Section 7
>
>1. Treating assignments as expressions is a bad idea. Just because something
> is done in C doesn't mean it has to be copied. Expression side-effects
> are undesirable in Verilog because they mess up the combinational behavior
> of continuous assignments. We should not be deliberately adding more
> side-effects to cause problems.
>
This feature is frequently used in while loops to test the return value
of a function. Also used to set a group of variables to the same value.
Combinational behavior is a matter of synthesis style. Those tools are
free to accept or reject assignments as expressions.
>2. The increment and decrement operators also introduce side-effects, as
> defined in the 3.0 document. This is bad. Treating them as assignment
> statements instead of expressions would solve this. It would still allow
> their use in for-loop increments, which is the main place they would be
> useful. Most of the "clever" uses of increment operators in C code are
> poor programming style. Only allowing these as statements would also
> resolve all the issues of evaluation order that have arisen over these
> as operators.
>
>
What about as a bit select index?:
word = mem[i++];
Someone had suggested earlier that we allow only one assignment to the
same variable per statement unit.
>3. Section 7.7 does not explain the signedness of an assignment statement
> when used as an expression. If a signed expression is assigned to an
> unsigned variable, what is the result type of the assignment?
>
I agree this is unclear. ANSI C says that the lvalue is used as the type
of the expression. SystemVerilog should do the same.
>3. Section 8.4 states that a local variable declared within a for-loop
> can be referenced hierarchically by adding a statement label before
> the for-loop. And yet section 8.6 states that a statement label does
> not create a hierarchy scope. This is a contradiction. If it is a
> special exception, then it is a nasty kludge.
>
I agree there is a contradiction here. The original Superlog donation
explicitly said that:
A: statement;
is equivalent to:
begin: A statement; end
I believe that is the way it is supposed to be. I did not see any
discussion in the Verilog++ committee so I am going under the assumption
that this is typo.
>
>4. If a local variable is declared within a for-loop without a statement
> label, then it has no hierarchical name. This is a problem which has
> been raised for declarations in unnamed blocks too.
>
This is no different than for unnamed instances. Tools can automatically
generate block names for debugging. However, the source code will not be
able to cross reference these identifiers in unnamed blocks.
>5. Statement labels don't allow anything that named blocks don't already
> allow. Disables should be discouraged, not encouraged by adding another
> way of doing the same thing.
>
Statement labels are useful for assertions and process control. By
printing out scope information, assertion failures or other errors would
be more useful then just file/line#. You don't want to end up with code
that looks like
begin // or fork
begin :A
statement;
end
begin : B
statement;
end
end //or join
>6. Section 8.8 states that disables shall not affect any nonblocking
> assignments which have been started. This is incompatible with the
> IEEE 1364 standard, which allows either behavior. Verilog-XL disables
> nonblocking assignments which were started in the disabled block.
> Apparently some simulators failed to do so, and the IEEE standard
> relaxed the requirements to allow those simulators to be compliant.
> If the rules are being tightened up, then it should be standardized
> on the original de facto standard behavior. It is fine for continue
> and break to be simple jumps, since this is not a backward compatibility
> issue.
>
I agree this should be tightened up. As the author of the non-blocking
assignment operator, I would love to see this fixed. Disables should
kill of all pending assignments. NBAs are supposed to eliminate
ambiguity. If a disable occurs on the same clock edge as the NBA, you
want to have unambiguous behavior.
>7. Section 8.8 says nothing about the effect of disables (or breaks and
> continues) on other subprocesses like procedural continuous assigns
> and forces. Verilog-XL disables all of them, and IEEE 1364 leaves
> the behavior unspecified.
>
SystemVerilog does not change the behavior of disable(other than #6
above). The LRM was only trying to relate the behavior of break and
continue to an equivalent disable statement, but failed.
>8. What happens when a break or continue is executed from a fork-join
> subprocess inside a loop? Execution is not allowed to continue from
> the fork-join until all subprocesses are complete. Does this require
> that the fork-join be effectively disabled? Or is something else
> required?
>
I agree that this is unclear. I suggest two possible solutions. One
solution is to define break, continue, and return in terms of their
equivalent disable representation. This would take care of all the
situation you describe. For example:
SV: loop_statement break;
V: begin: _break loop_statement disable _break; end
SV: loop_statement continue;
V: loop_statement begin: _continue disable _continue; end
SV: task mytask; return; endtask
V: task mytask begin: _return disable _return end endtask
An alternative is to define break, continue and return as just branching
statements. Then you will have to put restrictions like break can only
be invoked from the same thread as the original loop. The situation you
describe would have to be illegal.
>9. What happens if a break or continue is executed from a dynamic process
> inside a loop? Execution is supposed to terminate when reaching the
> end of the process. Is this illegal, or does it cause termination of
> the process, or something else?
>
Same issue as #8
>10. Is the iff qualifier really useful? The example uses can be done
> just as well with an if-test around the body of the always block.
>
This feature will have more benefits in the SV3.1 spec for declaring
gated clocking domains.
>
>11. Section 8.9 defines posedge and negedge in a manner incompatible
> with IEEE 1364. SV defines them as transitions from and to a value
> of 0. IEEE 1364 defines them as transitions on the lowest bit of
> a multi-bit value, not based on all bits.
>
It sounds like 1364-2001 make it useless to have a multi-bit value
qualified by posedge/negedge.
>12. The "changed" keyword is unnecessary and meaningless. The situation
> that it supposedly avoids is non-existent. Perhaps someone was aware
> of an old bug in Verilog-XL that would trigger on changes to operands
> that did not change the expression value. That bug was fixed eons ago.
> This keyword should be thrown away.
>
I agree. "changed" should be removed
>13. Section 8.9 notes that assignment expressions are allowed in an event
> control. It does not specify at what times the assignment will be
> executed. Presumably it will be evaluated whenever an operand of the
> RHS has changed, to determine whether its value has changed. Different
> simulators may evaluate the RHS in different circumstances, as long as
> they all guarantee to wake the event control up if the RHS value changes.
> This construct would make this unspecified behavior visible to the user
> through the side effect of changing the value of the LHS. This is another
> situation where the side-effects of assignments within expressions causes
> a problem.
>
Same issue as #1
-- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Thu Dec 26 2002 - 11:22:56 PST