Code Anatomy On DebugTransportModule

[DecodeTheEncoded]

The Debug Transport Module(JTAG DTM specifically) translates the access of JTAG data registers(dmi jtag data register particularly) from JTAG interface into access request to debug module's dmi address space via dmi bus. The holistic logic of JTAG DTM is coordinated via JTAG state machine, there are 1 instruction register chain(irChain) and 4 data registers chains in RC impl(bypassChain, idcodeChain, dmiAccessChain, dtmInfoChain), The debugger can write to instruction register chain the intended data chain index(shift-in a series of bits into irChain in state of Shift-IR, and during the Update-IR state irChain will have the correctly set data chain index, and corresponding data chain will be put into the scan chain), then the debugger can shift-in bits into the corresponding data register chain in state Shift-IR; Once the data register chain has been filled with purpose data, debugger will direct JTAG go to Update-DR; The Update-DR and Capture-DR are 2 crucial states for DTM, as depicted in the debug spec 6.1.5:

In Update-DR, the DTM starts the operation specified in op unless the current status reported in op is sticky.

In Capture-DR, the DTM updates data with the result from that operation, updating op if the current op isn’t sticky.

After a data register chain is selected by the instruction register, needed bits will be shifted into that data register chain by debugger in Shift-DR; After all needed bits are shifted, the debugger will transfer state to Update-DR, the implementation will conduct specific logic depending on the selected data register chain and contents in that register. Particularly , for instance, after the dmi data register chain is selected in instruction register, in Update-DR state a dmi bus request will be sent to debug module(TLDebugModuleOuterAsync, specifically). After some time interval, the debugger will transfer the states to Capture-DR, during this state, some implementation dependent info will be loaded into the selected data register chain. In terms of dmidata register,the result of a previous access to the dmi address space will be captured into the selected data register(if the time between Update-DR and Capture-DR is less than interval needed for a DM dmi address space access, busyResp will be captured instead. If the DM itself returns an error, extra logic is needed to handle this situation， will talk later). The holistic io interface of the DTM is depicted in figure below:

There are mainly 4 scala class&objects in the implementation, see detailed depiction below:

• CaptureUpdateChain
CaptureUpdateChain represents a jtag register chain, the io of CaptureUpdateChain module is as follows:

/** Base JTAG shifter IO, viewed from input to shift register chain.
* Can be chained together.
*/
class ShifterIO extends Bundle {
  val shift = Bool()  // advance the scan chain on clock high
  val data = Bool()  // as input: bit to be captured into shifter MSB on next rising edge; as output: value of shifter LSB
  val capture = Bool()  // high in the CaptureIR/DR state when this chain is selected
  val update = Bool()  // high in the UpdateIR/DR state when this chain is selected

  /** Sets a output shifter IO's control signals from a input shifter IO's control signals.
    */
  def chainControlFrom(in: ShifterIO): Unit = {
    shift := in.shift
    capture := in.capture
    update := in.update
  }
}
trait ChainIO extends Bundle {
  val chainIn = Input(new ShifterIO)
  val chainOut = Output(new ShifterIO)
}
class Capture[+T <: Data](gen: T) extends Bundle {
  val bits = Input(gen)  // data to capture, should be always valid
  val capture = Output(Bool())  // will be high in capture state (single cycle), captured on following rising edge
}

class ModIO extends ChainIO {
  val capture = Capture(genCapture)
  val update = Valid(genUpdate)  // valid high when in update state (single cycle), contents may change any time after
}
val io = IO(new ModIO)

The io of a register chain has two parts: ModIO with ChainIO, the ChainIO part is connected with JTAG Controller, it's used to shift in&out the register chain under control of JTAG state. val chainIn = Input(new ShifterIO) is used for shift into the register, and val chainOut = Output(new ShifterIO) is used for shifting out. The fields in ModIO are capture and update, the update.valid notifies outside world that JTAG state is in Update-DR(this is asserted by update of chainIn), it's time to conduct specific operations using the bits in this register, update.bits carries the bits in the selected data register chain. capture has two sub-ios:

class Capture[+T <: Data](gen: T) extends Bundle {
  val bits = Input(gen)  // data to capture, should be always valid
  val capture = Output(Bool())  // will be high in capture state (single cycle), captured on following rising edge
}

bits carries data needed to capture(store) into this register chain. capture.capture is output indicating the JTAG state machine now is in Capture-IR or Capture-DR, this signal is asserted by the chainIn.capture coming from JTAG controller. The implementation of CaptureUpdateChain is pretty straightforward:

/** Simple shift register with parallel capture only, for read-only data registers.
  *
  * Number of stages is the number of bits in gen, which must have a known width.
  *
  * Useful notes:
  * 7.2.1c shifter shifts on TCK rising edge
  * 4.3.2a TDI captured on TCK rising edge, 6.1.2.1b assumed changes on TCK falling edge
  */
class CaptureChain[+T <: Data](gen: T)(implicit val p: Parameters) extends Chain {
  class ModIO extends ChainIO {
    val capture = Capture(gen)
  }
  val io = IO(new ModIO)
  io.chainOut chainControlFrom io.chainIn

  val n = DataMirror.widthOf(gen) match {
    case KnownWidth(x) => x
    case _ => require(false, s"can't generate chain for unknown width data type $gen"); -1  // TODO: remove -1 type hack
  }

  val regs = (0 until n) map (x => Reg(Bool()))

  io.chainOut.data := regs(0)

  property.cover(io.chainIn.capture, "chain_capture", "JTAG; chain_capture; This Chain captured data")
  
  when (io.chainIn.capture) {
    (0 until n) map (x => regs(x) := io.capture.bits.asUInt()(x))
    io.capture.capture := true.B
  } .elsewhen (io.chainIn.shift) {
    regs(n-1) := io.chainIn.data
    (0 until n-1) map (x => regs(x) := regs(x+1))
    io.capture.capture := false.B
  } .otherwise {
    io.capture.capture := false.B
  }
  assert(!(io.chainIn.capture && io.chainIn.update)
      && !(io.chainIn.capture && io.chainIn.shift)
      && !(io.chainIn.update && io.chainIn.shift))
}

There are other versions of register chains: CaptureChain for read-only jtag registers like idcode, and JtagBypassChain for default bypassChain. It could be confusing sometimes in terms of capture-read juxtaposition. Call idcode read-only is from perspective of debugger, that register chain can actually be updated using the given values in io.capture.capture. The debugger can shift that value out, but it can not shift in some new value into that register. Therefore, it's a read-only register for debugger. Also note that the inner representation regs will always shifts its LSB bit out into io.chainOut.data := regs(0), and the shift-in bits go to the MSB.

• JtagTapController
JtagTapController controls the state of JTAG TAP, there is a JtagStateMachine inside JtagTapController, it outputs the current jtag states according its io.tms signal. JtagTapController has one instruction register chain(irChain) inside(there is only one instruction register inside RC), and will shift in&out that instruction register from&to the jtag.TDI and jtag.TDO, assert the io.chainIn.capture and io.chainIn.update of irChain under specific jtag state(Shift-IR, Capture-IR and Update-IR). JtagTapController can also interact with selected data register chain basically the same way with embedded instruction register chain(irChain), but via its io signal dataChainOut and dataChainIn, the selected data register chain is indicated with signal activeInstruction, it's normally updated at the state of Update-IR using the shift-in value of irChain. It's worth noting the name convention here, io.dataChainOut of JtagTapController goes to the chainIn of the selected CaptureUpdateChain, and the the chainOut of the selected CaptureUpdateChain will flow back to io.dataChainIn of JtagTapController; Moreover, jtag.TDO is driven by TDOdata(tdo registered) which may come from selected data register chain(currState === JtagState.ShiftDR.U) or irChian(currState === JtagState.ShiftIR.U) depending on the current jtag state. The JtagTapController code base is as follows with some comments adding on:

/** JTAG TAP controller internal block, responsible for instruction decode and data register chain
  * control signal generation.
  *
  * Misc notes:
  * - Figure 6-3 and 6-4 provides examples with timing behavior
  */
class JtagTapController(irLength: Int, initialInstruction: BigInt)(implicit val p: Parameters) extends Module {
  require(irLength >= 2)  // 7.1.1a

  val io = IO(new JtagControllerIO(irLength))

  val tdo = Wire(Bool())  // 4.4.1c TDI should appear here uninverted after shifting
  val tdo_driven = Wire(Bool())

  val clock_falling = WireInit((!clock.asUInt).asClock)

  val tapIsInTestLogicReset = Wire(Bool())

  //
  // JTAG state machine
  //

  val currState = Wire(JtagState.State.chiselType)

  // At this point, the TRSTn should already have been
  // combined with any POR, and it should also be
  // synchronized to TCK.
  require(!io.jtag.TRSTn.isDefined, "TRSTn should be absorbed into jtckPOReset outside of JtagTapController.")
  withReset(io.control.jtag_reset) {
    val stateMachine = Module(new JtagStateMachine)
    stateMachine.suggestName("stateMachine")
    stateMachine.io.tms := io.jtag.TMS
    currState := stateMachine.io.currState
    io.output.state := stateMachine.io.currState
     // 4.5.1a TDO changes on falling edge of TCK, 6.1.2.1d driver active on first TCK falling edge in ShiftIR and ShiftDR states
    withClock(clock_falling) {
      val TDOdata   = RegNext(next=tdo, init=false.B).suggestName("tdoReg")
      val TDOdriven = RegNext(next=tdo_driven, init=false.B).suggestName("tdoeReg")
      io.jtag.TDO.data   := TDOdata
      io.jtag.TDO.driven := TDOdriven
    }
  }

  //
  // Instruction Register
  //
  // 7.1.1d IR shifter two LSBs must be b01 pattern
  // TODO: 7.1.1d allow design-specific IR bits, 7.1.1e (rec) should be a fixed pattern
  // 7.2.1a behavior of instruction register and shifters
  val irChain = Module(CaptureUpdateChain(UInt(irLength.W)))
  irChain.suggestName("irChain")
  irChain.io.chainIn.shift := currState === JtagState.ShiftIR.U
  irChain.io.chainIn.data := io.jtag.TDI
  irChain.io.chainIn.capture := currState === JtagState.CaptureIR.U
  irChain.io.chainIn.update := currState === JtagState.UpdateIR.U
  irChain.io.capture.bits := "b01".U//hjr that said the capture of instruction register will always give constant value.

  withClockAndReset(clock_falling, io.control.jtag_reset) {
    val activeInstruction = RegInit(initialInstruction.U(irLength.W))
    when (tapIsInTestLogicReset) {
      activeInstruction := initialInstruction.U
    }.elsewhen (currState === JtagState.UpdateIR.U) {
      activeInstruction := irChain.io.update.bits
    }
    io.output.instruction := activeInstruction
  }

  tapIsInTestLogicReset := currState === JtagState.TestLogicReset.U
  io.output.tapIsInTestLogicReset := tapIsInTestLogicReset

  //
  // Data Register
  //
  io.dataChainOut.shift := currState === JtagState.ShiftDR.U
  io.dataChainOut.data := io.jtag.TDI
  io.dataChainOut.capture := currState === JtagState.CaptureDR.U
  io.dataChainOut.update := currState === JtagState.UpdateDR.U

  //
  // Output Control
  //
  when (currState === JtagState.ShiftDR.U) {
    //hjr io.dataChianIn is coming from the data chains outside this module(JtagTapController)
    tdo := io.dataChainIn.data
    tdo_driven := true.B
  } .elsewhen (currState === JtagState.ShiftIR.U) {
    //hjr the instruction chain is located inside this module(JtagTapController), consequently irChain.io.chainOut.data is the requested tdo.
    tdo := irChain.io.chainOut.data
    tdo_driven := true.B
  } .otherwise {
    // Needed when using chisel3._ (See #1160)
    tdo := DontCare
    tdo_driven := false.B
  }
}

• object JtagTapGenerator
  This object is mainly for dynamically connecting JtagTapController's dataChainOut and dataChainIn with the chainIn and chainOut of the selected data chain. It also defines intermediate wire(internalIo) to propagate io signal jtag and control(reset) of DTM into JtagTapController, and io.output of JtagTapController to elsewhere.
  In terms of dynamic connection, controllerInternal.io.dataChainIn(input to the JtagTapController) needs to be driven by selected data register's chainOut, furthermore controllerInternal.io.dataChainOut needs to drive chainIn of of the selected data register, chainIn of unselected data chains needs to be driven by unusedChainOut. This is why we need foldOutSelect and mapInSelect. The foldOutSelect function is very sleek, it constructs a series of elsewhen clauses to represent choose only 1 from many signal. The mapInSelect just constructs a when(){}.otherwise{} clause for each data chains' io.chainIn. Below is the code base of JtagTapGenerator with comment:

object JtagTapGenerator {
  /** JTAG TAP generator, enclosed module must be clocked from TCK and reset from output of this
    * block.
    *
    * @param irLength length, in bits, of instruction register, must be at least 2
    * @param instructions map of instruction codes to data register chains that select that data
    * register; multiple instructions may map to the same data chain
    * @param idcode optional idcode instruction. idcode UInt will come from outside this core.
    *
    * @note all other instruction codes (not part of instructions or idcode) map to BYPASS
    * @note initial instruction is idcode (if supported), otherwise all ones BYPASS
    *
    * Usage notes:
    * - 4.3.1b TMS must appear high when undriven
    * - 4.3.1c (rec) minimize load presented by TMS
    * - 4.4.1b TDI must appear high when undriven
    * - 4.5.1b TDO must be inactive except when shifting data (undriven? 6.1.2)
    * - 6.1.3.1b TAP controller must not be (re-?)initialized by system reset (allows
    *   boundary-scan testing of reset pin)
    *   - 6.1 TAP controller can be initialized by a on-chip power on reset generator, the same one
    *     that would initialize system logic
    *
    * TODO:
    * - support concatenated scan chains
    */
  def apply(irLength: Int, instructions: Map[BigInt, Chain], icode: Option[BigInt] = None)(implicit p: Parameters): JtagBlockIO = {

    val internalIo = Wire(new JtagBlockIO(irLength, icode.isDefined))


    // Create IDCODE chain if needed
    val allInstructions = icode match {
      case (Some(icode)) => {
        require(!(instructions contains icode), "instructions may not contain IDCODE")
        val idcodeChain = Module(CaptureChain(new JTAGIdcodeBundle()))
        idcodeChain.suggestName("idcodeChain")
        val i = internalIo.idcode.get.asUInt()
        assert(i % 2.U === 1.U, "LSB must be set in IDCODE, see 12.1.1d")
        assert(((i >> 1) & ((1.U << 11) - 1.U)) =/= JtagIdcode.dummyMfrId.U,
          "IDCODE must not have 0b00001111111 as manufacturer identity, see 12.2.1b")
        idcodeChain.io.capture.bits := internalIo.idcode.get
        instructions + (icode -> idcodeChain)

      }
      case None => instructions
    }

    val bypassIcode = (BigInt(1) << irLength) - 1  // required BYPASS instruction
    val initialInstruction = icode.getOrElse(bypassIcode) // 7.2.1e load IDCODE or BYPASS instruction after entry into TestLogicReset

    require(!(allInstructions contains bypassIcode), "instructions may not contain BYPASS code")

    val controllerInternal = Module(new JtagTapController(irLength, initialInstruction))

    val unusedChainOut = Wire(new ShifterIO)  // De-selected chain output
    unusedChainOut.shift := false.B
    unusedChainOut.data := false.B
    unusedChainOut.capture := false.B
    unusedChainOut.update := false.B

    val bypassChain = Module(JtagBypassChain())

    // The Great Data Register Chain Mux
    bypassChain.io.chainIn := controllerInternal.io.dataChainOut  // for simplicity, doesn't visibly affect anything else
    require(allInstructions.size > 0, "Seriously? JTAG TAP with no instructions?")

    // Need to ensure that this mapping is ordered to produce deterministic verilog,
    // and neither Map nor groupBy are deterministic.
    // Therefore, we first sort by IDCODE, then sort the groups by the first IDCODE in each group.
    val chainToIcode = (SortedMap(allInstructions.toList:_*).groupBy { case (icode, chain) => chain } map {
      case (chain, icodeToChain) => chain -> icodeToChain.keys
    }).toList.sortBy(_._2.head)
    println("hejianrui : chianToIcode is")
    println(chainToIcode)
    val chainToSelect = chainToIcode map {
      case (chain, icodes) => {
        assume(icodes.size > 0)
        val icodeSelects = icodes map { controllerInternal.io.output.instruction === _.asUInt(irLength.W) }
        chain -> icodeSelects.reduceLeft(_||_)
      }
    }

    controllerInternal.io.dataChainIn := bypassChain.io.chainOut  // default
    //hjr todo is this over-engineered way to traverse the chainToSelect just to show off? Or something deeper?
    def foldOutSelect(res: WhenContext, x: (Chain, Bool)): WhenContext = {
      val (chain, select) = x
      // Continue the WhenContext with if this chain is selected
      res.elsewhen(select) {
        controllerInternal.io.dataChainIn := chain.io.chainOut//hjr this kind of signal organization is just wired. And talent
      }
    }

    val emptyWhen = when (false.B) { }  // Empty WhenContext to start things off
    chainToSelect.toSeq.foldLeft(emptyWhen)(foldOutSelect).otherwise {
      controllerInternal.io.dataChainIn := bypassChain.io.chainOut
    }

    def mapInSelect(x: (Chain, Bool)): Unit = {
      val (chain, select) = x
      when (select) {
        chain.io.chainIn := controllerInternal.io.dataChainOut
      } .otherwise {
        chain.io.chainIn := unusedChainOut
      }
    }

    chainToSelect.map(mapInSelect)

    internalIo.jtag <> controllerInternal.io.jtag
    internalIo.control <> controllerInternal.io.control
    internalIo.output <> controllerInternal.io.output

    internalIo
  }

}

• the main DebugTransportModuleJTAG
  With depictions above, we can now begin to clarify the main part of DTM logic; In shorter words, code in main DebugTransportModuleJTAG handles update or capture request for every data register chain. Furthermore, most of the code is for handling the dmi data register chain.
  From CaptureUpdateChain we know that each register chain already carries update and capture signal that is combinationally asserted by the dataChainOut (of Type ShifterIO) from JtagTapController. Consequently, there is few logic coupled with JtagTapController in DebugTransportModuleJTAG.
  When dmi chain has its update.valid asserting, it indicates a new access request to dmi address space of dm should be initiated, but there are exceptions, see code sequence below:

  //--------------------------------------------------------
  // Drive Ready Valid Interface

  val dmiReqValidCheck = WireInit(false.B)
  assert(!(dmiReqValidCheck && io.dmi.req.fire()), "Conflicting updates for dmiReqValidReg, should not happen.");

  when (dmiAccessChain.io.update.valid) {
    when (stickyBusyReg) {
      //hjr according to the debug spec, the data scanned into dmi in this access will be ignored.
      // Do Nothing
    }.elsewhen (downgradeOpReg || (dmiAccessChain.io.update.bits.op === DMIConsts.dmi_OP_NONE)) {
      //Do Nothing ---hjr todo why this and the stickyBusyReg are seperate branches???
      dmiReqReg.addr := 0.U
      dmiReqReg.data := 0.U
      dmiReqReg.op   := 0.U
    }.otherwise {
      dmiReqReg := dmiAccessChain.io.update.bits
      dmiReqValidReg := true.B
      dmiReqValidCheck := true.B
    }
  }

There are situations that we can't initiate a new request(during update):
1, busy during previous capture;
When an access to dmi address space of dm is still ongoing when the debugger decides to capture the dmi chain, the signal busy is asserted(busy := (busyReg & !io.dmi.resp.valid) | stickyBusyReg;):

// We are busy during a given CAPTURE
// if we haven't received a valid response yet or if we
// were busy last time without a reset.
// busyReg will still be set when we check it,
// so the logic for checking busy looks ahead.
busy := (busyReg & !io.dmi.resp.valid) | stickyBusyReg;
/*
* hjr
* busy just indicates an ongoing operation doesn't have its response back yet.However, Setting the error bit(busy specifically) in op of dmi register
* based on the busy signal should only be conducted when there is a debugger capture request.
* */
when (dmiAccessChain.io.capture.capture) {
  //hjr indicating the DM responds with a bad code, the following access should be downgraded.
  downgradeOpReg := (!busy & nonzeroResp)
  stickyBusyReg := busy
  stickyNonzeroRespReg := nonzeroResp
}

Note the sticky version of busy: stickyBusyReg; The op field of dmi data chain can be used to indicate whether a previous access request succeeded; There are 3 states for op: success(0), failed(2), busy(3). This field is sticky in terms of debugger read(capture) so that any failed access request before will cause that field set stickily--that is, unless explicit reset by writing dmireset in dtmcs chain, this field will hold that failed code so that no new access can be initiated. The rationale of making this field sticky is well explained in the spec:

The still-in-progress status is sticky to accommodate debuggers that batch together a number of scans, which must all be executed or stop as soon as there’s a problem.
For instance a series of scans may write a Debug Program and execute it. If one of the writes fails but the execution continues, then the Debug Program may hang or have other unexpected side effects.

According to busy := (busyReg & !io.dmi.resp.valid) | stickyBusyReg;, Each time we consider busy during update state, we actually take the busy flag of history access into account(stickyBusyReg), stickyBusyReg is set during Capture-DR, and will keep asserting until explicitly reset. If busy is asserted during Update-DR, the access request will be somehow bypassed(Do Nothing);

when (dmiAccessChain.io.update.valid) {
  when (stickyBusyReg) {
    //hjr according to the debug spec, the data scanned into dmi in this access will be ignored.
    // Do Nothing
  }
  ...
}

When busy is asserted during capture, the busyResp will be loaded into the dmi chain:

  busyResp.addr  := 0.U
  busyResp.resp  := ~(0.U(DMIConsts.dmiRespSize.W)) // Generalizing busy to 'all-F'
  busyResp.data  := 0.U

2, Incorrect response during previous capture
There are another unexpected situation in terms of capture, the returned op code by dm through dmi bus is non zero, therefore indicating an implementation specific error happened. This status is also sticky in RC impl(stickyNonzeroRespReg), stickyNonzeroRespReg will keep asserting once there was an error before, like the way how stickyBusyReg is reset . But another signal downgradeOpReg is introduced, downgradeOpReg is set during capture: downgradeOpReg := (!busy & nonzeroResp); During update if downgradeOpReg is found asserted(instead of using the always-asserting stickyNonzeroRespReg), it means a previous access is incorrect, therefore this access request at update should be canceled:

when (dmiAccessChain.io.update.valid) {
.....
  elsewhen (downgradeOpReg || (dmiAccessChain.io.update.bits.op === DMIConsts.dmi_OP_NONE)) {
        //Do Nothing ---hjr todo why this and the stickyBusyReg are seperate branches???
        dmiReqReg.addr := 0.U
        dmiReqReg.data := 0.U
        dmiReqReg.op   := 0.U
      }
}

However, during update, downgradeOpReg will be deasserted(take effect one cycle later):

  // Downgrade/Skip. We make the decision to downgrade or skip
  // during every CAPTURE_DR, and use the result in UPDATE_DR.
  // The sticky versions are reset by write to dmiReset in DTM_INFO.
  when (dmiAccessChain.io.update.valid) {
    downgradeOpReg := false.B
  }

Therefore, if a capture captures incorrect response, the next access request initiated via update will be bypassed, however, if there are continuous updates, the subsequent update except for 1st one will succeed. I have no knowledge to understand this design consideration, why can't we just use the sticky version of non zero resp: stickyNonzeroRespReg to decide whether to initiate a proper access request?? --A series dmi writes????;

If none of the stickyBusyReg and downgradeOpReg || (dmiAccessChain.io.update.bits.op === DMIConsts.dmi_OP_NONE) is asserted. A proper access request can be initiated:

  when (dmiAccessChain.io.update.valid) {
    ...
    otherwise {
      dmiReqReg := dmiAccessChain.io.update.bits
      dmiReqValidReg := true.B
      dmiReqValidCheck := true.B
    }
  }

Assertion of dmiReqValidReg will valid the dmi.req: io.dmi.req.valid := dmiReqValidReg, the related handshake logic is as follows:

io.dmi.req.valid := dmiReqValidReg
// This is a name-based, not type-based assignment. Do these still work?--hjr todo what??
io.dmi.req.bits := dmiReqReg

when (io.dmi.req.fire()) {
  dmiReqValidReg := false.B
}

Once a proper access request is sent via dmi bus, after some time interval, the dm may return the access result through dmi bus. The debugger can direct the state machine to Capture-DR to capture the result into dmi data chain.

  //--------------------------------------------------------
  // Debug Access Chain Implementation
  // hjr note that capture states will always update the data register with/without valid response.
  // hjr during capture-DR, the dmi chain register is updated using the dmiAccessChain.io.capture.bits
  // hjr note that the value modification is effective one cycle later.
  dmiAccessChain.io.capture.bits := Mux(busy, busyResp, Mux(io.dmi.resp.valid, dmiResp, nopResp))

  io.dmi.resp.ready := Mux(
    dmiReqReg.op === DMIConsts.dmi_OP_WRITE,
      // for write operations confirm resp immediately because we don't care about data
      io.dmi.resp.valid,
      // for read operations confirm resp when we capture the data
      dmiAccessChain.io.capture.capture & !busy)//hjr why not busy as a prerequisite

  when (io.dmi.resp.fire()) {
    busyReg := false.B
  }

Note the logic of asserting io.dmi.resp.ready, for write operations confirm resp immediately because we don't care about data, I feel confused on this, this means io.dmi.resp.ready := io.dmi.resp.valid in terms of DMIConsts.dmi_OP_WRITE(anytime io.dmi.resp.valid, this handshake is considered firing ). If the dm returns ack info for this write access when the jtag state machine is not in Capture, there are chances that this ack-for-write will not be properly loaded into dmi data chain. Maybe in real world, they just assume the write to dm always succeed??

Note that the stickyNonzeroRespReg and stickyBusyReg can only be explicitly reset by dtmInfoChain.io.update.valid:

  //hjr the sticky bits can only be cleared by the dmireset signal.
  when (dtmInfoChain.io.update.valid) {
    when (dtmInfoChain.io.update.bits.dmireset) {
      stickyNonzeroRespReg := false.B
      stickyBusyReg := false.B
    }
  }

Other part of the main DebugTransportModuleJTAG is easy to understand, once you read comments above, below is the code base with some embedded comment：

// Use the Chisel Name macro due to the bulk of this being inside a withClockAndReset block
class DebugTransportModuleJTAG(debugAddrBits: Int, c: JtagDTMConfig)
  (implicit val p: Parameters) extends RawModule  {

  val io = IO(new Bundle {
    val jtag_clock = Input(Clock())
    val jtag_reset = Input(Reset()) // This is internally converted to AsyncReset.
                                    // We'd prefer to call this AsyncReset, but that's a fairly
                                    // invasive API change.
    val dmi = new DMIIO()(p)
    val jtag = Flipped(new JTAGIO(hasTRSTn = false)) // TODO: re-use SystemJTAGIO here?
    val jtag_mfr_id = Input(UInt(11.W))
    val jtag_part_number = Input(UInt(16.W))
    val jtag_version = Input(UInt(4.W))
  })
  val rf_reset = IO(Input(Reset()))    // RF transform

  withClockAndReset(io.jtag_clock, io.jtag_reset.asAsyncReset) {

  //--------------------------------------------------------
  // Reg and Wire Declarations

  val dtmInfo = Wire(new DTMInfo)

  val busyReg = RegInit(false.B)
  val stickyBusyReg = RegInit(false.B)
  val stickyNonzeroRespReg = RegInit(false.B)
  /*
  * hjr todo have trouble figuring out why this is even needed?
  * The stick bits can be used to cancel the following access.
  * */
  val downgradeOpReg = RegInit(false.B) // downgrade op because prev. failed.

  val busy = Wire(Bool())
  val nonzeroResp = Wire(Bool())

  val busyResp    = Wire(new DMIAccessCapture(debugAddrBits))
  val dmiResp     = Wire(new DMIAccessCapture(debugAddrBits))
  val nopResp     = Wire(new DMIAccessCapture(debugAddrBits))

  //hjr there is a dmi req needs to send through dmi bus
  //hjr 1,when the dmi data register chain is selected, and the jtag state is in Update-DR
  //hjr 2,the sticky busy reg flag is not being set:stickyBusyReg, no former operations end with busy err
  //hjr 3,downgradeOpReg is not being set(don't downgrade this op),no former operations end with error result
  //hjr 4, this is not a dmi_OP_NONE request.
  //hjr once all condition above is fulfilled, dmiReqReg will be set. Meaning that a dmi request is about to send
  //hjr note that once a dmi request is successively sent(io.dmi.req.fire()), dmiReqValidReg should be deasserted.
  val dmiReqReg  = Reg(new DMIReq(debugAddrBits))
  val dmiReqValidReg = RegInit(false.B)

  val dmiStatus = Wire(UInt(2.W))

  //--------------------------------------------------------
  // DTM Info Chain Declaration

  dmiStatus := Cat(stickyNonzeroRespReg, stickyNonzeroRespReg | stickyBusyReg)

  dtmInfo.debugVersion  := 1.U // This implements version 1 of the spec.
  dtmInfo.debugAddrBits := debugAddrBits.U
  dtmInfo.dmiStatus     := dmiStatus
  dtmInfo.dmiIdleCycles := c.debugIdleCycles.U
  dtmInfo.reserved0     := 0.U
  dtmInfo.dmireset      := false.B // This is write-only hjr todo this is wired. I never seem write only before
  dtmInfo.reserved1     := 0.U

  val dtmInfoChain = Module (CaptureUpdateChain(gen = new DTMInfo()))
  dtmInfoChain.io.capture.bits := dtmInfo

  //--------------------------------------------------------
  // Debug Access Chain Declaration

   val dmiAccessChain = Module(CaptureUpdateChain(genCapture = new DMIAccessCapture(debugAddrBits),
     genUpdate = new DMIAccessUpdate(debugAddrBits)))

  //--------------------------------------------------------
  // Debug Access Support

  // Busy Register. We become busy when we first try to send a request.
  // We stop being busy when we accept a response.

  when (io.dmi.req.valid) {
    busyReg := true.B
  }
  when (io.dmi.resp.fire()) {
    busyReg := false.B
  }

  // We are busy during a given CAPTURE
  // if we haven't received a valid response yet or if we
  // were busy last time without a reset.
  // busyReg will still be set when we check it,
  // so the logic for checking busy looks ahead.
  busy := (busyReg & !io.dmi.resp.valid) | stickyBusyReg;

  // Downgrade/Skip. We make the decision to downgrade or skip
  // during every CAPTURE_DR, and use the result in UPDATE_DR.
  // The sticky versions are reset by write to dmiReset in DTM_INFO.
  when (dmiAccessChain.io.update.valid) {
    downgradeOpReg := false.B
  }
  /*
  * hjr
  * busy just indicates an ongoing operation doesn't have its response back yet.However, Setting the error bit(busy specifically) in op of dmi register
  * based on the busy signal should only be conducted when there is a debugger capture request.
  * */
  when (dmiAccessChain.io.capture.capture) {
    //hjr indicating the DM responds with a bad code, the following access should be downgraded.
    downgradeOpReg := (!busy & nonzeroResp)
    stickyBusyReg := busy
    stickyNonzeroRespReg := nonzeroResp
  }
  //hjr the sticky bits can only be cleared by the dmireset signal.
  when (dtmInfoChain.io.update.valid) {
    when (dtmInfoChain.io.update.bits.dmireset) {
      stickyNonzeroRespReg := false.B
      stickyBusyReg := false.B
    }
  }

  // Especially for the first request, we must consider dtmResp.valid,(hjr todo should be dmiResp.valid`)
  // so that we don't consider junk in the FIFO to be an error response.
  // The current specification says that any non-zero response is an error.
  nonzeroResp := stickyNonzeroRespReg | (io.dmi.resp.valid & (io.dmi.resp.bits.resp =/= 0.U))
  property.cover(!nonzeroResp, "Should see a non-zero response (e.g. when accessing most DM registers when dmactive=0)")
  property.cover(!stickyNonzeroRespReg, "Should see a sticky non-zero response (e.g. when accessing most DM registers when dmactive=0)")

  busyResp.addr  := 0.U
  busyResp.resp  := ~(0.U(DMIConsts.dmiRespSize.W)) // Generalizing busy to 'all-F'
  busyResp.data  := 0.U

  dmiResp.addr := dmiReqReg.addr
  dmiResp.resp := io.dmi.resp.bits.resp
  dmiResp.data := io.dmi.resp.bits.data

  nopResp.addr := 0.U
  nopResp.resp := 0.U
  nopResp.data := 0.U

  //--------------------------------------------------------
  // Debug Access Chain Implementation
  // hjr note that capture states will always update the data register with/without valid response.
  // hjr during capture-DR, the dmi chain register is updated using the dmiAccessChain.io.capture.bits
  // hjr note that the value modification is effective one cycle later.
  dmiAccessChain.io.capture.bits := Mux(busy, busyResp, Mux(io.dmi.resp.valid, dmiResp, nopResp))

  //--------------------------------------------------------
  // Drive Ready Valid Interface

  val dmiReqValidCheck = WireInit(false.B)
  assert(!(dmiReqValidCheck && io.dmi.req.fire()), "Conflicting updates for dmiReqValidReg, should not happen.");

  when (dmiAccessChain.io.update.valid) {
    when (stickyBusyReg) {
      //hjr according to the debug spec, the data scanned into dmi in this access will be ignored.
      // Do Nothing
    }.elsewhen (downgradeOpReg || (dmiAccessChain.io.update.bits.op === DMIConsts.dmi_OP_NONE)) {
      //Do Nothing ---hjr todo why this and the stickyBusyReg are seperate branches???
      dmiReqReg.addr := 0.U
      dmiReqReg.data := 0.U
      dmiReqReg.op   := 0.U
    }.otherwise {
      dmiReqReg := dmiAccessChain.io.update.bits
      dmiReqValidReg := true.B
      dmiReqValidCheck := true.B
    }
  }

  when (io.dmi.req.fire()) {
    dmiReqValidReg := false.B
  }

  io.dmi.resp.ready := Mux(
    dmiReqReg.op === DMIConsts.dmi_OP_WRITE,
      // for write operations confirm resp immediately because we don't care about data
      io.dmi.resp.valid,
      // for read operations confirm resp when we capture the data
      dmiAccessChain.io.capture.capture & !busy)//hjr why not busy as a prerequisite
  /*
  * hjr
  * deassertion of busy is actually async with the assertion of capture:
  * capture is determined by the debugger, raising capture means the debugger wants the specified data register gets set by whatever value is available on capture.bits.
  * When capture is asserted while the DM is still busying conducting operation(busy is asserted), this is somewhat incorrect.
  * */
  // incorrect operation - not enough time was spent in JTAG Idle state after DMI Write
  property.cover(dmiReqReg.op === DMIConsts.dmi_OP_WRITE & dmiAccessChain.io.capture.capture & busy, "Not enough Idle after DMI Write");
  // correct operation - enough time was spent in JTAG Idle state after DMI Write
  property.cover(dmiReqReg.op === DMIConsts.dmi_OP_WRITE & dmiAccessChain.io.capture.capture & !busy, "Enough Idle after DMI Write");

  // incorrect operation - not enough time was spent in JTAG Idle state after DMI Read
  property.cover(dmiReqReg.op === DMIConsts.dmi_OP_READ & dmiAccessChain.io.capture.capture & busy, "Not enough Idle after DMI Read");
  // correct operation - enough time was spent in JTAG Idle state after DMI Read
  property.cover(dmiReqReg.op === DMIConsts.dmi_OP_READ & dmiAccessChain.io.capture.capture & !busy, "Enough Idle after DMI Read");

  io.dmi.req.valid := dmiReqValidReg

  // This is a name-based, not type-based assignment. Do these still work?--hjr todo what??
  io.dmi.req.bits := dmiReqReg

  //--------------------------------------------------------
  // Actual JTAG TAP
  val idcode = WireInit(0.U.asTypeOf(new JTAGIdcodeBundle()))
  idcode.always1    := 1.U
  idcode.version    := io.jtag_version
  idcode.partNumber := io.jtag_part_number
  idcode.mfrId      := io.jtag_mfr_id

  val tapIO = JtagTapGenerator(irLength = 5,
    instructions = Map(
      dtmJTAGAddrs.DMI_ACCESS -> dmiAccessChain,
      dtmJTAGAddrs.DTM_INFO   -> dtmInfoChain),
    icode = Some(dtmJTAGAddrs.IDCODE)
  )

  tapIO.idcode.get := idcode//hjr so idcode is coming from outer world, not inside the TAP.
  tapIO.jtag <> io.jtag

  tapIO.control.jtag_reset := io.jtag_reset.asAsyncReset

  //--------------------------------------------------------
  // TAP Test-Logic-Reset state synchronously resets the debug registers.

  when (tapIO.output.tapIsInTestLogicReset) {
    busyReg := false.B
    stickyBusyReg := false.B
    stickyNonzeroRespReg := false.B
    downgradeOpReg := false.B
    dmiReqValidReg := false.B
  }

}}