You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an ebreak or an ecall instruction is used in an application, special care should be given for those instruction handlers in case they are placed as the last instruction of an HWLoop.
147
+
Those handlers should manage MEPC and lpcountX CSRs updates because an hw loop early-exit could happen if not done.
148
+
149
+
At the end of the handlers after restoring the context/CSRs, a piece of smart code should be added with following highest to lowest order of priority:
150
+
151
+
1. if MEPC = lpend0 - 4 and lpcount0 > 1 then MPEC should be set to lpstart0 and lpcount0 should be decremented by 1,
152
+
2. else if MEPC = lpend0 - 4 and lpcount0 = 1 then MPEC should be incremented by 4 and lpcount0 should be decremented by 1,
153
+
3. else if MEPC = lpend1 - 4 and lpcount1 > 1 then MPEC should be set to lpstart1 and lpcount1 should be decremented by 1,
154
+
4. else if MEPC = lpend1 - 4 and lpcount1 = 1 then MPEC should be incremented by 4 and lpcount1 should be decremented by 1,
155
+
5. else if (lpstart0 <= MEPC < lpend0 - 4) or (lpstart1 <= MEPC < lpend1 - 4) then MPEC should be incremented by 4,
156
+
6. else if instruction at MEPC location is either ecall or ebreak then MPEC should be incremented by 4,
157
+
7. else if instruction at MEPC location location is c.ebreak then MPEC should be incremented by 2.
158
+
159
+
The 2 last cases are the standard ones when ebreak/ecall are not inside an HWLopp.
160
+
161
+
Interrupt handlers
162
+
------------------
163
+
164
+
When an interrupt is happening on the last HWLoop instruction, its execution is cancelled, its address is saved in MEPC and its execution will be resumed when returning from interrupt handler.
165
+
There is nothing special to be done in those interrupt handlers with respect to MEPC and lpcountX updates, they will be correctly managed by design when executing this last HWLoop instruction after interrupt handler execution.
166
+
167
+
Moreover since hardware loop could be used in interrupt routine, the registers have to be saved (resp. restored) at the beginning (resp. end) of the interrupt routine together with the general purpose registers.
168
+
169
+
Illegal instruction exception handler
170
+
-------------------------------------
171
+
172
+
Depending if an application is going to resume or not after Illegal instruction exception handler, same MEPC/HWLoops CSRs management than ebreak/ecall could be necessary.
173
+
174
+
Debugger
175
+
--------
176
+
177
+
If ebreak is used to enter in Debug Mode (:ref:`ebreak_scenario_2`) and put at the last instruction location of an HWLoop (not very likely to happen), same management than above should be done but on DPC rather than on MEPC.
178
+
179
+
When ebreak instruction is used as Software Breakpoint by a debugger when in debug mode and is placed at the last instruction location of an HWLoop in instruction memory, no special management is foreseen.
180
+
When executing the Software Breakpoint/ebreak instruction, control is given back to the debugger which will manage the different cases.
181
+
For instance in Single-Step case, original instruction is put back in instruction memory, a Single-Step command is executed on this last instruction (with desgin updating PC and lpcountX to correct values) and Software Breakpoint/ebreak is put back by the debugger in memory.
182
+
183
+
When ecall instruction is used by a debugger to execute System Calls and is placed at the last instruction location of an HWLoop in instruction memory, debugger ecall handler in debug rom should do the same than described above for application case.
`RISC-V ISA <https://github.com/riscv/riscv-isa-manual/releases/tag/Ratified-IMAFDQC>`_. The following is a summary of the behavior for three common scenarios.
164
164
165
+
.. _ebreak_scenario_1:
166
+
165
167
Scenario 1 : Enter Exception
166
168
""""""""""""""""""""""""""""
167
169
@@ -173,10 +175,14 @@ Executing the EBREAK instruction when the core is **not** in Debug Mode and the
173
175
To properly return from the exception, the ebreak handler will need to increment the MEPC to the next instruction.
174
176
This requires querying the size of the ebreak instruction that was used to enter the exception (16 bit c.ebreak or 32 bit ebreak).
175
177
178
+
As mentioned in :ref:`hwloop-exceptions_handlers`, some additional cases exist for MEPC update when ebreak is the last instruction of an Hardware Loop.
179
+
176
180
.. note::
177
181
178
182
The CV32E40P does not support MTVAL CSR register which would have saved the value of the instruction for exceptions. This may be supported on a future core.
179
183
184
+
.. _ebreak_scenario_2:
185
+
180
186
Scenario 2 : Enter Debug Mode
181
187
"""""""""""""""""""""""""""""
182
188
@@ -187,11 +193,15 @@ Executing the EBREAK instruction when the core is **not** in Debug Mode and the
187
193
188
194
Similar to the exception scenario above, the debugger will need to increment the DPC to the next instruction before returning from Debug Mode.
189
195
196
+
There is no forseseen situtation where it would be needed to enter in Debug Mode only on the last instruction of an Hardware Loop but just in case this is mentioned in :ref:`hwloop-exceptions_handlers` as well.
197
+
190
198
.. note::
191
199
192
200
The default value of DCSR.EBREAKM is 0 and the DCSR is only accessible in Debug Mode. To enter Debug Mode from EBREAK,
193
201
the user will first need to enter Debug Mode through some other means, such as from the external ``debug_req_i``, and set DCSR.EBREAKM.
194
202
203
+
.. _ebreak_scenario_3:
204
+
195
205
Scenario 3 : Exit Program Buffer & Restart Debug Code
0 commit comments