These test verify that explicit cast to packed array and packed struct
types are supported and executed correctly.
The tests are based on the test for integer casts. Just the type of the
variables was changed to packed array and packed struct respectively.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Update the enum cast test to reflect that enum casts are now supported.
Also add a small check to verify that the right value got assigned to the
enum after the cast.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Assigning a value to an enum signal that is not of the same type as the
enum requires an explicit cast.
To support this attach the type of a type cast to the resulting expression.
This allows the assignment elaboration to confirm that value has been
explicitly cast to the right type.
Also handle the case where the value is a constant. In this case create a
NetEConstEnum instead of a NetEConst as the resulting expression.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The scope_ field of the NetEConstEnum class is initialized in the
constructor, but never used anywhere again. Remove it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently explicit cast is supported to atom2 and vector types. packed
struct, packed array and enum are not supported.
An explicit cast to packed type works the same for all packed types though.
Add support for handling also packed structs, packed arrays and enums by
make the code more generic and querying the packed base type from the
ivl_type_t.
To correctly handle enums a bit more work is necessary, which will be done
in a follow up patch.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Mark them as NI so that in the fugure they might be turned back
on if they can be made to work. Keep the tests around as reference.
Also, remove reports that are no longer tested in CI. This is because
they are no longer tested by a previous patch that relies on the
change vvp_reg.pl behavior around failed tests.
Remove now obsolete update_msys2_report.pl, and simplify the test.sh
script, since diff commands and Windows specific trickery are no
longer needed.
If there are any failures, return a non-zero exit status so that
invoking scripts can detect that failures happen. This eliminates
the need to use regression report reference outputs, and should
make it easier to merge PRs that add or impact tests.
Add a test that checks that signing annotations on structs are supported
and that signed structs are properly evaluated as a signed value.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
packed structs and packed unions as a whole can either be signed or
unsigned. This information is used when it is used as a primary in an
expression, i.e. without accessing any of the members.
Add support for parsing and elaborating signed structs.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Extend the array_packed test to check declaring a packed array of a type
from another scope that is addressed via a scoped identifier.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
It is possible to directly declare a packed array of a struct or enum
without having to create a typedef first.
Add a check to the array_packed test that this is supported and works as
expected.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Allow scoped identifiers to be used as the base type for packed array
types. Scoped type identifiers can be used the same way as unscoped type
identifiers.
E.g.
```
package p;
typedef logic [1:0] vector;
endpackage
module test;
p::vector [1:0] pa;
endmodule
```
is a valid construct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
It is possible to directly declare a packed array of a struct or enum,
without having to typedef the struct or enum first. E.g.
```
struct packed {
int x;
} [1:0] pa;
```
Add support to the parser for handling this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
These tests check that a enum that is declared in a struct or class are
correctly elaborated and also name collisions with the enum names are
detected.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When creating an enum type it must be added to the scope where it is
declared so it can later be elaborated and the enum and its names can be
referenced in expressions.
In addition the names of the enum must be added to the lexor scope so that
name collisions are detected and can be reported as errors.
This is done with pform_put_enum_type_in_scope() function.
At the moment the function is called from two different places
* When adding a typedef of a enum type
* When creating a signal of a enum type
In addition the enum_type_t is added to a class scope `enum_sets` when
declaring a enum property in a class. But this only makes sure that the
enum gets elaborated, its names are not added to the lexor scope.
This works fine for the most part, but breaks for a few corner cases.
E.g. it is possible to declare a enum type as part of the subtype of
another packed type such as structs or packed arrays. E.g.
```
struct packed {
enum {
A
} e;
} s;
```
This is not covered by either of the cases above and neither do the names
of the enum get added to the lexor scope, nor is the enum type elaborated.
Another corner case that is currently not working is declaring a class
property where the type is a typedef of a enum that is declared outside of
the class. In this case the enum is elaborated again inside the class
scope. E.g. the below is supposed to work, but fails with an already
declared symbol error.
```
typedef enum {
A
} e_t;
class C;
typedef enum {
A
} e1;
e_t e2;
endclass
```
In addition since for enums declared in classes they are only added to
`enum_sets`, but names are not added to the lexor scope, it is possible to
declare a different symbol in the class scope with the same name.
E.g. the following elaborates fine
```
class C;
enum {
A
} e;
typedef int A;
endclass
```
To fix this call pform_put_enum_type_in_scope() when the enum_type_t is
created in the parser. This makes sure that it is handled the same
regardless where the type is declared or used.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Refactor the enum rule by adding a enum_base_type rule which handles the
type specific initialization. This allows to keep the non-type specific
parts in a common rule, which makes it easier to modify in future changes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The test checks that all invalid declarations produce an error and also do
not crash the application.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When something goes wrong when parsing a struct member, e.g. the type does
not exist, a nullptr is added to the struct member list. This will cause a
crash when iterating over the list.
E.g.
```
struct packed {
logc x;
} s;
```
Add a check so that nullptr members are not added to the list.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
By adding ivtest to the iverilog source tree, it is easier to keep
the regression test synchronized with the source that is being tested.
This should be especially helpful for PRs that add a new feature, and
have a matching ivtest PR with the regression test for that feature.
Currently it is only possible to declare packed array variables with a
struct type as the element type.
Add support for packed arrays of other packed types. This includes packed
arrays of enums and vectors as well as packed arrays of packed arrays.
Since packed arrays of packed types are already supported for class members
the infrastructure for elaborating all types of packed arrays exists.
It just needs to be called when elaborating a signal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When creating a signal of a packed array it is checked that the base-type
of the packed array is a packed type.
But this check is only done if the packed array itself is the type of the
signal. Placing the packed array in a struct or class will elaborate fine,
but then crash during simulation.
E.g.
```
typedef real myreal;
struct packed {
myreal [1:0] p;
} s;
```
Move the check from signal creation to type elaboration, so that it is not
possible to create a packed type with a non-packed base-type.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use netrange_t, which is meant for storing ranges, for storing the range of
a netenum_t.
This makes the integration with the rest of the codebase a bit more
seamlessly and also allow to reuse methods defined for netrange_t such as
the width() method rather than having to reimplement it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Specifying and enum with an invalid dimension range results in an assert or
segfault. E.g. `enum [$] E { ... }`.
Use the `evaluate_ranges()` function to elaborate the enum dimensions. This
functions has proper error checking and recovery built-in.
In addition verify that there is at most one packed dimension.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Having an enum with a lsb > msb base type, e.g. `enum logic [0:9]` is a
legal construct.
It is handled correctly for the most part already, there is just an assert
that triggers on it. Remove that assert.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
To determine the base type structs and packed arrays call the
figure_packed_base_type() for their sub-types.
This method is not defined for enum or atom2 types and the default
implementation returns IVL_VT_NO_TYPE.
As a result packed arrays of enum or atom2 types and packed structs with
members of enum or atom2 types get elaborated with IVL_VT_NO_TYPE
as the base type.
For example
```
struct packed {
bit signed [31:0] x;
} s1;
```
gets elaborated with a base type of IVL_VT_BOOL, while
```
struct packed {
int x;
} s2;
```
gets elaborated with a base type of IVL_VT_NONE.
To fix this define the figure_packed_base_type() for enum_type_t and
atom2_type_t.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Trying to elaborate a type with invalid packed dimensions currently results
in a crash. E.g. `typedef logic [] T;`
The issue is in the `elaborate_array_ranges()` function which
does not verify that the range specification is valid.
Replace the `elaborate_array_ranges()` with `evaluate_ranges()`, which does
the same thing, but properly checks the range specification and
reports an error if it is invalid.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If the left-hand side of a logical operator is a constant that causes the
right-hand side to be short-circuited the right-hand side can be discarded
even if it is not constant.
In this case replace the expression by a constant.
E.g.
* `0 && expr` will be replaced by a constant 0.
* `1 || expr` will be replaced by a constant 1.
* `0 -> expr` will be replaced by a constant 1.
Note that it is not possible to replace the expression by a constant if
only the right-hand side is a constant, even when the value of the
expression is constant. The left side still has to be evaluated for side
effects.
E.g. it is known at elaboration that `a++ && 0` will yield 0, but the
increment on `a` has to be executed regardless.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Section 11.4.7 of the SystemVerilog LRM states
```
The && and || operators shall use short circuit evaluation as follows:
- The first operand expression shall always be evaluated.
- For &&, if the first operand value is logically false then the second operand shall not be evaluated.
- For ||, if the first operand value is logically true then the second operand shall not be evaluated.
```
vvp currently evaluates both operands of a logical operator. This works
fine as long as the right-hand side does not have a side effect. But if it
has the result might be incorrect.
E.g. for `a && b++` `b` must not be incremented if `a` evaluates to false.
The Verilog LRM mentions that it is allowed to short circuit any expression
"if the final result of an expression can be determined early". But there
is no requirement to do so.
So the new and the old behavior are both correct implementations in
Verilog.
Use the new behavior in both Verilog and SystemVerilog mode to make sure
the behavior is consistent when an expression has side effects.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The code for generating the logical `and` and `or` operators is identical
except for the final opcode to combine the two results.
Consolidate this into a single function to reduce the code a bit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Stephen Williams
Lars-Peter Clausen
Martin Whitaker
Miodrag Milanovic
Michael Singer