clock domain confusion on debug-related components #3010

DecodeTheEncoded · 2022-07-22T09:40:40Z

DecodeTheEncoded
Jul 22, 2022

First thing first, glad to be first one posting here since the Discussions announcement!!
I have some confusion on the clock domain hierachy of Debug Module:
Consider the debugger connects with the DM via JTAG DTM; Inside the Debug Module, there are two sub-components TLDebugModuleInnerAsync and TLDebugModuleOuterAsync, the TLDebugModuleOuterAsync works at the dmiClock domain, that is the TCK fed into the DM from SimJTAG. The TLDebugModuleOuterAsync is there so that some debugging operation can be conducted even when the hart is not ready, like set haltreq, changing the selected harts, etc.. So, This Outer part is reasonable to function under the outer clock: that is dmiClock;

However, the clock domain of the TLDebugModuleInnerAsync confuses me a lot, the inner part is for handling other dmi register except the ones in outer part, and these registers could only be accessed by debugger when the inner part is ready (that is, the inner part has its clock working), otherwise the request to these dmi registers by debugger will be bypassed: (dmiBypass.module.io.bypass := ~io.ctrl.dmactive | ~dmactiveAck). Since the inner part is also memory mapped into the hart's memory space so that the hart could be aware of the debugger request(like FLAGS[hartid].go), therefore it's reasonable that the Inner part works at the clock domain of tl_clock, coming from the bus where debug module is connected as a slave, and hart is the master.

  val debugTLDomainOpt = p(DebugModuleKey).map { _ =>
    val domain = ClockSinkNode(Seq(ClockSinkParameters()))
    domain := tlbus.fixedClockNode
    domain
  }

However, there is another clock related signal in the Inner part: debug_clock, and this is the working clock domain of TLDebugModuleInnerAsync and its sub component:TLDebugModuleInner:

class TLDebugModuleInnerAsync(device: Device, getNComponents: () => Int, beatBytes: Int)(implicit p: Parameters) extends LazyModule{
......
  lazy val module = new LazyRawModuleImp(this) {
    childClock := io.debug_clock
    childReset := io.debug_reset

    val dmactive_synced = withClockAndReset(childClock, childReset) {
      val dmactive_synced = AsyncResetSynchronizerShiftReg(in=io.dmactive, sync=3, name=Some("dmactiveSync"))
      dmInner.module.clock := io.debug_clock
      dmInner.module.reset := io.debug_reset
      dmInner.module.io.tl_clock := io.tl_clock
      dmInner.module.io.tl_reset := io.tl_reset
      dmInner.module.io.dmactive := dmactive_synced
      dmInner.module.io.innerCtrl <> FromAsyncBundle(io.innerCtrl)
      dmInner.module.io.debugUnavail := io.debugUnavail
      io.hgDebugInt := dmInner.module.io.hgDebugInt
      io.extTrigger.foreach { x => dmInner.module.io.extTrigger.foreach {y => x <> y}}
      dmInner.module.io.hartIsInReset := io.hartIsInReset
      io.auth.foreach { x => dmInner.module.io.auth.foreach {y => x <> y}}
      dmactive_synced
    }
}
}

It seems that this debug_clock comes from the top level clock signal, I wonder what's the relation between this debug_clock and the tl_clock? Are they identical?

Also, I feel quiet confusing deducting the clock domain of a diplomatic module when the clock domain is specified by both the childClock and lazymodule.module.clock, see code below:

rocket-chip/src/main/scala/devices/debug/Debug.scala

Line 1777 in 00d9e02

childClock := io.debug_clock

    childClock := io.debug_clock
    childReset := io.debug_reset

In TLDebugModuleInnerAsync 's LazyRawModuleImp impl, the childClock is io.debug_clock, that means all child lazymodule of TLDebugModuleInnerAsync will have debug_clock as their clock domain; However, io.debug_clock is specified again to the sub lazymodule's module.clock: dmInner.module.clock := io.debug_clock, it's obvious that the dmInner (TLDebugModuleInner) is the sub lazymodule of TLDebugModuleInnerAsync, so I feel the code below are redundant:

rocket-chip/src/main/scala/devices/debug/Debug.scala

Line 1782 in 00d9e02

dmInner.module.clock := io.debug_clock

      dmInner.module.clock := io.debug_clock
      dmInner.module.reset := io.debug_reset

However, I am curious which clock domain setting will out-clock one another if different clock signal are assigned to them:

ParentLazymodule.module.childClock := clockA
subLazymodule.module.clock := clockB

Which will take effect???

Any comments are appreciated, thanks.
@mwachs5 @ernie-sifive

EmJunaid · 2025-05-28T18:34:37Z

EmJunaid
May 28, 2025

Hi @DecodeTheEncoded ,
tl_clock only get used when the optional flag hasBusMaster is set true. I guess this is the flag for optional debug feature of accessing memory from a hart’s point of view.
Also there is one more problem with the TLDebugModuleInner that I observed. I created a new issue , go check it out and see if you can help, thanks

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

clock domain confusion on debug-related components #3010

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

clock domain confusion on debug-related components #3010

Uh oh!

DecodeTheEncoded Jul 22, 2022

Replies: 1 comment

Uh oh!

EmJunaid May 28, 2025

DecodeTheEncoded
Jul 22, 2022

EmJunaid
May 28, 2025