[Open SoC Debug] Overview document

Philipp Wagner philipp.wagner at tum.de
Wed Feb 3 13:10:22 CET 2016


Hi Stefan,

On 02/01/2016 11:15 AM, Stefan Wallentowitz wrote:
> based on the many discussions I had over the last weeks I finished a
> first draft of an overview document that summarizes all ideas for Open
> SoC Debug.

thanks for the work.

> I am looking forward to your input, either as pull requests (for
> simple changes) or as followup discussion on this mailing list.

I have two types of remarks, a couple on the document, and others on the 
method. Let's start with the document.

- 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?

- 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?).

- 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.

- 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?

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

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

- 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.

- 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.
For the register based communication, low (not necessarily 
deterministic) latencies are key. This is especially true if 
cross-triggers or other run-time reconfiguration is transmitted over 
this channel, as the spec currently proposes. If the interconnect is 
heavily loaded with trace messages, the latencies become quickly 
unacceptable.


To summarize, I'm proposing a document structure like this:

1) Introduction
- Environment
- Goal + non-goals of the spec
- Intended audience

2) System Overview
- Full high-level system architecture
- system properties
-- run-control dbg
-- tracing
-- memory initialization
-- system auto-discovery
-- timestamping of events
-- security/auth

3) Hardware architecture
- Debug Module template
-- register/trace interfaces, common register map,
- Infrastructure modules (HAM/HIM, etc.)
- on-chip interconnect(s)
- off-chip interconnect(s)
- clock/power domains

4) Individual Debug Modules
- core
-- general description
-- register map
-- types of trace events generated
-- interface to the functional unit (here: CPU core)
-- etc.
- memory
- etc.

5) Host software interface
What's the entry point for software development? What is part of the 
spec, what is specific to the implementation?



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.

Philipp



More information about the OpenSoCDebug mailing list