Subject: More issues
From: Steven Sharp (sharp@cadence.com)
Date: Tue Dec 10 2002 - 16:51:10 PST
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.
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.
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?
Comments on Section 8
1. The unique and priority keywords appear to be synthesis attributes.
Verilog-2001 already added attributes, which can be used for such
things. The checks for unique and priority behavior at run-time
are potentially inefficient. And if someone wants them, that is
what assertions are for.
2. IEEE 1364-2001 already considered and rejected the do-while construct.
If SystemVerilog is going to claim to be based on the Verilog-2001
standard, it should be fixed so that it actually is based on it.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
This archive was generated by hypermail 2b28 : Tue Dec 10 2002 - 16:51:36 PST