Author Name: Clifford Wolf (@cliffordwolf)
Original Redmine Issue: 999 from https://www.veripool.org
Original Date: 2015-11-12
Original Assignee: Wilson Snyder (@wsnyder)

A PicoRV32 user reported problems with simulating the PicoRV32 CPU with Verilator. So I investigated and found the following bug in Verilator. Sorry for not positing a minimalist test case. I've tried to create one from scratch, but was unable to reproduce the problem this way.

Here is the problem: http://i.imgur.com/evkRLNx.png

alu_lts clearly should be high when reg_op1 is -1 and reg_op2 is 0. But it seems like Verilator incorrectly merges the alu_lts and alu_ltu signal.

Using current git head of verilator (4e4bc7b):

$ wget https://raw.githubusercontent.com/cliffordwolf/picorv32/master/picorv32.v

$ verilator -Wno-fatal --trace --cc picorv32.v

$ grep -r alu_lt obj_dir/Vpicorv32__Trace__Slow.cpp
	vcdp->declBit  (c+8,"v picorv32_core alu_ltu",-1);
	vcdp->declBit  (c+8,"v picorv32_core alu_lts",-1);
	vcdp->fullBit  (c+8,(vlTOPp->v__DOT__picorv32_core__DOT__alu_lts));

Interestingly, in the larger test bench that includes PicoRV32, the signals alu_lts and alu_ltu are not merged, but are still assigned the same expressions. Looking at the generated c++ code:

     // ALWAYS at picorv32.v:570
     vlTOPp->v__DOT__uut__DOT__alu_lts = (vlTOPp->v__DOT__uut__DOT__reg_op1
                                          < vlTOPp->v__DOT__uut__DOT__reg_op2);
     // ALWAYS at picorv32.v:571
     vlTOPp->v__DOT__uut__DOT__alu_ltu = (vlTOPp->v__DOT__uut__DOT__reg_op1
                                          < vlTOPp->v__DOT__uut__DOT__reg_op2);

In this case, manually changing the assignment for alu_lts fixes the problem and the testbench runs successfully:

     vlTOPp->v__DOT__uut__DOT__alu_lts = VL_LTS_III(1, 32, 32, vlTOPp->v__DOT__uut__DOT__reg_op1, vlTOPp->v__DOT__uut__DOT__reg_op2);