1 / 12

Target Communication Framework Vision

Introducing TCF, a lightweight, open, and vendor-agnostic communication framework for debugging and development of device software. It provides a simple and extensible protocol, dynamic service discovery, support for slow/high latency connections, and more.

daggett
Download Presentation

Target Communication Framework Vision

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. Target Communication Framework Vision Felix Burton (felix.burton@windriver.com) Aaron Spear (aaron_spear@mentor.com)

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

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

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

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

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

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

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

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

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

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

  12. Open Issues • Is there an existing protocol that could be used? • Protocol: (RPC), (CORBA), D-Bus, ? • Marshalling: JSON, XDR, (XML), ? • Discovery: ZeroConf, ?

More Related