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
backends/protobuf/protobuf.cc depends on the source and header files
generated by protoc, but this dependency wasn't explicitly declared. Add
a rule to the Makefile to fix intermittent build failures when the
protobuf header/source file isn't built before protobuf.cc.
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.
Mutating the SigMap by adding a new connection will throw off FfInitVals
index. Work around this by removing the relevant init values from index
whenever we connect nets, then re-add the new init value.
Should fix#2920.
Previously, opt_clean would reconnect all ports (including FF Q ports)
to a "canonical" SigBit chosen by complex rules, but would leave the
init attribute on the old wire. This change applies the same
canonicalization rules to the init attributes, ensuring that init moves
to wherever the Q port moved.
Part of another jab at #2920.
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.