arith_expr_type() queries the expression type of its two child nodes up to two
times. Since the child nodes might also need to query their child nodes
expression type to determine their own this can lead to an exponential runtime.
For complex expressions this can easily result in very long elaboration time.
Avoid this by querying the expression type only once for each child node.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that it is possible to declare module ports with only partial
attributes. Other attributes should be inherited from the previous port in
the list or use the default.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In Verilog it is possible to declare multiple ports as part of the same
port declaration. Ports declared this way all have same direction, signal
kind and data type. E.g.
```
module M (input [3:0] a, b, c) ...
```
SystemVerilog extends this and allows to override on a per port basis
certain port attributes. E.g. redefine just the data type
```
module test (input [3:0] a, [1:0] b, int c) ...
```
Or to just redefine the port kind
```
module test(input [3:0] a, var b, wire c) ...
```
It is even possible to leave out the direction for the very first port. As
long as at least one other property of the port is specified. In that case
the direction will default to `inout`. E.g.
```
module test(integer a, b, c) ...
```
Furthermore it is possible to specify unpacked dimensions for each of the
ports. E.g.
```
module test(input integer a, b[1:0], c[3:0][1:0]) ...
```
If all port properties are omitted for the first port this indicates the
start of a non-ANSI port list.
Extend the parser to handle this.
If all three direction, port kind and data type are omitted they are
inherited from the previous port. Otherwise
* If the direction is omitted it is inherited from the previous port.
* If the data type is omitted it defaults to logic.
* If the port kind is omitted the behavior depends on the direction.
For output ports with an explicit data type it is a variable, for
all others it is a net.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Add a helper function to the parser that handles module port declaration.
This allows to reduce a bit of duplicated code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
`$bits()` for array types is supposed to return the full size of the array
in bits. This currently works for data types that are passed to `$bits()`,
but not for array typed identifiers.
E.g.
```
typedef int T[1:0];
T x;
$display($bits(T)); // -> 64
$display(x); // -> 32
```
Since the `$bits()` implementation uses the expr_width of an expression
include the size of the unpacked dimensions in that for array identifiers
and array slices. Strictly speaking an array identifier does not have an
expression width, but this would be its expression with if it were for
example bitstream cast to a vector.
Special care needs to be take to not trying to pad array identifier
expressions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Bit selects on packed arrays are always unsigned and have a width of 1.
Element selects on a multi-dimensional packed array are always unsigned and
have the width of the element.
At the moment a element or bit select on the last level element of a
multi-dimensional signed array will incorrectly yield a signed expression.
Commit 40b36337e2 ("Fix some bugs with packed array dimensions") added
some special checks to fix the width on multi-dimensional array element
selects. But this removed the unsigned attribute from bit selects.
Commit 81947edaa5 ("A bit select is not the same as selecting part of a
packed array") fixed this for single dimensional packed array, but left it
broken for multi-dimensional arrays.
Commit 7c024d6cab ("Fix width calculation for bit/part selects of
multi-dimensioned packed arrays.") added some additional fixes for the
width calculation, which make the special checks in the first commit
unnecessary.
We can now remove those checks which will give us the correct behavior in
terms of the signedness of bit and element selects on both single- and
multi-dimensional packed arrays.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
At the moment there are two rules for port declarations. One that allows
the port to be declared as an unpacked array, the other that allows to
specify an initializer expression.
SystemVerilog allows both to be specified in the same port declaration. Add
support for this to the parser.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The module_output_port_list_def declares a output port with an implicit
data type and assigns an initial value to it. Since output ports with an
implicit data type are nets this test is not standard compliant.
This only works because at the moment the parser incorrectly flags all
output ports with an initial value as variables rather than following the
method defined by the standard to decide whether the port should be a net
or variable.
Make the test standard compliant by using an explicit data type for the
output port, in which case it will be a variable.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The currently used checkout@v2 CI action shows the following deprecation
warning
```
Node.js 12 actions are deprecated. Please update the following actions to
use Node.js 16: actions/checkout@v2. For more information see:
https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
```
Github has announced that this will eventually stop working somewhen in mid
2023.
Switch to checkout@v3 which uses Node.js 16 to avoid the ci from breaking
in the near future.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that basic assignment patterns are supported for unpacked arrays.
Check that all of packed types, reals and string arrays are supported.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog allows to use assignment patterns to assign values to an
array. E.g. `int a[4] = '{1, 2, 3, 4}`.
Each value is evaluated in the context of the element type of the array.
Nested assignment patterns are supported. E.g. `int a[2][2] = '{'{1, 2},
'{1, 2}};`
Add initial support for array assignment patterns for both continuous as
well as procedural assignments.
For continuous assignments the assignment pattern is synthesized into an
array of nets. Each pin is connected to one of the assignment pattern
values and then the whole net array is connected to target array.
For procedural assignments it is unrolled in the vvp backend. E.g
effectively turning `a = '{1, 2};` into `a[0] = 1; a[1] = 2;`.
Not yet supported are indexed initializers or `default`.
E.g. `int a[10] = '{1:10, default: 20};`
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Types for array signals are currently handled as a special case. The type
that is associated with the signal is not the array type itself but rather
the element type.
There is a fair amount of existing code that depends on this behavior so it
is not trivial to change this.
But there are certain constructs such as assignment patterns or array
concatenation where the array type itself is required.
Add a new `NetNet::array_type()` method that will return the array type if
the signal is an array. This will allow to query the array type when
needed.
`NetAssign_::net_type()` is updated to use this new method to return the
array type if the assigned signal is an array.
Long term the special handling of arrays for signals should be removed.
This will for example allow to unify the handling of arrays for signals,
class properties and struct members.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The are many binary operations where if the two operands are 2-state the
result is guaranteed to be 2-state.
This is true for all arithmetic operation with the exception of division
where division by 0 will always result in 'x even if the inputs are both
2-state.
The same is true for all binary bitwise operators as well as the binary
logical operators.
Having the expression type be 2-state avoids some unnecessary %cast2
instructions that would otherwise get inserted when assigning the result to
a 2-state variable.
E.g without this change the following will result in
```
int a, b, c;
b = a + b;
```
will result in
```
%load/vec4 ...;
%load/vec4 ...;
%add;
%cast2;
%store/vec4 ...;
```
For binary comparison operators this is already handled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There are some cases where during an assignment the elaboration step can
generate constructs with the right-hand-side expression being wider than
the left-hand-side expression.
To handle this the tgt-vvp backend inserts a %pad operation when necessary.
One place where this is missing is when writing to an string element. Here
instead an assert is triggered requiring the right-hand-side expression to
be 8 bits wide.
E.g.
```
bit [7:0] x;
bit [8:0] y;
string s;
x = y; // tgt-vvp inserts %pad
s[0] = y; // tgt-vvp triggers assert
```
Long term this should be fixed at the elaboration stage and insert the
proper width cast. But for now solve this the same way as other places in
tgt-vvp and insert the %pad operation for string element assignments if the
width does not match.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
`ivl_assert()` is similar to `assert()` except that it will also include
source file and line information about the expression for which the assert
was triggered.
Use `ivl_assert()` instead of `assert()` where the line information is
available. This will generate better bug reports and make it easier to
diagnose why an assert is triggered.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that the file and line location is correct for errors
related to implicit named port connections.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some tests require a specific compiler error, rather than just failing. Add
support for this by allowing to check for gold files for CE tests.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Implicit named port connections are only supported by SystemVerilog. Add a
check to generate an error when trying to use it in Verilog mode.
Regression test br_gh315 is modified to run in SystemVerilog mode since it
makes use of implicit named port connections.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>