[FIRRTL] error in dead code mismatch
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 2.2k
- Forks
- 524
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 46
Description
The following FIRRTL program
circuit top_mod :
module mod_0 :
input clock0: Clock
input reset: Reset
module top_mod :
input clock0: Clock
input reset: UInt<1>
Compiled with firtool --lower-to-hw --infer-widths --imconstprop --lowering-options=disallowPackedArrays,emittedLineLength=8192 --mlir-timing --verilog -o=$VFILE2 produces this error:
a_top_mod.fir:2:10: error: 'firrtl.module' op contains an abstract reset type after InferResets
module mod_0 :
^
a_top_mod.fir:2:10: note: see current operation: "firrtl.module"() ( {
^bb0(%arg0: !firrtl.clock, %arg1: !firrtl.reset): // no predecessors
}) {annotations = [], portAnnotations = [[], []], portDirections = 0 : i2, portNames = ["clock0", "reset"], sym_name = "mod_0", type = (!firrtl.clock, !firrtl.reset) -> ()} : () -> ()
Compiled with firrtl-1.5-SNAPSHOT produces this Verilog:
module top_mod(
input clock0,
input reset
);
endmodule
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the provided minimal FIRRTL program with the shown firtool command and compare it with the firrtl-1.5-SNAPSHOT behavior. Trace the lowering steps around the unused mod_0 module and reset handling; done means the dead-code mismatch is resolved without the abstract reset type error and the resulting Verilog behavior is consistent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100