fix(SRAM.scala): change x_sel_1 RegNext to Reg(Bool())

[Chelsea819]

Related issue:

Type of change: bug report

Impact: no functional change

Development Phase: implementation

Release Notes

File Changed: SRAM.scala

The code involved is as follows:

    val r_sel0 = address.contains(in.ar.bits.addr)
    val w_sel0 = address.contains(in.aw.bits.addr)

    val r_sel1 = RegNext(r_sel0)
    val w_sel1 = RegNext(w_sel0)
    when (in.aw.fire) {
      w_id := in.aw.bits.id
      w_sel1 := w_sel0
      w_echo :<= in.aw.bits.echo
    }
    when (in.ar.fire) {
      r_id := in.ar.bits.id
      r_sel1 := r_sel0
      r_echo :<= in.ar.bits.echo
    }

Change Description: In the original code within the SRAM.scala file, the signals r_sel_1 and w_sel_1 were being assigned values based on the rising edge of the clock using in.ax.bits.addr. Consequently, the rresp and wresp wire signals, which are directly controlled by r_sel_1 and w_sel_1, could result in incorrect behavior where the response signals did not accurately reflect the addr signal captured upon the successful handshake of the read address channel. This could potentially lead to an incorrect RESP_DECERR condition.

Detailed Explanation: Consider a scenario where the addr_read channel handshake is completed. Post-handshake, the raddr signal could theoretically take any value (as long as rvalid is 0), for instance, it could change to 0. The previous code version could inadvertently cause rresp to incorrectly transition to a value of 3 under such circumstances. If the master’s rready signal does not immediately assert to 1, but instead is delayed by one or more clock cycles, the response captured at the time of the successful read channel handshake could be 3. According to the AXI4 specification, a response value of 3 indicates that the rdata associated with the transaction is invalid.

Fix Implemented: The assignment of r_sel_1 and w_sel_1 has been modified to ensure that the rresp and wresp signals accurately reflect the addr signal captured at the moment of the successful read address channel handshake. This change prevents the occurrence of an invalid response code (3) being incorrectly assigned to rresp when the rready signal is delayed, thereby maintaining protocol compliance and data integrity as per the AXI4 specification.

[linux-foundation-easycla]

• ✅login: Chelsea819 / (6357077)

The committers listed above are authorized under a signed CLA.