find_scope() requires the hierarchical path to use escaped identifiers;
without the leading '\' and trailing ' ', if there are any '.' characters,
the path will be broken up at the wrong point(s).
vvp is missing a parser rule for unsigned 2-state net arrays. E.g.
```
bit a[0:1];
assign a[0] = 1'b0;
```
will synthesize fine, but when running it with vvp cause a syntax error.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For 2-state non-automatic arrays currently real 0.0 value is propagated as
the initial value. This will cause an assert at the downstream receivers
which expect a vector.
Make sure that the vector value 0 is propagated instead for 2-state
vectors.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When vvp parses a command which it thinks is a system call it tries to
match the symbols to values in the scope. The typo uses the wrong index
variable to access the vpi table. This results in a failed dynamic cast
which goes unchecked until the value is dereferenced, resulting in a
segfault.
Automatic 2-state vectors currently get initialized to 'hx, while their
default value should be 0.
Make sure the vector is initialized to 0 at the beginning of the automatic
context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Partial out-of-bounds write to a function's return value will trigger an
assert, even though the operation is valid.
The assert checks that the truncated value has the expected width, but
instead it should check that the non-truncated value has the expected with.
Move the assert before the truncation to fix this.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Directly casting a negative double to a unsigned integer type is undefined
behavior and has different results on x86 and ARM based platforms.
On x86 the behavior is similar to casting a signed int to an unsigned
integer, i.e. the sign bit will end up in the MSB. But on ARM the result
will be 0.
To get consistent behavior, first cast to signed integer and then cast the
signed integer value to an unsigned integer value.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In the current implementation a `%fork` instruction in a final block will
get scheduled, but never executed.
And while SystemVerilog requires a `final` procedure to execute in 0 time
and so no SystemVerilog `fork` is allowed inside of it, there are some
other scenarios where iverilog generates `%fork` statements.
For example when declaring variables in a sub-block a sub-scope with its
own thread is is used to allocate the storage for those variables and
`%fork` is used to execute the child thread.
E.g. the following, while being valid SystemVerilog, will never execute the
loop because the generated code will implement the loop as a child thread
being executed by a `%fork` statement.
```
final for (int i = 0; i < 10; i++) $display(i);
```
To mitigate this treat final statements the same as functions and rather
than scheduling a child thread, execute it immediately when using the
`%fork` statement.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently when reading a number literal through the VPI API as a
vpiStringVal all null-bytes in the literal get ignored. This behavior is
different from when reading a signal through the VPI API as a vpiStringVal.
The latter will only ignore leading null-bytes and replace other null-bytes
with a space. E.g. the following two will print different values.
```
$display("%s", "a\000b"); // -> " ab"
reg [23:0] x = "a\000b";
$display("%s", x); // -> "a b"
```
For consistency modify the number literal formatting code so that it has
the same behavior as the signal value formatting code and only replaces
leading null-bytes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The VPI API for string literals does not correctly handle the case where a
null-byte ('\0') appears in the string literal. It uses strlen() to
calculate the length of the literal, which will give the wrong result if
there is a null-byte in the string literal. Instead of using strlen() use
the stored length to fix this.
In addition when formatting a string literal as a string ignore any
null-bytes. The LRM is not entirely clear what should happen to null-bytes
when formatting a value as a string. But the behavior of ignoring the
null-bytes is consistent with the rules of SystemVerilog for converting a
string literal to a SV string.
This problem can occur when a string literal gets null-byte left-padded due
to width of its context of its expression, but then optimization removes
part of the expression and only leaves the padded string literal.
E.g.
```
$display(0 ? "Yes" : "No");
```
will be transformed into
```
$display("\000No");
```
There is also one subtle change in behavior associated with this. The empty
string ("") is supposed to be equivalent to 8'h00. So e.g.
`$display(":%s:", "")` should print ": :" since the width of the empty
string is 1 byte and the %s modifier prints a string with the width of the
value, left-padding with spaces if necessary. The current implementation
will print "::" though. This change requires to update the marco_with_args
gold file.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The `%pushi/str` and `%concati/str` instructions should remove null-bytes
from the string literal when converting it to a string. This is defined in
section 6.16 ("String data type") of the LRM (1800-2017).
This is already handled correctly when converting a vector from the stack
to a SV string, just not when converting a string literal to SV string.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Clean up warnings that show up on newer compilers. Many of these warnings
are related to obsolete c library features or language features. This does
not clear up warnings in code generated by bison or flex.
An empty dynamic array or queue is represented by a null object in vvp.
Currently when trying to copy such an object results in undefined behavior
in various places. Either hitting an assert or causing a nullptr
dereference.
Make sure that the empty object is handled correctly by treating it as a
special case.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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>
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>
Marlon James
DeflateAwning
Lars-Peter Clausen
mole99
Cary R
Mason Loyet
Ethan Sifferman
Stephen Williams
Stephen Williams
Jonathan Kimmitt