Presenter : Shao-Chieh Hou 2012/8/27 Second ACM/IEEE International Symposium on Networks-on-Chip IEEE computer society

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

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

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 4 Communication-base information

5 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] Debug architecture analysis [4][6][7][9][11][12][19]

This paper select the DTL protocol 6 request response

7 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

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 9

TPR : Test Point Register 10

Component of EDI  EDI node  FSM Like the CTM(cross trigger matrix) in coresight 11

Modify the FSM in Master interface to match the breakpoint Add shadow state:  In this state, deactivates the handshake protocol  End with SW signal 12

13 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

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 14

15 APIParameterFunction Corresponding TAP instructions resetnoneFunctional resetDBG_RESET set_bp Monitor: monitor number Setup breakpoint and trigger event to monitor PROGRAM_TPR Condition: trigger event set_bp_action Channel: select channel Setup breakpoint action PROGRAM_TPR Granularity: messages or elements Condition: edi or always get_mon_statusmonitor Return an ASCII string to specified monitor is trigger or not None get_ni_statusni Return an ASCII string to specified NI is idle or not None continuechannel Continue the communication PROGRAM_TPR synchronizeNone Retrieve the complete state of system PROGRAM_TCB

16

The paper propose a new level debug  Communication-centric level  HW stop-run mechanism  SW API control Area cost only 2.5% increase 17

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 18