1 |
60 |
zero_gravi |
<<<
|
2 |
|
|
:sectnums:
|
3 |
|
|
== On-Chip Debugger (OCD)
|
4 |
|
|
|
5 |
|
|
The NEORV32 Processor features an _on-chip debugger_ (OCD) implementing **execution-based debugging** that is compatible
|
6 |
72 |
zero_gravi |
to the **Minimal RISC-V Debug Specification Version 0.13.2**. Please refer to this spec for in-deep information.
|
7 |
60 |
zero_gravi |
A copy of the specification is available in `docs/references/riscv-debug-release.pdf`.
|
8 |
72 |
zero_gravi |
|
9 |
60 |
zero_gravi |
The NEORV32 OCD provides the following key features:
|
10 |
|
|
|
11 |
72 |
zero_gravi |
* JTAG access port
|
12 |
60 |
zero_gravi |
* run-control of the CPU: halting, single-stepping and resuming
|
13 |
|
|
* executing arbitrary programs during debugging
|
14 |
72 |
zero_gravi |
* accessing core registers
|
15 |
|
|
* indirect access to the whole processor address space (via program buffer)
|
16 |
|
|
* trigger module for hardware breakpoints
|
17 |
|
|
* compatible with upstream OpenOCD
|
18 |
60 |
zero_gravi |
|
19 |
61 |
zero_gravi |
.OCD Security Note
|
20 |
72 |
zero_gravi |
[NOTE]
|
21 |
61 |
zero_gravi |
Access via the OCD is _always authenticated_ (`dmstatus.authenticated` == `1`). Hence, the
|
22 |
65 |
zero_gravi |
_whole system_ can always be accessed via the on-chip debugger. Currently, there is no option
|
23 |
|
|
to disable the OCD via software. The OCD can only be disabled by disabling implementation
|
24 |
|
|
(setting _ON_CHIP_DEBUGGER_EN_ generic to _false_).
|
25 |
61 |
zero_gravi |
|
26 |
72 |
zero_gravi |
.Hands-On Tutorial
|
27 |
60 |
zero_gravi |
[TIP]
|
28 |
72 |
zero_gravi |
A simple example on how to use NEORV32 on-chip debugger in combination with OpenOCD and the GNU debugger
|
29 |
62 |
zero_gravi |
is shown in section https://stnolting.github.io/neorv32/ug/#_debugging_using_the_on_chip_debugger[Debugging using the On-Chip Debugger]
|
30 |
|
|
of the User Guide.
|
31 |
60 |
zero_gravi |
|
32 |
72 |
zero_gravi |
The NEORV32 on-chip debugger complex is based on four hardware modules:
|
33 |
60 |
zero_gravi |
|
34 |
|
|
.NEORV32 on-chip debugger complex
|
35 |
|
|
image::neorv32_ocd_complex.png[align=center]
|
36 |
|
|
|
37 |
|
|
[start=1]
|
38 |
|
|
. <<_debug_transport_module_dtm>> (`rtl/core/neorv32_debug_dtm.vhd`): External JTAG access tap to allow an external
|
39 |
|
|
adapter to interface with the _debug module(DM)_ using the _debug module interface (dmi)_.
|
40 |
|
|
. <<_debug_module_dm>> (`rtl/core/neorv32_debug_tm.vhd`): Debugger control unit that is configured by the DTM via the
|
41 |
|
|
the _dmi_. Form the CPU's "point of view" this module behaves as a memory-mapped "peripheral" that can be accessed
|
42 |
|
|
via the processor-internal bus. The memory-mapped registers provide an internal _data buffer_ for data transfer
|
43 |
|
|
from/to the DM, a _code ROM_ containing the "park loop" code, a _program buffer_ to allow the debugger to
|
44 |
|
|
execute small programs defined by the DM and a _status register_ that is used to communicate
|
45 |
|
|
_halt_, _resume_ and _execute_ requests/acknowledges from/to the DM.
|
46 |
|
|
. CPU <<_cpu_debug_mode>> extension (part of`rtl/core/neorv32_cpu_control.vhd`):
|
47 |
|
|
This extension provides the "debug execution mode" which executes the "park loop" code from the DM.
|
48 |
|
|
The mode also provides additional CSRs.
|
49 |
72 |
zero_gravi |
. (CPU <<_trigger_module>> (also part of`rtl/core/neorv32_cpu_control.vhd`):
|
50 |
|
|
This module provides a single _hardware_ breakpoint, which allows to debug code executed from ROM.)
|
51 |
60 |
zero_gravi |
|
52 |
|
|
**Theory of Operation**
|
53 |
|
|
|
54 |
|
|
When debugging the system using the OCD, the debugger issues a halt request to the CPU (via the CPU's
|
55 |
|
|
`db_halt_req_i` signal) to make the CPU enter _debug mode_. In this state, the application-defined architectural
|
56 |
|
|
state of the system/CPU is "frozen" so the debugger can monitor and even modify it.
|
57 |
|
|
While in debug mode, the CPU executes the "park loop" code from the _code ROM_ of the DM.
|
58 |
|
|
This park loop implements an endless loop, in which the CPU polls the memory-mapped _status register_ that is
|
59 |
|
|
controlled by the _debug module (DM)_. The flags of these register are used to communicate _requests_ from
|
60 |
|
|
the DM and to _acknowledge_ them by the CPU: trigger execution of the program buffer or resume the halted
|
61 |
|
|
application.
|
62 |
|
|
|
63 |
|
|
|
64 |
|
|
|
65 |
|
|
<<<
|
66 |
|
|
// ####################################################################################################################
|
67 |
|
|
:sectnums:
|
68 |
|
|
=== Debug Transport Module (DTM)
|
69 |
|
|
|
70 |
|
|
The debug transport module (VHDL module: `rtl/core/neorv32_debug_dtm.vhd`) provides a JTAG test access port (TAP).
|
71 |
|
|
The DTM is the first entity in the debug system, which connects and external debugger via JTAG to the next debugging
|
72 |
|
|
entity: the debug module (DM).
|
73 |
61 |
zero_gravi |
External JTAG access is provided by the following top-level ports.
|
74 |
60 |
zero_gravi |
|
75 |
|
|
.JTAG top level signals
|
76 |
|
|
[cols="^2,^2,^2,<8"]
|
77 |
|
|
[options="header",grid="rows"]
|
78 |
|
|
|=======================
|
79 |
|
|
| Name | Width | Direction | Description
|
80 |
|
|
| `jtag_trst_i` | 1 | in | TAP reset (low-active); this signal is optional, make sure to pull it _high_ if it is not used
|
81 |
|
|
| `jtag_tck_i` | 1 | in | serial clock
|
82 |
|
|
| `jtag_tdi_i` | 1 | in | serial data input
|
83 |
|
|
| `jtag_tdo_o` | 1 | out | serial data output
|
84 |
|
|
| `jtag_tms_i` | 1 | in | mode select
|
85 |
|
|
|=======================
|
86 |
|
|
|
87 |
68 |
zero_gravi |
.Maximum JTAG Clock
|
88 |
60 |
zero_gravi |
[IMPORTANT]
|
89 |
68 |
zero_gravi |
All JTAG signals are synchronized to the processor clock domain by oversampling them in DTM. Hence, no additional
|
90 |
|
|
clock domain is required for the DTM. However, this constraints the maximal JTAG clock frequency (`jtag_tck_i`) to be less
|
91 |
|
|
than or equal to **1/5** of the processor clock frequency (`clk_i`).
|
92 |
60 |
zero_gravi |
|
93 |
|
|
[NOTE]
|
94 |
|
|
If the on-chip debugger is disabled (_ON_CHIP_DEBUGGER_EN_ = false) the JTAG serial input `jtag_tdi_i` is directly
|
95 |
|
|
connected to the JTAG serial output `jtag_tdo_o` to maintain the JTAG chain.
|
96 |
|
|
|
97 |
|
|
[WARNING]
|
98 |
|
|
The NEORV32 JTAG TAP does not provide a _boundary check_ function (yet?). Hence, physical device pins cannot be accessed.
|
99 |
|
|
|
100 |
|
|
The DTM uses the "debug module interface (dmi)" to access the actual debug module (DM).
|
101 |
|
|
These accesses are controlled by TAP-internal registers.
|
102 |
|
|
Each registers is selected by the JTAG instruction register (`IR`) and accessed through the JTAG data register (`DR`).
|
103 |
|
|
|
104 |
|
|
[NOTE]
|
105 |
|
|
The DTM's instruction and data registers can be accessed using OpenOCDs `irscan` and `drscan` commands.
|
106 |
|
|
The RISC-V port of OpenOCD also provides low-level command (`riscv dmi_read` & `riscv dmi_write`) to access the _dmi_
|
107 |
|
|
debug module interface.
|
108 |
|
|
|
109 |
|
|
JTAG access is conducted via the *instruction register* `IR`, which is 5 bit wide, and several *data registers* `DR`
|
110 |
|
|
with different sizes.
|
111 |
|
|
The data registers are accessed by writing the according address to the instruction register.
|
112 |
|
|
The following table shows the available data registers:
|
113 |
|
|
|
114 |
|
|
.JTAG TAP registers
|
115 |
|
|
[cols="^2,^2,^2,<8"]
|
116 |
|
|
[options="header",grid="rows"]
|
117 |
|
|
|=======================
|
118 |
|
|
| Address (via `IR`) | Name | Size [bits] | Description
|
119 |
|
|
| `00001` | `IDCODE` | 32 | identifier, default: `0x0CAFE001` (configurable via package's `jtag_tap_idcode_*` constants)
|
120 |
|
|
| `10000` | `DTMCS` | 32 | debug transport module control and status register
|
121 |
|
|
| `10001` | `DMI` | 41 | debug module interface (_dmi_); 7-bit address, 32-bit read/write data, 2-bit operation (`00` = NOP; `10` = write; `01` = read)
|
122 |
|
|
| others | `BYPASS` | 1 | default JTAG bypass register
|
123 |
|
|
|=======================
|
124 |
|
|
|
125 |
68 |
zero_gravi |
.`DTMCS` - DTM Control and Status Register
|
126 |
|
|
[cols="^2,^3,^1,<8"]
|
127 |
|
|
[options="header",grid="rows"]
|
128 |
|
|
|=======================
|
129 |
|
|
| Bit(s) | Name | r/w | Description
|
130 |
|
|
| 31:18 | - | r/- | _reserved_, hardwired to zero
|
131 |
|
|
| 17 | `dmihardreset` | r/w | setting this bit will reset the DM interface; this bit auto-clears
|
132 |
|
|
| 16 | `dmireset` | r/w | setting this bit will clear ste sticky error state; this bit auto-clears
|
133 |
|
|
| 15 | - | r/- | _reserved_, hardwired to zero
|
134 |
|
|
| 14:12 | `idle` | r/- | recommended idle states (= 0, no idle states required)
|
135 |
|
|
| 11:10 | `dmistat` | r/- | DMI statu: `00` = no error, `01` = reserved, `10` = operation failed, `11` = failed operation during pending DMI operation
|
136 |
|
|
| 9:4 | `abits` | r/- | number of DMI address bits (= 7)
|
137 |
|
|
| 3:0 | `version` | r/- | `0001` = spec version 0.13
|
138 |
|
|
|=======================
|
139 |
|
|
|
140 |
60 |
zero_gravi |
[INFO]
|
141 |
|
|
See the https://github.com/riscv/riscv-debug-spec[RISC-V debug specification] for more information regarding the data
|
142 |
68 |
zero_gravi |
registers and operations. A local copy can be found in `docs/references`.
|
143 |
60 |
zero_gravi |
|
144 |
|
|
|
145 |
|
|
|
146 |
|
|
<<<
|
147 |
|
|
// ####################################################################################################################
|
148 |
|
|
:sectnums:
|
149 |
|
|
=== Debug Module (DM)
|
150 |
|
|
|
151 |
|
|
According to the RISC-V debug specification, the DM (VHDL module: `rtl/core/neorv32_debug_dm.vhd`)
|
152 |
|
|
acts as a translation interface between abstract operations issued by the debugger and the platform-specific
|
153 |
|
|
debugger implementation. It supports the following features (excerpt from the debug spec):
|
154 |
|
|
|
155 |
|
|
* Gives the debugger necessary information about the implementation.
|
156 |
|
|
* Allows the hart to be halted and resumed and provides status of the current state.
|
157 |
|
|
* Provides abstract read and write access to the halted hart's GPRs.
|
158 |
|
|
* Provides access to a reset signal that allows debugging from the very first instruction after reset.
|
159 |
|
|
* Provides a mechanism to allow debugging the hart immediately out of reset. (_still experimental_)
|
160 |
|
|
* Provides a Program Buffer to force the hart to execute arbitrary instructions.
|
161 |
|
|
* Allows memory access from a hart's point of view.
|
162 |
|
|
|
163 |
|
|
The NEORV32 DM follows the "Minimal RISC-V External Debug Specification" to provide full debugging
|
164 |
|
|
capabilities while keeping resource (area) requirements at a minimum level.
|
165 |
|
|
It implements the **execution based debugging scheme** for a single hart and provides the following
|
166 |
|
|
hardware features:
|
167 |
|
|
|
168 |
|
|
* program buffer with 2 entries and implicit `ebreak` instruction afterwards
|
169 |
|
|
* no _direct_ bus access (indirect bus access via the CPU)
|
170 |
|
|
* abstract commands: "access register" plus auto-execution
|
171 |
|
|
* no _dedicated_ halt-on-reset capabilities yet (but can be emulated)
|
172 |
|
|
|
173 |
|
|
The DM provides two "sides of access": access from the DTM via the _debug module interface (dmi)_ and access from the
|
174 |
|
|
CPU via the processor-internal bus. From the DTM's point of view, the DM implements a set of <<_dm_registers>> that
|
175 |
|
|
are used to control and monitor the actual debugging. From the CPU's point of view, the DM implements several
|
176 |
|
|
memory-mapped registers (within the _normal_ address space) that are used for communicating debugging control
|
177 |
|
|
and status (<<_dm_cpu_access>>).
|
178 |
|
|
|
179 |
|
|
|
180 |
|
|
:sectnums:
|
181 |
|
|
==== DM Registers
|
182 |
|
|
|
183 |
|
|
The DM is controlled via a set of registers that are accessed via the DTM's _dmi_.
|
184 |
|
|
The "Minimal RISC-V Debug Specification" requires only a subset of the registers specified in the spec.
|
185 |
|
|
The following registers are implemented.
|
186 |
|
|
Write accesses to any other registers are ignored and read accesses will always return zero.
|
187 |
|
|
Register names that are encapsulated in "( )" are not actually implemented; however, they are listed to explicitly show
|
188 |
|
|
their functionality.
|
189 |
|
|
|
190 |
|
|
.Available DM registers
|
191 |
|
|
[cols="^2,^3,<7"]
|
192 |
|
|
[options="header",grid="rows"]
|
193 |
|
|
|=======================
|
194 |
|
|
| Address | Name | Description
|
195 |
|
|
| `0x04` | `data0` | Abstract data 0, used for data transfer between debugger and processor
|
196 |
|
|
| `0x10` | `dmcontrol` | Debug module control
|
197 |
|
|
| `0x11` | `dmstatus` | Debug module status
|
198 |
|
|
| `0x12` | `hartinfo` | Hart information
|
199 |
|
|
| `0x16` | `abstracts` | Abstract control and status
|
200 |
|
|
| `0x17` | `command` | Abstract command
|
201 |
|
|
| `0x18` | `abstractauto` | Abstract command auto-execution
|
202 |
|
|
| `0x1d` | (`nextdm`) | Base address of _next_ DM; read as zero to indicate there is only _one_ DM
|
203 |
|
|
| `0x20` | `progbuf0` | Program buffer 0
|
204 |
|
|
| `0x21` | `progbuf1` | Program buffer 1
|
205 |
|
|
| `0x38` | (`sbcs`) | System bus access control and status; read as zero to indicate there is no _direct_ system bus access
|
206 |
|
|
| `0x40` | `haltsum0` | Halt summary 0
|
207 |
|
|
|=======================
|
208 |
|
|
|
209 |
|
|
|
210 |
|
|
:sectnums!:
|
211 |
|
|
===== **`data`**
|
212 |
|
|
|
213 |
|
|
[cols="4,27,>7"]
|
214 |
|
|
[frame="topbot",grid="none"]
|
215 |
|
|
|======
|
216 |
|
|
| 0x04 | **Abstract data 0** | `data0`
|
217 |
|
|
3+| Reset value: _UNDEFINED_
|
218 |
|
|
3+| Basic read/write registers to be used with abstract command (for example to read/write data from/to CPU GPRs).
|
219 |
|
|
|======
|
220 |
|
|
|
221 |
|
|
|
222 |
|
|
:sectnums!:
|
223 |
|
|
===== **`dmcontrol`**
|
224 |
|
|
|
225 |
|
|
[cols="4,27,>7"]
|
226 |
|
|
[frame="topbot",grid="none"]
|
227 |
|
|
|======
|
228 |
|
|
| 0x10 | **Debug module control register** | `dmcontrol`
|
229 |
|
|
3+| Reset value: 0x00000000
|
230 |
|
|
3+| Control of the overall debug module and the hart. The following table shows all implemented bits. All remaining bits/bit-fields are configures as "zero" and are
|
231 |
|
|
read-only. Writing '1' to these bits/fields will be ignored.
|
232 |
|
|
|======
|
233 |
|
|
|
234 |
|
|
.`dmcontrol` - debug module control register bits
|
235 |
|
|
[cols="^1,^2,^1,<8"]
|
236 |
|
|
[options="header",grid="rows"]
|
237 |
|
|
|=======================
|
238 |
|
|
| Bit | Name [RISC-V] | R/W | Description
|
239 |
|
|
| 31 | `haltreq` | -/w | set/clear hart halt request
|
240 |
|
|
| 30 | `resumereq` | -/w | request hart to resume
|
241 |
|
|
| 28 | `ackhavereset` | -/w | write `1` to clear `*havereset` flags
|
242 |
|
|
| 1 | `ndmreset` | r/w | put whole processor into reset when `1`
|
243 |
|
|
| 0 | `dmactive` | r/w | DM enable; writing `0`-`1` will reset the DM
|
244 |
|
|
|=======================
|
245 |
|
|
|
246 |
|
|
|
247 |
|
|
:sectnums!:
|
248 |
|
|
===== **`dmstatus`**
|
249 |
|
|
|
250 |
|
|
[cols="4,27,>7"]
|
251 |
|
|
[frame="topbot",grid="none"]
|
252 |
|
|
|======
|
253 |
|
|
| 0x11 | **Debug module status register** | `dmstatus`
|
254 |
|
|
3+| Reset value: 0x00000000
|
255 |
|
|
3+| Current status of the overall debug module and the hart. The entire register is read-only.
|
256 |
|
|
|======
|
257 |
|
|
|
258 |
|
|
.`dmstatus` - debug module status register bits
|
259 |
|
|
[cols="^1,^2,<10"]
|
260 |
|
|
[options="header",grid="rows"]
|
261 |
|
|
|=======================
|
262 |
|
|
| Bit | Name [RISC-V] | Description
|
263 |
|
|
| 31:23 | _reserved_ | reserved; always zero
|
264 |
|
|
| 22 | `impebreak` | always `1`; indicates an implicit `ebreak` instruction after the last program buffer entry
|
265 |
|
|
| 21:20 | _reserved_ | reserved; always zero
|
266 |
|
|
| 19 | `allhavereset` .2+| `1` when the hart is in reset
|
267 |
|
|
| 18 | `anyhavereset`
|
268 |
|
|
| 17 | `allresumeack` .2+| `1` when the hart has acknowledged a resume request
|
269 |
|
|
| 16 | `anyresumeack`
|
270 |
|
|
| 15 | `allnonexistent` .2+| always zero to indicate the hart is always existent
|
271 |
|
|
| 14 | `anynonexistent`
|
272 |
|
|
| 13 | `allunavail` .2+| `1` when the DM is disabled to indicate the hart is unavailable
|
273 |
|
|
| 12 | `anyunavail`
|
274 |
|
|
| 11 | `allrunning` .2+| `1` when the hart is running
|
275 |
|
|
| 10 | `anyrunning`
|
276 |
|
|
| 9 | `allhalted` .2+| `1` when the hart is halted
|
277 |
|
|
| 8 | `anyhalted`
|
278 |
|
|
| 7 | `authenticated` | always `1`; there is no authentication
|
279 |
|
|
| 6 | `authbusy` | always `0`; there is no authentication
|
280 |
|
|
| 5 | `hasresethaltreq` | always `0`; halt-on-reset is not supported (directly)
|
281 |
|
|
| 4 | `confstrptrvalid` | always `0`; no configuration string available
|
282 |
|
|
| 3:0 | `version` | `0010` - DM is compatible to version 0.13
|
283 |
|
|
|=======================
|
284 |
|
|
|
285 |
|
|
|
286 |
|
|
:sectnums!:
|
287 |
|
|
===== **`hartinfo`**
|
288 |
|
|
|
289 |
|
|
[cols="4,27,>7"]
|
290 |
|
|
[frame="topbot",grid="none"]
|
291 |
|
|
|======
|
292 |
|
|
| 0x12 | **Hart information** | `hartinfo`
|
293 |
|
|
3+| Reset value: see below
|
294 |
|
|
3+| This register gives information about the hart. The entire register is read-only.
|
295 |
|
|
|======
|
296 |
|
|
|
297 |
|
|
.`hartinfo` - hart information register bits
|
298 |
|
|
[cols="^1,^2,<8"]
|
299 |
|
|
[options="header",grid="rows"]
|
300 |
|
|
|=======================
|
301 |
|
|
| Bit | Name [RISC-V] | Description
|
302 |
|
|
| 31:24 | _reserved_ | reserved; always zero
|
303 |
|
|
| 23:20 | `nscratch` | `0001`, number of `dscratch*` CPU registers = 1
|
304 |
|
|
| 19:17 | _reserved_ | reserved; always zero
|
305 |
|
|
| 16 | `dataccess` | `0`, the `data` registers are shadowed in the hart's address space
|
306 |
72 |
zero_gravi |
| 15:12 | `datasize` | `0001`, number of 32-bit words in the address space dedicated to shadowing the `data` registers (1 register)
|
307 |
60 |
zero_gravi |
| 11:0 | `dataaddr` | = `dm_data_base_c(11:0)`, signed base address of `data` words (see address map in <<_dm_cpu_access>>)
|
308 |
|
|
|=======================
|
309 |
|
|
|
310 |
|
|
|
311 |
|
|
:sectnums!:
|
312 |
|
|
===== **`abstracts`**
|
313 |
|
|
|
314 |
|
|
[cols="4,27,>7"]
|
315 |
|
|
[frame="topbot",grid="none"]
|
316 |
|
|
|======
|
317 |
|
|
| 0x16 | **Abstract control and status** | `abstracts`
|
318 |
|
|
3+| Reset value: see below
|
319 |
|
|
3+| Command execution info and status.
|
320 |
|
|
|======
|
321 |
|
|
|
322 |
|
|
.`abstracts` - abstract control and status register bits
|
323 |
|
|
[cols="^1,^2,^1,<8"]
|
324 |
|
|
[options="header",grid="rows"]
|
325 |
|
|
|=======================
|
326 |
|
|
| Bit | Name [RISC-V] | R/W | Description
|
327 |
|
|
| 31:29 | _reserved_ | r/- | reserved; always zero
|
328 |
|
|
| 28:24 | `progbufsize` | r/- | `0010`; size of the program buffer (`progbuf`) = 2 entries
|
329 |
|
|
| 23:11 | _reserved_ | r/- | reserved; always zero
|
330 |
|
|
| 12 | `busy` | r/- | `1` when a command is being executed
|
331 |
|
|
| 11 | _reserved_ | r/- | reserved; always zero
|
332 |
|
|
| 10:8 | `cmerr` | r/w | error during command execution (see below); has to be cleared by writing `111`
|
333 |
|
|
| 7:4 | _reserved_ | r/- | reserved; always zero
|
334 |
|
|
| 3:0 | `datacount` | r/- | `0001`; number of implemented `data` registers for abstract commands = 1
|
335 |
|
|
|=======================
|
336 |
|
|
|
337 |
|
|
Error codes in `cmderr` (highest priority first):
|
338 |
|
|
|
339 |
|
|
* `000` - no error
|
340 |
|
|
* `100` - command cannot be executed since hart is not in expected state
|
341 |
|
|
* `011` - exception during command execution
|
342 |
|
|
* `010` - unsupported command
|
343 |
|
|
* `001` - invalid DM register read/write while command is/was executing
|
344 |
|
|
|
345 |
|
|
|
346 |
|
|
:sectnums!:
|
347 |
|
|
===== **`command`**
|
348 |
|
|
|
349 |
|
|
[cols="4,27,>7"]
|
350 |
|
|
[frame="topbot",grid="none"]
|
351 |
|
|
|======
|
352 |
|
|
| 0x17 | **Abstract command** | `command`
|
353 |
|
|
3+| Reset value: 0x00000000
|
354 |
|
|
3+| Writing this register will trigger the execution of an abstract command. New command can only be executed if
|
355 |
|
|
`cmderr` is zero. The entire register in write-only (reads will return zero).
|
356 |
|
|
|======
|
357 |
|
|
|
358 |
|
|
[NOTE]
|
359 |
|
|
The NEORV32 DM only supports **Access Register** abstract commands. These commands can only access the
|
360 |
|
|
hart's GPRs (abstract command register index `0x1000` - `0x101f`).
|
361 |
|
|
|
362 |
|
|
.`command` - abstract command register - "access register" commands only
|
363 |
72 |
zero_gravi |
[cols="^1,^2,^1,<8"]
|
364 |
60 |
zero_gravi |
[options="header",grid="rows"]
|
365 |
|
|
|=======================
|
366 |
65 |
zero_gravi |
| Bit | Name [RISC-V] | R/W | Description / required value
|
367 |
|
|
| 31:24 | `cmdtype` | -/w | `00000000` to indicate "access register" command
|
368 |
|
|
| 23 | _reserved_ | -/w | reserved, has to be `0` when writing
|
369 |
|
|
| 22:20 | `aarsize` | -/w | `010` to indicate 32-bit accesses
|
370 |
66 |
zero_gravi |
| 21 | `aarpostincrement` | -/w | `0`, post-increment is not supported
|
371 |
65 |
zero_gravi |
| 18 | `postexec` | -/w | if set the program buffer is executed _after_ the command
|
372 |
|
|
| 17 | `transfer` | -/w | if set the operation in `write` is conducted
|
373 |
72 |
zero_gravi |
| 16 | `write` | -/w | `1`: copy `data0` to `[regno]`, `0`: copy `[regno]` to `data0`
|
374 |
65 |
zero_gravi |
| 15:0 | `regno` | -/w | GPR-access only; has to be `0x1000` - `0x101f`
|
375 |
60 |
zero_gravi |
|=======================
|
376 |
|
|
|
377 |
|
|
|
378 |
|
|
:sectnums!:
|
379 |
|
|
===== **`abstractauto`**
|
380 |
|
|
|
381 |
|
|
[cols="4,27,>7"]
|
382 |
|
|
[frame="topbot",grid="none"]
|
383 |
|
|
|======
|
384 |
|
|
| 0x18 | **Abstract command auto-execution** | `abstractauto`
|
385 |
|
|
3+| Reset value: 0x00000000s
|
386 |
|
|
3+| Register to configure when a read/write access to a DM repeats execution of the last abstract command.
|
387 |
|
|
|======
|
388 |
|
|
|
389 |
|
|
.`abstractauto` - Abstract command auto-execution register bits
|
390 |
|
|
[cols="^1,^2,^1,<8"]
|
391 |
|
|
[options="header",grid="rows"]
|
392 |
|
|
|=======================
|
393 |
|
|
| Bit | Name [RISC-V] | R/W | Description
|
394 |
|
|
| 17 | `autoexecprogbuf[1]` | r/w | when set reading/writing from/to `progbuf1` will execute `command again`
|
395 |
|
|
| 16 | `autoexecprogbuf[0]` | r/w | when set reading/writing from/to `progbuf0` will execute `command again`
|
396 |
|
|
| 0 | `autoexecdata[0]` | r/w | when set reading/writing from/to `data0` will execute `command again`
|
397 |
|
|
|=======================
|
398 |
|
|
|
399 |
|
|
|
400 |
|
|
:sectnums!:
|
401 |
|
|
===== **`progbuf`**
|
402 |
|
|
|
403 |
|
|
[cols="4,27,>7"]
|
404 |
|
|
[frame="topbot",grid="none"]
|
405 |
|
|
|======
|
406 |
|
|
| 0x20 | **Program buffer 0** | `progbuf0`
|
407 |
|
|
| 0x21 | **Program buffer 1** | `progbuf1`
|
408 |
|
|
3+| Reset value: `NOP`-instruction
|
409 |
72 |
zero_gravi |
3+| General purpose program buffer (two entries) for the DM.
|
410 |
60 |
zero_gravi |
|======
|
411 |
|
|
|
412 |
|
|
|
413 |
|
|
:sectnums!:
|
414 |
|
|
===== **`haltsum0`**
|
415 |
|
|
|
416 |
|
|
[cols="4,27,>7"]
|
417 |
|
|
[frame="topbot",grid="none"]
|
418 |
|
|
|======
|
419 |
|
|
| 0x40 | **Halt summary 0** | `haltsum0`
|
420 |
|
|
3+| Reset value: _UNDEFINED_
|
421 |
|
|
3+| Bit 0 of this register is set if the hart is halted (all remaining bits are always zero). The entire register is read-only.
|
422 |
|
|
|======
|
423 |
|
|
|
424 |
|
|
:sectnums:
|
425 |
|
|
==== DM CPU Access
|
426 |
|
|
|
427 |
|
|
From the CPU's point of view, the DM behaves as a memory-mapped peripheral that includes
|
428 |
|
|
|
429 |
|
|
* a small ROM that contains the code for the "park loop", which is executed when the CPU is _in_ debug mode.
|
430 |
|
|
* a program buffer populated by the debugger host to execute small programs
|
431 |
|
|
* a data buffer to transfer data between the processor and the debugger host
|
432 |
|
|
* a status register to communicate debugging requests
|
433 |
|
|
|
434 |
71 |
zero_gravi |
.DM Register Access
|
435 |
|
|
[IMPORTANT]
|
436 |
|
|
All memory-mapped registers of the DM can only be accessed by the CPU if it is actually _in_ debug mode.
|
437 |
|
|
Hence, the DM registers are not "visible" for normal CPU operations.
|
438 |
|
|
Any access outside of debug mode will raise a bus error exception.
|
439 |
|
|
|
440 |
60 |
zero_gravi |
.Park Loop Code Sources
|
441 |
|
|
[NOTE]
|
442 |
|
|
The assembly sources of the **park loop code** are available in `sw/ocd-firmware/park_loop.S`. Please note, that these
|
443 |
|
|
sources are not intended to be changed by the used. Hence, the makefile does not provide an automatic option
|
444 |
|
|
to compile and "install" the debugger ROM code into the HDL sources and require a manual copy
|
445 |
|
|
(see `sw/ocd-firmware/README.md`).
|
446 |
|
|
|
447 |
|
|
The DM uses a total address space of 128 words of the CPU's address space (= 512 bytes) divided into four sections
|
448 |
|
|
of 32 words (= 128 bytes) each.
|
449 |
|
|
Please note, that the program buffer, the data buffer and the status register only uses a few effective words in this
|
450 |
|
|
address space. However, these effective addresses are mirrored to fill up the whole 128 bytes of the section.
|
451 |
|
|
Hence, any CPU access within this address space will succeed.
|
452 |
|
|
|
453 |
|
|
.DM CPU access - address map (divided into four sections)
|
454 |
|
|
[cols="^2,^4,^2,<7"]
|
455 |
|
|
[options="header",grid="rows"]
|
456 |
|
|
|=======================
|
457 |
|
|
| Base address | Name [VHDL package] | Actual size | Description
|
458 |
|
|
| `0xfffff800` | `dm_code_base_c` (= `dm_base_c`) | 128 bytes | Code ROM for the "park loop" code
|
459 |
|
|
| `0xfffff880` | `dm_pbuf_base_c` | 16 bytes | Program buffer, provided by DM
|
460 |
|
|
| `0xfffff900` | `dm_data_base_c` | 4 bytes | Data buffer (`dm.data0`)
|
461 |
|
|
| `0xfffff980` | `dm_sreg_base_c` | 4 bytes | Control and status register
|
462 |
|
|
|=======================
|
463 |
|
|
|
464 |
|
|
[NOTE]
|
465 |
|
|
From the CPU's point of view, the DM is mapped to an _"unused"_ address range within the processor's
|
466 |
|
|
<<_address_space>> right between the bootloader ROM (BOOTROM) and the actual processor-internal IO
|
467 |
|
|
space at addresses `0xfffff800` - `0xfffff9ff`
|
468 |
|
|
|
469 |
|
|
When the CPU enters or re-enters (for example via `ebreak` in the DM's program buffer) debug mode, it jumps to
|
470 |
|
|
the beginning of the DM's "park loop" code ROM at `dm_code_base_c`. This is the _normal entry point_ for the
|
471 |
|
|
park loop code. If an exception is encountered during debug mode, the CPU jumps to `dm_code_base_c + 4`,
|
472 |
|
|
which is the _exception entry point_.
|
473 |
|
|
|
474 |
|
|
**Status Register**
|
475 |
|
|
|
476 |
|
|
The status register provides a direct communication channel between the CPU executing the park loop and the
|
477 |
|
|
host-controlled controller of the DM. Note that all bits that can be written by the CPU (acknowledge flags)
|
478 |
|
|
cause a single-shot (1-cycle) signal to the DM controller and auto-clear (always read as zero).
|
479 |
|
|
The bits that are driven by the DM controller and are read-only to the CPU and keep their state until the CPU
|
480 |
|
|
acknowledges the according request.
|
481 |
|
|
|
482 |
|
|
.DM CPU access - status register
|
483 |
|
|
[cols="^2,^2,^2,<8"]
|
484 |
|
|
[options="header",grid="rows"]
|
485 |
|
|
|=======================
|
486 |
|
|
| Bit | Name | CPU access | Description
|
487 |
|
|
| 0 | `halt_ack` | -/w | Set by the CPU to indicate that the CPU is halted and keeps iterating in the park loop
|
488 |
|
|
| 1 | `resume_req` | r/- | Set by the DM to tell the CPU to resume normal operation (leave parking loop and leave debug mode via `dret` instruction)
|
489 |
|
|
| 2 | `resume_ack` | -/w | Set by the CPU to acknowledge that the CPU is now going to leave parking loop & debug mode
|
490 |
|
|
| 3 | `execute_req` | r/- | Set by the DM to tell the CPU to leave debug mode and execute the instructions from the program buffer; CPU will re-enter parking loop afterwards
|
491 |
|
|
| 4 | `execute_ack` | -/w | Set by the CPU to acknowledge that the CPU is now going to execute the program buffer
|
492 |
|
|
| 5 | `exception_ack` | -/w | Set by the CPU to inform the DM that an exception occurred during execution of the park loop or during execution of the program buffer
|
493 |
|
|
|=======================
|
494 |
|
|
|
495 |
|
|
|
496 |
|
|
|
497 |
|
|
<<<
|
498 |
|
|
// ####################################################################################################################
|
499 |
|
|
:sectnums:
|
500 |
|
|
=== CPU Debug Mode
|
501 |
|
|
|
502 |
72 |
zero_gravi |
The NEORV32 CPU Debug Mode `DB` or `DEBUG` (part of `rtl/core/neorv32_cpu_control.vhd`) is compatible to the
|
503 |
|
|
"Minimal RISC-V Debug Specification 0.13.2".
|
504 |
60 |
zero_gravi |
It is enabled/implemented by setting the CPU generic _CPU_EXTENSION_RISCV_DEBUG_ to "true" (done by setting processor
|
505 |
|
|
generic _ON_CHIP_DEBUGGER_EN_).
|
506 |
72 |
zero_gravi |
It provides a new operation mode called "debug mode". When enabled, three additional CSRs are available
|
507 |
|
|
(section <<_cpu_debug_mode_csrs>>) and the "return from debug mode" instruction `dret` are available.
|
508 |
60 |
zero_gravi |
|
509 |
|
|
[IMPORTANT]
|
510 |
64 |
zero_gravi |
The CPU _debug mode_ requires the `Zicsr` and `Zifencei` CPU extension to be implemented (top generics _CPU_EXTENSION_RISCV_Zicsr_
|
511 |
|
|
and _CPU_EXTENSION_RISCV_Zifencei_ = true).
|
512 |
60 |
zero_gravi |
|
513 |
65 |
zero_gravi |
The CPU debug-mode is entered when one of the following events appear:
|
514 |
|
|
|
515 |
60 |
zero_gravi |
[start=1]
|
516 |
72 |
zero_gravi |
. executing the `ebreak` instruction (when in machine-mode and `dcsr.ebreakm` is set OR when in user-mode and `dcsr.ebreaku` is set)
|
517 |
60 |
zero_gravi |
. debug halt request from external DM (via CPU signal `db_halt_req_i`, high-active, triggering on rising-edge)
|
518 |
|
|
. finished executing of a single instruction while in single-step debugging mode (enabled via `dcsr.step`)
|
519 |
72 |
zero_gravi |
. hardware trigger by the <<_trigger_module>>
|
520 |
60 |
zero_gravi |
|
521 |
72 |
zero_gravi |
From a hardware point of view, these "entry conditions" are special synchronous (e.g. `ebreak` instruction) and asynchronous
|
522 |
|
|
(e.g. halt request "interrupt") traps, that are handled invisibly by the control logic.
|
523 |
60 |
zero_gravi |
|
524 |
72 |
zero_gravi |
**Whenever the CPU enters debug-mode it performs the following operations:**
|
525 |
60 |
zero_gravi |
|
526 |
72 |
zero_gravi |
* wake-up CPU if it was send to sleep mode by the `wfi` instruction
|
527 |
|
|
* move `pc` to `dpc`
|
528 |
60 |
zero_gravi |
* copy the hart's current privilege level to `dcsr.prv`
|
529 |
|
|
* set `dcrs.cause` according to the cause why debug mode is entered
|
530 |
|
|
* **no update** of `mtval`, `mcause`, `mtval` and `mstatus` CSRs
|
531 |
72 |
zero_gravi |
* load the address configured via the CPU's _CPU_DEBUG_ADDR_ generic to the `pc` to jump to the "debugger park loop" code stored in the debug module (DM)
|
532 |
60 |
zero_gravi |
|
533 |
72 |
zero_gravi |
**When the CPU is in debug-mode the following things are important:**
|
534 |
60 |
zero_gravi |
|
535 |
|
|
* while in debug mode, the CPU executes the parking loop and the program buffer provided by the DM if requested
|
536 |
72 |
zero_gravi |
* effective CPU privilege level is `machine` mode, any active physical memory protection (PMP) configuration is bypassed
|
537 |
65 |
zero_gravi |
* the `wfi` instruction acts as a `nop` (also during single-stepping)
|
538 |
|
|
* if an exception occurs:
|
539 |
|
|
** if the exception was caused by any debug-mode entry action the CPU jumps to the _normal entry point_
|
540 |
|
|
(= _CPU_DEBUG_ADDR_) of the park loop again (for example when executing `ebreak` _in_ debug-mode)
|
541 |
|
|
** for all other exception sources the CPU jumps to the _exception entry point_ ( = _CPU_DEBUG_ADDR_ + 4)
|
542 |
72 |
zero_gravi |
to signal an exception to the DM; the CPU restarts the park loop again afterwards
|
543 |
65 |
zero_gravi |
* interrupts are disabled; however, they will remain pending and will get executed after the CPU has left debug mode
|
544 |
60 |
zero_gravi |
* if the DM makes a resume request, the park loop exits and the CPU leaves debug mode (executing `dret`)
|
545 |
72 |
zero_gravi |
* the standard counters <<_machine_counter_and_timer_csrs>> `[m]cycle[h]` and `[m]instret[h]` are stopped; note that the
|
546 |
|
|
<<_machine_system_timer_mtime>> keep running as well as it's shadowed copies in the `[m]time[h]` CSRs
|
547 |
|
|
* all <<_hardware_performance_monitors_hpm_csrs>> are stopped
|
548 |
60 |
zero_gravi |
|
549 |
|
|
Debug mode is left either by executing the `dret` instruction footnote:[`dret` should only be executed _inside_ the debugger
|
550 |
|
|
"park loop" code (-> code ROM in the debug module (DM).)] (_in_ debug mode) or by performing
|
551 |
|
|
a hardware reset of the CPU. Executing `dret` outside of debug mode will raise an illegal instruction exception.
|
552 |
|
|
|
553 |
72 |
zero_gravi |
**Whenever the CPU leaves debug mode it performs the following operations:**
|
554 |
|
|
|
555 |
60 |
zero_gravi |
* set the hart's current privilege level according to `dcsr.prv`
|
556 |
|
|
* restore `pc` from `dpcs`
|
557 |
|
|
* resume normal operation at `pc`
|
558 |
|
|
|
559 |
|
|
|
560 |
|
|
:sectnums:
|
561 |
|
|
==== CPU Debug Mode CSRs
|
562 |
|
|
|
563 |
|
|
Two additional CSRs are required by the _Minimal RISC-V Debug Specification_: The debug mode control and status register
|
564 |
|
|
`dcsr` and the program counter `dpc`. Providing a general purpose scratch register for debug mode (`dscratch0`) allows
|
565 |
|
|
faster execution of program provided by the debugger, since _one_ general purpose register can be backup-ed and
|
566 |
|
|
directly used.
|
567 |
|
|
|
568 |
|
|
[NOTE]
|
569 |
|
|
The debug-mode control and status registers (CSRs) are only accessible when the CPU is _in_ debug mode.
|
570 |
|
|
If these CSRs are accessed outside of debug mode (for example when in `machine` mode) an illegal instruction exception
|
571 |
|
|
is raised.
|
572 |
|
|
|
573 |
|
|
|
574 |
|
|
:sectnums!:
|
575 |
|
|
===== **`dcsr`**
|
576 |
|
|
|
577 |
|
|
[cols="4,27,>7"]
|
578 |
|
|
[frame="topbot",grid="none"]
|
579 |
|
|
|======
|
580 |
|
|
| 0x7b0 | **Debug control and status register** | `dcsr`
|
581 |
72 |
zero_gravi |
3+| Reset value: 0x40000000
|
582 |
60 |
zero_gravi |
3+| The `dcsr` CSR is compatible to the RISC-V debug spec. It is used to configure debug mode and provides additional status information.
|
583 |
|
|
The following bits are implemented. The reaming bits are read-only and always read as zero.
|
584 |
|
|
|======
|
585 |
|
|
|
586 |
72 |
zero_gravi |
.Debug control and status register `dcsr` bits
|
587 |
60 |
zero_gravi |
[cols="^1,^2,^1,<8"]
|
588 |
|
|
[options="header",grid="rows"]
|
589 |
|
|
|=======================
|
590 |
72 |
zero_gravi |
| Bit | Name [RISC-V] | R/W | Description
|
591 |
|
|
| 31:28 | `xdebugver` | r/- | `0100` - indicates external debug support exists
|
592 |
|
|
| 27:16 | - | r/- | `000000000000` - _reserved_
|
593 |
|
|
| 15 | `ebereakm` | r/w | `ebreak` instructions in `machine` mode will _enter_ debug mode when set
|
594 |
|
|
| 14 | `ebereakh` | r/- | `0` - hypervisor mode not supported
|
595 |
|
|
| 13 | `ebereaks` | r/- | `0` - supervisor mode not supported
|
596 |
|
|
| 12 | `ebereaku` | r/w | `ebreak` instructions in `user` mode will _enter_ debug mode when set
|
597 |
|
|
| 11 | `stepie` | r/- | `0` - IRQs are disabled during single-stepping
|
598 |
|
|
| 10 | `stopcount` | r/- | `1` - standard counters and HPMs are stopped when in debug mode
|
599 |
|
|
| 9 | `stoptime` | r/- | `0` - timers increment as usual
|
600 |
|
|
| 8:6 | `cause` | r/- | cause identifier - why debug mode was entered (see below)
|
601 |
|
|
| 5 | - | r/- | `0` - _reserved_
|
602 |
|
|
| 4 | `mprven` | r/- | `0` - `mstatus.mprv` is ignored when in debug mode
|
603 |
|
|
| 3 | `nmip` | r/- | `0` - non-maskable interrupt is pending
|
604 |
|
|
| 2 | `step` | r/w | enable single-stepping when set
|
605 |
|
|
| 1:0 | `prv` | r/w | CPU privilege level before/after debug mode
|
606 |
60 |
zero_gravi |
|=======================
|
607 |
|
|
|
608 |
72 |
zero_gravi |
Cause codes in `dcsr.cause` (highest priority first):
|
609 |
60 |
zero_gravi |
|
610 |
72 |
zero_gravi |
* `010` - trigger by hardware <<_trigger_module>>
|
611 |
|
|
* `001` - executed EBREAK instruction
|
612 |
|
|
* `011` - external halt request (from DM)
|
613 |
|
|
* `100` - return from single-stepping
|
614 |
|
|
|
615 |
|
|
|
616 |
60 |
zero_gravi |
:sectnums!:
|
617 |
|
|
===== **`dpc`**
|
618 |
|
|
|
619 |
|
|
[cols="4,27,>7"]
|
620 |
|
|
[frame="topbot",grid="none"]
|
621 |
|
|
|======
|
622 |
|
|
| 0x7b1 | **Debug program counter** | `dpc`
|
623 |
|
|
3+| Reset value: _UNDEFINED_
|
624 |
|
|
3+| The `dcsr` CSR is compatible to the RISC-V debug spec. It is used to store the current program counter when
|
625 |
|
|
debug mode is entered. The `dret` instruction will return to `dpc` by moving `dpc` to `pc`.
|
626 |
|
|
|======
|
627 |
|
|
|
628 |
|
|
|
629 |
|
|
:sectnums!:
|
630 |
|
|
===== **`dscratch0`**
|
631 |
|
|
|
632 |
|
|
[cols="4,27,>7"]
|
633 |
|
|
[frame="topbot",grid="none"]
|
634 |
|
|
|======
|
635 |
|
|
| 0x7b2 | **Debug scratch register 0** | `dscratch0`
|
636 |
|
|
3+| Reset value: _UNDEFINED_
|
637 |
|
|
3+| The `dscratch0` CSR is compatible to the RISC-V debug spec. It provides a general purpose debug mode-only scratch register.
|
638 |
|
|
|======
|
639 |
|
|
|
640 |
|
|
|
641 |
72 |
zero_gravi |
<<<
|
642 |
|
|
// ####################################################################################################################
|
643 |
|
|
:sectnums:
|
644 |
|
|
=== Trigger Module
|
645 |
|
|
|
646 |
|
|
The NEORV32 trigger module implements a subset of the features described in the "RISC-V Debug Specification / Trigger Module".
|
647 |
|
|
It is always implemented when the CPU debug mode / the on-chip debugger is implemented.
|
648 |
|
|
|
649 |
|
|
[IMPORTANT]
|
650 |
|
|
The trigger module only provides a single trigger of _instruction address match_ type. This trigger will fire
|
651 |
|
|
**after** the instruction at the specific address has been executed.
|
652 |
|
|
|
653 |
|
|
The trigger module only provides a single trigger supporting only the "instruction address match" type. This limitation
|
654 |
|
|
is granted by the RISC-V specs. and is sufficient to **debug code executed from read-only memory (ROM)**.
|
655 |
|
|
"Normal" _software_ breakpoints (using gdb's `b`/`break` command) are implemented by temporarily replacing the according
|
656 |
|
|
instruction word by a BREAK instruction. This is not possible when debugging code that is executed from read-only memory
|
657 |
|
|
(for example when debugging programs that are executed via the <<_execute_in_place_module_xip>>).
|
658 |
|
|
Therefore, the NEORV32 trigger module provides a single "instruction address match" trigger to enter debug mode when
|
659 |
|
|
executing the instruction at a specific address. These "hardware-assisted breakpoints" are used by gdb's `hb`/`hbreak` command.
|
660 |
|
|
|
661 |
|
|
|
662 |
|
|
:sectnums:
|
663 |
|
|
==== Trigger Module CSRs
|
664 |
|
|
|
665 |
|
|
The trigger module provides 8 additional CSRs, which accessible in debug mode and also in machine-mode. Since the
|
666 |
|
|
trigger module does not support _native mode_ writes from machine-mode software to those CSRs are ignored.
|
667 |
|
|
Hence, the CSRs of this module are only relevant for the debugger.
|
668 |
|
|
|
669 |
|
|
|
670 |
|
|
:sectnums!:
|
671 |
|
|
===== **`tselect`**
|
672 |
|
|
|
673 |
|
|
[cols="4,27,>7"]
|
674 |
|
|
[frame="topbot",grid="none"]
|
675 |
|
|
|======
|
676 |
|
|
| 0x7a0 | **Trigger select register** | `tselect`
|
677 |
|
|
3+| Reset value: 0x00000000
|
678 |
|
|
3+| This CSR is hardwired to zero indicating there is only one trigger available. Any write access is ignored.
|
679 |
|
|
|======
|
680 |
|
|
|
681 |
|
|
|
682 |
|
|
:sectnums!:
|
683 |
|
|
===== **`tdata1`**
|
684 |
|
|
|
685 |
|
|
[cols="4,27,>7"]
|
686 |
|
|
[frame="topbot",grid="none"]
|
687 |
|
|
|======
|
688 |
|
|
| 0x7a1 | **Trigger data register 1 / match control register** | `tdata1` / `mcontrol`
|
689 |
|
|
3+| Reset value: 0x28041048
|
690 |
|
|
3+| This CSR is used to configure the address match trigger. Only one bit is writable, the remaining bits are hardwired (see table below).
|
691 |
|
|
Write attempts to the hardwired bits are ignored.
|
692 |
|
|
|======
|
693 |
|
|
|
694 |
|
|
.Match control CSR (`tdata1`) bits
|
695 |
|
|
[cols="^1,^2,^1,<8"]
|
696 |
|
|
[options="header",grid="rows"]
|
697 |
|
|
|=======================
|
698 |
|
|
| Bit | Name [RISC-V] | R/W | Description
|
699 |
|
|
| 31:28 | `type` | r/- | `0010` - address match trigger
|
700 |
|
|
| 27 | `dmode` | r/- | `1` - only debug-mode can write to the `tdata*` CSRs
|
701 |
|
|
| 26:21 | `maskmax` | r/- | `000000` - only exact values
|
702 |
|
|
| 20 | `hit` | r/- | `0` - feature not supported
|
703 |
|
|
| 19 | `select` | r/- | `0` - fire trigger on address match
|
704 |
|
|
| 18 | `timing` | r/- | `1` - trigger **after** executing the triggering instruction
|
705 |
|
|
| 17:16 | `sizelo` | r/- | `00` - match against an access of any size
|
706 |
|
|
| 15:12 | `action` | r/- | `0001` - enter debug mode on trigger fire
|
707 |
|
|
| 11 | `chain` | r/- | `0` - chaining is not supported - there is only one trigger
|
708 |
|
|
| 10:6 | `match` | r/- | `0000` - only full-address match
|
709 |
|
|
| 6 | `m` | r/- | `1` - trigger enabled when in machine-mode
|
710 |
|
|
| 5 | `h` | r/- | `0` - hypervisor-mode not supported
|
711 |
|
|
| 4 | `s` | r/- | `0` - supervisor-mode not supported
|
712 |
|
|
| 3 | `u` | r/- | trigger enabled when in user-mode, set when `U` ISA extension is enabled
|
713 |
|
|
| 2 | `exe` | r/w | set to enable trigger
|
714 |
|
|
| 1 | `store` | r/- | `0` - store address/data matching not supported
|
715 |
|
|
| 0 | `load` | r/- | `0` - load address/data matching not supported
|
716 |
|
|
|=======================
|
717 |
|
|
|
718 |
|
|
|
719 |
|
|
:sectnums!:
|
720 |
|
|
===== **`tdata2`**
|
721 |
|
|
|
722 |
|
|
[cols="4,27,>7"]
|
723 |
|
|
[frame="topbot",grid="none"]
|
724 |
|
|
|======
|
725 |
|
|
| 0x7a2 | **Trigger data register 2** | `tdata2`
|
726 |
|
|
3+| Reset value: _UNDEFINED_
|
727 |
|
|
3+| Since only the "address match trigger" type is supported, this r/w CSR is used to store the address of the triggering instruction.
|
728 |
|
|
|======
|
729 |
|
|
|
730 |
|
|
|
731 |
|
|
:sectnums!:
|
732 |
|
|
===== **`tdata3`**
|
733 |
|
|
|
734 |
|
|
[cols="4,27,>7"]
|
735 |
|
|
[frame="topbot",grid="none"]
|
736 |
|
|
|======
|
737 |
|
|
| 0x7a3 | **Trigger data register 3** | `tdata3`
|
738 |
|
|
3+| Reset value: 0x00000000
|
739 |
|
|
3+| This CSR is not required for the NEORV32 trigger module. Hence, it is hardwired to zero and any write access is ignored.
|
740 |
|
|
|======
|
741 |
|
|
|
742 |
|
|
|
743 |
|
|
:sectnums!:
|
744 |
|
|
===== **`tinfo`**
|
745 |
|
|
|
746 |
|
|
[cols="4,27,>7"]
|
747 |
|
|
[frame="topbot",grid="none"]
|
748 |
|
|
|======
|
749 |
|
|
| 0x7a4 | **Trigger information register** | `tinfo`
|
750 |
|
|
3+| Reset value: 0x00000004
|
751 |
|
|
3+| This CSR is hardwired to "4" indicating there is only an "address match trigger" available. Any write access is ignored.
|
752 |
|
|
|======
|
753 |
|
|
|
754 |
|
|
|
755 |
|
|
:sectnums!:
|
756 |
|
|
===== **`tcontrol`**
|
757 |
|
|
|
758 |
|
|
[cols="4,27,>7"]
|
759 |
|
|
[frame="topbot",grid="none"]
|
760 |
|
|
|======
|
761 |
|
|
| 0x7a5 | **Trigger control register** | `tcontrol`
|
762 |
|
|
3+| Reset value: 0x00000000
|
763 |
|
|
3+| This CSR is not required for the NEORV32 trigger module. Hence, it is hardwired to zero and any write access is ignored.
|
764 |
|
|
|======
|
765 |
|
|
|
766 |
|
|
|
767 |
|
|
:sectnums!:
|
768 |
|
|
===== **`mcontext`**
|
769 |
|
|
|
770 |
|
|
[cols="4,27,>7"]
|
771 |
|
|
[frame="topbot",grid="none"]
|
772 |
|
|
|======
|
773 |
|
|
| 0x7a8 | **Machine context register** | `mcontext`
|
774 |
|
|
3+| Reset value: 0x00000000
|
775 |
|
|
3+| This CSR is not required for the NEORV32 trigger module. Hence, it is hardwired to zero and any write access is ignored.
|
776 |
|
|
|======
|
777 |
|
|
|
778 |
|
|
|
779 |
|
|
:sectnums!:
|
780 |
|
|
===== **`scontext`**
|
781 |
|
|
|
782 |
|
|
[cols="4,27,>7"]
|
783 |
|
|
[frame="topbot",grid="none"]
|
784 |
|
|
|======
|
785 |
|
|
| 0x7aa | **Supervisor context register** | `scontext`
|
786 |
|
|
3+| Reset value: 0x00000000
|
787 |
|
|
3+| This CSR is not required for the NEORV32 trigger module. Hence, it is hardwired to zero and any write access is ignored.
|
788 |
|
|
|======
|
789 |
|
|
|