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.
This code now takes the AST nodes of type AST_BIND and generates a
representation in the RTLIL for them.
This is a little tricky, because a binding of the form:
bind baz foo_t foo_i (.arg (1 + bar));
means "make an instance of foo_t called foo_i, instantiate it inside
baz and connect the port arg to the result of the expression 1+bar".
Of course, 1+bar needs a cell for the addition. Where should that cell
live?
With this patch, the Binding structure that represents the construct
is itself an AST::AstModule module. This lets us put the adder cell
inside it. We'll pull the contents out and plonk them into 'baz' when
we actually do the binding operation as part of the hierarchy pass.
Of course, we don't want RTLIL::Binding to contain an
AST::AstModule (since kernel code shouldn't depend on a frontend), so
we define RTLIL::Binding as an abstract base class and put the
AST-specific code into an AST::Binding subclass. This is analogous to
the AST::AstModule class.
- User-defined types must be data types. Using a net type (e.g. wire) is
a syntax error.
- User-defined types without a net type are always variables (i.e.
logic).
- Nets and variables can now be explicitly declared using user-defined
types:
typedef logic [1:0] W;
wire W w;
typedef logic [1:0] V;
var V v;
Fixes#2846
This doesn't do anything useful yet: the patch just adds support for
the syntax to the lexer and parser and adds some tests to check the
syntax parses properly. This generates AST nodes, but doesn't yet
generate RTLIL.
Since our existing hierarchical_identifier parser doesn't allow bit
selects (so you can't do something like foo[1].bar[2].baz), I've also
not added support for a trailing bit select (the "constant_bit_select"
non-terminal in "bind_target_instance" in the spec). If we turn out to
need this in future, we'll want to augment hierarchical_identifier and
its other users too.
Note that you can't easily use the BNF from the spec:
bind_directive ::=
"bind" bind_target_scope [ : bind_target_instance_list]
bind_instantiation ;
| "bind" bind_target_instance bind_instantiation ;
even if you fix the lookahead problem, because code like this matches
both branches in the BNF:
bind a b b_i (.*);
The problem is that 'a' could either be a module name or a degenerate
hierarchical reference. This seems to be a genuine syntactic
ambiguity, which the spec resolves (p739) by saying that we have to
wait until resolution time (the hierarchy pass) and take whatever is
defined, treating 'a' as an instance name if it names both an instance
and a module.
To keep the parser simple, it currently accepts this invalid syntax:
bind a.b : c d e (.*);
This is invalid because we're in the first branch of the BNF above, so
the "a.b" term should match bind_target_scope: a module or interface
identifier, not an arbitrary hierarchical identifier.
This will fail in the hierarchy pass (when it's implemented in a
future patch).
- 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
The recent fix for case expression width detection causes the width of
the expressions to be queried before they are simplified. Because the
logic supporting module scope identifiers only existed in simplify,
looking them up would fail during width detection. This moves the logic
to a common helper used in both simplify() and detectSignWidthWorker().
- The case expression and case item expressions are extended to the
maximum width among them, and are only interpreted as signed if all of
them are signed
- Add overall width and sign detection for AST_CASE
- Add sign argument to genWidthRTLIL helper
- Coverage for both const and non-const case statements
The current_module global is needed so that genRTLIL has somewhere to
put cells and wires that it generates as it makes sense of expressions
that it sees. However, that doesn't actually need to be an AstModule:
the Module base class is enough.
This patch should cause no functional change, but the point is that
it's now possible to call genRTLIL with a module that isn't an
AstModule as "current_module". This will be needed for 'bind' support.
No functional change: just get rid of the explicit iterator and
replace (*it)-> with child->. It's even the same number of characters,
but is hopefully a little easier to read.
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.
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
Calling log10() on zero causes a non-sensical value to be calculated. On some
compile options, I've observed yosys crashing with an illegal
instruction (SIGILL).
To make it safe, fix the calculation to do a range check; wrap it a
decimal_digits() function, and use it where the previous ceil(log10(n)) call
was used. As a side, it also improves readability.
Signed-off-by: Henner Zeller <h.zeller@acm.org>
The changes in #2476 ensured that function inputs like `input x;`
retained their single-bit size when instantiated with a constant
argument and turned into a localparam. That change did not handle the
possibility for an input to be redeclared later on with an explicit
width, such as `integer x;`.
- Signed cell outputs are sign extended when bound to larger wires
- Signed connections are sign extended when bound to larger cell inputs
- Sign extension is performed in hierarchy and flatten phases
- genrtlil indirects signed constants through signed wires
- Other phases producing RTLIL may need to be updated to preserve
signedness information
- Resolves#1418
- Resolves#2265
The only difference between "RTLIL" and "ILANG" is that the latter is
the text representation of the former, as opposed to the in-memory
graph representation. This distinction serves no purpose but confuses
people: it is not obvious that the ILANG backend writes RTLIL graphs.
Passes `write_ilang` and `read_ilang` are provided as aliases to
`write_rtlil` and `read_rtlil` for compatibility.
- expand_genblock defers prefixing of items within named sub-blocks
- Allow partially-qualified references to local scopes
- Handle shadowing within generate blocks
- Resolve generate scope references within tasks and functions
- Apply generate scoping to genvars
- Resolves#2214, resolves#1456
This commit fixes R/R conflicts introduced by commit 7e83a51.
Parameter logic is already defined as part of `param_range_type` rule.
Signed-off-by: Kamil Rakoczy <krakoczy@antmicro.com>
This commit fixes signed/unsigned grammar in parameters as defined in SV
LRM A2.2.1. Example of correct parameters:
parameter integer signed i = 0;
parameter integer unsigned i = 0;
Example of incorrect parameters:
parameter signed integer i = 0;
parameter unsigned integer i = 0;
Signed-off-by: Lukasz Dalek <ldalek@antmicro.com>
Signed-off-by: Kamil Rakoczy <krakoczy@antmicro.com>
The chosen value shouldn't have any effect. I considered something
clearly wrong like -1, but there's no checking inside the generated
lexer, and I suspect this will cause even weirder bugs if triggered
than just setting it to INITIAL.
Miodrag Milanovic
Zachary Snow
Rupert Swarbrick
Brett Witherspoon
Michael Singer
Marcelina Kościelnicka
Claire Xen
Xiretza
whitequark
TimRudy
Karol Gugala
Kamil Rakoczy
Diego H
Henner Zeller
David Shah
Lukasz Dalek
Tom Verbeure
georgerennie
Julius Roob
Claire Xenia Wolf
Udi Finkelstein
Kazuki Sakamoto
Anonymous Maarten
Peter Crozier
Eddie Hung
Claire Wolf