[Open SoC Debug] packet vs. memory interface
tim at sifive.com
Thu Jan 28 23:17:22 CET 2016
On Thu, Jan 28, 2016 at 12:39 PM, Stefan Wallentowitz <
stefan at wallentowitz.de> wrote:
> -----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 :)
I'm coming to that conclusion as well. Excellent.
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenSoCDebug