RISC-V调试支持草案：0.14.0-DRAFT版

需积分: 0 162 浏览量更新于2024-07-10 收藏 920KB PDF 举报

"RISC-V调试支持版本0.14.0-DRAFT" RISC-V是一种开放源码的指令集架构（ISA），旨在提供高效、模块化和可扩展的计算平台。RISC-V Debug Support Version 0.14.0-DRAFT 是针对RISC-V架构的调试规范的一个草案版本，由Ernie Edgar和Tim Newsome等人编辑，由SiFive公司贡献。这个文档的目的是定义一套标准，使得开发者能够有效地调试基于RISC-V架构的处理器和系统。调试在软件开发中至关重要，因为它允许开发者识别并修复代码中的错误。对于RISC-V这样的ISA，调试支持是确保开发者能充分利用其灵活性和效率的关键组件。此草案涵盖了多个关键概念和功能，包括： 1. **调试接口**：定义了用于连接调试器和目标处理器的通信协议。这通常涉及到JTAG（Joint Test Action Group）或SWD（Serial Wire Debug）等物理层协议，以及更高级别的调试协议，如DPI（Debug Port Interface）。 2. **断点机制**：调试器能够设置和管理断点，使程序在特定地址暂停执行，以便检查程序状态。这可能包括硬件断点，它们在指令执行时由处理器硬件自动检测，以及软件断点，通过修改指令来实现。 3. **寄存器访问**：调试器需要能够读取和修改处理器的通用寄存器和特殊寄存器，以分析程序执行的上下文。 4. **内存访问**：调试器应能够读写目标系统的内存，以便查看变量值、堆栈帧和数据结构。 5. **单步执行**：允许调试器控制处理器，使其每次只执行一条指令，便于跟踪程序流程。 6. **异常和中断处理**：调试器需要理解处理器如何处理异常和中断，以便在这些事件发生时正确地响应和恢复。 7. **线程和多核支持**：在多核RISC-V系统中，调试器需要能够独立控制和调试每个核心，同时跟踪线程间的交互。 8. **调试模块（Debug Module, DM）**：DM是RISC-V调试体系结构的核心，它负责与调试器通信，并控制CPU进入调试模式。 9. **调试事件模型**：定义了如何处理和报告调试相关的事件，如断点命中、陷阱、系统调用等。 10. **安全性与隐私**：调试接口需要考虑安全性，防止未经授权的访问，同时保护调试过程中可能暴露的敏感信息。这个草案的贡献者列表展示了来自不同组织和个人的专业知识，他们共同致力于改进和标准化RISC-V的调试体验。尽管该规范仍处于草案阶段，但随着RISC-V的普及，最终的调试规范将对整个RISC-V生态系统的成熟和完善起到重要作用。

4 RISC-V Debug Support Version 0.14.0-DRAFT

1.4 Supported Features

The debug interface described in this speciﬁcation supports the following features:

1. All hart registers (including CSRs) can be read/written.

2. Memory can be accessed either from the hart’s point of view, through the system bus directly,

or both.

3. RV32, RV64, and future RV128 are all supported.

4. Any hart in the platform can be independently debugged.

5. A debugger can discover almost

everything it needs to know itself, without user conﬁguration.

6. Each hart can be debugged from the very ﬁrst instruction executed.

7. A RISC-V hart can be halted when a software breakpoint instruction is executed.

8. Hardware single-step can execute one instruction at a time.

9. Debug functionality is independent of the debug transport used.

10. The debugger does not need to know anything about the microarchitecture of the harts it is

debugging.

11. Arbitrary subsets of harts can be halted and resumed simultaneously. (Optional)

12. Arbitrary instructions can be executed on a halted hart. That means no new debug function-

ality is needed when a core has additional or custom instructions or state, as long as there

exist programs that can move that state into GPRs. (Optional)

13. Registers can be accessed without halting. (Optional)

14. A running hart can be directed to execute a short sequence of instructions, with little overhead.

(Optional)

15. A system bus master allows memory access without involving any hart. (Optional)

16. A RISC-V hart can be halted when a trigger matches the PC, read/write address/data, or

an instruction opcode. (Optional)

17. Harts can be grouped, and harts in the same group will all halt when any of them halts.

These groups can also react to or notify external triggers. (Optional)

This document does not suggest a strategy or implementation for hardware test, debugging or error

detection techniqes. Scan, BIST, etc. are out of scope of this speciﬁcation, but this speciﬁcation

does not intend to limit their use in RISC-V systems.

It is possible to debug code that uses software threads, but there is no special debug support for

it.

Notable exceptions include information about the memory map and peripherals.

8 RISC-V Debug Support Version 0.14.0-DRAFT

instead of the “RISC-V Debug Speciﬁcation 0.14.0-DRAFT”.

A single DM can debug up to 2

harts.

3.1 Debug Module Interface (DMI)

Debug Modules are slaves to a bus called the Debug Module Interface (DMI). The master of the

bus is the Debug Transport Module(s). The Debug Module Interface can be a trivial bus with

one master and one slave (see A.3), or use a more full-featured bus like TileLink or the AMBA

Advanced Peripheral Bus. The details are left to the system designer.

The DMI uses between 7 and 32 address bits. It supports read and write operations. The bottom

of the address space is used for the ﬁrst (and usually only) DM. Extra space can be used for custom

debug devices, other cores, additional DMs, etc. If there are additional DMs on this DMI, the base

address of the next DM in the DMI address space is given in nextdm.

The Debug Module is controlled via register accesses to its DMI address space.

3.2 Reset Control

There are two methods that allow a debugger to reset harts. ndmreset resets all the harts in the

system, as well as all other parts of the system except for the Debug Modules, Debug Transport

Modules, and Debug Module Interface. Exactly what is aﬀected by this reset is implementation

dependent, but it must be possible to debug programs from the ﬁrst instruction executed. hartreset

resets all the currently selected harts. In this case an implementation may reset more harts than

just the ones that are selected. The debugger can discover which other harts are reset (if any) by

selecting them and checking anyhavereset and allhavereset.

To perform either of these resets, the debugger ﬁrst asserts the bit, and then clears it. The actual

reset may start as soon as the bit is asserted, but may start an arbitrarily long time after the bit

is deasserted. The reset itself may also take an arbitrarily long time. While the reset is on-going,

harts are either in the running state, indicating it’s possible to perform some abstract commands

during this time, or in the unavailable state, indicating it’s not possible to perform any abstract

commands during this time. Once a hart’s reset is complete, havereset becomes set. When a hart

comes out of reset and haltreq or resethaltreq are set, the hart will immediately enter Debug Mode

(halted state). Otherwise, if the hart was initially running it will execute normally (running state)

and if the hart was initially halted it should now be running but may be halted.

There is no general, reliable way for the debugger to know when reset has actually begun.

The Debug Module’s own state and registers should only be reset at power-up and while dmactive

in dmcontrol is 0. If there is another mechanism to reset the DM, this mechanism must also reset

all the harts accessible to the DM.

Due to clock and power domain crossing issues, it might not be possible to perform arbitrary DMI

剩余129页未读，继续阅读

修勾不见了

粉丝: 0
资源: 3

RISC-V调试支持草案：0.14.0-DRAFT版

P802.11ax-D8.0-Draft.pdf

riscv-privileged-draft-20191214-d98903e.pdf

riscv-spec-unprivileged-V20191214-draft.pdf

ISO TS 7849-2-2009 draft.pdf

BS ISO 18623-1-2014 Draft.pdf

riscv-spec-20191213.pdf

NIST SP800-160-vol2-draft.pdf

NIST SP800-133r1-draft.pdf

NIST SP800-38Gr1-draft.pdf

NIST SP800-175Br1-draft.pdf

最新资源