© 2002 IBM Corporation Confidential | Date | Other Information, if necessary November 4, 2014 Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 Target Communication Framework Vision Felix Burton Aaron Spear

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 Current Architecture is not Scalable Multiple heterogeneous cores requires vendor to support all cores or customer needs to use separate tools The number of cores in a system is rapidly increasing New tools have a hard time using features from already existing agents and target communication links New communication links require all tools to support the new link type or the product availability matrix will have holes and customers as well as the sales force suffers Poor performance over high latency communication links New features are sometimes hard to add because of layering in the communication link with limited transparency Customers cannot easily chose best in class tools for their OS 2

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 Example of Existing Architectures 3 UI Target Tool A Tool B Tool C Tool D Target A Target B Target C Value Add B Value Add C Host P1 P3 P2

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.04 Goals Define a lightweight, small footprint, open and vendor agnostic way for tools and target to communicate for purpose of debugging and development of device software Single configuration per target (not per tool per target as today in most cases) Simple & extensible protocol 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

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 Vision 5 UI Target Tool A Tool B Tool C Tool D Service Manager Service 1 Value Add Host Service 2 Service 3 Service 4 Service 5 P1

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 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 6

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 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 7

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 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 8

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.09 TCF requirements (1) TCF is a lightweight way for tools and targets to locate services and send/receive requests/events to/from them It does NOT specify what service are possible, where they are located or who can specify new services Value adding services can be located between the tool and the target This is important to reduce footprint on the target There services should pass through any commands they do not understand TCF is layered in such a way so it is possible convert between different transport medias (e.g. TCP/IP, RS232, USB, etc) without having to know anything about individual services

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v TCF requirements (2) Each services defines how marshalling is done for command arguments, results and events. This allows existing agents to continue to use their current marshalling However, TCF should define a preferred marshalling mechanism that new services can use Services are separate from protocol Anybody (including 3 rd parties) can add new services without having to modify any value adding servers between the target and the tools Clients can query for available services Protocol supports multiplexing i.e. multiple clients accessing the same target To reduce footprint on the target, multiplexing can be implemented on a higher level (host) if needed

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v TCF requirements (3) Protocol can support forwarding Clients can send requests to services before the reply to the first request is received Servers are not required to process or buffer more than one request at the time, however advanced servers may buffer and process multiple requests at the same time as long as the order of dependent requests are preserved Server can send events to client at any time (no polling should be required) Protocol should specify a way to send data larger than MTU

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v Open Issues Is there an existing protocol that could be used? Protocol: (RPC), (CORBA), D-Bus, ? Marshalling: JSON, XDR, (XML), ? Discovery: ZeroConf, ?