[J-core] Debug jump log?

[Rob Landley]

On 02/23/2017 06:55 PM, D. Jeff Dionne wrote:
> Have a look at how ColdFire does this.

I've never even heard of this feature, let alone encountered anything
using it. I have no idea how to look it up: googling for "coldfire
backtrace" and "coldfire instruction log" doesn't bring up anything
relevant.

> Essentially, recording the addresses is
> (almost) not necessary, you only need to be able to reconstruct the
program counter.
> To do that, you need a fairly thin stream of information, because you
have the machine
> code (you can read memory).  What their debug interface does is quite clever, and
> simple to implement, but...

How do you reconstruct "three functions back we did fifty-seven
iterations of the loop that decided where to go next"?

I am pondering ways to compress multiple consecutive identical jumps.
(Using high bits of the pointer is kinda disgusting by they _are_ there
and unused right now. Although it wouldn't help nested loops so I expect
software has to collate it if want to retain that data.)

> No one ever seems to use that.  Nor does anyone seem to bother with the ARM trace
> macrocell.

In the short run I want to trace through why our interrupt path takes
9000 cycles to service, and in the longer run I want a tool to make that
kind of thing easier to do.

> There -are- use cases, but the complexity isn't worth it in the general
> case.  So for those cases where it is useful, just hack the RTL:
datapath.vhm
> contains all the signals you need to bring out.   In the case of
wanting to follow
> the flow, it might even be enough to look at the .jp element of the
instruction
> fetch bus (an external interface, obviously) but be mindful of the
fact that
> the timing relationship between the retirement of instructions
previously in
> the stream and the fetch cycles that brought them into the core depends on
> the past execution history, and memory stalls, interrupts etc...

I don't understand what most of that paragraph is telling me to do. :)

> I'm all for adding the ports necessary to do ColdFire style backtrace...

I think we can do it in one new debug register and one interrupt.

(Oh, and obviously while servicing the interrupt you don't write more to
the log, and the jump for the interrupt isn't written to the log either. :)

> I doubt it will ever make it to package pins in any of our designs.

How are pins involved? This tells the CPU to write extra data to memory
when a thing it's already doing happens.

But yeah, I'm not saying this is something you'd necessarily want to
ship, but it's a good config option you can build into your own bitstreams.

> If it does, users of those ASICs will have a hard time with signal
> integrity (not to mention finding a debug tap controller with the
> necessary inputs) at the speeds even those highly compressed signals
> will have to run at...

insmod handle_logging_interrupt
Set debug register before calling system call.
Zero debug register after calling system call.
Parse log from userspace.

This affects signal integrity?

> So, yeah, does an emulator cover the use case you're looking at?

Of demonstrating a small feature you can add to the CPU that's an
example of something you can do in VHDL but can't do in a closed source
processor, which might help people learn about VHDL and our processor
design?

> Cheers,
> J.

Rob