- Attempt to lookup a derived module if it potentially contains a port
connection with elaboration ambiguities
- Mark the cell if module has not yet been derived
- This can be extended to implement automatic hierarchical port
connections in a future change
This enables the usage of declarations of wand or wor with a base type
of logic, integer, or a typename. Note that declarations of nets with
2-state base types is still permitted, in violation of the spec.
- Root AST_PREFIX nodes are now subject to genblk expansion to allow
them to refer to a locally-visible generate block
- Part selects on AST_PREFIX member leafs can now refer to generate
block items (previously would not resolve and raise an error)
- Add source location information to AST_PREFIX nodes
This is accomplished by generating a unique name for the genvar,
renaming references to the genvar only in the loop's initialization,
guard, and incrementation, and finally adding a localparam inside the
loop body with the original name so that the genvar can be shadowed as
expected.
- disallow [gen]blocks with an end label but not begin label
- check validity of module end label
- fix memory leak of package name and end label
- fix memory leak of module end label
This breaks the ability to use a global typename as a standard
identifier in a subsequent input file. This is otherwise backwards
compatible, including for sources which previously included conflicting
typedefs in each input file.
This defers the simplification of globals so that globals in one file
may depend on globals in other files. Adds a simplify() call downstream
because globals are appended at the end.
It was previously possible to override global parameters on a
per-instance basis. This could be dangerous when using positional
parameter bindings, hiding oversupplied parameters.
- Modules with a parameter without a default value will be automatically
deferred until the hierarchy pass
- Allows for parameters without defaults as module items, rather than
just int the `parameter_port_list`, despite being forbidden in the LRM
- Check for parameters without defaults that haven't been overriden
- Add location info to parameter/localparam declarations
Declaring the ports as standard module items already worked as expected.
This adds a missing usage of `checkRange()` so that headers such as
`module m(output integer x);` now work correctly.
- Standard data declarations can now use any integer type
- Parameters and localparams can now use any integer type
- Function returns types can now use any integer type
- Fix `parameter logic`, `localparam reg`, etc. to be 1 bit (previously 32 bits)
- Added longint type (64 bits)
- Unified parser source for integer type widths
- Simplify synthetic localparams for normal calls to update their width
- This step was inadvertently removed alongside `added_mod_children`
- Support redeclaration of constant function arguments
- `eval_const_function` never correctly handled this, but the issue
was not exposed in the existing tests until the recent change to
always attempt constant function evaluation when all-const args
are used
- Check asserts in const_arg_loop and const_func tests
- Add coverage for width mismatch error cases
This would previously complain about an undefined internal macro if the
unapplied macro had not already been used. If it had, it would
incorrectly use the arguments from the previous invocation.
This is a somewhat obscure edge case I encountered while working on test
cases for earlier changes. Declarations in generate blocks should not be
checked against the list of ports. This change also adds a check
forbidding declarations within generate blocks being tagged as inputs or
outputs.
This change set contains a number of bug fixes and improvements related to
scoping and resolution in generate and procedural blocks. While many of the
frontend changes are interdependent, it may be possible bring the techmap
changes in under a separate PR.
Declarations within unnamed generate blocks previously encountered issues
because the data declarations were left un-prefixed, breaking proper scoping.
The LRM outlines behavior for generating names for unnamed generate blocks. The
original goal was to add this implicit labelling, but doing so exposed a number
of issues downstream. Additional testing highlighted other closely related scope
resolution issues, which have been fixed. This change also adds support for
block item declarations within unnamed blocks in SystemVerilog mode.
1. Unlabled generate blocks are now implicitly named according to the LRM in
`label_genblks`, which is invoked at the beginning of module elaboration
2. The Verilog parser no longer wraps explicitly named generate blocks in a
synthetic unnamed generate block to avoid creating extra hierarchy levels
where they should not exist
3. The techmap phase now allows special control identifiers to be used outside
of the topmost scope, which is necessary because such wires and cells often
appear in unlabeled generate blocks, which now prefix the declarations within
4. Some techlibs required modifications because they relied on the previous
invalid scope resolution behavior
5. `expand_genblock` has been simplified, now only expanding the outermost
scope, completely deferring the inspection and elaboration of nested scopes;
names are now resolved by looking in the innermost scope and stepping outward
6. Loop variables now always become localparams during unrolling, allowing them
to be resolved and shadowed like any other identifier
7. Identifiers in synthetic function call scopes are now prefixed and resolved
in largely the same manner as other blocks
before: `$func$\func_01$tests/simple/scopes.blk.v:60$5$\blk\x`
after: `\func_01$func$tests/simple/scopes.v:60$5.blk.x`
8. Support identifiers referencing a local generate scope nested more
than 1 level deep, i.e. `B.C.x` while within generate scope `A`, or using a
prefix of a current or parent scope, i.e. `B.C.D.x` while in `A.B`, `A.B.C`,
or `A.B.C.D`
9. Variables can now be declared within unnamed blocks in SystemVerilog mode
Addresses the following issues: 656, 2423, 2493