1 / 15

Open End-to-End Tool Communication Framework for Target Development and Debug

This workshop discusses the need for a communication framework to support cross-development tools for target debugging, monitoring, analysis, and testing. The framework aims to provide a standardized and extensible set of services, allowing for efficient sharing and interoperability between tools. The workshop will cover the background, core design ideas, example use cases, and the current status of the prototype implementation.

hdang
Download Presentation

Open End-to-End Tool Communication Framework for Target Development and Debug

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 FrameworkECSI System Debug Workshop, Mar 10, 2008 Felix Burton (felix.burton@windriver.com)

  2. Agenda • Background • Out Line • Motivation • Core Design Ideas • Example use cases • Status

  3. Background • Cross development tools need communication link between host and target • Many tools, each typically using its own agent and communication method • Lots of overlap between these, e.g. how to communicate, retrieve/model target objects, manipulate target, etc

  4. Out Line • Define an open end to end tool to target communication mechanism for the purpose of development, debug, monitor, analysis and test • Specification • Transport channel supporting extensible set of “services” • Typically on top of a TCP/IP stream, but other transports supported as needed but the target • Services defining commands, progress, replies, events & semantics • Discovery of available servers and services • Prototype implementation • Eclipse plug-ins • C-based agent • Scope • Cross tools (i.e. host and target are different) benefits the most, but is applicable to native tools as well • Target agent, OCD/JTAG and simulator connections

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

  6. Motivation • Almost every cross development tool have their own infrastructure (agent, connection, protocol, setup, etc) • This leads to: • Poor user experience • Each tools has its own target configuration • Increased target intrusion (footprint, multiple agent interaction) • Inconsistent product availability matrix • No sharing between agents • Duplicated maintenance effort • New features have to be added in multiple places • New tools have to start from ground zero • Limited Eco-system

  7. Core Design Ideas • Service knows best how to represent the system – get information from there and data-drive layers above • If not possible, put the knowledge in the lowest possible layer and data drive the layers above • Use the same protocol end-to-end, but allow value-adding servers to intercept select services when needed and pass-through everything else • Services as building blocks that can be used by multiple clients (tools) for different environments (target agent, OCD, simulator) • Avoid tools specific agents • Bridge gap with environment specific services to setup/configure common services • Support high latency communication links

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

  9. Use Case: SimpleJtagDevice • Debug (run-control, breakpoint, memory register) • Possibly Others (flash programming, download, etc)

  10. Use Case: TestExceutionAgent • Process launch and kill • Standard I/O redirection • File system access

  11. Use Case: LinuxUserModeAgent • Debug (run-control, breakpoint, memory, register) • OS Awareness (process/thread list, CPU utilization, etc) • Process launch and kill • Standard I/O redirection • File system access • Monitoring (event-config, event-log)

  12. Prototype Status • Eclipse plug-ins • Remote file system access and simple top style monitoring integrated with RSE • Basic debugging integrated with Eclipse Core Debug plug-ins • DSF integration in the works • C-based agent • Services needed by Eclipse plug-ins • Simple UDP based discovery • Functional on Linux and VxWorks

  13. Specification Status • Transport Channel • Current Services • Run Control, Memory, Register, Breakpoint, Processes, Stack Trace, File System, System Monitoring • Review of current and specification of additional services in power.org and Eclipse

  14. Links • Prototype source repository • svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk • http://dev.eclipse.org/viewsvn/index.cgi/org.eclipse.tm.tcf/?root=DSDP_SVN • FAQ • http://wiki.eclipse.org/DSDP/TM/TCF_FAQ

  15. Questions/Comments?

More Related