Debugging Distributed-Shared-Memory Communication

at Multiple Granularities in Networks on ChipBart Vermeulen, Kees Goossens, Siddharth Umrani

NXP Semiconductors, The Netherlands,Computer Engineering, Delft University of Technology, The

Netherlands

Presenter : Shao-Chieh Hou

2012/8/27

Second ACM/IEEE International Symposium on Networks-on-ChipIEEE computer society

2

We present a methodology to debug a SOC by concentrating on its communication. Our extended communication model includes a) multiple signal groups per interface protocol at each IP port, b) the handshakes per signal group (e.g. for command), and c) the handshakes within a signal group (e.g. for write and read data elements). As a result, our debug methodology is the first to offer debug control at three communication granularities: individual data elements in a message, messages (i.e. requests or responses), and entire transactions.

Communication to distributed shared memories is supported in networks on chip (NOC) by transparently (de)multiplexing different master-slave channels based on the memory address, also called narrowcast. In this paper, we extend previous work on NOC debug that allowed per-connection debug (i.e. a master without differentiating between its slaves) to also support per-channel (i.e. per master-slave pair) debugging, also for narrowcast connections. This enables essential fine-grained debug control for multi-processor SOCs that use distributed-shared-memory communication.

Abstract

3

The debug infrastructure consists of hardware components, and a software API and library. We define the hardware infrastructure and the required changes to a NOC. Our architecture cleanly separates the monitoring and distribution of events from how they are interpreted and used, in terms of hardware and programming. We define a high-level software API for run-time user control. The debug methodology offers run-time programmable breakpoints, stopping, continuing, and single-stepping of distributed-shared memory communication at three granularities, at the cost of 2.5% NOC area increase and no speed penalty.

Abstract(cont.)

4

Important of debug technology in NoC Increasing of complex Time to market

Debug phase Software debug (e.g. GDB)

Hardware debug (clock cycle information)

SW to HW control flow integrate Control both HW/SW in same interface

What’s the problem?

Communication-base information

5

Related work

This Paper

NXP debug infrastructure Communication

protocol

AXI[1] DTL[14]

OCP[13]

This paper use

Monitor-base [2][3][8][16][18]

Scan-base [5][10][19]

Debug architecture analysis

[4][6][7][9][11][12][19]

6

This paper select the DTL protocol

Communication model

request

response

7

Debug session For the session, we

need those following function: Reset: reset(restart)

system Internal Stop: stop

signal by HW monitor External Stop: stop

signal by SW debugger Continue: resume the

system

8

Architecture of debug infrastructure

9

Send out the control signal for each components Catch data from TAP controller Select and send out the signal to corresponding

component Like the controller in system

Debug control interconnect(DCI)

10

TPR : Test Point Register

On-chip monitor

11

Component of EDI EDI node FSM

Like the CTM(cross trigger matrix) in coresight

Event distribution interconnect(EDI)

12

Modify the FSM in Master interface to match the breakpoint

Add shadow state: In this state, deactivates the handshake protocol End with SW signal

Network interface

13

Network interface(cont.)

Stop enable 0/1: stop or not when event

trigger

Stop granularity 0/1: messages or elements

Stop condition 0: stop only after a plus from

EDI 1: stop unconditionally before

next elements

SW control signal

Continue 0/1: continue or not

IP stop 0/1: stop connected to IP or

not

14

To support the communication-centric debug, add extra TAP controller instructions DBG_RESET

。Functional reset for system PROGRAM_TPR

。Program the monitor and NI TPRs QUERY_TAP

。Query the state of the breakpoint and the channels in NI shell

JTAG_STOP。Send stop trigger to EDI from TAP

PROGRAM_TCB。Switch system state between functional and debug

DBG_SCAN。Scan out the complete state of system via scan-chain in

debug mode

TAP controller instructions

15

API for softwareAPI Parameter Function

Corresponding TAP instructions

reset none Functional reset DBG_RESET

set_bpMonitor: monitor number Setup breakpoint and

trigger event to monitor

PROGRAM_TPRCondition: trigger event

set_bp_action

Channel: select channel

Setup breakpoint action PROGRAM_TPRGranularity: messages or

elements

Condition: edi or always

get_mon_status monitor

Return an ASCII string to specified monitor is trigger or not

None

get_ni_status niReturn an ASCII string to specified NI is idle or not

None

continue channel Continue the communication PROGRAM_TPR

synchronize None Retrieve the complete state of system

PROGRAM_TCB

16

Case study and experiment

17

The paper propose a new level debug Communication-centric level HW stop-run mechanism SW API control

Area cost only 2.5% increase

Conclusion

18

The architecture of this paper is similar with our platform Monitor =>WICE + Tracer DLT => AMBA API => GDB command

The design of API and TAP signal corresponding is good reference for my reaserch

My comment