[Open SoC Debug] Overview document

Stefan Wallentowitz stefan at wallentowitz.de
Wed Feb 3 13:33:09 CET 2016


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

Hi,

let me shortly go through the points, because some of them are maybe
not relevant for this document (see first comment).

On 03.02.2016 13:10, Philipp Wagner wrote:

> 
> - I'm not sure I fully understood the goal of the document. I'm 
> especially confused by the use of the future tense (e.g. "the 
> specification will always allow for ...", p. 2) in many places. Is
> it a specification overview, or a plan to do something possibly in
> the future and to tell people about it?

It is an introductory document, hence it is vague about which version
of the spec will contain which features. You are right, we need to
define target audience better. I think it is hardware system engineers.

> - I think the document could be improved by explicitly spelling out
> the scope of the project: how does the target hardware look like
> (and how not?). What types of debugging/tracing are supported (and
> what not?).

Actually it should be open to any trace debugging. Can you think of a
trace use case that is not covered by the ideas?

> - The document switches regularly between the levels of
> abstraction, which made reading for me not as smooth as it could
> be. For example, the Debug System Overview then quickly turns into
> an description of the physical transport (e.g. discussing the
> requirements for a NoC implementation), and then turns back to the
> higher-level description of the debug modules. I think the document
> would be easier to read if it started off with a high-level
> description of the whole system, then showed the general concept of
> the debug modules, and only then went into the details of the
> modules.

Yes, its two parts: The first part presents the interconnect and
protocol parts and covers the modules on a generic level. The secons
part is examplary debug modules which will be part of the first spec.
Makes sense to introduce this in the beginning.

> - The topic of clock-domain (crossing) is spread across many parts
> of the description, and mixes implementation options and
> requirements with a specification of functionality. Could this be
> consolidated and put after the discussion of the functional
> specification?

Can you point to confusing usages?

> - In the section "Register Access", the MMIO bridge wrapper seems
> to be a implementation helper, but not really a part of the
> specification.

Yes, but it is an integral functional module.

> - A figure showing how all the presented modules interact in an 
> exemplary system is missing. This would make understanding easier.

Yep, we can put in two example systems.

> - The document should mark more clearly what is 
> optional/implementation-dependent in terms of the design, and what
> is a required part that needs to be implemented by anyone.
> 
> On the actual content, I have two remarks:
> 
> - Hot-attach is an important property of a debug solutions, i.e.
> you can always attach to the system when it's running. The section
> about the "Host Interface Module" specifies that the data stream is
> length-value encoded, a format which doesn't allow for hot-attach
> if no side-channel mechanism is added for reset. We should spell
> out this topic more clearly.

Yes, that will be part of the actual SCM spec.

> - I'd like to propose logical a splitting of the register-based 
> communication (for run-control debug and configuration of the
> debug modules) and the trace communication, as the two streams
> have significantly differing properties. Even if those two data
> streams end up being transferred on the same interconnect, or use
> the same NoC with different prioritized virtual channels, the
> possibility to implement different interconnects seems valuable to
> me.

We can highlight this in the interconnect overview, but I think a more
detailed discussion should go into the interconnect specification.

> [..]
> 
> Does that make sense? Let me know where it makes sense to get
> involved in the document git directly, and where you're planning to
> make changes.

I am a bit undecided about the middle part. We have to find a trade
off between the general description and some sort of outlook on
spec'ed stuff. Most parts are currently answers to questions I
received so far, thats why I considered them important for the overview.

Please start with the introduction, while I (and others of course!)
think about the main part.

Also see there are comments from Wei inside the commits of the document.

Thanks!

Cheers,
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlax84UACgkQuMYtsrn2U9wzFQCZAZZu/6/D0nhfNt8kI+8h2HPo
ti0AnRH/jdXosX/7nFbp++UrarSDXKMH
=Qf8o
-----END PGP SIGNATURE-----



More information about the OpenSoCDebug mailing list