Subject: Further issues (mostly for SV-BC)
From: Steven Sharp (sharp@cadence.com)
Date: Mon Jul 08 2002 - 11:14:16 PDT
These are further issues that I have come up with in reviewing sections 3
through 5. There will undoubtedly be more as I continue reviewing. Since
the SV-BC reflector is not really working yet, I am sending this to other
lists also. If you are not involved in these issues, or end up with multiple
copies, I apologize for the inconvenience.
Steven Sharp
sharp@cadence.com
Issues with System Verilog Specification (cont.)
Further Comments on Section 3
1. The functionality of the new integer data types can be gotten
without introducing new reserved words, by using typedef. For
example, the byte can be typedeffed as a packed array of 8 bits.
A common include file could be used to define all of these types,
and included whenever they were wanted. There is no reason to
predefine these in the language.
2. The section on enumerated types states that it is an error to
assign a name with an x or z value to an enum with no explicit
data type (i.e. defaulting to the 2-state int type). It states
that such assignments shall be permitted for 4-state types. It
does not state whether such an assignment is permitted for an
enum declared with an explicit 2-state type.
3. The section on enumerated types states that it is an error for
an automatically incremented value to be assigned elsewhere in the
same enumeration. It is not clear whether the same value can be
assigned twice using explicit values. Was the intent to avoid
duplicates, or just to avoid non-obvious duplicates?
4. What happens when an automatically incremented value overflows
the width of the enumerated type? Is this an error? Is it only
an error if the overflow leads to a duplicate value?
5. The section on enumerated types states that the type is checked
in assignments, arguments, and relational operators. It does not
state what is being checked, what is not being allowed, or what is
supposed to happen if the check fails.
6. It is awkward that struct/union references use the same syntax
as hierarchical paths. If the first element in a name is not a
local name, it is not clear which elements in the name are path
elements, and which are field names. This cannot be resolved until
elaboration, which is inconvenient. If the name of a struct
variable is misspelled, this cannot be determined at parse time,
since it could be a hierarchical names.
Comments on Section 5
1. The proposed "static" keyword and functionality was explicitly
rejected for the IEEE Verilog-2001 standard. None of the reasons
for that have changed, so there is no reason to believe that it
would be accepted for any future IEEE Verilog standard.
2. Are automatic variables expected to have any useful purpose
outside of tasks, functions and dynamic processes? Nothing
else is re-entrant, so what could be the intended use? They
seem particularly confusing and dangerous in static tasks and
functions.
3. In section 5.4, it is stated that variable initialization does
not generate an event. It is not clear whether it is expected that
continuous assignments will be evaluated to propagate the initial
values. Note that the lack of an event could produce unexpected
behavior after initialization.
4. Initialization of large automatic structs or arrays every time
the scope is entered could have bad effects on performance, which
may not be realized by many users. However, a lot of this problem
already exists in Verilog-2001 without explicit initializers,
because of the implicit initializations.
5. Section 5.5 states that automatic variables cannot be used to
trigger an event expression. It should be noted that this is more
restrictive than the Verilog-2001 rule. If the intent was to match
Verilog-2001, then this is incorrect. If it is deliberately more
restrictive for ease of implementation, then this is a good change.
6. The logic type appears to be superfluous. Its capabilities are
a subset of regs and nets. The supposed flexibility of being able
to declare an object as logic and then change its usage between a
reg and a net is of limited value. Changing the declaration when
the usage changes is trivial compared to the usage changes. If
you are going to change between a continuous assignment and a
combinational always block, changing the output net to a reg is
a trivial part of the change. In exchange for that minor convenience,
you have the confusion that two different objects that appear to
be the same type (logic) may actually behave differently (as a reg
or a wire). Concerns about efficiency of nets, which have strength,
and logic used as a net, which doesn't, are misplaced. Vector nets,
if used under the same restrictions as logic, can leave out the
strength and simulate just as efficiently. And port collapsing makes
nets more efficient, but does not appear to be possible for logic
variables.
7. The logic type when used as a net has many of the properties of a
net. However, it is not clear how similar it is. For example, is
port collapsing possible, or must all port connections involving logic
variables be implemented with continuous assignments? Can a logic
variable be connected to an inout port? Can a continuous assignment
or port drive a bit select or part select of a logic variable? Do port
directions get coerced for logic variables if they turn out to be wrong
for the location of the driver? Can timing features such as path
delays or interconnect delays be applied to logic variables?
8. When a logic variable is being driven by a port or continuous assign
(i.e. it is acting as a net), is it allowed to have an initializer, or
is that only allowed when it is used like a reg? Note that a logic
"net" could pass through multiple levels of hierarchy and be initialized
with different values at each level. This inconsistent state would
presumably remain until an event managed to propagate through the
hierarchy.
9. A logic variable can be driven by a primitive. Does this include the
MOS switch primitives, which explicitly pass strength? Does it include
tran and tranif primitives, which are bidirectional and pass strength?
This archive was generated by hypermail 2b28 : Mon Jul 08 2002 - 11:16:11 PDT