Here is a picture of the change to the pipeline:
  https://app.lucidchart.com/invitations/accept/da44b89c-a93c-45e9-ba5e-cb6f9140d84e

Compared to the old pipeline, occupancy is increased from 2 cycles to 3 for:
 - atomics
 - sub-ECC-granularity writes
 - repaired ECC values

In exchange for this occupancy increase, a new register (REG) was added:
  sram data output => *REG* => ecc-correction => ALU => sram write setup
This path was sufficiently long that it limited fMAX on many designs.
In designs without ECC and without atomics, this pipeline is optimized away.

Compared to the old pipeline, response latency is unchanged (by default) for:
 - reads   (1)
 - atomics (1)
 - writes  (1)
 - ECC-repaired reads   (2)
 - ECC-repaired atomics (2)

Added a knob (sramReg) to set latency for all operations to 2.
With this knob disabled (the default), as in the old pipeline:
  - output data can flow uncorrected from the SRAM
  - output valid depends on correct ECC decode of SRAM output
With the knob enabled:
  - data flows from an ECC correction fed by registers
  - valid is a register

PTW clock_en l2_refill

Add another TLArbiter Policy "highestIndexFirst"

Remove PutPartial from DMIToTL

Fix unused args

Change wrdata width to support xLen != fLen case

Mark Certain LazyModules For Inlining

Added functions that allow you to look at the emits parameters