[Open SoC Debug] Pulpino

Stefan Wallentowitz stefan at wallentowitz.de
Tue Nov 17 14:58:52 CET 2015

Hash: SHA1

Hi Andy,

Finally, this was some kind of open discussion.

On 16.11.2015 20:49, Andreas Traber wrote:
>> Generating trace data is usually relatively cheap. In mor1kx we
>> just needed to add some logic to preserve the full instruction
>> through the whole pipeline
>> (https://github.com/openrisc/mor1kx/commit/73ed16718a9be2627eb8b9426c
> Depends on how you define relative ;-) If you want to preserve the
> full instruction (and PC) through the whole pipeline you will have
> to add 2x 32 bit registers in all pipeline stages after the
> Instruction Decode stage. In a 4-stage design (like ours), this
> means adding at least 128 more registers. For a small-scale core
> this is already ~10% of registers just for trace data. Of course if
> we consider a complete system, then it almost disappears in the
> noise.

Yes, you are right. So in such cases the instruction may be omitted
without loss of information as long as there is no dynamic code
modification. We used it for the l.nop magic, thats why its in mor1kx :)

> Anyway, what I would like to say is that it could be interesting
> to provide a minimalist trace port that just collects the program
> counter and the instruction. You could even go further and just
> collect the program counter, the instruction can be recovered from
> binary.

Right, should have read further :)

> As far as I've understood the trace infrustructure you're
> describing anyway supports any kind of trace port, so adding a pure
> "program counter" tracer should be quite easy?

Yes, by their nature trace modules are pretty hard to standardize,
because they are pretty low level. I think in Nexus 5001 they tried
this, but most stuff ends up as "vendor-specific" or so.

>> I agree, it may be desirable to share resources with the system,
>> but talking about a 16-bit unidirectional ring, I think it is
>> very reasonable to add this extra hardware. Also an adopter to
>> connect a core to the network is not problematic:
>> * see http://opensocdebug.org/slides/2015-11-12-overview/#/12
>> * In OpTiMSoC we used a bridge between the debug NoC and the
>> standard interconnect: 
>> https://github.com/TUM-LIS/lisnoc/tree/master/rtl/lisnoc16/converter
> Out of curiosity, do you have any numbers on how much overhead this
> NoC adds?

The whole debug system is in the order of ~10-15% for a simple system.
I don't have numbers for the NoC at hand, but will have a look at it


Version: GnuPG v2


More information about the OpenSoCDebug mailing list