Ritu Varma Roshanak Roshandel Manu Prasanna

Slides:



Advertisements
Similar presentations
WHAT IS AN OPERATING SYSTEM? An interface between users and hardware - an environment "architecture ” Allows convenient usage; hides the tedious stuff.
Advertisements

Chapter 2 – Software Processes
Programming Languages Marjan Sirjani 2 2. Language Design Issues Design to Run efficiently : early languages Easy to write correctly : new languages.
Systems Software.
1 Architectural Complexity: Opening the Black Box Methods for Exposing Internal Functionality of Complex Single and Multiple Processor Systems EECC-756.
Introduction CSCI 444/544 Operating Systems Fall 2008.
Towards Target-Level Testing and Debugging Tools For Embedded Software Harry Koehnemann, Arizona State University Dr. Timothy Lindquist, Arizona State.
Characteristics of Realtime and Embedded Systems Chapter 1 6/10/20151.
Feng-Xiang Huang A Low-Cost SOC Debug Platform Based on On-Chip Test Architectures.
1 HW/SW Partitioning Embedded Systems Design. 2 Hardware/Software Codesign “Exploration of the system design space formed by combinations of hardware.
Presenter : Shih-Tung Huang Tsung-Cheng Lin Kuan-Fu Kuo 2015/6/15 EICE team Model-Level Debugging of Embedded Real-Time Systems Wolfgang Haberl, Markus.
1 ITC242 – Introduction to Data Communications Week 12 Topic 18 Chapter 19 Network Management.
Behavioral Design Outline –Design Specification –Behavioral Design –Behavioral Specification –Hardware Description Languages –Behavioral Simulation –Behavioral.
Mahapatra-Texas A&M-Fall'001 cosynthesis Introduction to cosynthesis Rabi Mahapatra CPSC498.
OPERATING SYSTEM OVERVIEW
The Procedure Abstraction Part I: Basics Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412.
Active Messages: a Mechanism for Integrated Communication and Computation von Eicken et. al. Brian Kazian CS258 Spring 2008.
Chapter 13 Embedded Systems
Chapter 1 and 2 Computer System and Operating System Overview
Chapter 2: Impact of Machine Architectures What is the Relationship Between Programs, Programming Languages, and Computers.
November 18, 2004 Embedded System Design Flow Arkadeb Ghosal Alessandro Pinto Daniele Gasperini Alberto Sangiovanni-Vincentelli
Mehmet Can Vuran, Instructor University of Nebraska-Lincoln Acknowledgement: Overheads adapted from those provided by the authors of the textbook.
Copyright Arshi Khan1 System Programming Instructor Arshi Khan.
1.3 Executing Programs. How is Computer Code Transformed into an Executable? Interpreters Compilers Hybrid systems.
Operating System A program that controls the execution of application programs An interface between applications and hardware 1.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
The Procedure Abstraction Part I: Basics Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412.
1 COMPSCI 110 Operating Systems Who - Introductions How - Policies and Administrative Details Why - Objectives and Expectations What - Our Topic: Operating.
Introduction and Overview Questions answered in this lecture: What is an operating system? How have operating systems evolved? Why study operating systems?
LOGO OPERATING SYSTEM Dalia AL-Dabbagh
Operating System Review September 10, 2012Introduction to Computer Security ©2004 Matt Bishop Slide #1-1.
Parallel Programming Models Jihad El-Sana These slides are based on the book: Introduction to Parallel Computing, Blaise Barney, Lawrence Livermore National.
Operating System Support for Virtual Machines Samuel T. King, George W. Dunlap,Peter M.Chen Presented By, Rajesh 1 References [1] Virtual Machines: Supporting.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 16 System Architecture and Design II.
Eric Keller, Evan Green Princeton University PRESTO /22/08 Virtualizing the Data Plane Through Source Code Merging.
Real-Time Java on JOP Martin Schöberl. Real-Time Java on JOP2 Overview RTSJ – why not Simple RT profile Scheduler implementation User defined scheduling.
Hardware/Software Co-design Design of Hardware/Software Systems A Class Presentation for VLSI Course by : Akbar Sharifi Based on the work presented in.
Replay Compilation: Improving Debuggability of a Just-in Time Complier Presenter: Jun Tao.
Unit-1 Introduction Prepared by: Prof. Harish I Rathod
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Memory: Relocation.
Issues Autonomic operation (fault tolerance) Minimize interference to applications Hardware support for new operating systems Resource management (global.
25 April 2000 SEESCOASEESCOA STWW - Programma Evaluation of on-chip debugging techniques Deliverable D5.1 Michiel Ronsse.
Handling Mixed-Criticality in SoC- based Real-Time Embedded Systems Rodolfo Pellizzoni, Patrick Meredith, Min-Young Nam, Mu Sun, Marco Caccamo, Lui Sha.
BridgePoint Integration John Wolfe / Robert Day Accelerated Technology.
Introduction to Compilers. Related Area Programming languages Machine architecture Language theory Algorithms Data structures Operating systems Software.
Lecture 12: Reconfigurable Systems II October 20, 2004 ECE 697F Reconfigurable Computing Lecture 12 Reconfigurable Systems II: Exploring Programmable Systems.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 1 after designing to meet functional requirements, design the system.
L/O/G/O Input Output Chapter 4 CS.216 Computer Architecture and Organization.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi.
Program Development Cycle
Software Systems Division (TEC-SW) ASSERT process & toolchain Maxime Perrotin, ESA.
Parallel Computing Presented by Justin Reschke
1 Device Controller I/O units typically consist of A mechanical component: the device itself An electronic component: the device controller or adapter.
Agenda  Quick Review  Finish Introduction  Java Threads.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Operating Systems Overview: Using Hardware.
Embedded Real-Time Systems Processing interrupts Lecturer Department University.
Introduction to Computer Programming Concepts M. Uyguroğlu R. Uyguroğlu.
Some of the utilities associated with the development of programs. These program development tools allow users to write and construct programs that the.
1 Chapter 2: Operating-System Structures Services Interface provided to users & programmers –System calls (programmer access) –User level access to system.
Computer System Structures
DDC 2223 SYSTEM SOFTWARE DDC2223 SYSTEM SOFTWARE.
Advanced Computer Systems
CSCI/CMPE 3334 Systems Programming
Memory Management Tasks
Chapter 8: Memory management
Outline Module 1 and 2 dealt with processes, scheduling and synchronization Next two modules will deal with memory and storage Processes require data to.
CS 501: Software Engineering Fall 1999
An Introduction to Software Architecture
System Testing.
Presentation transcript:

Ritu Varma Roshanak Roshandel Manu Prasanna Toward Target Level Testing and Debugging for Embedded Software Koehnemann, Lindquist Ritu Varma Roshanak Roshandel Manu Prasanna

Introduction Identifies problems with the test case execution for embedded systems and propose solutions Testing is done to reveal errors whereas debugging is done to locate and correct the cause of error. Embedded systems are usually constrained by Concurrent design Real time constraints Distributed hardware architecture Device control dependencies Execution visibility and control severely restricted Why testing in Embedded Systems necessary?

Software Testing Testing for embedded systems has four stages: Module level Testing Integration Testing System Testing Hardware/Software Integration Testing Testing Methods which address the problem identified by the embedded systems Concurrency Real-time constraints Embedded Environment are of interest to this paper.

Testing Concurrent Systems Concurrency increases testing difficulties: Large set of execution sequences Subsequent Execution with the same input  different results Valid result as well as how the program arrived at that result Effect of the environment on testing and its results Acceptable output more important than correct output- Control over program execution Research: Static analysis: must examine a large set of state  not scalable Dynamic testing: passive watch of execution and replaying the execution in case of failure Runtime control of concurrent program Static analysis- determine all parallel actions and states that could block a task from executing. Run time control –regulates the sequence of events – assign each concurrent event in the test program a unique time value. test clock The event would execute if its time value > test clock

Non-intrusive Testing Control and testing techniques must not interfere with behavior of test program, timing issues Why not instrumentation? Insert probes to watch execution, link users object code with the rest of debugging system, Code interferes with execution behavior of the program Intrusive, voids execution of system Non-intrusive debugger for Ada Separate processor executes testing system and communicates with the target processor through specialized hardware Good start but don’t deal with the high level activities (process scheduling ,fault handling) only low level ( monitoring bus activity) Other Real time embedded tools: ROM monitors, Emulators, Bus Monitors

Impact of Underlying System Problem: dealing with abstraction Concurrency, IPC at high level and implementation at complier level (on run-time system) In Development phase abstraction is fine but in Testing phase? Complication Without sufficient control over program , there is no way to ensure that a test case is testing the code. Implementation difference in the host and the target environment. Compilers provide runtime system operation to bridge the gap between language construct and hardware.

Current State of Embedded Testing Concurrency causes Problems for testing and debugging H/S integration testing reveal problems such as: Incorrect handling of interrupts, Distributed Communication problems, Incorrect order of concurrent events, etc. Goal: reveal errors early as possible Problem: Target level testing tools don’t exist Two environments- Host : supports s/w development and tools which give user control over program execution (high level interface) Target: no support for software development and tools as minimum cost and space are the goals of the target. Target level testing occurs late in the development cycle and a small part is allocated for H/S integration testing. But,Target is the only location where errors can be revealed.

Current Solutions Hardware solutions Software solutions Attempts at gaining execution visibility and program control Bus monitors, ROM monitors and in-circuit emulator Minimal effectiveness for software development - low level machine data gathered only Mapping b/w low level events and entities in the program Software solutions Attempts to reduce the cost and time spent testing on target Determining factors in software testing: Level of Criticality of software module Test platform availability Test Classification Criteria's that assign program modules to test platforms Type of software, Hardware requirements, Test classification, Platform availability, Certification Requirements Current solution attempts to reduce the amount of target testing

Are these Techniques Effective? Expensive Low level of functionality Available too late Poor test selection criteria What about new architectures?

Expensive Custom validation facilities Little or no reuse Hardware is late and erroneous Software must be malleable

Testing Problems Host: high-level interface, language Target: machine instruction and physical address Translation: Tedious and error prone Migration to target Hardware’s errors have to be mitigated by software Late in the development process – costs

More Problems Test cases and scenarios depend on tools and platforms instead of theoretical test criteria Guidelines not being followed Hardware architecture changes rapidly Solution: Adding functionality to the underlying system to support debugging Hardware and run-time system Specialized Middleware for development and testing of embedded systems?

Model Debugging System Add functionality to target Ada Semantic Interface Spec toolkit Two communicating processor: Running the test program Running the debugger Target processor can: Execute and debug code only at a break point Run the debugger as a separate processor Provide a separate execution unit to execute the debugger Interface between internal and external debugger

Changes in HW Architecture Hardware partitioning of memory Computational facilities for debugger Hardware break points Dedicated bus

Memory Partitioning Software is infinitely malleable Any change requires several tests and retests Late changes is expensive Hardware should bound software SW is usually partitioned based on critical level instead of design factors  Hardware partitioning – protected address space for processes – restriction on access

Computational Facilities for Debugger External debugger vs. Internal debugger Internal debugger: located on target, executes from the target without interfering with the application Runs as a regular process on the processor Low-level or periodic high level process Architecture provides separate facility for debugger execution Target processor provides computational facility Computation Facility utilize architecture to dump some representation of instruction being executed Info must be parsed to create history. Implement state machines for messages sent by HW. Program the (stateful) functional unit within the processor. At boot time, the internal debugger code gets loaded and reside there. Messages are passed between internal and external debuggers.

Hardware Breakpoints Software and conditional breakpoints are not feasible for real time systems Breakpoint registers – data and instruction types State of a processor – all internal registers, pipeline and cache information must be saved when a break is encountered Conditional breakpoints – how are they dealt with?

Architecture Support for Abstractions Utilities must be built into architecture to provide basis for emulation, testing and program visibility A new level of abstraction is needed: Basic type (int, float) Process, memory management, semaphore, etc Hardware should be more aware of programming elements (software) Awareness of the programming environment is important

Dedicated Bus An interface between the processor and the external world Protocol used across the connection data rate, volume, direction, etc. Master-slave relationship Internal and external debuggers Bus and debugger Determination of active element within the processor Processor is active – sends messages to debugger Use special debugger portion of RTS – both debugger and RTS are active Perhaps a combination of the two

Runtime System Additions Goal: to minimize data and computational requirements of the internal debugger along with communication with the external debugger Standardize services that provide visibility into RTS abstractions Processes: concurrency is a common abstraction Need to support modifying task state, communication and synchronization, and process scheduling Interrupt management, Time management, Memory management, Exception Handling

Summary Embedded system testing techniques are ill-equipped Architectural and RTS changes have to be made Evaluate the changes and check feasibility Definition of Embedded Systems?? What is the border between HW/SW? Software techniques more suitable for less resource constraint system Need for classification of embedded system?? Need for specialized middleware for both design and testing of embedded systems Need for software development techniques although not discussed in the paper