[Open SoC Debug] packet vs. memory interface

Tim Newsome 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:

> 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.
> Cheers,
> Stefan
> Version: GnuPG v2
> iEYEARECAAYFAlaqfJ4ACgkQuMYtsrn2U9wRFwCdGTKbRCze/afqao6b8+L327gh
> =UsiC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fossi-foundation.org/pipermail/opensocdebug/attachments/20160128/833bce74/attachment.html>

More information about the OpenSoCDebug mailing list