Two fixes needed:
- when searching for a base class, we need to look in the root scope
if the base class isn't found in the scope hierarchy
- the classes in the root scope need to be stored in an ordered
list, not a map, to ensure they are elaborated in the order they
were declared. Without this, the compiler may try elaborating an
extended class before its base class is known about.
(cherry picked from commit 87cddf33dc)
SystemVerilog allows tasks, functions, and classes to be defined at the
root level or inside packages, so we can't rely on an enclosing module
being present to provide the timescale.
(cherry picked from commit 7bed181f68)
When checking that an enumeration value is in range we need to cast it to
a 2-state value so that when we compare it we get a true or false value
instead of an undefined value. Undefined bits in the comparison return
undefined which is not logically false.
We need the scope where the class is defined so that it can find
types in that containing scope. Note that most definitions cannot
escape into the the lexical scope of the class, but some can.
This patch fixes the following enumeration bugs:
When looking for an enumeration look in the current scope and then
recursively in any parent scope.
Add enumeration definitions to a package scope.
The verinum arithmetic operators now observe the standard Verilog
rules for calculating the result width if all operands are sized.
If any operand is unsized, the result is lossless, as before.
They also now all observe the standard rules for handling partially
undefined operands (if any operand bit is 'x', the entire result is
'x').
I've also added the unary '-' operator, and renamed v_not() to be
the unary '~' operator. This has allowed some simplification in
other parts of the compiler.
When a module is instantiated multiple times, the enum
types contained within would cause trouble. This fixes
that by elaborating in proper scope context.
There were also some subtleties related to using enumerations
from typedefs and using them in multiple places. Fix various
bugs related to those issues.
It is better to leave the handling of PChainConstructor calls to
the elaboration, instead of stripping them out early. This allows
for handling the arguments of the chain constructor in the correct
scope.
Class types that have both implicit construction and
an explicit constructor can blend the implicit and
explicit construction into the "new" function defined
by the user. This doesn't change the behavior any, but
removes a function call and related scope.
Johann Klammer
Martin Whitaker
Larry Doolittle
Stephen Williams
Cary R