Time travel
Step back, reverse continue and Run Back To: rewinding a debug session in simulated time.
Overshot the bug? A debug session can go back in simulated time:
| Action | Goes to |
|---|---|
| Step Back (Ctrl+Shift+F10, debug toolbar) | the previous time step with activity |
| Reverse Continue (debug toolbar) | the previous breakpoint hit or watched signal change, stopping on the breakpoint line itself |
| HDL Studio: Run Back To… | any earlier time you type, such as 40 ns |
From the terminal, hdl run-back-to 40ns does the same in the window’s session.
run 150 ns, three Step Back (Ctrl+Shift+F10), then HDL Studio: Run Back To… with 40 ns.How it works#
The signal viewer already keeps the whole history, so moving the cursor to a past time shows past values without touching the simulator. Going back with the debugger restarts and runs forward:
- The breakpoints, watches and the values you deposited with
forceare remembered. - The simulation restarts with the same executable and arguments, and runs to the target time with breakpoints disabled. Each deposit is replayed at the start of the time step it was made in.
- Breakpoints are re-enabled, and the session stops at the start of the target time step.
On the bundled examples a step back or a Run Back To takes about a tenth of a second, so no checkpoints are needed.
The history recorded by the rerun is compared with the stored one. If they differ, the Debug Console reports a non-deterministic testbench and the new history replaces the old.
What to expect after a rewind#
- A rewind stops at the start of a time step, before its events, in a frame named
simulation @ t. No process is running at that boundary, so the call stack is that frame alone and the raw process locals appear only once a breakpoint line is reached. - Deposits made at or after the target time are not replayed: running on generates the future again.
- The viewer shades the already simulated stretch after the current time until the simulation moves on and overwrites it.