Configurable I$ banking

[eric-lefort]

Currently, I am configuring a rocket chip with a 64-byte wide L2 write width, MBUS and axi4 port. I have also moved from an 8-byte to a 64-byte system bus. (and TileBus)

I am not very well-versed in chisel, but I am seeing that the i-cache is now instantiating 16 banks in order to upsize from the 4-byte fetch width to the 64-byte TileBus. This banking scheme is very costly in terms of area. I am interested in adding a parameter that modifies this scheme in order to instantiate memories with wider lines and write masks.

Is this a sensible change or are there other, more subtle reasons that this may be a bad idea?
I am assuming the primary required changes will be the decode logic and potential additional stalls on reads coming back to I$ (less banks ~~ more bank collisions)

Interestingly, the d-cache is being instantiated in a manner more suitable to my application, with 64-byte wide memories that have write masks for more narrow reads, and separate banks for each way.
(on the side, I was wondering if there are intentional reasons behind these different banking schemes)

Here's some of the code instantiating the memories (rest is in src/main/scala/rocket/ICache.scala)

  val data_arrays = Seq.tabulate(tl_out.d.bits.data.getWidth / wordBits) {
    i =>
      DescribedSRAM(
        name = s"data_arrays_${i}",
        desc = "ICache Data Array",
        size = nSets * refillCycles,
        data = Vec(nWays, UInt(dECC.width(wordBits).W))
      )
  }

[jerryz123]

You can use

rocket-chip/src/main/scala/subsystem/Configs.scala

Line 261 in dbcb06a

class WithRocketCacheRowBits(n: Int) extends Config((site, here, up) => {

to force a specific cache width.