The default implementation of the virtual method `NetExpr::has_width()`
returns true. There are a few classes that directly inherit from NetExpr
that override the method with the exact same implementation. Remove these.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There are no users for the `NetScope::find_enumeration_for_name()` and
`Definitons::enumeration_for_name()` methods. Remove both of them.
The last user was removed in commit 61a088fa78 ("Use elaborate_type()
infrastructure to elaborate signal types").
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The last user of the `make_range_from_width()` was removed in commit
f6042033d0 ("Correctly handle separate port type declaration for
`integer` and `time`").
Remove the function itself as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The last user of the `PExpr::is_the_same()` method was removed in commit
37b60a4c52 ("Clean up interface of the PWire class").
Remove the method.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that default values are support for module port lists.
* For output ports it is supported in both Verilog and SystemVerilog.
* For input ports it is only supported in SystemVerilog.
* For inout ports it is never supported
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Both Verilog (2005) and SystemVerilog support default port values for
variable output ports. SystemVerilog also supports default port values for
input ports. For port declaration lists it is possible to specify the
default value for port identifier.
E.g.
```
module M (
input integer x, y = 1,
output integer z, w = 2
) ...
```
Currently the parser only supports specifying the default value for the
first identifier in the list. Extend the parser to also allow to specify
the default value for identifiers in the list.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There are a few places where it is possible to provide an optional
initializer in the form of `[ = <expression> ]`.
There are currently multiple rules that implement this behavior as well as
few places with duplicated rules, one with and one without the initializer.
Introduce a common helper rule for optional initializers. This allows to
remove some duplicated code from the parser.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For output port lists with a default value for the first port declaration
all subsequent port declarations are declared as inout ports. This is due
to a small typo when setting the `port_declaration_context` port direction.
Fix this to make sure all ports in the port declaration list are declared
as output ports.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that SystemVerilog sign cast are supported correctly. The regression
tests are modeled after the existing tests for $unsigned/$signed.
They check that
* Width extension is done correctly on the cast expression
* Expressions in the sign cast are evaluated as self-determined
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog supports sign cast where it is possible to change the
signedness of an expression. Syntactical it is similar to width or type
casting, except that the keywords 'signed' or 'unsigned' are used in front
of the cast operator. E.g.
```
logic [3:0] a = 4'b1000;
logic [7:0] b = signed'(a); // b is 8'b11111000;
logic signed [3:0] c = 4'b1000;
logic signed [7:0] d = unsigned'(c); // d is 8'b00001000;
```
As noted by the LRM section 6.24.1 ("Cast operator") applying a sign cast
to an expression is equivalent to calling the $signed() and $unsigned()
system functions on the expression.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that the var keyword is supported in the following contexts
* Module ports (both ANSI and non-ANSI)
* Module variable declarations
* Package variable declarations
* Task and function ports
* block variable declarations
* for loop variable declarations
Also check that it is an error to use the var keyword in a for loop without
an explicit data type, as that is not allowed by the standard.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog adds the `var` keyword that can be used to declare a signal
as a variable.
In contexts where a signal is always a variable it is purely optional and
it makes no difference whether it is specified or not. This is in
* for loop variable declarations
* task and function port declarations
For variable declarations as block items when `var` is used it is possible
to omit the explicit data type and use a implicit data type instead. E.g.
all of the following are valid.
```
var x;
var signed y;
var [1:0] z;
```
For module input and output ports the `var` keyword can be used in place of
the net type. It can be combined with either an implicit or explicit data
type.
E.g.
```
input var x
output var [1:0] y
```
inout ports can not be variables and will be reported as an error.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Refactor the variable lifetime parser rules so that instead of having too
rules, one with lifetime and one without, there is a single rule where the
lifetime is an optional element.
This helps to avoid a combinatorial explosion of parser rules once we
add `var` support.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the parser can recover from `integer` or `time` variable
declarations, but not for variables of other types. Refector the parser
rules so that it can recover for all variable types as well as events.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog allows input ports to be variables. If something is connected
to the input port it will be converted to an unresolved wire.
This is handled the same as having a continuous assignment on a
SystemVerilog varibale.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If the parameter has no explicit type, the type is inferred from the RHS
expression. The first time the parameter is evaluated, the RHS hasn't yet
been elaborated, so the type is unknown. This causes the evaluation to be
performed by NetScope::evaluate_parameter_logic_, which correctly handles
both logic and real types. However, on subsequent evaluations of the
parameter, the expression type is now known, so the evaluation was being
performed by NetScope::evaluate_parameter_real_. This function requires
the parameter to have an explicit type.
For now, rather than add more code to NetScope::evaluate_parameter_real_
to handle an implicit type, force NetScope::evaluate_parameter_logic_ to
be used whenever we have an implicit type. This should probably be reworked
if support for more complex types is added.
Without this fix, ivlh_textio was failing at step 11 where the time is read from the file. This was because clang happens to put period directly after the units buffer on the stack. sscanf writes the terminating NUL overwriting the low byte of period, which is 100, so it returns 0.
Example clang warning fixed:
warning: 'sscanf' may overflow; destination buffer in argument 4 has size 2, but the corresponding specifier may require size 3 [-Wfortify-source]
Both the `vvp_fun_signal_real` and `vvp_fun_signal_string` classes
implement a `size()` method that returns 1. There are no users of these
methods, remove them.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Add regression tests for the following types partial writes for both
2-state and 4-state vectors.
* Non-blocking
* Blocking
* Blocking event control
Check that all in-bounds partial writes, partial out-of-bounds and
full out-of-bounds all works as expected.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Writes to 2-state arrays currently only support full writes. If the write
is a partial write it will trigger an assert. E.g.
```
int a[3:0]
int i = -1;
a[i+:8] = 8'h0; // Triggers assert
```
Add support for partial writes by doing a read-modify-write in the same way
as for 4-state arrays.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The `%store/vec4a` instruction does not handle partial of full
out-of-bounds writes to a vector array element. Trying to do so will
trigger an assert. E.g.
```
integer a[3:0];
integer i = -10;
a[0][i+:8] = 8'h0; // Triggers assert
```
For fully out-of-bounds writes the write should be skipped, for partial
out-of-bounds writes the value needs to be resized to be within the bounds
of the vector. Use the `resize_rval_vec()` helper function to implement
this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There are a few functions that handle implement different kinds of vector
writes that have to handle that the assigned value partially or completely
out-of-bounds.
Each function has similar, but not identical, code for this, sometimes with
small bugs for corner cases.
Add a helper function that takes care of handling of updating the width and
offset of the assigned value if necessary.
This ensure consistent and correct behavior and allow to remove some
duplicated code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The `%assign/vec4/a/{d,e}` instructions, when checking for a full
out-of-bounds write on the low side, uses the target signal width, while it
should use the assigned value width.
This can lead to a fully out-of-bounds write to be assumed to be a partial
out-of-bounds access, which will trigger an assert later on.
E.g.
```
integer a[1:0];
integer i = -4;
a[0][i+:4] <= 4'h0; // Triggers assert
```
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that multiple events can be used in a non-blocking event control
assignment. The assignment should happen if either of the events trigger.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When multiple events are used in a non-blocking event control they need to
be combined into a single event using `event/or`.
The generated `event/or` statement is missing the trailing semicolon and
newline, which results in parser error when vvp tries to run.
E.g.
```
event e, f;
integer x;
x <= @(e or f) 10;
```
Add the missing semicolon and newline to fix this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Stephen Williams
Lars-Peter Clausen
Nish Tahir
Martin Whitaker
Henner Zeller
Jevin Sweval