Programming Tools for Embedded Multicore Jakob Engblom Technical Marketing Manager – Simics Wind River jakob.engblom@windriver.com | http://blogs.windriver.com/engblom/
Disclaimer These are my personal views on multicore and embedded Nothing in this presentation should be interpreted as indicating the plan (or lack of plan) for products and product features in Wind River products 2 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Embedded Multicore Some Advantages 3 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Software Dominates Development Software-dominated systems industry 10 12 Gates/chip 2x / 18months 10 10 SW/chip: 2 x / 10 months SW Productivity: 2x HW/ 5 years 10 8 10 6 10 4 Lines of Code Lines of Code 10 2 No. Gates No. Gates 1 1960 1970 1980 1990 2000 2010 2020 4 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Embedded Multicore Advantage When it comes to multicore, there are certain advantages to the embedded tools field – Embedded debug tools tend to be better at dealing with timing errors and doing debug of low-level code and – Operating-system – application interfaces have better debug support – Hardware-supported debug far beyond what desktops and servers can do – OS awareness in external debug tools Debuggers and tools are starting to catch up, including awareness of cores, systems, threads, domains, … – But it gets pretty complex pretty quickly… 5 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Multiple Context Debugging Host System Target System Multiple Targets Bay Networks • One Wind River Workbench instance Control • Target manager Processors • Multiple simultaneous connections including shared connections • Multiple OS types supported Bay Networks simultaneously • Multiple target processors Function supported simultaneously Processors Multiple Contexts • Core, process, or thread Bay Networks • Each context has a set of views: • Source • Stack • Registers Processes/Threads Target boards may be any mix of physical, logical, or • Qualify breakpoints on a process or specific thread virtual boards and any mix of uniprocessors and multicore • Stop the entire process or an running SMP or UP with Hypervisor, VxWorks, Wind River individual thread Linux and bare metal software. 6 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Hardware Trace On-Chip Trace – Added feature of hardware – Costs some chip area, some designers – and T T some customers – do not CPU L1$ consider it worth the cost Mem T T L2$ DDR RAM Intf T – Mostly for processors and CPU L1$ their buses T – Being added for other parts Peripherals PIC of the system, as they become more important Serial Timer Flash PCIe Eth Eth Performance counters P P P P common in complex devices today SoC – Interface bandwidth Board 1 limitations can put a limit on effectiveness 7 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Hardware Triggering Cross-triggering – Coordination across the chip B – Cause action in one place B CPU L1$ based on events occurring Mem elsewhere in the system B B L2$ DDR RAM Intf B Stop execution, start CPU L1$ tracing, stop tracing, B interrupt, ... Peripherals B PIC Requires logic on the chip Serial Timer Flash PCIe Basically, it is an on-chip Eth Eth programmable little supervisor processor SoC Conclusion: wise users Board 1 buy hardware with good debug support 8 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Trace, Trace, Trace There seems to be a growing consensus that trace is a key tool for debugging multicore large-scale software – Software stacks adding tracing as feature – Hardware support for extracting traces from software – Hardware actually tracing its own operation – Simulators hooks for getting data and key points out Only way to get an overview of the system Trace long runs… – Trace processing and analysis of data stream a key technology for the future, manual inspection does not suffice And drop back to a debugger around a problem http://jakob.engbloms.se/archives/1251 9 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Overhead vs Efficiency Common complaint about debug hooks in hardware and software: it costs too much power / performance / throughput / chip area / money / … Cary Millsap, Thinking Clearly about Performance 2, CACM Oct 2010 http://mags.acm.org/communications/201010#pg40 10 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Embedded Multicore Software Architecture and Hypervisors 11 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
More Than Just SMP “ Traditional ” Core Virtualization OS OS OS Hypervisor Single Core Core Core SMP AMP OS OS OS Multi-core Hypervisor Core 1 Core 2 Core 1 Core 2 Combinations of these primary configurations can be used to create more advanced configurations. OS: Could be VxWorks, Wind River Linux, or other executive or OS 12 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Example: Consolidation with Hypervisor App 1 App 3 Bare-metal application OS 1 OS 3 Single-core Single-core Multicore Unit 1 Unit 2 Unit 3 Single-core apps keep Single hardware = easier running as single-core, to manage, reduced App 1 App 3 Bare-metal avoiding the risk of manufacturing cost, more application breakage due to true units fits in the same OS 1 OS 3 space. Most of the concurrency multicore gain with very limited pain! Hypervisor provides Wind River Hypervisor isolation between guests, virtual boards Multicore Hardware keep running as-is Consolidated unit 13 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Example: Back to Basics WRE – Wind River Executive. Management, control Clear trend to provide sub-RTOS Network Network Network “executives” to provide very high stack stack stack performance for applications with no Control-Plane OS need for a full OS. Typically per-core. WRE WRE WRE Wind River Hypervisor Hypervisor can simplify the coordination between OS instances and provide a simpler programming Core Core Core Core Core interface for a WRE: Multicore Hardware 14 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Simics and Multicore Debug 15 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Wind River Simics: Full Simulation of Any Electronic System Aerospace and Defense Automotive Industrial and Medical Mobile and Consumer Network Equipment Virtual Platform Wind River Simics An adaptive virtual platform that enables customers to define, develop, and deploy electronics systems more efficiently 16 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
System-Level Features Checkpoint and restore Multicore, processor, board Real-world connections Repeatable fault injection on Scripting Mixed endianness, word any system component sizes, heterogeneity con0.wait-for-string "$“ con0.record-start con0.input "./ptest.elf 5\n" con0.wait-for-string "." $r = con0.record-stop if ($r == "fail.”) { echo ”test failed” } 17 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Full-System Insight 18 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Hypervisor is just any Software Stack App 1 App 3 Bare-metal application OS 1 OS 3 Wind River Hypervisor Multicore Hardware Simics Linux, Windows 32/64-bit PC 19 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Simics Debugging Features Synchronous stop Determinism and Reverse execution for entire system repeatability Unlimited and powerful Trace anything Insight into all devices breakpoints break –x 0x0000->0x1F00 break-io uart0 break-exception int13 20 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
http://blogs.windriver.com/engblom/2010/09/deterministic-but-unpredictable.html Repeatability and Reverse Debugging Repeat any run trivially – No need to rerun and hope for bug to reoccur Stop and go back in time – No rerunning program from start – Breakpoints and watchpoints backward in time – Investigate exactly what happened this time This control and reliable repeatability is very powerful for parallel code. Discover Bug Discover Bug Rerun, bug doesn’t show up Rerun, bug doesn’t show up Reverse execute and find source of bug Rerun, different bug Rerun, initial bug occurs On hardware, only some runs reproduce an error. On virtual hardware, debugging is much easier. 21 Wind River - Programming Embedded Multicore - ICES Seminar 2010-11-24
Recommend
More recommend
