Target Communication Framework Vision

1. Target Communication Framework Vision Felix Burton (felix.burton@windriver.com) Aaron Spear (aaron_spear@mentor.com)

2. Scope • End to end tool to target interaction needs for the purpose of development, debug, analysis and test • Cross tools (i.e. host and target are different) benefits the most, but it is applicable to native tools also • Target agent, OCD and simulator connections

3. The Problem • Every tool that is talking to the target has its own agent/connection/protocol/setup • This leads to: • Bad user experience • Each tools has its own target configuration • No sharing between agents • Duplicated maintenance effort • New features have to be added in multiple places • Increased target footprint • Incomplete product matrix, e.g. serial supported by some tools but not others • Hard to build Eco-system

4. Example of Existing Architectures Tool A Tool B Tool C Tool D UI P2 Value Add B Value Add C Host P1 P3 Agent A Agent B Agent C Target

5. Current Architectures not Scalable • New features are sometimes hard to add because of layering in the communication link with limited transparency • Details about target representation are usually hard coded into protocols and APIs • New tools have a hard time building on existing APIs, protocols and agents • Performance over high latency communication links

6. Solution • Define a lightweight, small footprint, open and vendor agnostic way for tools and target to communicate for purpose of development, debug, analysis and test of device software • Single configuration per target (not per tool per target as today in most cases) • Simple & extensible protocol • Designed so the same protocol can be used above and below value adding parts • Services can be added dynamically • Support for slow and high latency connections • Transport protocol agnostic • Dynamic discovery of available boards and services • Share services between multiple tools e.g.: • Up-load mechanism • Kernel awareness • Run-control • File system access

7. Vision Tool A Tool B Tool C Tool D UI Value Add P1 Service 4 Host Service 5 P1 Service Manager Service 1 Service 2 Service 3 Target

8. Use Case: SimpleJtagDevice • Protocol • TCP/IP • Services • Service Manager (returns fixed list of services) • Debug (run-control, breakpoint, memory access) • Possibly Others (flash programming, download, etc) • No Dynamic Addition or Removal of Services • No Multiplexing (single client) • No Forwarding • No Dynamic Discovery

9. Use Case: TestExceutionAgent • Protocol • Depends on OS configuration and board • Services • Service Manager (returns fixed list of services) • Process launch and kill • Standard I/O redirection • File system access • No Dynamic Addition or Removal of Services • No Multiplexing (multiple clients) • No Forwarding • No Dynamic Discovery

10. Use Case: LinuxUserModeAgent • Protocol • Typically TCP/IP, but depends on OS configuration and hardware • Services • Service Manager • Debug (run-control, breakpoint, memory access) • OS Awareness (process/thread list, CPU utilization, etc) • Process launch and kill • Standard I/O redirection • File system access • Possibly Dynamic Addition or Removal of Services • Possibly Multiplexing (multiple clients) • No Forwarding • No Dynamic Discovery