Add generic intrinsic operation to FIRRTL. Not used anywhere, just adding to the IR to build on.
Re-use module parameter printing/parsing for use as custom printer on the op.
See PR for more context.
Now that we've added a cached symbol table at the circuit level, we
can use that to look up option groups as well. This didn't have a
major performance improvement on some large designs, but in the
presence of more instance choices, this could help. Regardless, this
is one minor piece to clean up for #6772.
Fix a bug where SVExtractTestCode was not extracting asserts, assumes, and
covers from the verif dialect. This resulted in unexpected end-to-end
"failures" from Chisel where Chisel asserts, assumes, and covers were not
extracted and left in the design.
Fixes#6864.
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
When an IRN has a huge number of top-level operations that need inner
ref verification, the current code scaled poorly as the amount of
per-op verification work is tiny (handful of hashtable lookups)
compared to the overhead and atomic access of failableParallelForEach.
Scan through the operations sequentially as a pre-pass and directly
verify operations with no regions, only using parallelization for
verifying recursive walks of modules.
Sometimes the start of a hierarchical path is an InnerRefAttr, and
sometimes the path is just a single FlatSymbolRefAttr. Either way, we
just need the StringAttr refering to the module name. There is a
helper called `root` for this on HierPathOp. But at this point we are
constructing the path to build a HierPathOp, we don't already have
one. So, I've implemented this the same as how `root` is implemented.
This fixes a bug in InferReadWrite, the builder was not respecting dominance when updating the IR.
Ensure that the builder creates the constant at the start of the module.
The bug was introduced in #6818
This reverts commit 2e23cda6c2.
This change caused memories that were previously deduping to no
longer dedupe, so we're reverting this while we investigate. An
issue will be created to include a small reproducer and track
re-landing this change.
This PR updates the heuristic to infer an unmasked memory.
If all the bits of the mask signal are driven by the same value, then it can
be replaced with an unmasked memory.
(Example: `mem_RW0_wmask = {6{baseWrEn_F1}}`)
This is an attempt to fix a use case, in which firtool introduces masked memory
for an aggregate data type when the user expected an unmasked one.
The read-write port of a memory has an input enable `en` signal and a
write-mode `wmode` signal. The `en` signal enables the port for either
read/write mode. The `wmode` is enabled to set the memory in the write mode
and disabled to read from the memory.
This PR removes the dependency of `wmode` on the `en` signal of a read-write
port of a memory.
The `wmode` signal matters only if the `en` is enabled, hence traverse the
expression tree for the `wmode` and replace `en` with a constant `1`.
Compatibility dest/source operands were backwards,
introduced in #4656 .
Add test as "legacy wiring" as non-ref-type-port path is a hidden option.
Fixes#6819.
Instead of using the replicated op mechanism, fragments of SV code
which must precede certain modules are grouped into fragment ops.
Modules which rely on them reference them through a `emit.fragment`
attribute. The fragments are printed through ExportVerilog.
Subsequent PRs will fully replace replaced ops using fragments.
v3.11.2 had a requirements.txt file which had some python libs which
have the following security alerts:
CVE-2022-21797, joblib 1.1.0, Critical
CVE-2023-40267, gitpython 3.1.27, Critical
Extend the `ImportVerilog` conversion to support most of the basic
expressions that commonly appear in SystemVerilog input files. Also add
the correpsonding expression ops to the Moore dialect, and finally get
rid of the old MIR expressions file which is now obsolete.
Thanks @hailongSun2000 and @albertethon for doing a lot of the leg work
to get expression support in!
Co-authored-by: Hailong Sun <hailong.sun@terapines.com>
Co-authored-by: ShiZuoye <albertethon@163.com>
Co-authored-by: Martin Erhart <maerhart@outlook.com>
* [FIRRTL] Support alternative base paths in LowerClasses.
We previously had a constraint that paths are targeting entities in
the same owning module as the path. This allowed us to assume that a
single base path can be created for each owning module, and used in
all paths. However, we have transforms that extract entities targeted
by paths outside the paths' owning module.
To support this, we can instead plumb through base paths created
higher up in the instance graph down to the paths that need them. When
a path is detected outside the owning module, we find the module in
which the entity is instantiated and pass through its base path to the
paths that reference the entity.
Most of the work here is just plumbing, and the PathInfoTable has been
extended with new data structures and functions to support this.
This is already called in multiple places, and we will soon use it in
another situation. This can be expensive, so it is worth memoizing to
avoid repeatedly traversing the module bodies in the slow case.
To handle more complex situations, we will soon need to track some
more information related to paths. This carves out PathInfoTable as a
struct so we can add more fields for use in the same places as the
existing map.
To clearly separate semantics, define a bit-vector type and attribute instead of reusing the built-in integer attribute. The built-in integer is usually encoded using two SMT bit-vectors to model poison and the regular bit values.
We have an existing check that paths are in the same owning module as
the entity they target. This is absolutely required for hierarchical
references to compose with basepaths. However, we have legacy flows
that extract entities out of their owning module, and we want to be
able to target those things. This works around these conflicting
requirements by skipping the owning module check for local targets
only. This is safe because we still check such local targets are only
instantiated once, so there is no ambiguity even though they are not
instantiated within the owning module.
Fix an issue in the parser of the `firrtl.constant` op, which would
truncate the sign bit of negative constants without reporting an error.
This would for example accept -2 as a valid 1-bit constant, truncating
the `...11111110` bit pattern to `0`.
Most interesting arithmetic on APSInt asserts that both operands are
the same bitwidth, but the IntegerAttrs that we are working with may
have used the smallest necessary bitwidth to represent the number they
hold, and won't necessarily match.
This extends the smaller operand if necessary. This is safe to do,
even for operands like the RHS of a shift right, because it will zero
or sign extend without adding "significant bits" in the APSInt
representation. So if we had a shift right amount that previously fit
in 64 bits, and we had to extend it beyond 64 bits, we are still able
to truncate to 64 bits when performing the shift.
Will Dietz