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>
Check that assigning array that have opposite left-to-righto order for
their dimensions have their elements assigned in reversed order.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that foreach counts counts from $left to $right. This means it should
count up if $left is less than $right and count down otherwise.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
vvp_reg.py requires 4 gold files. One for each of stdout and stderr of both
iverilog and vvp. Most of these log files will be empty for most test
cases. This will result in a lot of empty files being added to the
repository.
If a gold file for a specific output stream can not be found assume that
the output stream is supposed to empty. This allows to omit the empty gold
files.
Also remove all the existing empty gold files.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This adds the "normal-vlog95" test type, because we need to run a different
set of commands for this to work so a new test type makes sense. This also
moves a few of the existing tests to the new format in order to test the
new test rig.
Add a regression test to show that the proper dumpfile is selected, by
noting in the output from the vvp command what file name it is creating.
To make this work, I also needed to add some capabilities to the vvp_reg.py
regression test rig.
This creates a new test suite driver and infrastructure for going
forward. This cleans up the descriptions for tests, and is more
extensible.
Include documentation for the new engine, so that new tests can go
here instead of the old test suite.
Check that null-bytes get removed when reading a value through the VPI API
as a vpiStringVal. Also check that null-bytes are not removed from string
literals when string literals are read through the VPI API as a non
vpiStringVal.
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>
Verilog compiler directives are free-form and, subject to semantic rules,
can appear anywhere in the source code. Whilst it is common practice to
write them on a separate line, we should handle all legal syntax.
It was common practice in the past to just declare a port direction
and declare it as a vector in a subsequent type declaration. Versions
of the standard up to and including 1364-2005 include an example that
does this (e.g. 1364-2005 section 12.3.7). Users may have old or
third-party code that they can't or don't want to modify, so allow
the warning to be suppressed by including it in the anachronisms
category.
(System)Verilog allows to declare the port direction separate from the
signal declaration. E.g.
```
output x;
integer x;
```
But this is only allowed if the port declaration
* does not have an explicit net type
* does not have an explicit data type
* is a non-ANSI style declaration
For all other cases of port declarations the signal is considered fully
defined and it is not allowed to have a separate signal declaration.
In addition the declared packed dimensions need to match between the port
and signal declaration.
In the current implementation there are a few cases where this is not
handled correctly.
1) It is possible to declare non-ANSI task ports with the same name over
and over again, if it was declared as a signal before the port.
```
task t;
string x;
input logic x;
output real x;
endtask
```
2) It is possible to re-declare non-ANSI input ports of a module that have
a data type, but no explicit net type.
```
module M;
input integer x;
wire integer x;
endmodule
```
3) It is possible to re-declare a ANSI port if it has an implicit data type.
```
module M(output [1:0] x);
reg [1:0] x;
endmodule
```
4) It is possible to declare a vector signal for a scalar non-ANSI task
port.
```
task t;
input x;
reg [7:0] x;
```
To handle all of these correctly refactor signal declaration and lookup a
bit.
The PWire class that represents a signal already has two flags `port_set_`
and `net_set_`. These flags indicate whether a signal has already been used
in a port or signal declaration. A port declaration that includes an
explicit data type is considered both a port and signal declaration.
Use these flags to decide whether it is possible to extend an existing
declaration. E.g. when creating a port without an explicit data type and a
PWire by that name already exists and the `port_set_` flag is not set
extend the existing PWire. On the other hand if the `port_set_` flag is
already set report an error.
Similar for signals but with the `net_set_` flag.
For port declarations with an explicit data type or ANSI style port
declarations it is always an error if a PWire by that name already exists.
This is for both module and task/function ports.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Parameters with real values are possible in Verilog, but not in the VCD
format, so lie a little and call them "real" objects. Otherwise, we can
treat them like constants and it works out, at least for gtkwave.
Writing parameters into VCD files makes the values available to waveform
tools. This can be done easily enough by writing out a $dumpadd section
at the beginning of the file that sets the parameter values. We don't need
to track the values over change, because by definition they do not change.
This changes the typical vcd output as well, so a few of the regression tests
need to be adjusted to account for this.
Also, while tracking this down, found and fixed the vvp/README.txt documention
for the .param/x records.
There are currently two implementations for elaborating unpacked array
types. One that is used when elaborating a signal with an unpacked array
type and one that is used everywhere else using the elaborate_type()
infrastructure.
The elaborate_type() implementation is less complete and for example does
not support bounded queue types.
Consolidate both into a single implementation to reduce duplicated code and
get consistent behavior. This for example makes sure that the maximum queue
size is respected when used as a function return type.
Nested data structures of arrays, dynamic arrays or queues are not yet
supported. In the current implementation when encountering such a type an
assert will be triggered and the application crashes. In the new
implementation an error message will be printed without crashing the
application.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that constant recursive functions are supported. Check both Verilog
style using assignments to the implicit function return signal and
SystemVerilog style using `return`.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that queues of packed arrays are supported. These tests are identical
to the existing queue tests for other data type, just that the data type
is a packed array.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
While a variable can have any data type the data type for nets is quite
restricted.
The SystemVerilog LRM section 6.7.1 ("Net declarations with built-in net
types") requires that the data type of a wire is either a 4-state packed or
a unpacked struct or unpacked array of 4-state packed types.
As an extension to this iverilog allows real data type for wires as well as
2-state packed types.
Add a check that reports an error if a net with any other type is declared.
In addition in Verilog a net can not have an explicit data type at all. It
can only have a packed dimension and a signed flag. As an extension to this
Icarus also allows wires to be of `real` data type.
Note that in Verilog mode the data type is checked in the parser since only
the parser knows whether the data type is an implicit type (`input reg
[7:0]` and `input [7:0] x` elaborate the same). But for SystemVerilog the
type is checked during elaboration since due to forward typedefs and type
parameters the type is not necessarily known in the parser.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Split the test into multiple tests that each check one type of invalid
override rather than having one big tests that checks for everything.
This allow to check whether the test passes or fails by seeing if it
compiles or not. The one big test on the other hand relies on seeing the
exact error messages as recorded in the gold file.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Stephen Williams
Cary R
mole99
Lars-Peter Clausen
Srinivasan Venkataramanan
Martin Whitaker