RISC-V调试系统深入解析：JTAG、DMI与DM的层次分工及Verilog实现

嵌入式开发这几年我最大的感受是RISC-V 这类开放指令集架构把过去 ARM 调试系统里的黑盒全部摊开了。你不再是连上调试器就能跑而是要真正理解 JTAG、DMI、DM 这些层次各干什么、怎么协作才能把芯片调明白。这篇文章就从底层开始把 RISC-V 调试系统完整拆开重点放在 JTAG、DMI、DM 三者的分工以及用 Verilog 实现时那些绕不开的状态机设计。适合刚接触 RISC-V 调试协议、准备自己做调试子系统或 FPGA 原型验证的工程师也适合被调试器连不上、CPU 停不下来这类问题折磨过的同学。1. 调试系统不是一条线而是三层结构1.1 用快递系统理解 JTAG、DMI、DM 的关系很多初学者拿到 RISC-V 调试规范第一反应是去看寄存器表结果越看越晕。我建议反过来先把整个链路想象成一套快递系统。你在电脑上跑 GDBGDB 背后有 OpenOCD 这类调试代理代理通过 USB 转 JTAG 适配器跟芯片打交道。适配器输出的四根 JTAG 信号相当于长途运输的公路。信号进入芯片后经过 TAPTest Access Port状态机在芯片内部形成一条扫描链这是第一层。扫描链上挂着好几个寄存器其中有一个叫 DMIDebug Module Interface的寄存器它充当了区域分拣中心的角色。你的调试请求到了这里会被翻译成对调试模块内部寄存器的读写操作这是第二层。真正干活的是第三层——DMDebug Module它是芯片里的本地仓库里面有一堆控制寄存器、状态寄存器负责让 CPU 核在 RISC-V 里叫 Hart停下来、跑起来、读写寄存器、访问内存。记住这个分层JTAG 管传输DMI 管翻译和路由DM 管执行。这套分层设计不是拍脑袋想出来的。JTAG 本来就是为芯片测试设计的边界扫描协议串行、速度慢但它简单可靠几乎所有芯片都有。DMI 作为中间层把 JTAG 的移位寄存器读写转换成语义清晰的内部总线操作。DM 则完全不用关心 JTAG 那边的时序细节只跟 DMI 打交道。这样每一层都能独立设计、独立验证调试模块甚至可以工作在与 JTAG 完全不同的时钟域里。1.2 每一层各管什么一张表说清楚如果你想在 Verilog 里实现这套东西脑子里必须有清晰的模块边界。层次核心组件主要职责典型信号/寄存器JTAG 层TAP、IR、DR扫描链移位、指令译码、数据串转并TCK/TMS/TDI/TDO、IDCODE、DTMCS、DMIDMI 层DTM 中的 DMI 状态机地址寻址、读写控制、busy/error 处理dmi_addr、dmi_data、dmi_op、dmi_dmerrDM 层寄存器堆、Hart 控制逻辑halt/resume、寄存器读写、程序缓冲执行dmcontrol、dmstatus、data0-11、abstractcsHart 层CPU 核调试接口响应 halt/resume 请求、进入调试模式debug_req、debug_halt、debug_resume我先多说一句很多人把 DTMDebug Transport Module和 DMI 混为一谈。DTM 是调试传输模块的统称JTAG DTM 只是其中一种实现。DMI 是 DTM 和 DM 之间的接口协议你可以理解成约定的总线格式。JTAG DTM 内部包含一个 DMI 状态机负责把 JTAG 扫描链上的串行数据变成对 DM 寄存器的并行读写。2. 四根线里的秘密JTAG 和 TAP 状态机2.1 为什么 JTAG 能传数据Shift 与 Update 的分工JTAG 对外就是四根线TCK 时钟、TMS 模式选择、TDI 数据输入、TDO 数据输出。它的核心是一个有限状态机在 TCK 的每一个上升沿根据 TMS 的电平跳转到下一个状态。这个状态机像一个圆环环上有几个关键节点其中最重要的是 Shift 和 Update。如果拿流水线来类比Shift 阶段就是传送带一格一格往前送包裹每个 TCK 沿把 TDI 上的一个 bit 送进移位寄存器。Update 阶段则是卸货,把移位寄存器里攒好的一整包数据一次性锁存到并行输出寄存器里。反过来Capture 阶段负责装货,把并行输入寄存器里的数据一次性抓进移位寄存器然后在接下来的 Shift 阶段逐个 bit 从 TDO 送出去。这套机制的精妙之处在于读写是异步错开的。你往扫描链里移入数据的同时上一个指令捕获到的数据正在从 TDO 被推出来。读和写共用同一个移位过程省了一半时间。2.2 IR 和 DR先选寄存器再传数据TAP 状态机里有两条扫描链一条叫指令寄存器 IR一条叫数据寄存器 DR。它们的长度不一样IR 通常是固定的比如 5 位或 8 位DR 则根据当前选中的指令长度可以完全不同。整个流程分两步走。第一步进入 Shift-IR 状态把一条指令从 TDI 移入 IR。第二步回到 Shift-DR 状态根据 IR 的值选通对应的数据寄存器进行真正的数据传输。比如说如果你移入的指令是 IDCODE那么 DR 就会接上 IDCODE 寄存器下次 Capture 时把芯片的 ID 码装进移位寄存器然后在 Shift-DR 状态从 TDO 读出来。常见的 RISC-V JTAG DTM 指令大概有这几条具体编码以你的实现为准指令名称功能DR 宽度IDCODE读取调试模块 ID32 位DTMCS读写 DTM 控制状态32 位DMI访问 DMI 接口通常是 42 位1 位复位 7 位地址 32 位数据 2 位操作DMI 指令的 DR 宽度值得注意。它一次打包了复位标志、地址、数据、操作类型四个字段也就是说你通过一次 JTAG 扫描链移位就能完成一次 DMI 请求的投递。2.3 Verilog 里写 TAP核心就一个状态机用 Verilog 实现 TAP本质就是写一个 16 状态的同步状态机标准 JTAG 定义的是 16 个状态有些资料画成 17 个是包含了上电路径。关键的状态跳转如下所示代码可以这样组织localparam TAP_RESET 4d0, TAP_IDLE 4d1, TAP_IR_SELECT 4d2, TAP_IR_CAPTURE 4d3, TAP_IR_SHIFT 4d4, TAP_IR_EXIT1 4d5, TAP_IR_UPDATE 4d7, TAP_DR_SELECT 4d8, TAP_DR_CAPTURE 4d9, TAP_DR_SHIFT 4d10, TAP_DR_EXIT1 4d11, TAP_DR_UPDATE 4d13; always (posedge tck or negedge trst_n) begin if (!trst_n) begin tap_state TAP_RESET; end else begin case (tap_state) TAP_RESET: tap_state tms ? TAP_RESET : TAP_IDLE; TAP_IDLE: tap_state tms ? TAP_IR_SELECT : TAP_IDLE; TAP_IR_SELECT: tap_state tms ? TAP_IR_CAPTURE : TAP_DR_CAPTURE; TAP_IR_CAPTURE: tap_state tms ? TAP_IR_EXIT1 : TAP_IR_SHIFT; TAP_IR_SHIFT: tap_state tms ? TAP_IR_EXIT1 : TAP_IR_SHIFT; TAP_IR_EXIT1: tap_state tms ? TAP_IR_UPDATE : TAP_IR_SHIFT; TAP_IR_UPDATE: tap_state tms ? TAP_IR_SELECT : TAP_IDLE; TAP_DR_SELECT: tap_state tms ? TAP_IR_CAPTURE : TAP_DR_CAPTURE; TAP_DR_CAPTURE: tap_state tms ? TAP_DR_EXIT1 : TAP_DR_SHIFT; TAP_DR_SHIFT: tap_state tms ? TAP_DR_EXIT1 : TAP_DR_SHIFT; TAP_DR_EXIT1: tap_state tms ? TAP_DR_UPDATE : TAP_DR_SHIFT; TAP_DR_UPDATE: tap_state tms ? TAP_IR_SELECT : TAP_IDLE; default: tap_state TAP_IDLE; endcase end end写 TAP 的时候有三个地方特别容易踩坑。第一个是 TDO 的三态控制只有在 Shift-IR 和 Shift-DR 状态时 TDO 才应该输出有效数据其他时候必须置为高阻否则多设备菊花链会打架。第二个是 Update 寄存器的时机必须在 Update-DR/Update-IR 状态的下降沿更新这样移位和更新才能完全隔离。第三个是异步复位很多芯片的 TRST 引脚是可选实现的如果你的设计没有这根线上电时必须通过 TMS 连续保持 5 个以上周期的高电平把状态机硬拉到 Reset 状态。3. DMI连接 JTAG 与调试模块的内部通道3.1 DMI 的请求格式地址、数据、操作三位一体JTAG TAP 把 DMI 寄存器当成一个 42 位的移位寄存器但移位完成之后这 42 位怎么解释就是 DMI 协议的事了。DMI 请求的典型字段包括1 位 dmireset7 位地址32 位数据2 位操作码。操作码的定义很简单0 表示忽略Ignore1 表示读2 表示写。如果你写过 AXI 总线会觉得 DMI 很像一个极简版本的 AXI-Lite但它没有独立的握手通道所有的请求和响应都挤在这 42 位里。正因为通道是复用的DMI 访问天然有一个延迟特性你这一次移入的请求对应的响应要等到下一次 DMI 访问时才能真正从 TDO 移出来。很多第一次做调试模块的人在这里栽跟头读寄存器时少做一次空操作结果读回来的数据永远是对不上的。3.2 busy 和 dmerr为什么调试器会卡死DMI 协议里有一个重要的状态反馈机制就是 dmerr 字段。当主机发起一次 DMI 读写时如果 DM 正忙无法及时响应DTM 会返回 dmerr3表示 busy。这时主机必须重试刚才的操作。如果 DM 一直忙主机就会一直重试表现出来就是调试器卡死报出类似 could not stop cortex-m device! please check the jtag cable 这类让人摸不着头脑的错误当然这是 ARM 的报错但 RISC-V 调试器同样有类似的超时机制。从 Verilog 实现的角度看busy 信号通常产生在 DM 内部。比如你发了一个写 data0 寄存器的请求但 DM 正在执行上一条抽象命令寄存器堆还没空闲这时它就应该拉高 busy。DTM 拿到 busy 后不会真的把这次写操作提交而是记录一个 dmerrbusy 的状态等主机下次访问时上报。3.3 DTM 状态机IDLE、READ、WAIT、WRITE 四态循环JTAG DTM 的核心是 DMI 状态机它负责管理一次 DMI 操作的整个生命周期。常见的设计是四个状态IDLE、READ、WAIT、WRITE。IDLE 表示总线空闲DMI 寄存器里的数据被解开根据 op 字段决定下一步动作。如果是读请求进入 READ 状态把地址送到 DM 侧然后进入 WAIT 等待 DM 返回数据。如果是写请求进入 WRITE 状态把数据和地址一起锁存到 DM 侧同样等待 DM 接受。DM 接受之后状态机会回到 IDLE同时把 dmerr 状态更新为成功把读取的数据缓存到 DMI 寄存器的数据字段。这里的关键是读取的数据不能当场通过 TDO 返回而是先存起来等下一次 DMI 扫描链移位时再在 Capture 阶段装进移位寄存器。这就回到了前面说的流水线效应。用 Verilog 写这个状态机核心代码结构大致如下localparam DMI_IDLE 2d0, DMI_READ 2d1, DMI_WAIT 2d2, DMI_WRITE 2d3; reg [1:0] dmi_state; reg [31:0] dmi_rdata_q; reg [1:0] dmi_err_q; always (posedge clk or negedge rst_n) begin if (!rst_n) begin dmi_state DMI_IDLE; dmi_rdata_q 32d0; dmi_err_q 2d0; end else begin case (dmi_state) DMI_IDLE: begin if (dmi_req_valid) begin if (dmi_op DMI_OP_READ) begin dmi_state DMI_READ; end else if (dmi_op DMI_OP_WRITE) begin dmi_state DMI_WRITE; end end end DMI_READ: begin dmi_state DMI_WAIT; end DMI_WAIT: begin if (dm_busy) begin dmi_err_q 2b11; // busy dmi_state DMI_IDLE; end else if (dm_valid) begin dmi_rdata_q dm_rdata; dmi_err_q 2d0; // ok dmi_state DMI_IDLE; end end DMI_WRITE: begin if (dm_busy) begin dmi_err_q 2b11; dmi_state DMI_IDLE; end else begin dmi_err_q 2d0; dmi_state DMI_IDLE; end end default: dmi_state DMI_IDLE; endcase end end写 DTM 的时候我建议把 dmi_err_q 和数据返回都做成寄存器输出避免组合逻辑路径太长。JTAG 时钟通常不会太快但 DMI 状态机如果跨到系统时钟域寄存器的时序余量还是要认真查的。4. DM调试模块真正干活的大脑4.1 DM 寄存器别背要理解组合关系DM 里面有很多寄存器但真正核心的也就这几类控制状态类dmcontrol、dmstatus、数据类data0-11、抽象命令类abstractcs、command、程序缓冲类progbuf0-15、系统总线访问类sbcs、sbaddress0-3、sbdata0-3。寄存器作用dmcontrol控制 hart 的 halt/resume、复位、hart 选择、DM 激活dmstatus反映 hart 状态比如是否已暂停、是否 runningdata0-11抽象命令的数据通道读写 GPR 时作用最大abstractcs抽象命令的状态包括命令是否忙、错误码command写入后触发抽象命令执行progbuf0-15程序缓冲可以写入指令让 hart 执行sbcs / sbdata系统总线访问控制用来读写内存我见过很多人试图把每个寄存器的 bit 位都背下来我觉得没必要。RISC-V Debug Spec 的寄存器数量不多但 bit 位极其琐碎。更好的方法是把寄存器按功能组理解控制 hart 用哪一组、传输数据用哪一组、发起命令用哪一组。用的时候查规范对应的表格比硬背高效。4.2 核心操作流程如何让 CPU 停下来调试系统最基础的操作就是让 CPU 停下来读它的寄存器再让它继续跑。这个过程对应 OpenOCD 内部的完整流程也对应你 Verilog 实现里 DM 逻辑的核心状态转移。第一步激活 DM。写 dmcontrol 的 dmactive 位为 1DM 内部的寄存器堆才开始工作。第二步选择 hart。对多核芯片需要把 hartsel 设成目标核的编号。第三步发起暂停请求。在 dmcontrol 里把 haltreq 置 1。第四步轮询 dmstatus等 allhalted 或 anyhalted 变成 1。CPU 可能正在处理中断或者在一个不可打断的总线事务里所以这一步需要等待。让 CPU 恢复运行的流程完全对称。往 dmcontrol 写 resumereq1然后轮询 allrunning确认 CPU 已经重新跑起来。关于这个流程有一个小细节值得强调haltreq 是电平信号不是脉冲。你不能写了 1 之后立刻清零必须等 hart 真正进入调试模式、allhalted 有效之后才可以把 haltreq 清掉。有些芯片对这一点的处理比较宽松但严谨的设计还是建议用一个状态机把 haltreq 保持到确认暂停为止。4.3 读写寄存器和内存抽象命令与程序缓冲CPU 停下来之后调试器要读 GPR比如读出 a0 的值。这个过程在 RISC-V 里有两种主流实现方式。第一种是抽象命令Abstract Command。调试器把命令写到 command 寄存器比如访问寄存器命令再把要访问的寄存器编号放在相关字段数据则通过 data0 寄存器传递。DM 硬件自己解析命令去读取 hart 的寄存器文件然后把数据填到 data0 里。这种方式的优点是实现简单缺点是真的慢因为每一步都要等命令执行完。第二种是程序缓冲Program Buffer。调试器把一段 RISC-V 汇编指令直接写进 progbuf0-n比如csrr t0, mstatus; store to memory之类的然后让 DM 控制 hart 执行这段程序。这就像你请了个助手把具体活交给他干比你自己一步步指挥要快得多。对比项抽象命令程序缓冲速度慢每条命令都有握手开销快可以连续执行多条指令实现难度DM 硬件需要理解命令语义DM 只需要填充程序并触发执行灵活性受限于命令集可以用任意汇编指令调试寄存器可以直接读 CSR需要通过窗口寄存器间接访问实际调试系统中两种方案经常配合使用寄存器读写用抽象命令批量内存访问用程序缓冲。4.4 Verilog 里 DM 状态机怎么搭DM 内部的逻辑核心是那个控制 hart 的状态机。如果只实现最基本的功能状态转移大概是这样localparam DM_IDLE 3d0, DM_HALT_REQ 3d1, DM_WAIT_HALT 3d2, DM_HALTED 3d3, DM_RESUME_REQ 3d4, DM_WAIT_RUN 3d5; reg [2:0] dm_state; reg haltreq_q, resumereq_q; always (posedge clk or negedge rst_n) begin if (!rst_n) begin dm_state DM_IDLE; haltreq_q 1b0; resumereq_q 1b0; end else begin case (dm_state) DM_IDLE: begin if (dmctrl_haltreq) begin dm_state DM_HALT_REQ; haltreq_q 1b1; end else if (dmctrl_resumereq) begin dm_state DM_RESUME_REQ; resumereq_q 1b1; end end DM_HALT_REQ: begin dm_state DM_WAIT_HALT; end DM_WAIT_HALT: begin if (hart_halted) begin haltreq_q 1b0; dm_state DM_HALTED; end end DM_HALTED: begin // 在这里处理寄存器读写、程序缓冲执行等命令 if (dmctrl_resumereq) begin dm_state DM_RESUME_REQ; resumereq_q 1b1; end end DM_RESUME_REQ: begin dm_state DM_WAIT_RUN; end DM_WAIT_RUN: begin if (hart_running) begin resumereq_q 1b0; dm_state DM_IDLE; end end default: dm_state DM_IDLE; endcase end end这个状态机看起来简单但它在实际工程里会变得很复杂。原因在于halt 的请求是异步的。JTAG 时钟域可能只有 10MHz而 CPU 跑在 100MHz 甚至更高两个时钟域的握手必须经过同步器处理。haltreq 信号要先同步到系统时钟域hart 返回的 halted 信号要再同步回 JTAG 时钟域这一来一回状态机的等待时间就变得不确定而你又不能设一个太短的超时否则慢的 hart 会被误判为不存在。5. 从零搭一个最小可用的调试系统工程实践5.1 模块划分把电路切到能单独验证为止做 Verilog 实现千万不要在一个顶层文件里把 TAP、DMI、DM 全写完那样调试起来你会疯掉。我比较推荐的模块划分是这样的tap_top.svTAP 状态机、IR、DR 选择逻辑dmi_if.svDMI 寄存器、dmi 状态机、busy/error 处理dm_top.svDM 寄存器堆、hart 控制状态机、抽象命令控制器hart_if.sv与 CPU 核的调试接口包括 halt/resume 握手各模块之间尽量用简单的 valid/ready 或者 request/response 接口对接方便在 testbench 里单独激励。一个容易忽略的问题是 reset 域的划分。JTAG TAP 通常使用独立的异步复位而 DM 部分因为要跟 CPU 交互一般挂在系统复位域下。两个复位域之间不止时序上需要同步连上电顺序都有讲究。理想情况下调试模块应该能够在 CPU 还没启动时就被 JTAG 激活这样才能实现上电暂停这类调试功能。5.2 接口设计一个可行的信号清单如果你要给 CPU 核提供调试接口信号大概是这样方向信号名说明DM - Hartdebug_req请求进入调试模式暂停DM - Hartdebug_haltedHart 已暂停DM - Hartdebug_resume请求恢复运行DM - Hartdebug_runningHart 正在运行DM - Hartdebug_cmd_valid抽象命令有效DM - Hartdebug_cmd_readyHart 接受命令DM - Hartdebug_gpr_raddr / gpr_rdata读寄存器文件这套机制其实和 ARM 的 DBGEN 有些相似但 RISC-V 更强调调试器与核的交互是异步且可轮询的。也就是说Hart 可以不马上响应 debug_req而是先完成当前指令再进入调试模式。这也是为什么 DM 必须有等待状态的原因。5.3 仿真验证从 testbench 到波形检查代码写完仿真阶段有几个重点。首先要构造一个最小的 CPU 核模型或者直接接一个现成的 RISC-V core比如 Ibex、VexRiscv 之类并让它跑一段简单的循环程序。然后用 Verilog testbench 模拟 JTAG 主机的行为发 IDCODE 指令读 DMI写 dmcontrol发 halt 请求。我在仿真中最常用的一种激励写法是先定义几个任务task封装好 JTAG 的扫描操作再用这些任务组合出 DMI 读写。比如定义一个dmi_write(addr, data)的任务内部自动完成 IR 选择 DMI、DR 移入 42 位、触发 Update、再额外做一次空访问以完成流水线读取。这样 testbench 可读性会好很多。时序上要特别关注的点是DMI 写操作完成之后DM 内部的寄存器值是否真的更新了。常见的问题是因为忘记考虑 DMI 的流水线延迟testbench 在发出写请求后立刻就发读请求结果读回来的是旧值。这不是调掉 bug而是协议本来的行为必须通过插入空闲周期或额外访问来规避。6. 排查实录连不上、读不到、停不下来怎么办6.1 问题速查表做调试子系统的过程中接触最多的问题集中在这几类。我整理了一个速查表基本覆盖了从原型验证到系统联调会遇到的高频故障。现象可能原因排查方法JTAG 读不到 IDCODETAP 状态机复位异常检查 TMS 上电时序确认前 5 个 TCK 周期 TMS 为高IDCODE 能读DMI 访问无响应DMI 状态机没从 IDLE 走出来仿真里看 dmi_state 是否卡住检查 op 字段解析DMI 访问一直返回 busyDM 的时钟没起或复位未释放确认 dmactive 是否置位DM 时钟域是否被独立复位按住haltreq 置位后 allhalted 一直为 0hart 没收到 debug_req检查跨时钟域同步链确认 debug_req 被正确同步到系统时钟域resume 后程序跑飞程序缓冲或抽象命令破坏上下文检查是否误改了 GPR 或 CSR建议先用程序缓冲执行一条无害指令验证多核芯片只能控制一个核hartsel 设置不正确或 hasel 配置错误逐个核写 hartsel 后重新发 haltreq不要在选核前就发请求这里特别提醒一下JTAG 连接不上不一定是代码问题。示波器或逻辑分析仪看一下 TCK 频率是不是太高TMS/TDI 的上拉是否正常都是很有效的排查手段。有时候就是杜邦线太长、接触不良并不涉及协议本身。6.2 经验笔记先走通 JTAG再谈其他我做第一版调试系统的时候犯过一个特别低级的错误把 IR 宽度设成了 5 位但 IDCODE 指令编码用了 8 位结果移入的指令根本不是预期值TAP 始终选不对 DMI。从那以后我养成了一个习惯就是先写一个极简的 testbench只测 IDCODE 能不能读回来读不到就把时序图放大逐拍核对。另外如果你打算在 FPGA 上做原型验证我会建议把 TCK 频率先降到 1MHz 左右跑通全流程。这个频率下时序约束很容易满足所有问题锅都在逻辑本身。等到功能全部正确再逐步提高 TCK 频率逼着自己去处理 JTAG 时序余量和跨时钟域延迟。调试系统这个东西越往底层做越考验耐心。每次觉得怎么这么麻烦的时候想想你手上这个协议栈帮你在芯片出厂后省了多少改版成本心里就平衡了。如果让我给刚入门的同学一个建议先把 JTAG 这一关走通把 TAP 状态机的流转背下来后面 DMI、DM 都是在这个地基上盖楼地基稳了楼就不会塌。