[J-core] Debug jump log?

D. Jeff Dionne Jeff at SE-Instruments.com
Thu Feb 23 19:55:58 EST 2017


Have a look at how ColdFire does this.   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...

No one ever seems to use that.  Nor does anyone seem to bother with the ARM trace macrocell.   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'm all for adding the ports necessary to do ColdFire style backtrace... I doubt it will ever make it to package pins in any of our designs.  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...

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

Cheers,
J.

> On Feb 24, 2017, at 09:18, Rich Felker <dalias at libc.org> wrote:
> 
>> On Thu, Feb 23, 2017 at 01:35:53PM -0600, Rob Landley wrote:
>> What would it take to add a debug feature to j-core which recorded the
>> address each jump came from into a ring buffer when we set a status
>> flag? I.E "start debugging mode", then run until breakpoint, then dump
>> the buffer to have all the "come from" addresses so we can reconstruct
>> the path that got us here back into the runtime history?
>> 
>> Even if it was writing the data straight into DRAM (thus slowing
>> execution down a lot) it would be a really useful feature for things
>> like profiling the interrupt path. (Doing that would need a register to
>> set the size/location of the buffer...)
> 
> Is there a reason you'd want this in the hardware rather than an
> emulator?
> 
> Rich
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core



More information about the J-core mailing list