The current implementation expects that for a module instantiation with a
ordered list connection all ports are supplied.
But there doesn't seem to be such a requirement in the LRMs. The Verilog
LRM doesn't mention anything in this regard and the SystemVerilog LRM
mentions in section 23.3.2.1 that a blank or omitted port connection is
either left unconnected or uses the default value of the port.
Update the implementation so that it allows to omit trailing ports and only
generates an error message if too many ports are specified in the ordered
port list.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently continue and break are supported in most loops. But not in
do-while loops. Add support for them in do-while loops as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that partial and fully out-of-bound writes to a function's return
value are handled correctly. Check this for both 4-state and 2-state
vectors.
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>
The current check to decide whether a port is an array or a scalar signal
uses the number of pins on the NetNet. If it is larger than one the code
assumes that it is an array.
But for arrays with on a single element the number of pins will be 1 and
the port is incorrectly treated as a scalar signal which results in an
error.
Instead of using the number of pins check for the number of unpacked
dimensions to decide whether the port is an array.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check support for using the return statement in a task.
* That it is possible to exit form a task using the `return` statement
without affecting other concurrently running instances of the same task
* That it is possible to use return in a named block in a task
* That using a return value in a task results in a elaboration error
* Returning from inside a parallel block in a task results in a
elaboration error
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog allows to use the `return` statement in a task to exit the
task before it reaches the end of its execution. This is defined in section
13.3 ("Tasks") of the LRM (1800-2017).
This is similar to using `disable` to stop a task from within itself with
the difference that `disable` will affect all concurrently running
executions of a task, while `return` will only affect the task from which
it has been called.
The `%disable/flow` vvp instruction allows to implement the required
behavior for task return.
There is one complication in that it is not allowed to call return from
inside a parallel block (fork-join). If a parallel block is unnamed and has
no variable declarations there won't be a NetScope for it. So it is not
possible to detect whether the return is inside a parallel block by
walking up the scope chain.
To solve this add a design global counter that gets incremented when
entering a fork block and decremented when exiting a parallel block. The
return implementation then checks if the counter is non 0 to determine
whether it is in a parallel block.
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>
In SystemVerilog arrays assignments are supposed to be connected left to
right. This means if the left to right direction differs between the two
arrays they will be connected in reverse order.
E.g.
```
logic a[1:0];
logic b[0:1];
assign b = a;
```
should connect a[0] to b[1] and a[1] to b[0]. Things get a bit more tricky
for multi-dimensional arrays where some dimensions have a matching
direction and some do not.
The current implementation always connects them low to high, which results
in incorrect behavior.
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>
The port_index_ member of the NetNet is not initialized which can lead to
undefined behavior. Make sure to initialize to -1 to indicate that the net
is not associated with any port.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Lars-Peter Clausen
Cary R
mole99
أحمد المحمودي (Ahmed El-Mahmoudy)
Martin Whitaker
Srinivasan Venkataramanan
a1ca7raz
Stephen Williams