verilator giving error while generating a rocketchip. firrtl bug?

[ygkim912]

I got the following error and did not generate the rocketchip C simulator when I added a memory port to freechips.rocketchip.system.DefaultConfig.

The error message is:

…/chipyard/sims/verilator/generated-src/freechips.rocketchip.system.DefaultTestConfig/freechips.rocketchip.system.DefaultTestConfig.harness.mems.v:842: Operator COND expects 64 bits on the Conditional False, but Conditional False's CONST '1'h0' generates 1 bits.
... Use "/* verilator lint_off WIDTH */" and lint_on around source to disable this message.
%Error: Exiting due to 1 warning(s)

It geneated a wrong mux in the freechips.rocketchip.system.DefaultTestConfig.harness.mems.fir and freechips.rocketchip.system.DefaultTestConfig.harness.mems.v:

R0_data <= mux(eq(R0_addr_sel_reg, UInt<2>("h0")), R0_data_0, mux(eq(R0_addr_sel_reg, UInt<2>("h1")), R0_data_1, mux(eq(R0_addr_sel_reg, UInt<2>("h2")), R0_data_2, mux(eq(R0_addr_sel_reg, UInt<2>("h3")), R0_data_3, UInt<1>("h0")))))

` assign R0_data = R0_addr_sel_reg == 2'h0 ? R0_data_0 : R0_addr_sel_reg == 2'h1 ? R0_data_1 : R0_addr_sel_reg == 2'h2 ? R0_data_2 : R0_addr_sel_reg == 2'h3 ? R0_data_3 : 1'h0;

`

And the last value should be UInt<64>("h0"))))) and 64'h0.

The codes what I added in rocket-chip/src/main/scala/system/Configs.scala:

class WithTestMemPort extends Config((site, here, up) => {
  case ExtMem => Some(MemoryPortParams(MasterPortParams(
    base = x"8000_0000",
    size = x"8000_0000",
    beatBytes = site(MemoryBusKey).beatBytes,
    idBits = 4), 1))
})
class DefaultTestConfig extends Config(new WithTestMemPort ++ new WithNBigCores(1) ++ new BaseConfig)

And The error happened when I run the verilator with the DefaultTestConfig and the MasterPortParams.size is equal to or larger than 8000_0000h.

It seems to be related to firrtl.
Thanks for your help.
Young.

[ygkim912]

Solved by ucb-bar/barstools#74 (comment)

[baltazarortiz]

I'm getting a similar bug, but I'm pretty unclear on where it's coming from (I'm trying to make some stuff that hooks into a Chipyard design). Any tips on debugging? Or should I just figure out how to bump barstools to get the patch?

update - just pulled barstools and I'm no longer getting the error. Thanks for the fix!

[colinschmidt]

We plan on getting the fix into the next release. Glad it works for you now.

[baltazarortiz]

Sounds good! I tried making another change and the error is back, even after reverting the change and running make clean before rebuilding. Is there anything else I have to do other than just updating barstools to get the patch included in my build process?

The first time I rebuilt after updating barstools, the only thing that seemed to run was a few barstools macro commands and then building c++ files.

Just in case it makes a difference, the exact error I'm getting is slightly different:

%Warning-STMTDLY: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3235: Unsupported: Ignoring delay on this delayed state
ment.
                  ... Use "/* verilator lint_off STMTDLY */" and lint_on around source to disable this message.
%Warning-STMTDLY: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3280: Unsupported: Ignoring delay on this delayed state
ment.
%Warning-WIDTH: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3437: Operator LT expects 32 bits on the RHS, but RHS's V
ARREF 'MEMSIZE' generates 12 bits.
%Warning-WIDTH: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3437: Operator LT expects 32 bits on the RHS, but RHS's V
ARREF 'MEMSIZE' generates 11 bits.
%Warning-WIDTH: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3438: Operator ASSIGN expects 129 bits on the Assign RHS,
 but Assign RHS's REPLICATE generates 130 bits.
%Warning-WIDTH: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3440: Operator ASSIGN expects 129 bits on the Assign RHS,
 but Assign RHS's REPLICATE generates 130 bits.
%Warning-WIDTH: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3441: Operator ASSIGN expects 129 bits on the Assign RHS,
 but Assign RHS's REPLICATE generates 130 bits.
%Warning-WIDTH: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3442: Operator ASSIGN expects 129 bits on the Assign RHS,
 but Assign RHS's REPLICATE generates 130 bits.
%Warning-WIDTH: /home/ubuntu/testnew/chipyard-my-hw/sims/verilator/generated-src/example.TestHarness.MyHWRocketConfig/mkWrapper.v:3443: Operator ASSIGN expects 129 bits on the Assign RHS,
 but Assign RHS's REPLICATE generates 130 bits.
%Error: Exiting due to 9 warning(s)

If there's a specific part of the verillog or FIRRTL files that would be helpful for you, let me know!

[baltazarortiz]

Looks like if I rerun the compilation with a single core it catches the need to run the macros (uncertain this is the right terminology, not super familiar with this part of the Chisel toolchain/build system). Possibly something similar is happening here as #377 / #386 ?

Specifically, I have to rerun the compilation with a single core. If I run the rest of the build single core or multicore, it still seems to fail with the verilator errors.

[albert-magyar]

Is the mkWrapper.v file being generated by some custom part of your flow?

[baltazarortiz]

I don't believe so, I created Chisel hardware description in my own generator then modified Top.scala and RocketConfigs.scala in the example generator to pull them into a Chipyard build.