<div dir="ltr">I haven't really been following this thread fully, so sorry if this is off target. <div><br></div><div>I do think the idea of exploring tracing, profiling or other debugging features that work in a FPGA SoC which wouldn't make sense in silicon. A couple of things which might be useful inspiration are;<div><div><br></div><div>OpenSoCDebug (<a href="http://opensocdebug.org/">http://opensocdebug.org/</a>) -- they have a bunch of stuff around tracing, including a Core Trace Module (CTM) & Software Trace Module (STM) -- see <a href="http://opensocdebug.org/docs/overview/#trace-modules">http://opensocdebug.org/docs/overview/#trace-modules</a> and the rest of the docs. FYI There is a strong change that we will be looking at adding OpenSoCDebug to litex and hopefully connect it to j1 when that is integrated.<div><br></div><div>rr -- <a href="http://rr-project.org/">http://rr-project.org/</a>, which is a super useful tool for recording a failure once, then debug the recording, deterministically, as many times as you want. It does need a couple of special instructions to be performant however. See the following talk from slide 15 onwards -- <a href="http://rr-project.org/rr.html#15.0">http://rr-project.org/rr.html#15.0</a></div><div><br></div><div>Hope that helps,</div></div></div></div><div><br></div><div>Tim 'mithro' Ansell</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 March 2017 at 16:17, BGB <span dir="ltr"><<a href="mailto:cr88192@gmail.com" target="_blank">cr88192@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 3/3/2017 7:23 PM, Rob Landley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 02/25/2017 08:49 PM, BGB wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2/25/2017 6:40 PM, D. Jeff Dionne wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Feb 26, 2017, at 09:00, Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How do you reconstruct "three functions back we did fifty-seven<br>
iterations of the loop that decided where to go next"?<br>
</blockquote>
You just reconstruct the jump log from the trace.   A register doesn't<br>
help you with any of this, you need an external interface.  If you're<br>
really (only) interested in looking at the 9k instruction cycles for<br>
interrupts, the better approach is gprof.<br>
<br>
A trace log system is for reconstructing whole program flows,<br>
including things like stalls and cache misses...<br>
</blockquote>
seems like it could be possible to have a feature to generate an<br>
interrupt whenever a branch occurs, so that the PC could be recorded?<br>
</blockquote>
Sure, but that would slow it down a lot. If a branch occurs every dozen<br>
or so instructions (for loops, function calls, if statements...) and it<br>
takes hundreds if not thousands of instructions to service an interrupt<br>
(see "9000 cycles to service an interrupt in linux") then this isn't<br>
necessarily much faster than single stepping?<br>
<br>
In theory you could just single step the code and record all the<br>
addresses (might need a jtag to do it in the kernel but all real<br>
hardware targets have those), but only the jumps change program flow<br>
(and thus need to be recorded to be able to work backwards). My<br>
suggestion of writing them into to a buffer more or less assumed it<br>
would write out filled cache lines, then deal with them in larger<br>
batches later. It seemed a small enough feature not to eat too many<br>
cells (it's basically one more memory location in the 0xabcdxxxx SOC<br>
control block you write an address to when you start it and zero to when<br>
you disable it, and maybe a second to indicate the interrupt to raise if<br>
you don't want to hardwire it). That sounded like a small self-contained<br>
VHDL project to me.<br>
<br>
The first counter-argument was "why would you ever modify VHDL when you<br>
could do an emulator". The second counter-argument was somebody else<br>
once did a feature on some other platform and I should look that up<br>
without actually knowing the name of the feature or (so far) being able<br>
to find anyone who's ever used it. (Maybe it's "coldfire trace log<br>
system"? No, that doesn't seem to find anything... there's a mention of<br>
trace32 but the first hit on that is Lauterbach which is a type of jtag...)<br>
<br>
*shrug* I stand corrected.<br>
</blockquote>
<br></div></div>
could be, what I had originally imagined was something similar to the single-step feature in x86 (trap flag), but with the tweak of being able to (optionally?) ignore non-branch instructions. then again, I could have probably just said "like the x86 trap flag".<br>
<br>
had imagined the ISR probably doing something similar to the buffer idea you had mentioned, but didn't think of having this part implemented in hardware (or fully understand the suggestion of doing so). if a trap ISR, would ideally want a minimalist interrupt handler to limit overhead (ideally with no direct dependence on kernel facilities if used on the kernel).<br>
<br>
yep, "every dozen or so instructions" falls within the average-case range I have been seeing.<br>
<br>
<br>
but, dunno really, not entirely thought through the idea.<br>
<br>
<br>
<snip><br>
<br>
ok, just nothing really to add.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
J-core mailing list<br>
<a href="mailto:J-core@lists.j-core.org" target="_blank">J-core@lists.j-core.org</a><br>
<a href="http://lists.j-core.org/mailman/listinfo/j-core" rel="noreferrer" target="_blank">http://lists.j-core.org/mailma<wbr>n/listinfo/j-core</a><br>
</div></div></blockquote></div><br></div>