This is an error in traditional Verilog and a unsupported feature in
SystemVerilog. Fail gracefully with a suitable error/sorry message.
Do the same for task declarations.
Get rid of the data_type, signed_flag, and range arguments to the
pform_module_define_port because they add no value within the
parse.y parser. Cleaning these out will hopefully ease the addition
of new functionality.
There were also some subtleties related to using enumerations
from typedefs and using them in multiple places. Fix various
bugs related to those issues.
Rework lexical support for PACKAGE_IDENTIFIER so that the lexor
can help with package scoped identifiers.
Pform package types and package functions up to elaboration.
IVL_VT_NO_TYPE is now used to signal an untyped LHS in a parameter
declaration. The parser function that handles specparam declarations
needs to do this too. Also, although it should never happen, make
sure we don't set the expression width in a NetECast object to a
negative number. Make constant evaluation of NetECast objects
observe the expression width.
A package can have parameters, but it does not have specparams or
keep the order the parameters are defined. This patch skips these
items if the scope is not a Module.
This was temporarily implemented to just copy definitions to the
local scope, but the better method is to create a PEIdent that has
the package attached to it.
defparam assignments found inside a generate block were being stored
in the enclosing module scope. They should be stored in the generate
block scope.
Also removed the genvar list from the PGenerate class, as this is
already declared in the base LexicalScope class.
In vvp, create the .var/str variable for representing strings, and
handle strings in the $display system task.
Add to vvp threads the concept of a stack of strings. This is going to
be how complex objects are to me handled in the future: forth-like
operation stacks. Also add the first two instructions to minimally get
strings to work.
In the parser, handle the variable declaration and make it available
to the ivl_target.h code generator. The vvp code generator can use this
information to generate the code for new vvp support.
An important advantage of program blocks is its ability to nest
within a module. This winds up also allowing modules to nest, which
is legal but presumably less used feature.