If a net or variable is referenced in another net or variable declaration
or in a value parameter definition (e.g. when using the $bits function)
and hasn't already been elaborated, we need to elaborate it early. So
during the scope elaboration phase, add placeholders in each NetScope
object to record the PWire objects that are yet to be elaborated. This
allows the symbol_search() function to find the unelaborated objects
and to trigger early elaboration.
Add a flag in the PWire object to indicate when we are elaborating it.
This allows us to detect circular references and avoid an infinite loop.
This fixes issue #483, issue #575, and issue #1097.
`std::vector<netrange_t>` is used for signal array dimensions. As such it is
used in quite a few places.
Add a typedef that can be used as a shorthand to refer to it. This helps to
keep lines where this is used from growing to overly long.
The new type is called `netranges_t`.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog allows to declare const variables. These variables are
read-only and can not be assigned a value after their declaration. It is
only possible to assign an initial value as an initializer.
E.g.
```
const int x = 10;
x = 20; // Error
```
The LRM requires that for variable declarations with static storage the
initializer is a constant expression with the extension that other const
variables are also allowed. const variables with automatic storage can
be initialized by any expression.
Checking if an expression contains only const variables requires a bit more
work to implement. So for now be more lenient that what the standard
requires and allow arbitrary expressions to initialize const variables even
for those with static storage.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The ivl_variable_type_t in PWire is now only used for passing the base type
for vector types to the elaboration stage. But we can query the base the
from the vector_type_t itself. If the there is no data_type_t set for the
PWire the base type will default to IVL_VT_LOGIC.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently when referencing a typedef this gets replaced with the
`data_type_t` that the typedef points to. This works for most cases, but
there are some corner cases where it breaks down.
E.g. it is possible to have a scoped type identifier which references a
type defined in a package. For such type identifiers, only the data_type_t
itself is remembered, but not the package scope. This will cause the type
identifier to be elaborated in the wrong scope.
Furthermore type identifiers of vector types used for module or task port
might not be elaborated in the correct scope.
Introduce a new `typeref_t` which has `data_type_t` as a base type and can
be used as the data type for a signal. A new instance of a `typeref_t` is
created when referencing a type identifier. The `typeref_t` remembers both
the data type and the scope of the type identifier.
When elaborating the `typeref_t` the elaboration is passed through to the
referenced `data_type_t`. But special care is taken to lookup the right
scope first.
With the new approach also typedefs of typedefs are supported. This
previously did not work because chained typedefs all reference the same
`data_type_t`, but each typedef sets the `name` field of the `data_type_t`.
So the second typedef overwrites the first typedef and a lookup of the
scope of the first typedef by name will fail as it will return the scope of
the second typedef.
This refactoring also allows to define clear ownership of a data_type_t
instance. This e.g. means that an array type owns its base type and the
base type can be freed when the array type itself is freed. The same is
true for signals and class properties, they now own their data type and the
data type can be freed when the signal or property is freed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If the type of a port is an array type it currently always gets evaluated
in the scope where the port is declared.
But if the type is a typedef it might be declared in a different scope and
must be evaluated in that scope. E.g. the following will declare an array
port with 10 entries and an element type of a 5 bit vector, while it should
declare one with 4 entries and an element type of a 2 bit vector.
```
localparam A = 2;
localparam B = 4;
typedef [A-1:0] T[B];
module test (
T x
);
localparam A = 5;
localparam B = 10;
endmodule
```
This is in part due to array types being given special handling. This was
necessary before because each base type required slightly different
handling and so the base type had to be extracted from the array type.
This has now been consolidated and all data types are treated the same.
The only exception is the vector type which still needs special handling to
support separate definition of port direction and type.
As a result it is possible to remove the special handling of the array
type. This solves the problem of evaluating the type in the wrong scope.
Some special handling needs to be retained though to be able to
differentiate between array dimensions that are part of a type and array
dimensions that are part of port declaration. This is again necessary to
correctly support separate definition of port direction and type. E.g. in
the example below port `x` and `y` get treated slightly differently, even
though the resulting signals will be identical.
```
typedef logic [7:0] T[1:0];
...
input T x;
input [7:0] y[1:0];
```
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The parser used to have behavior that was dependent on the
`ivl_variable_type_t` of a signal. It also used the `ivl_variable_type_t`
of a signal to decide whether a signal can be re-declared as part of a
non-ANSI port declaration.
Neither of these is done anymore and most of the reference to
`ivl_variable_type_t` can be removed from the parser. The only thing it is
still needed for is to decide whether a vector type is 4-state or 2-state.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
(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>
When using non-ANSI style port declarations it is possible to declare the
port direction and the data type for the port in separate statements. E.g.
```
input x;
reg x;
```
When using packed array dimensions they must match for both declarations.
E.g.
```
input [3:0] x;
reg [3:0] x;
```
But this only applies for vector types, i.e. the packed dimension is
explicitly declared. It does not apply to the `integer` and `time` types,
which have an implicit packed dimension.
The current implementation requires that even for `integer` and `time`
types the implicit dimension needs to be explicitly declared in the port
direction. E.g. the following will result in a elaboration error
complaining about a packed dimension mismatch.
```
module test;
output x;
integer x;
endmodule
```
Currently the parser creates a vector_type_t for `time` and `integer`. This
means that e.g. `time` and `reg [63:0]` are indistinguishable during
elaboration, even though they require different behavior.
To fix let the atom2_type_t handle `integer` and `time`. Since it no longer
exclusively handles 2-state types, rename it to atom_type_t.
This also fixes a problem with the vlog95 target unit tests. The vlog95
target translates
```
module test(output integer x);
endmodule
```
to
```
module test(x);
output x;
integer x;
endmodule
```
which then fails when being elaborated again. There were some regression
tests that were failing because of this that will now pass.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently only dynamic arrays and queues of atom2 and vector types are
supported. Add support for packed arrays. Since these three types are
essentially handled the same internally supporting this only requires to
allow to elaborate a packed array base type.
Factor out type elaboration into a helper function that can be shared
between the elaboration of the base type of a dynamic array or queue and
the type for other signals. This gives consistent behavior and will also
make it easier to support additional base types for dynamic arrays or
queues.
Note that it is not yet possible to index elements of packed array dynamic
arrays or queues. But neither is it possible to do a bit select for vector
or atom2 type dynamic arrays or queues yet. Supporting this needs some
additional work.
There is one test that declares a queue of a struct type, but doesn't use
it since it is not supported. With this change a error will generated when
trying to declare a queue of a struct. So update that test to not declare
the variable so it does not fail.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The logic that decides whether a vector is scalar or not incorrectly flags
all variables that are declared in packages as scalar. As a result it is
not possible to do a part select on a vector declared in a package.
Rather than having an independent scalar flag consider a vector as scalar
if it does not have any packed dimensions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This is a cleanup in preparation for better support of range lists.
(cherry picked from commit 8f7cf3255acad55841f8b3725e3786ef49daad68)
Conflicts:
PTask.h
elab_scope.cc
elab_sig.cc
parse.y
pform.cc
pform.h
pform_types.h
Signed-off-by: Stephen Williams <steve@icarus.com>
The pform propagates the parsed enum base type information
to the elaborator so that the base type can be fully elaborated.
This is necessary to get the types of the enumeration literals
correct.
When enum names are used as r-values in expressions, use their
values. Treat the enum names similar to (but not exactly as)
localparams so that they fit into the rest of the elaboration
flow naturally.
In 1364-2005 it is an explicit error to take the select of a scalar
or real value. We added the checks for real a while ago. This patch
adds the functionality for scalar values. In the future we may want
to push the scalar property to the run time.
Signals may have VMA disciplines attached. Make the attached discipline
visible through the ivl_target.h API. Also, re-arrange the internal
handling of the discipline structure so that we can expose disciplines
through the ivl_target C API without creating new structures. The
t-dll-api implementations of the discipline access functions can look
at the elaborated discipline structure directly. This is possible since
the discipline parse and elaboration are very simple.
Move the storage of wires (signals) out of the Module class into
the PScope base class, and instead of putting the PWires all into
the Module object, distribute them into the various lexical scopes
(derived from PScope) so that the wire names do not need to carry
scope information.
This required some rewiring of elaboration of signals, and rewriting
of lexical scope handling.
This patch is rather large and fixes a couple of problems. The major
change is that instead of keeping all the range specifications in
a list that is later processed the information is now kept as
individual entries for the port and net definitions. This allows
easier checking for multiple definitions (pr1660028), more
detailed error messages and the ability to pass the now deprecated
style of a scalar I/O definition used with a vectored net definition.
These changes did require extra code to prevent a single definition
from setting the range values in more than on place.
When using the new ANSI-C style of port declarations (1364-2001 12.3.4
list_of_port_declarations) the compiler ensures that you do not
redeclare the port in the body (it is already completely defined).
This caught a few errors in the test suite (pr859 and sqrt32*).
The flag to disable the normal port checking and allow the deprecated
port syntax is -gno-io-range-error. This will print a warning for the
case of a scalar port with a vectored definition in the body. All
other cases are still considered an error.
syntax. Hook this support into existing $attribute
handling, and add number and void value types.
Add to the ivl_target API new functions for access
of complex attributes attached to gates.
Cary R
Martin Whitaker
Lars-Peter Clausen
Stephen Williams
Arun Persaud
steve