This was actually a ticking UB bomb: after running the parser, the type
maps contain pointers to children of the current AST, which is
recursively deleted after the pass has executed. This leaves the
pointers in user_type_stack dangling, which just happened to never be a
problem due to another bug that causes typedefs from higher-level type
maps to never be considered.
Rebuilding the type stack from the design's globals ensures the AstNode
pointers are valid.
Calling log_signal is problematic for several reasons:
- with recent changes, empty string is serialized as { }, which violates
the "no spaces in IdString" rule
- the type (plain / real / signed / string) is dropped, wrongly conflating
functionally different values and potentially introducing a subtle
elaboration bug
Instead, use a custom simple serialization scheme.
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.
From IEEE1364-2005, section 7.3 buf and not gates:
> These two logic gates shall have one input and one or more outputs.
> The last terminal in the terminal list shall connect to the input of the
> logic gate, and the other terminals shall connect to the outputs of
> the logic gate.
yosys does not follow this and instead interprets the first argument as
the output, the second as the input and ignores the rest.
Previously, memories were silently discarded by the JSON backend, making
round-tripping modules with them crash.
Since there are already some users using JSON to implement custom
external passes that use memories (and infer width/size from memory
ports), let's fix this by just making JSON backend and frontend support
memories as first-class objects.
Processes are still not supported, and will now cause a hard error.
Fixes#1908.
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 adds a mechanism for marking certain portions of elaboration as
occurring within unevaluated ternary branches. To enable elaboration of
the overall ternary, this also adds width detection for these
unelaborated function calls.
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 fixes binding signed memory reads, signed unary expressions, and
signed complex SigSpecs to ports. This also sets `is_signed` for wires
generated from signed params when -pwires is used. Though not necessary
for any of the current usages, `is_signed` is now appropriately set when
the `extendWidth` helper is used.
Elaboration now attempts constant evaluation of any function call with
only constant arguments, regardless of the context or contents of the
function. This removes the concept of "recommended constant evaluation"
which previously applied to functions with `for` loops or which were
(sometimes erroneously) identified as recursive. Any function call in a
constant context (e.g., `localparam`) or which contains a constant-only
procedural construct (`while` or `repeat`) in its body will fail as
before if constant evaluation does not succeed.
