Open DecodeTheEncoded opened 2 weeks ago
@jerryz123 Jerry, sorry to bother, do you have any comment on this? Any reply will be very appreciated.
We haven't used the JTAG-driven reset in our test chips.
There is a PR right now to expose the reset pin for the JTAG state machine, but this isn't exactly what you are asking for.
We generally wire up the reset of the chip to the host FPGA, and use different FPGA bitstreams or FPGA capabilities to reset the chip during bringup, not JTAG.
For resetting harts, we haven't used hartResetReq
. We instead use the TileResetter memory-mapped control registers, which we can write to with serial-TL. Resetting harts during execution is also risky... it can put the memory interconnect and caches in a weird state, so I personally try to avoid it.
I'd be open to reviewing and merging any PRs that add debug-module-driven-bringup features.
We haven't used the JTAG-driven reset in our test chips.
There is a PR right now to expose the reset pin for the JTAG state machine, but this isn't exactly what you are asking for.
We generally wire up the reset of the chip to the host FPGA, and use different FPGA bitstreams or FPGA capabilities to reset the chip during bringup, not JTAG.
For resetting harts, we haven't used
hartResetReq
. We instead use the TileResetter memory-mapped control registers, which we can write to with serial-TL. Resetting harts during execution is also risky... it can put the memory interconnect and caches in a weird state, so I personally try to avoid it.I'd be open to reviewing and merging any PRs that add debug-module-driven-bringup features.
Thanks for your reply, Jerry, I really appreiciate your comment on this. In terms of use different FPGA bitstreams or FPGA capabilities to reset the chip during bringup, I think this is very typical way to reset the system. But I have some confusion on the current Debug IOBinder, it seems that the the system reset will reset the whole soc, including the DTM and DM.
d.systemjtag.map { j =>
**j.reset := ResetCatchAndSync(j.jtag.TCK, clockBundle.reset.asBool)**
j.mfr_id := p(JtagDTMKey).idcodeManufId.U(11.W)
j.part_number := p(JtagDTMKey).idcodePartNum.U(16.W)
j.version := p(JtagDTMKey).idcodeVersion.U(4.W)
}
I think many people expect a debuging functionality that the core can jump right into the DebugROM out of reset. But it seems that there is no way to accomplish this under the current IOBinder configration because the system reset or power on reset will reset all part of SOC, including the TLDebugOuter which is in charge of handling the dmcontrol
logic. Could you please confirm this? @jerryz123
After pondering about this again, I feel like jumping directly to DebugRom
out of reset is actually not very necessary if you use the current chipyard BOOTROM, the wfi
keeps waiting for interrupts, and program counter will go nowhere without interrupts, therefore this is almost the same as jumping to DebugROM and wait for command
from DMI. Even though the system reset also resets the DM and DTM, when the core is awake, you still can send the haltreq
to the core through dmcontrol
dmi register, the side effect is minor, because the core is wfi(waiting for interrupts), and will not jump out of BootROM.
Background Work
OS Setup
Not-relevant
Other Setup
Ex: Prior steps taken / Documentation Followed / etc...
Current Behavior
Hi Community, Our team is taping out a chipyard based design and we have confusion on the JTAG interface. Currently, it seems that the iobinder for
HasPeripheryDebug
punched out only JTAGChipIO(4 wires) out of chip. After going thru the code, it seems that thendreset
are left unconnected, this means that the debugger can not writendmreset
field ofdmcontrol
to reset the whole system(except theDTM
ANDDM
), also thesystem.resetctrl.hartResetReq
seems also unconnected, indicating that we can not reset the specific hart by assertinghartreset
indmcontrol
. So, If we leave the iobinder as it currently is, does this mean that there is no way for debuggers to forcefully reset the whole system or a speicific hart. Since this is our first tapout, I wonder if this is the default debugging configuration for other team that had tapped out chipyard based design before. Can anyone shed some light into this? Any help will be appreciated. Thanks for you work.Expected Behavior
See above
Other Information
No response