Subject: [sv-bc] Proposal: Enumerated type proposal to enhance synthesis optimization potential
From: Evan Rosser (Evan.Rosser@synopsys.com)
Date: Sun Mar 16 2003 - 16:51:16 PST
Hello SV-BC members,
I've recently been looking at enum types in synthesis and thinking
about a way to modify or clarify the 3.1 draft LRM to preserve the
ability to do certain optimizations, given that out-of-range values may
be present. Attached is an initial proposal; there is a fuller
discussion at the end of the proposal.
I'll also send a second proposal which only adds new functionality to
the enum types, but doesn't modify any existing behavior.
I would welcome any feedback or suggestions.
Thanks,
Evan Rosser
Staff R&D Engineer, HDL Compiler
Synopsys, Inc.
Proposal to clarify casting of enumerated types, and modify semantics
of comparisons of out-of-range values.
1. ADD a new section between the existing 3.11.3 and 3.11.4:
Enumerated types in comparison expressions
When two expressions of the same enumerated type are the operands of a
relational, equality, or inequality operator, or are compared via a
case statement, then if either of the expressions yields an out of
range value, the result of the comparison shall be undefined.
2. CHANGE in 3.11.3
"thus, a variable of type enum cannot be assigned a value that lies
outside the enumeration set."
TO
"thus, a variable of type enum cannot be assigned a value that lies
outside the enumeration set unless an explicit cast is used, or unless
the enum variable is a member of a union."
3. CHANGE in section 3.15
"Without this type of cast, the assignment is illegal."
TO
"Without this cast, or the static cast described below, the
assignment is illegal"
Discussion
The second and third changes only clarify out-of-range casts and bring
the description into better agreement with EC-CH27.
The third change has important implications for synthesis. Without
this change, some significant synthesis optimizations that could take
advantage of an enumerated type will not be possible, because of the
ability to put out-of-range values into enums.
For example, if a module port has an enum type, currently a compiler
cannot make the assumption that values seen on that port will be only
from the set of enumerated values. This prevents automatic detection
of unique case and if statements, as well as simplifying the logic for
comparisons using a known set of possible values.
Because the change only applies to comparisons in which both operands
have the same enumerated type, this doesn't prevent the user from
comparing an enum variable containing an out-of-range value against an
int expression containing the same value.
The description of casting to an out of range value already includes
language which suggests that although static casts aren't checked,
that it's not intended as a feature, only a performance improvement:
"If users know that it is safe to assign certain expressions to an
enumerated variable, the faster static compile-time cast can be used."
The primary benefit is in case statements, so an alternate proposal
would be to only make this change for the comparisons that they
generate. However, that inconsistency might cause confusion.
If these changes aren't made, enums still have some usefulness as a
programming aid, but don't supply more information to the compiler
about the possible values more int declarations do. Today, synthesis
pragmas permit these optimizations; under the current enum proposal,
tools would still require analogous attributes or pragmas identifying
which enum variables are "true" enums, and can be relied upon to
contain only enum values.
Comments and suggestions are welcome,
Evan Rosser
This archive was generated by hypermail 2b28 : Sun Mar 16 2003 - 16:51:49 PST