forked from riscv/riscv-debug-spec
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathintroduction.tex
184 lines (145 loc) · 7.43 KB
/
introduction.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
\chapter{Introduction}
\label{sec:intro}
When a design progresses from simulation to hardware implementation, a user's
control and understanding of the system's current state drops dramatically.
To help bring up and debug low level software and hardware,
it is critical to have good debugging support built into the hardware.
When a robust OS is running on a core, software can handle many
debugging tasks. However, in many scenarios, hardware support is essential.
This document outlines a standard architecture for external debug support
on RISC-V platforms. This architecture allows a variety of implementations and
tradeoffs, which is complementary to the wide range of RISC-V implementations.
At the same time, this specification defines common interfaces to
allow debugging tools and components to target a variety of platforms based on the RISC-V ISA.
System designers may choose to add additional hardware debug support,
but this specification defines a standard interface for common
functionality.
\section{Terminology}
A \emph{platform} is a single integrated circuit consisting of one or more
\emph{components}. Some components may be RISC-V cores, while others may have a different
function. Typically they will all be connected to a single system bus.
A single RISC-V core contains one or more hardware threads, called
\emph{harts}.
\emph{DXLEN} of a hart is its widest supported XLEN, ignoring the current value
of \Fmxl in \Rmisa.
\subsection{Context}
\begin{steps}{This document is written to work with:}
\item The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document
Version 2.2 (the ISA Spec)
\item The RISC-V Instruction Set Manual, Volume II: Privileged Architecture,
Version 1.10 (the Privileged Spec)
\end{steps}
\subsection{Compatibility}
By 0.13-DRAFT, we mean version f2873e71, dated October 2, 2018 of that document.
\begin{steps}{Debuggers that implement 0.13-DRAFT can debug:}
\item Targets that implement 0.13-DRAFT.
\item Targets that implement \versionnum.
\end{steps}
\begin{steps}{Debuggers that implement \versionnum{} can debug:}
\item Targets that implement 0.13-DRAFT.
\item Targets that implement \versionnum.
\end{steps}
\subsection{Errata}
This document may contain mistakes.
\url{https://github.com/riscv/riscv-debug-spec} will contain an errata document
that lists any mistakes that were discovered after it was finalized.
\section{About This Document}
\subsection{Structure}
This document contains two parts. The main part of the document is the
specification, which is given in the numbered sections. The second part
of the document is a set of appendices. The information
in the appendices is intended to clarify and provide examples, but is
not part of the actual specification.
\subsection{Register Definition Format}
All register definitions in this document follow the format shown below. A
simple graphic shows which fields are in the register. The upper and lower bit
indices are shown to the top left and top right of each field. The total number
of bits in the field are shown below it.
After the graphic follows a table which for each field lists its name,
description, allowed accesses, and reset value. The allowed accesses are listed
in Table~\ref{tab:access}. The reset value is either a constant or ``Preset.''
The latter means it is an implementation-specific legal value.
Names of registers and their fields are hyperlinks to their definition, and are
also listed in the index on page \pageref{index}.
\input{sample_registers.tex}
\begin{table}[htp]
\centering
\caption{Register Access Abbreviations}
\label{tab:access}
\begin{tabulary}{\textwidth}{|l|L|}
\hline
R & Read-only. \\
\hline
R/W & Read/Write. \\
\hline
R/W1C & Read/Write. For each bit in the field, writing 1 clears that bit. Writing 0 has no effect. \\
\hline
W & Write-only. When read this field returns 0. \\
\hline
W1 & Write-only. Only writing 1 has an effect. \\
\hline
WARL & Write any, read legal. A debugger may write any value. If a
value is unsupported, the implementation converts the value to one that
is supported. \\
\hline
\end{tabulary}
\end{table}
%\input{reading_order.tex}
\section{Background}
There are several use cases for dedicated debugging hardware, both
internal to a CPU core and with an external connection.
This specification addresses the use cases listed below. Implementations
can choose not to implement every feature, which means some use cases might
not be supported.
\begin{itemize}
\item Debugging low-level software in the absence of an OS or other software.
\item Debugging issues in the OS itself.
\item Bootstrapping a system to test, configure, and program components before
there is any executable code path in the system.
\item Accessing hardware on a system without a working CPU.
\end{itemize}
In addition, even without a hardware debugging interface,
architectural support in a RISC-V CPU can aid software debugging and
performance analysis by allowing hardware triggers and breakpoints.
\section{Supported Features}
The debug interface described in this specification supports the following features:
\begin{enumerate}
\item All hart registers (including CSRs) can be read/written.
\item Memory can be accessed either from the hart's point of view, through
the system bus directly, or both.
\item RV32, RV64, and future RV128 are all supported.
\item Any hart in the platform can be independently debugged.
\item A debugger can discover almost\footnote{Notable exceptions include
information about the memory map and peripherals.} everything it needs
to know itself, without user configuration.
\item Each hart can be debugged from the very first instruction executed.
\item A RISC-V hart can be halted when a software breakpoint instruction is
executed.
\item Hardware single-step can execute one instruction at a time.
\item Debug functionality is independent of the debug transport used.
\item The debugger does not need to know anything about the microarchitecture
of the harts it is debugging.
\item Arbitrary subsets of harts can be halted and resumed simultaneously.
(Optional)
\item Arbitrary instructions can be executed on
a halted hart. That means no new debug functionality 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)
\item Registers can be accessed without halting. (Optional)
\item A running hart can be directed to execute a short sequence
of instructions, with little overhead. (Optional)
\item A system bus master allows memory access without
involving any hart. (Optional)
\item A RISC-V hart can be halted when a trigger matches the PC,
read/write address/data, or an instruction opcode. (Optional)
\item 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)
\end{enumerate}
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 specification, but this specification 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.