clock domain confusion on debug-related components #3010
Unanswered
DecodeTheEncoded
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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
andTLDebugModuleOuterAsync
, theTLDebugModuleOuterAsync
works at thedmiClock
domain, that is theTCK
fed into the DM from SimJTAG. TheTLDebugModuleOuterAsync
is there so that some debugging operation can be conducted even when the hart is not ready, like sethaltreq
, 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 oftl_clock
, coming from the bus where debug module is connected as a slave, and hart is the master.However, there is another clock related signal in the Inner part:
debug_clock
, and this is the working clock domain ofTLDebugModuleInnerAsync
and its sub component:TLDebugModuleInner
:It seems that this debug_clock comes from the top level clock signal, I wonder what's the relation between this
debug_clock
and thetl_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
andlazymodule.module.clock
, see code below:rocket-chip/src/main/scala/devices/debug/Debug.scala
Line 1777 in 00d9e02
In
TLDebugModuleInnerAsync
's LazyRawModuleImp impl, thechildClock
isio.debug_clock
, that means all child lazymodule ofTLDebugModuleInnerAsync
will havedebug_clock
as their clock domain; However,io.debug_clock
is specified again to the sub lazymodule'smodule.clock
:dmInner.module.clock := io.debug_clock
, it's obvious that thedmInner
(TLDebugModuleInner
) is the sub lazymodule ofTLDebugModuleInnerAsync
, so I feel the code below are redundant:rocket-chip/src/main/scala/devices/debug/Debug.scala
Line 1782 in 00d9e02
However, I am curious which clock domain setting will out-clock one another if different clock signal are assigned to them:
Which will take effect???
Any comments are appreciated, thanks.
@mwachs5 @ernie-sifive
Beta Was this translation helpful? Give feedback.
All reactions