1 / 18

Presenter : Shao- Chieh Hou

Debugging Distributed-Shared-Memory Communication at Multiple Granularities in Networks on Chip Bart Vermeulen , Kees Goossens , Siddharth Umrani NXP Semiconductors, The Netherlands , Computer Engineering, Delft University of Technology, The Netherlands. Presenter : Shao- Chieh Hou.

shana
Download Presentation

Presenter : Shao- Chieh Hou

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Debugging Distributed-Shared-Memory Communicationat Multiple Granularities in Networks on ChipBart Vermeulen, KeesGoossens, SiddharthUmraniNXP Semiconductors, The Netherlands,Computer Engineering, Delft University of Technology, The Netherlands Presenter : Shao-ChiehHou Second ACM/IEEE International Symposium on Networks-on-Chip IEEE computer society

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

  3. Abstract(cont.) • 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.

  4. What’s the problem? • 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 Communication-base information

  5. Related work Monitor-base [2][3][8][16][18] Scan-base [5][10][19] Debug architecture analysis [4][6][7][9][11][12][19] OCP[13] AXI[1] DTL[14] This paper use Communication protocol NXP debug infrastructure This Paper

  6. Communication model • This paper select the DTL protocol 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. Debug control interconnect(DCI) • 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

  10. On-chip monitor • TPR : Test Point Register

  11. Event distribution interconnect(EDI) • Component of EDI • EDI node • FSM • Like the CTM(cross trigger matrix) in coresight

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

  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. TAP controller instructions • 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

  15. API for software

  16. Case study and experiment

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

  18. My comment • 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

More Related