TLArbiter lowestIndexFirst bug report

Type of issue: bug report

Impact: lowestIndexFirst behaves wrong and threw firrtl exception under some circumstances.

the TileLink arbiter policy lowestIndexFirst's one liner implementation is as follows:https://github.com/chipsalliance/rocket-chip/blob/46c88b71056581a6bf2a0c4febd5ec3d768c6c59/src/main/scala/tilelink/Arbiter.scala#L16

val lowestIndexFirst: Policy = (width, valids, select) => ~(leftOR(valids) << 1)(width-1, 0)
The impl is actually straightforward, but when you call this policy using parameters:(width = 4, valilds = "b0001".U, select =false.B), the firrtl threw the following exception:
Exception in thread "main" firrtl.passes.CheckWidths$BitsWidthException: @[ChiselTester.scala 32:48]: [target ~PassThroughGenerator|PassThroughGenerator] High bit 3 in bits operator is larger than input width 3 in bits(_finalValid_T_4, 3, 0).
I traced the code and figured out this is due to the auto width triming of chisel operator <<, "b0001".U<<1 will give you an UInt of width 2 instead of 4. And when you want to get [3,0] part of a 2-bit UInt, the firrtl will complain.

I have no idea if this is a real functionl bug or there are actually some protection clause to prevent this behavior from actually triggering. I just read the implmentation code line by line and lack of knowledge holisticlly.
@terpstra
@hcook

Start in src/main/scala/tilelink/Arbiter.scala at the lowestIndexFirst policy and reproduce it with width 4, valids "b0001".U, and select false.B. Inspect the FIRRTL width error reported at ChiselTester.scala:32:48 and verify the policy no longer requests bits beyond the shifted value's width while preserving its intended behavior.