[Open SoC Debug] packet vs. memory interface

Stefan Wallentowitz stefan at wallentowitz.de
Thu Jan 28 21:39:58 CET 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28.01.2016 21:30, Tim Newsome wrote:
> Thanks for the overview of bus/interconnect history. That was
> insightful.
> 
> I'm more talking about the abstraction than the actual
> implementation, though. The abstraction of reads/writes at an
> address is baked into everything. Whatever the actual interconnect
> is, it will likely support it. (Memory mapped I/O is not likely to
> disappear any time soon.) The abstraction of sending
> variable-length packets is less common (at least within SoCs).
> What's more, it is obvious how to map reads/writes at an address
> into packets. Mapping variable-length packets to reads/writes at an
> address is less obvious.
> 
> Any small SoC will have something that looks like a memory+data
> bus. That's why I picked it as my default debug interconnect.
> Otherwise you're adding logic that translates back and forth
> between a packet format that's really only relevant in a more
> complex system. Having some extra translation in a more complex
> system (which might actually use a ring as its bus implementation)
> feels less bad.
> 
> Does that make sense?

Yes, it makes a lot of sense and the debug interface should not care
about how data is transported in the system. Similarly, as you put a
clear focus on run-control debugging, it also makes a lot of sense
that you use a bus and memory-mapped I/O. Simlarly as Pulp will
probably do.

The most common case is to use JTAG to interface the debug interface
register accesses. There the transport is also not by itself a bus
interface but it is necessary to implement a protocol in the TAP that
maps to a memory-mapped interface.

But to summarize, I am absolutely sure that we are on the same page
despite what the length of our exchanged emails may suggest :)

Great that the debug topic advances now for RISC-V and we can share
the processor implementations and don't need variations for different
debug infrastructures.

Cheers,
Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlaqfJ4ACgkQuMYtsrn2U9wRFwCdGTKbRCze/afqao6b8+L327gh
+LIAoKgd66Z8tATETNW7ChT0EGvaCM9O
=UsiC
-----END PGP SIGNATURE-----



More information about the OpenSoCDebug mailing list