[Libre-soc-dev] [OpenPOWER-HDL-Cores] microwatt-libre-soc interoperable verilator snapshots / debugging

[Luke Kenneth Casson Leighton]

On Sun, Jan 9, 2022 at 2:21 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> maybe VM save/restore? though that would miss TLB activity.

yes.  unless the TLB can be extracted [from qemu]

> if you can get an instruction trace from qemu or similar, you could then postprocess it (e.g. with a relatively simple python script)

we're 10 *million* instructions in to execution, only the first few
lines of the linux kernel have been displayed up to that point.  to
get to the boot prompt could easily be 100 million instructions,
possibly even a billion.  whatever solution is envisaged has to take
that into account.

it did occur to me that if this is done properly in hardware, it would
actually be possible to use the DMI interface to HALT microwatt when
running on an FPGA, perform a full state-dump (including reading the
full memory over DMI-wishbone), and then start it back up again *under
verilator*.

this would be extremely cool because even a few thousand or tens of
thousands of instructions under verilator is perfectly reasonable
(even when VCD traces are enabled), and it would allow full
signal-level debugging of FPGA execution just before it goes wrong.

> to add the TLB info, allowing generating the state you want to load. alternatively you could just clear the TLB on state load, as long as our TLB automatically does page table walking, and then just ignore TLB state when comparing to microwatt or qemu.

the issue is that if the TLB state is not captured, it is not possible
to exactly have the exact same state.  TLB misses will occur which
will cause lookups to occur that would otherwise not occur, and that
is not *exactly* the behaviour, at that exact time, that the
[snapshotted] system was about to do.

if there are bugs *in* the HDL of the TLB miss (or bugs in TLB hits),
these will not be caught because the state was not exactly the same.

l.