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.
instead of a signal pointer,
Wire attributes added,
Ability to parse UDP descriptions added,
XNF generates EXT records for signals with
the PAD attribute.
Lars-Peter Clausen
Martin Whitaker
Cary R
Stephen Williams
Arun Persaud
steve