DSP for Embedded and Real Time Systems Expert Guide 1st Edition Robert Oshana

Visit https://ebookultra.com to download the full version and
explore more ebooks
DSP for Embedded and Real Time Systems Expert
Guide 1st Edition Robert Oshana
_____ Click the link below to download _____
https://ebookultra.com/download/dsp-for-embedded-and-
real-time-systems-expert-guide-1st-edition-robert-
oshana/
Explore and download more ebooks at ebookultra.com

Here are some suggested products you might be interested in.
Click the link to download
Real Time Concepts for Embedded Systems 1st Edition Qing
Li
https://ebookultra.com/download/real-time-concepts-for-embedded-
systems-1st-edition-qing-li/
Real time embedded components and systems with Linux and
RTOS 2nd Revised ed Edition Pratt
https://ebookultra.com/download/real-time-embedded-components-and-
systems-with-linux-and-rtos-2nd-revised-ed-edition-pratt/
Real Time Systems and Programming Languages Ada Real Time
Java and C Real Time POSIX 4th Edition Alan Burns
https://ebookultra.com/download/real-time-systems-and-programming-
languages-ada-real-time-java-and-c-real-time-posix-4th-edition-alan-
burns/
Real World Multicore Embedded Systems 1st Edition Bryon
Moyer
https://ebookultra.com/download/real-world-multicore-embedded-
systems-1st-edition-bryon-moyer/

Real time embedded multithreading using ThreadX and MIPS
Edward L. Lamie
https://ebookultra.com/download/real-time-embedded-multithreading-
using-threadx-and-mips-edward-l-lamie/
Real Time Systems Design and Analysis 3rd Edition Phillip
A. Laplante
https://ebookultra.com/download/real-time-systems-design-and-
analysis-3rd-edition-phillip-a-laplante/
Embedded Systems Handbook Second Edition Embedded Systems
Design and Verification Richard Zurawski
https://ebookultra.com/download/embedded-systems-handbook-second-
edition-embedded-systems-design-and-verification-richard-zurawski/
Fuzzy Logic for Embedded Systems Applications First
Edition Embedded Technology Ahmad Ibrahim
https://ebookultra.com/download/fuzzy-logic-for-embedded-systems-
applications-first-edition-embedded-technology-ahmad-ibrahim/
Multi Core Embedded Systems Embedded Multi Core Systems
1st Edition Georgios Kornaros
https://ebookultra.com/download/multi-core-embedded-systems-embedded-
multi-core-systems-1st-edition-georgios-kornaros/

DSP for Embedded and Real Time Systems Expert Guide
1st Edition Robert Oshana Digital Instant Download
Author(s): Robert Oshana
ISBN(s): 9780123865359, 0123865352
Edition: 1
File Details: PDF, 21.18 MB
Year: 2012
Language: english

DSP for Embedded
and Real-Time Systems
Expert Guide
Robert Oshana
AMSTERDAM • BOSTON • HEIDELBERG • LONDON • NEW YORK • OXFORD
PARIS • SAN DIEGO • SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO
Newnes is an imprint of Elsevier

Newnes is an imprint of Elsevier
The Boulevard, Langford Lane, Kidlington, Oxford, OX5 1GB
225 Wyman Street, Waltham, MA 02451, USA
First published 2012
Copyright Ó 2012 Elsevier Inc. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording, or any information storage and retrieval system,
without permission in writing from the publisher. Details on how to seek permission, further information
about the Publisher’s permissions policies and our arrangement with organizations such as the
Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website:
www.elsevier.com/permissions
This book and the individual contributions contained in it are protected under copyright by the Publisher
(other than as may be noted herein).
Notices
Knowledge and best practice in this field are constantly changing. As new research and experience
broaden our understanding, changes in research methods, professional practices, or medical treatment
may become necessary.
Practitioners and researchers must always rely on their own experience and knowledge in evaluating
and using any information, methods, compounds, or experiments described herein. In using such
information or methods they should be mindful of their own safety and the safety of others, including
parties for whom they have a professional responsibility.
To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume
any liability for any injury and/or damage to persons or property as a matter of products liability,
negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas
contained in the material herein.
British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library
Library of Congress Number: 2012938003
ISBN: 978-0-12-386535-9
For information on all Newnes publications visit our
website at store.elsevier.com
Printed and bound in the United States
12 13 14 15 10 9 8 7 6 5 4 3 2 1

Author Biographies
Kia Amiri
kiaa@alumni.rice.edu
Kia Amiri received his M.S. and Ph.D. degrees in Electrical and Computer Engineering at
Rice University, Houston, TX, in 2007 and 2010, where he has been a member of the Center
for Multimedia Communication (CMC) lab. His research focus is in the area of physical layer
design and hardware architecture for wireless communication. He is the co-inventor of 7
(pending) patents in this area. During the summer and fall of 2007, Kia worked on developing
and implementing MIMO algorithms as part of the Advanced Systems Technology Group in
Xilinx, San Jose, CA.
Arokiasamy I
arokia@freescale.com
Arokiasamy I is presently working as Engineering Manager for LTE Layer-1 with Freescale,
with over 25 years of Software Architecture and Development experience covering, Industrial
Automation Systems for Hydro/Power Stations, Realtime Operating systems(RTOS),
compiler backend for MIPS platform as part of CodeWarrior tool, WiMAX PHY for Freescale
MSC8144 platform etc. Arokiasamy I received his Bachelors of Engineering in Electronics
and Communication Engineering from Indian Institute Of Science, Bangalore, India.
Dr Michael C. Brogioli
Dr Michael C. Brogioli is currently a computer engineering and software consultant in
Austin, TX, USA, as well as an adjunct professor of computer engineering at Rice University.
In addition, he also serves on the advisory boards of a number of early stage technology
companies in the Austin and New York areas. Prior to this, he was a Senior Member Technical
Staff and Lead Architect of compilers and build tools in their Technology Solutions
Organization. During his time at Freescale, he also worked in conjunction with the hardware
development teams on next generation DSP platforms. Prior to his time at Freescale,
Dr Brogioli worked with Texas Instruments Advanced Architecture and Chip Technologies
group in Stafford, TX, USA and Intel’s Microprocessor Research Labs in Santa Clara, CA,
xv

USA. He has authored over a dozen peer reviewed publications as well as co-authored three
books in the embedded computing and signal processing space. He holds a Ph.D. and M.S. in
Computer Engineering from Rice University in Houston, TX, USA, as well as a B.S. in
Electrical Engineering from Rensselaer Polytechnic Institute in Troy, NY, USA.
Cristian Caciuloiu
Cristian C
aciuloiu is a Software Engineer in Freescale Semiconductor Romania. He received
BSc/MSc in Computer Science in 1999 from the University POLITEHNICA of Bucharest,
Romania. Cristian joined Freescale (Motorola’s Semiconductor Products Sector at that time)
in 2000 and worked in various embedded software projects for several DSP and PowerPC
platforms. From 2005 onwards, he held senior technical leadership and managerial positions,
the most recent being the Software Architect for the VoIP Media Gateway Software Products
from the Signal Processing Software and Systems team in Freescale Romania.
Joseph R. Cavallaro
cavallar@rice.edu
Joseph R. Cavallaro is a Professor in the Electrical and Computer Engineering Department
and Director of the Center for Multimedia Communication at Rice University, Houston,
Texas. He is also a Docent in the Centre for Wireless Communications at the University of
Oulu in Finland. He received a B.S. from the University of Pennsylvania (1981), an M.S. from
Princeton University (1982) and a Ph.D. from Cornell University (1988), all in Electrical
Engineering. He has been engaged in research since 1981 after joining ATT Bell
Laboratories as a Member of Technical Staff and his research interests include VLSI signal
processing with applications to wireless communication systems.
Stephen Dew
stephendew@yahoo.com
Stephen Dew is currently a Compiler Engineer at Freescale Semiconductor. Previously, he
held positions in Applications Engineering at Freescale and StarCore, LLC. He received
a Masters of Science in Electrical and Computer Engineering from the Georgia Institute of
Technology in 2001.
Dr Chris Dick
chris.dick@xilinx.com
Dr Chris Dick is the DSP Chief Scientist at Xilinx and the engineering manager for the Xilinx
Wireless Systems Engineering team. Chris has worked with signal processing technology for
two decades and his work has spanned the commercial, military and academic sectors. Prior
to joining Xilinx in 1997 he was a professor at La Trobe University, Melbourne Australia for
xvi Author Biographies

13 years and managed a DSP Consultancy called Signal Processing Solutions. Chris’ work
and research interests are in the areas of fast algorithms for signal processing, digital
communication, MIMO, OFDM, software defined radios, VLSI architectures for DSP,
adaptive signal processing, synchronization, hardware architectures for real-time signal
processing, and the use of Field Programmable Arrays (FPGAs) for custom computing
machines and real-time signal processing. He holds a bachelor’s and Ph.D. degrees in the
areas of computer science and electronic engineering.
Melissa Duarte
megduarte@gmail.com
Melissa Duarte was born in Cucuta, Colombia. She received the B.S. degree in Electrical
Engineering from the Pontificia Universidad Javeriana, Bogota, Colombia, in 2005, and the
M.S and Ph.D. degrees in Electrical and Computer Engineering from Rice University,
Houston, TX, in 2007 and 2012 respectively. Her research is focused on the design and
implementation of architectures for next-generation wireless communications, full-duplex
systems, feedback based Multiple Input Multiple Output (MIMO) antenna systems, and the
development of a Wireless Open Access Research Platform (WARP) for implementation and
evaluation of algorithms for wireless communications. Melissa was a recipient of a Xilinx
Fellowship at Rice University 2006e2007, a TI Fellowship at Rice University 2007e2008,
and a Roberto Rocca Fellowship 2009e2012.
Michelle Fleischer
Michelle.fleischer@freescale.com
Michelle Fleischer grew up in Southeastern Michigan and majored in electrical engineering at
Michigan Technological University in Houghton Michigan where she earned her BSEE
(1992) and MSEE (1995) degrees. In 1992 she started working on a research grant for the
Keweenaw research center performing acoustic modeling experiments for NASA and active
noise control experiments for the US Army Tank Command (TACOM). In 1995 she started
work at Texas Instruments in Dallas Texas. In 2006 she joined Freescale in Chicago Illinois as
a Field Applications Engineer, supporting key accounts such as Motorola and RIM for the
wireless group and key networking accounts for the Networking and Multimedia group.
Ms. Fleischer has authored numerous application notes, design documents, software
specifications, and software designs throughout her career.
Umang Garg
Umang.Garg@gmail.com
Umang Garg is currently an Engineering Manager for LTE Layer 2 software development in
Networking and Multimedia Solutions Group at Freescale He has 10 years of experience in
Author Biographies xvii

software development for DSP and Communication Processors. His current work interest is
in the area of leveraging multi-core architectures for LTE software development while
previous work interests have included Audio, Speech, Image Processing and VoIP
technologies. Umang has a B.E.(Honors) in Computer Systems Engineering from University
of Sussex, U.K. and a Master of Science in Advanced Computing from Imperial College,
U.K.
Vatsal Gaur
vatsal@freescale.com
Vatsal Gaur is a DSP Software Engineer with over 7 years of experience in wireless baseband
domain. He has worked on Layer-1 software development for various technologies such as
GSM, GPRS, EDGE, WiMAX and LTE. His current work includes algorithm development
and system design to enable various features of LTE eNodeB. Before joining Freescale, Vatsal
had worked as a technical lead at Hughes software systems (now Aricent Technologies).
Vatsal received his Bachelors of Engineering in Electrical and Electronics from Birla Institute
of Technology, India.
Mircea Ionita
Mircea.Ionita@freescale.com
Mircea Ionit
‚
a is the manager of the Networking and Signal Processing Software and Systems
Team within Freescale Semiconductor Romania since 2007. Mircea joined Freescale/
Motorola in 2001 where he held senior technical and managerial positions until 2007 when he
was appointed to lead the Networking and Signal Processing Software and Systems Team.
Mircea received his Bachelors of Science, Masters of Science and Doctorate degrees in
Electronic Engineering from the University POLITEHNICA of Bucharest, Romania.
Nitin Jain
nitin19@gmail.com
Nitin Jain received his B.E. degree specializing in Electronics and Communications from
Visvesvaraya Technological University, Belgaum, India, in 2003. From 2004 to 2007, he
worked with MindTree’s Research group and was responsible for developing Speech and
Audio algorithms, and integrating them within different Bluetooth and mobile products. Nitin
joined Freescale in 2008 as a Senior Engineer in the Networking group and has been involved
in WiMAX and LTE physical layer development for Macro and Femto product segments on
Freescale’s baseband devices. As a Lead Engineer, his recent assignment is to perform LTE
Femto eNB integration and verification with commercial-grade higher layers and user
equipments. His work has appeared in renowned magazines and conference in Embedded and
DSP domain.
xviii Author Biographies

Michael Kardonik
michael.kardonik@gmail.com
Michael Kardonik’s career begun at Motorola Semiconductor Israel at 1999 where he worked
on board support packages for PowerQUICC II processors. Later, Michael led engineering
team that designed and implemented SmartDSP OS for Motorola’s StarCore DSP. After his
relocation to Austin, US, Michael served as DSP Applications Engineer, Tools engineer
responsible for advanced debugging technologies. Today, Michael is part of Architecture
team at Freescale Semiconductor working on current and next generation of QorIQ. Michael
received his Bachelors of Arts in Economics and Computer Science degree from Ben Gurion
University of Negev Israel and Masters of Science in Software Engineering degree from the
University of Texas at Austin.
Robert Krutsch
Robert Krutsch is a DSP Software Engineer at Freescale Semiconductor with a primary focus
in medical and baseband applications. He received a BSc/MSc degree specializing in
automatics and computer science from the Polytechnic University of Timisoara; a BSc/Msc
degree from the Automation Institute at the University of Bremen.
Tai Ly
tai.ly@ni.com
Tai Ly obtained his PhD in High Level Synthesis in 1993 from the University of Alberta,
Canada, and has since worked in Research and Development in a number of companies
including Synopsys, 0-In Design Automation, Mentor Graphics and Synfora Inc, He holds
14 Patents in the fields of High Level Synthesis, Assertion Verification, Formal Verification,
and Clock Domain Crossing Verification. He is currently a Principal Engineer in National
Instrument.
Akshitij Malik
akshitij.malik@freescale.com
Akshitij Malik is a Software Engineer with over 11 years of experience in the Telecom/
Wireless industry. Akshitij worked as a Senior Principal Engineer at Hughes Systique and
Hughes Software Systems LLC before moving on to his current role as a Lead Software
Engineer at Freescale Semiconductor. Past works include development of L3 software for
WCDMA RNCs, L2 software for WiMAX Base-Stations amongst other topics. Akshitij
received his Bachelors of Engineering in Computer Engineering from the University of Pune,
India.
Author Biographies xix

Robert Oshana
robert.oshana@freescale.com
Robert Oshana 30 years of experience in the software industry, primarily focused on
embedded and real-time systems for the defense and semiconductor industries. He has
BSEE, MSEE, MSCS, and MBA degrees and is a Senior Member of IEEE. Rob is
a member of several Advisory Boards including the Embedded Systems group, where he is
also an international speaker. He has over 100 presentations and publications in various
technology fields and has written several books on Embedded software technology. Rob is
an adjunct professor at Southern Methodist University where he teaches graduate software
engineering courses. He is a Distinguished Member of Technical Staff and Director of
Global Software RD for Networking and Multimedia at Freescale Semiconductor.
Raghu Rao
raghu.rao@xilinx.com
Raghu Mysore Rao is a Principal Engineer and System Architect with the Communications
Signal Processing Group, Communications Business Unit, Xilinx Inc. He and his team are
currently working on signal processing and digital communication algorithms for FPGAs. He
is an IEEE senior member. He has a Ph.D. in wireless communications from University of
California, Los Angeles. In the past, he has worked at Texas instruments India, Exemplar
Logic Inc. and Mentor Graphics Inc. His interests are in digital communication and signal
processing algorithms and architectures for their efficient implementation on FPGAs.
Ashutosh Sabharwal
ashu@rice.edu
Ashutosh Sabharwal is a Professor of Electrical and Computer Engineering at Rice
University. His research interests are in information theory, network protocols and high-
performance wireless platforms. He is the founder of Rice Wireless Open-Access Research
Platform (http://warp.rice.edu), which is in use at 100+ organizations worldwide.
Yang Sun
ysunrice@gmail.com
Yang Sun received the B.S. degree in Testing Technology and Instrumentation in 2000,
and the M.S. degree in Instrument Science and Technology in 2003, both from Zhejiang
University, Hangzhou, China. He received the Ph.D. degree in electrical and computer
engineering from Rice University, Houston, Texas, in 2010. He is currently a senior
engineer in Qualcomm Inc. His research interests include parallel algorithms and VLSI
architectures for wireless communication systems, digital signal processing systems,
multimedia systems, and general purpose computing systems.
xx Author Biographies

Adrian Susan
Adrian.Susan@freescale.com
Adrian Susan is the technical manager of L1 DSP Software Components Team in Freescale
Romania located in Bucharest. Adrian is a Software Engineer, having graduated from the
“Politehnica” University of Timioara with a B.Sc. in Computer Science. Adrian worked
for Freescale Romania since 2004 where he was a member of the team in charge with
the development of Freescale VoIP multimedia gateway.
Andrew Temple
temple.andrewr@gmail.com
Andrew Temple is an application engineer with over 10 years of experience in the
semiconductor industry. Andrew worked as an applications engineer at Texas Instrument and
StarCore LLC before moving on to his current role as a DSP Applications Engineer at
Freescale Semiconductor. Past works include application notes on power consumption, bus
interfacing, deadlock arbitration, Serial Rapid IO usage, Ethernet performance and
connectivity, amongst other topics. Andrew received his Bachelors of Science in Computer
Engineering and Masters of Science in Software Engineering degrees from the University of
Texas at Austin.
Guohui Wang
gw2@rice.edu
Guohui Wang received his B.S. degree in EE from Peking University, Beijing, China,
and M.S. degree in CS from Institute of Computing Technology, Chinese Academy of
Sciences, Beijing, China. Since 2008, he has been pursuing a Ph.D. degree in Department
of Electrical and Computer Engineering, Rice University, Houston, Texas. His
research interests include mobile computing, VLSI signal processing for wireless
communication systems and parallel signal processing on GPGPU.
Bei Yin
by2@rice.edu
Bei Yin received his B.S. degree in Electrical Engineering from Beijing University of
Technology, Beijing, China, in 2002, and his M.S. degree in Electrical Engineering from
Royal Institute of Technology, Stockholm, Sweden, in 2005. From 2005 to 2008, he worked at
ARCA Technology Co. as an ASIC/SoC design engineer. He is currently a Ph.D. student in
the Department of Electrical and Computer Engineering at Rice University, Houston, Texas.
His research interests include VLSI signal processing and wireless communications.
Author Biographies xxi

DSP in Embedded Systems: A Roadmap
DSP Software development for embedded systems follows the standard hardware/software
co-design model for embedded systems as shown in Figure 1.
The development process can be divided into six phases;
• Phase 1; Product Specification
• Phase 2; Algorithmic Modeling
• Phase 3; HW/SW Partitioning
• Phase 4; Iteration and Selection
• Phase 5; Real-Time SW Design
• Phase 6; HW/SW Integration
This book will cover each of these important phases of DSP Software Development.
xxiii

Phase 1 e Product Specification
Phase 1 is an overview of embedded and real time systems and introduces the reader to the
unique aspects of this type of software development.
There are several embedded systems challenges that we need to comprehend before we can
have a discussion on digital signal processing. These include a significant degree of
complexity of environments as well as interactions between systems, an increasing
percentage of software within embedded components, the need for software code reuse and
rapid reengineering, fast innovation and release cycles driven by shifting market demands,
numerous real time demands and the need for requirements management, and the increasing
focus on quality and process maturity. Chapters 1 and 2 (page 1 and 15) will provide an
overview of DSP as well as embedded systems in general, and review the key differences that
exist in embedded systems in general and DSP specifically.
HW design path activities
SW design path activities
Phase 5; Real-Time SW Design
Phase 6; HW/SW Integration
Phase
1;
Product
Specification
Phase
4;
Iteration
and
Selection
Phase
3;
HW/SW
Partitioning
Phase
2;
Algorithmic
modeling
Product Release
Phase 1;
Chapter 1; Introduction to Digital Signal Processing
Chapter 2; Overview of Embedded and Real Time Systems
Phase 3;
Chapter 4 Programmable DSP Architectures
Chapter 5; DSP Hardware components and FPGA
Chapter 6; The Hardware/Software Continuum for DSP
Phase 2;
Chapter 7 Overview of Digital Signal Processing Algorithms
Phase 4;
Chapter 3 Overview of Embedded Systems Lifecycle
Development Using DSP
Phase 5;
Chapter 8; High-Level Design Tools for
Complex DSP Applications
Chapter 9; Benchmarking and Profiling DSP
Systems
Chapter 10,11,12,13; Optimizing DSP SW for
performance, memory, and power
Chapter 14; Real-Time Operating Systems
Using DSP
Chapter 15; Managing the DSP Software
Development Effort
Chapter 17; Debugging DSP Systems
Phase 6;
Chapter 16; Multicore software
development for DSP
Case study 1; DSP for LTE
basestations
Case study 2; DSP for VoIP
Case study 3; DSP for Medical
Case Study 4; Performance Eng
Case Study 5; Specifying Embedded
DSP for SW defined Radio
Identify the stimuli for
processing and required
respective to the stimuli
Identify timing constraints
for each stimuli and
response
Design a scheduling
solution ensuring processes
are scheduled in time to
meet their deadlines
Design algorithms to
process stimulus and
reponse, meeting the
given timing requirements
Aggregate stimulus and
response processing into
concurrent processes
Figure 1:
DSP Software Development Following the Embedded HW/SW Co-design Model
xxiv DSP in Embedded Systems: A Roadmap

Phase 2 e Algorithmic Modeling
Phase 2 focuses on the understanding of the fundamental algorithmic nature of signal
processing. Digital signal processing is about the representation of discrete time signals using
a sequence of numbers or symbols and the subsequent processing of these signals. DSP
includes areas like audio and speech signal processing, sonar and radar signal processing,
statistical signal processing, digital image processing, communications, system control,
biomedical signal processing, and many other areas. DSP algorithms are used to process these
digital signals. There are a set of fundamental algorithms used in signal processing such as
fourier transforms, digital filters, convolution, and correlations. Chapter 7 (page 113) will
introduce and explain some of the most important and fundamental DSP algorithms in order
to set the base for many of the topics later in the book.
Phase 3 e Hardware/Software Partitioning
An important phase of any embedded development project is the partitioning of the system
into hardware and software components.
Much of DSP is programmable. Programmable architectures for digital signal processing take
a number of forms, each having their own tradeoffs in terms of cost, power consumption,
performance and flexibility. At one end of the spectrum, digital signal processing system
designers can achieve extremely high levels of efficiency and performance via the use of
proprietary assembly language implementations of their application. At the other end of the
spectrum, system developers can implement digital signal processing software stacks using
ordinary ANSI C or C++ or other domain specific languages, executing the resulting
algorithm on commercial desktop computers. Chapter 4 (page 63) details tradeoffs in
implementations at varying points on a continuum, with one end being utmost digital signal
processing performance and the other end of the continuum being flexibility and portability of
a software implementation. Tradeoffs for each solution are detailed along the way, with the
goal of guiding the digital signal processing system developer to the solution that meets their
particular use case needs.
DSP is also implemented using Field Programmable Gate Arrays (FPGA) . As an example of
this, in chapter 5 (page 75), we discuss the architectural challenges associated with spatial
multiplexing and diversity gain schemes and introduce FPGA architectures and report
experimental results for the FPGA realization of these systems. Chapter 5 (page 75) will
introduce a flexible architecture and implementation of a spatial multiplexing MIMO
detector, Flex-sphere, and its FPGA implementation. We also present a hardware architecture
for beamforming in a WiMAX system as a way to enhance the diversity and performance in
the next-generation wireless systems.
DSP in Embedded Systems: A Roadmap xxv

Hardware platforms for digital signal processing systems come in varying designs, each with
inherent programmability, power and performance tradeoffs. What is suitable for one system
designer may not be suitable for another. Chapter 6 (page 103) details various digital signal
processing platform designs as they pertain to system configurability and programmability.
At one end of the spectrum, application specific integrated circuits (ASICs) are detailed as
a high performance, low configurability solution. At the other end of the spectrum, general
purpose embedded microprocessors with SIMD style extensions are presented as a highly
configurable solution with robust software programmability support. Various design points
are presented throughout such as reconfigurable field programmable gate array (FPGA) based
solutions, and high performance application specific integrated processors (ASIP) with
varying degrees of software programmability. Chapter 6 (page 103) will present tradeoffs for
each system design, as a way of guiding the system developer in choosing the right digital
signal processing hardware platform and component for their immediate and future system
deployment needs.
Phase 4 e Iteration and Selection
Another key concern for DSP developers is managing the embedded lifecycle. This starts
with selection of the solution space for the DSP problem you are trying to solve, and defining
an embedded system that meets performance as well as cost, time to market and other
important system constraints. As mentioned earlier, an embedded system is a specialized
computer system that is integrated as part of a larger system. Many embedded systems are
implemented using digital signal processors. The DSP will interface with the other embedded
components to perform a specific function. The specific embedded application will determine
the specific DSP to be used. For example, if the embedded application is one that performed
video processing, the system designer may choose a DSP that is customized to perform media
processing including video and audio processing. Chapter 3 (page 29) will discuss the
embedded lifecycle and the various options for DSP and how to determine overall system
performance and capability.
Phase 5 e Real-Time Software Design
Real-time software design follows the five step process outlines in Figure 1;
1. Identify the stimuli for processing and required responses to the stimuli
2. Identify timing constraints for each stimuli and response
3. Aggregate stimulus and response processing into concurrent processes
4. Design algorithms to process stimulus and response, meeting the given timing
requirements
xxvi DSP in Embedded Systems: A Roadmap

5. Design a scheduling solution ensuring processes are scheduled in time to meet their
deadlines
We will discuss details of this process in this phase of the process.
1. Part 1; Identify the stimuli for processing and required responses to the stimuli
Firstly, we need to identify the system stimuli for signal processing as well as the response
to these stimuli. This must be done regardless of whether we are using hardware or
software.
We introduce a simple practical but very powerful specification technique in Case Study 2:
DSP for medical devices (page 493) to give the developer a set of guidelines for this level of
specification. The focus is on DSP development process focusing on specifying the behavior
of embedded systems using DSP. The criticality of correct, complete, testable requirements is
a fundamental tenet in software engineering. Both functional and financial success is affected
by the quality of requirements. This starts with good requirements. Requirements may range
from a high-level abstract statement of a service or of a system constraint to a detailed
mathematical functional specification. Requirements are needed to Specify external system
behavior, specify implementation constraints, serve as reference tool for maintenance, record
forethought about the life cycle of the system i.e. predict changes, and to characterize
responses to unexpected events. This case study introduces a rigorous behavioral
specification technique that can greatly reduce risk by exposing ambiguities in requirements
and making explicit otherwise tacit information. Such an external, or “black box”
specification can be developed from behavioral requirements in a systematic manner through
the process of sequence enumeration. This process results in an arguably complete,
consistent, and traceable specification of external system behavior. Sequence abstraction
provides a powerful means to manage and focus the enumeration process. A simple cell
phone is used to reinforce these concepts.
There are some more advanced techniques that can be used for both hardware and
software. Chapter 8 (page 133) focuses on a system level methodology of designing
and synthesizing real-time digital signal processing systems. This is another challenge
in the area of DSP development. Current hardware designs and implementations for
DSP systems have a huge time gap between the development of algorithms for new
DSP applications and their hardware implementation. The high level design and
synthesis tools create application-special DSP accelerators from high abstraction-level
for complex DSP processing hardware, which greatly reduces the design cycle while
still maintaining area and power efficiency. This chapter presents two high level
design methodologies, 1) C-to-RTL high level synthesis (HLS) for ASIC/FPGA
implementation of the DSP systems, and 2) System Generator for FPGA
DSP in Embedded Systems: A Roadmap xxvii

implementation of the DSP systems. In the case studies, we will present three complex
DSP accelerator designs using high level design tools: 1) Low-density parity-check
(LDPC) decoder accelerator design using PICO C, 2) Matrix multiplication accelerator
design using Catapult C, and 3) QR decomposition accelerator design using System
Generator.
2. Identify timing constraints for each stimuli and response
A key part of optimizing DSP software is being able to properly profile and benchmark a DSP
kernel and a DSP system. With a solid benchmark and profiling of a DSP kernel, both best
case and in system performance can be assessed. Proper profiling and benchmarking can
often be an art form. It is often the case that an algorithm is tested in nearly ideal conditions,
and that performance is then used within a performance budget. Truly understanding the
performance of an algorithm requires being able to model system effects along with
understanding an algorithms best-case performance. System effects can include changes such
as a running operating system, executing out of memories with different latencies, cache
overhead, and managing coherency with memory. All of these effects require a carefully
crafted benchmark, which can model these behaviors in a standalone fashion. If modeled
correctly the standalone benchmark can very closely replicate a DSP kernel’s execution, as it
would behave in a running system. Chapter 9 (page 157) discusses how to perform this kind
of benchmark.
3. Aggregate stimulus and response processing into concurrent processes
Once we understand what goes in and what comes out, we need to design and development
the DSP software solution. Software development using DSPs is subject to many of the same
constraints and development challenges that other types of software development face. These
include a shrinking time to market, tedious and repetitive algorithm integration cycles, time
intensive debug cycles for real-time applications, integration of multiple differentiated tasks
running on a single DSP, as well as other real-time processing demands. Up to 80% of the
development effort is involved in analysis, design, implementation, and integration of the
software components of a DSP system.
Chapter 15 (page 335), will cover several topics related to managing the DSP software
development effort. The first section of this chapter will discuss DSP system engineering
and problem framing issues that relate to DSP and real-time software development. High
level design tools are then discussed in the context of DSP application development.
Integrated development environments and prototyping environments are also discussed.
Specific challenges to the DSP application developer such as code tuning, profiling
and optimization are reviewed. At the end of the chapter, there are several white papers
xxviii DSP in Embedded Systems: A Roadmap

that discuss related topics to DSP and real-time system development, integration, and
analysis.
4. Design algorithms to process stimulus and response, meeting the given timing
requirements
Writing DSP software to meet real-time constraints is challenging, so we dedicate several
chapters to this area. Historically, DSP software was written in assembly languages. However,
with the advent of the modern compiler, writing efficient DSP code using the C language is
standard. However, since most DSPs have features that cannot be expressed fully in the C
language, various alternatives exist to augment the standard languages of C and C++ such as
extensions, higher-level languages and auto-vectorizing compilers. Chapter 10 (page 169)
explains the high-level languages and programming models available for writing DSP
software.
Optimization is the process of transforming a piece of code to make more efficient (either
in terms of time, space, or power) without changing its output or side-effects. The only
difference visible to the code’s user should be that it runs faster and/or consumes less
memory or power. Optimization is really a misnomer in the sense that the name implies
one is trying to find an “optimal” solutiond in reality, optimization aims to improve, not
perfect, the result.
DSP is all about optimization, and this includes optimization for performance, memory, and
power.
Chapter 11 (page 181) focuses on code optimization for performance. This is a critical step in
the development process as it directly impacts the ability of the system to do it’s intended job.
Code that executes faster means more channels, more work performed and competitive
advantage. This chapter is intended to help programmers write the most efficient code
possible. It starts with an introduction to using the tool chain, covers the importance of
knowing the Digital Signal Processor architecture before optimization, then moves on to
cover wide range of optimization techniques. Techniques are presented which are valid on all
programmable DSP architectures e C-language optimization techniques and general loop
transformations. Real-world examples are presented throughout. To illustrate the concepts,
DSPs from both Texas Instruments and Freescale are discussed.
Chapter 12 (page 217) focuses on memory optimization. Optimizing application code around
memory system performance can often yield impressive gains in both executable code size, as
well as runtime performance. This chapter illustrates methods that applications developers
can utilize to improve both the static size of their executables in the presence of all too often
resource constrained embedded systems. In addition, the chapter illustrates code optimization
DSP in Embedded Systems: A Roadmap xxix

techniques that can either provide explicit performance gains of the application code, or
implicit gains by improving the software build tools’ ability to optimize code at compilation,
assembly and link time.
Chapter 13 (page 241) focuses on optimization for power. This chapter is intended to be
a resource for programmers needing to optimize a DSP for power consumption using strictly
software. In order to provide the most comprehensive source for DSP software power
optimization, this chapter provides a basic introduction into power consumption background,
measurement techniques, and then goes into the details of power optimization. The chapter
will focus on three main areas: algorithmic optimization, software controlled hardware power
optimization (low power modes, clock control, and voltage control), and data flow
optimization with a discussion into the functionality and power considerations when using
fast SRAM type memories (common for cache) and DDR SDRAM.
5. Design a scheduling solution ensuring processes are scheduled in time
to meet their deadlines
DSP applications are very demanding in terms of data rates and real-time computational
requirements. These applications also can have very diverse real-time requirements. The
DSP designer must understand the real-time design issues or order to obtain maximum
performance. In addition, the resulting complexity requires the use of a real-time
operating system. Key characteristics of a DSP RTOS include, extremely fast context
switch times, very low interrupt latency times, optimized scheduler and interrupt handler,
task, event, message, circular queue, and timer management, resource and semaphore
processing, fixed block and memory management, and full pre-emption and ability to
also have cooperative and time slice scheduling. Chapter 14 (page 291) will cover DSP
RTOS in depth in order to be able to effectively utilize a DSP RTOS in application
development.
This entire phase of real-time software design and development requires the engineer to build
and debug the system in iterative steps using software development tools. DSP debug
technology includes both hardware and software technology. Debug hardware consists of
functionality on the DSP chip, which enables the collection of data. This data provides state
behavior and other system visibility. Hardware is also required to extract this information
from the DSP device at high rates and format the data. Debug software provides additional
higher level control and an interface with the host computer, usually in terms of an interface
called a debugger. The debugger provides the development engineer an easy migration from
the compilation process (compiling, assembling, and linking an application) to the execution
environment. The debugger takes the output from the compilation process and loads the
image into the target system. The engineer then uses the debugger to interact with the
emulator to control and execute the application and find and fix problems. These problems
xxx DSP in Embedded Systems: A Roadmap

can be hardware as well as software problems. The debugger is designed to be a complete
integration and test environment. Chapter 17 (page 381) discusses a sequence of activities and
techniques to debug complex DSP systems.
Case Study 1 (page 423) will pull all of this together with an excellent case study on
performance engineering for DSP systems. The focus is on a case study related to
Performance Engineering. Expensive disasters can be avoided when system performance
evaluation takes place relatively early in the software development lifecycle. Applications
will generally have better performance when alternative designs are evaluated prior to
implementation. Software Performance Engineering (SPE) is a set of techniques for gathering
data, constructing a system performance model, evaluating the performance model, managing
risk of uncertainty, evaluating alternatives, and verifying the models and results. SPE also
includes strategies for the effective use of these techniques. Software performance
engineering concepts have been used on programs developing digital signal processing
applications concurrently with a next generation DSP-based array processor. Algorithmic
performance and an efficient implementation were driving criteria for the program. As the
processor was being developed concurrently with the software application a significant
amount of the system and software development would be completed prior to the availability
of physical hardware. This led to incorporation of SPE techniques into the development life-
cycle. The techniques were incorporated cross-functionally into both the systems engineering
organization responsible for developing the signal processing algorithms and the software
and hardware engineering organizations responsible for implementing the algorithms in an
embedded real-time system.
Phase 6 e Hardware/Software Integration
The integration phase is where the system is integrated into a fully functional real time
system. This is where we choose to describe several cases studies that reinforce many of the
points discussed in the preceding chapters. We will cover the more useful and important
aspects of system integration as it relates to DSP systems. Topical areas in this phase include;
• Integration of Multicore DSP systems
• Integration of DSP systems for base stations
• Integration of DSP systems for medical
• Integration of DSP systems for Voice over IP (VoIP)
• Integration of DSP systems for Software Defined Radio
Multicore Digital Signal Processors have grown in importance in recent years mainly because
of the emergence of data-intensive applications, such as video and high-speed Internet
browsing on mobile devices. These applications demand significant computational
performance and at lower cost and power consumption. In Chapter 16 (page 361), we discuss
DSP in Embedded Systems: A Roadmap xxxi

these topics and use the example of porting a single core application to a multicore
environment, which entails the consideration of complex programming and process
scheduling in addition to performing the required process algorithms. This chapter discusses
two basic multicore programming methods: multiple-single-cores and true-multiple-cores.
The true-multiple-cores model is used to port a motion JPEG application to a multicore DSP
device and serves to illustrate the concepts presented. The chapter also addresses some of the
concerns that arise when porting applications to a multi-core environment along with
proposed solutions to address these issues.
As more and more DSP algorithm components are developed for a growing number of signal
processing centric applications, the need for a programming model and standard is also
emerging. Like other coding standards, a DSP programming standard can improve
engineering efficiency and improve integration time and effectiveness. It can also make
integration of DSP components from multiple vendors more effective.
Phase 6 also includes a case study describing a Long Term Evolution (LTE) basestation design
of layer 1 and layer 2 software and some of the techniques used to develop a multicore
implementation of this application (Case Study 1, page 423). It brings together many points
raised earlier in the book. This case study summarizes the various challenges and their
resolution when migrating single-core embedded application software to multi-core SoCs
(System-on-a-Chip). The migration of a LTE eNodeB protocol stack is taken as the subject of
this case-study.
This case study describes the essential software engineering practices which could be used by
engineering teams for enhancing the viability of projects that involve software development
over complex embedded platforms.
Thereafter the case study describes through a well defined 3-Step process, the steps required
to develop the embedded applications for multicore SoCs with the help of associated
examples at each step. Each of the steps is further broken down into sub steps, which seek
to ensure that there is a measurable progress at the end of each phase of development.
The various technical challenges and their resolution are described in detail, along with
various suggestions, using the example of a high performance multicore SoC.
There is a case study on DSP for Voice over IP (VoIP) systems (Case Study 3, page 523). VoIP
offers many cost related advantages over legacy copper-based telephony, on both the physical
side (the equipment and wiring materials), as well as the logical side (considering the
flexibility to add services and to differentiate the cost model). This case study gives an
introduction on how the DSP made possible the VoIP ubiquity in the last decade.
There are many packet-based voice technologies that reshaped the telecommunication
network, once the migration from twisted-pair and E1/T1 trunk wiring made room for
Ethernet LAN and optical backbones. One of the workhorse systems that made the
xxxii DSP in Embedded Systems: A Roadmap

infrastructure transition possible was the VoIP Gateway. Segments of the network were
replaced with IP-based technologies but still the service had to be operational when the legacy
and new technologies collided. A VoIP Media Gateway handled the voice and signaling
information that is required to interface two technologically different sides of the network, for
example the TDM network to a packet network. Full-duplex real-time voice or fax/modem
communications are compressed by the DSP engine and encoded into IP packets and then
sent to the IP network. Packets received from the network are decoded and then
decompressed towards TDM side. A dynamic jitter buffer automatically compensates for
network delay variation enabling real-time voice communication. Voice processing includes
echo cancellation, voice compression, voice-activity detection, and voice packetization.
Other functions included are signaling detection and relay and fax/modem relay. DSP
technology enabled all of this underlying technology. The architecture of a Media Gateway
will be described in this case study.
There is also a case study on the use of DSP in the medical field (Case Study 2, page 493). The
example used is a real time ultrasound system. Real time ultrasound systems have been
available for more than forty years. During this time the architecture of such systems has
changed significantly, bringing new capabilities, in terms of quality and operation modes.
In this case study we present an overview of some of the most common operation modes
concentrating on an engineering approach to answer some of the frequent design questions.
The text is focused on implementation of beamforming and B-Mode on modern DSP
architecture, discussing tradeoffs and hardware capabilities.
Today’s generation of DSP bring a lot of processing power, making them more suitable for
medical ultrasound applications. The use of cases and examples in this chapter (Case Study 2,
page 493) will show what could be implemented on DSP, where the bottlenecks are and what
are the benefits.
There is a case study on Software Defined Radio (SDR) (Case Study 6, page 599); Digital signal
processing has become a powerful premise for the world of wireless communications. All the
latest technologies, including OFDM, CDMA, SC-FDMA that represent the main foundation of
the 3 G-4 G networks, such as HSPA, LTE or WiMAX, are now made possible by the high
density of digital algorithms that can be squeezed in a small, low-power chip. On top of that,
additional signal processing techniques, such as beamforming or spatial multiplexing, have
contributedtothe achievement ofthroughputs ofhundredsMbpsand spectralefficiencies oftens
of b/s/Hz. Also, some other complex algorithms that can be found in channel estimators,
equalizers and bit decoders allow all these techniques to operate in a tough radio environment,
including in non-line of sight communications with high mobility, even at large distance.
Large-scale integration allows a handheld device to include a multi-standard terminal,
compliant with a large variety of wireless standards. Think about a smart phone, that now
DSP in Embedded Systems: A Roadmap xxxiii

conveniently chooses the best technology for data and voice transmission, according to its
service needs and to the channel conditions. This is why your smart phone can connect to the
BTS through GSM, EDGE, UMTS or soon, LTE. At the same time, it has capabilities for
Wi-Fi, Bluetooth, GPS connections, all these in a very small terminal, with decent battery life.
In the future, this service selection and multiplexing will only be defined through software.
Without digital signal processing, relying solely on analog components, there would be no
possible way to achieve such performance. Right now, the analog part in a transceiver is
losing its pace in front of the digital part. More and more operations are performed in the
digital part, including filtering, up/down conversion, compensations of the distortions
produced in the analog chain, at a smaller price and with better performances. Moreover, it is
expected that the analog part will be completely conquered in the future, with the help of
high-speed A/D and D/A converters, so that the digital transceiver will be glued directly to the
antenna. This part is called front-end in a transceiver and while some 10 years ago it used to
be completely analog, it is becoming more and more digital. This case study (Case Study 6,
page 599) attempts to reveal some of the digital signal processing existing in the front end of
a digital transceiver.
DSP systems require accurate specification of requirements for processing for many
applications. In this book we have a case study involving the specification steps for a cell
phone application utilizing DSP technology. Detailed and accurate specification techniques
lead to systems that meet customer requirements and perform well in the field. This case study
will walk the reader through these interesting and practical steps to specify software systems.
Finally, there are case studies that overview software performance engineering (SPE). SPE is
a systematic, quantitative approach that leads to cost-effective development of software
systems to meet system performance requirements. SPE is a software-oriented approach that
focuses on architecture, design, and implementation choices. There is an excellent case study
focusing on the use of SPE for a large DSP application with hard real-time deadlines.
xxxiv DSP in Embedded Systems: A Roadmap

CHAPTER 1
Introduction to Digital Signal Processing
Robert Oshana
Chapter Outline
What is digital signal processing? 1
Advantages of DSP 2
DSP systems 3
Analog-to-digital conversion 4
The Nyquist criteria 6
Digital-to-analog conversion 9
Applications for DSPs 10
Low cost DSP applications 10
Power efficient DSP applications 11
High performance DSP applications 13
Conclusion 14
What is digital signal processing?
Digital signal processing (DSP) is the method of processing signals and data in order to
enhance, modify, or analyze those signals to determine specific information content. It
involves the processing of real-world signals that are converted to, and represented by,
sequences of numbers. These signals are then processed using mathematical techniques, in
order to extract certain information from the signal, or to transform the signal in some
preferably beneficial way.
The term ‘digital’ in DSP requires processing using discrete signals to represent the data in
the form of numbers that can be easily manipulated. In other words, the signal is represented
numerically. This type of representation implies some form of quantization of one or more
properties of the signal, including time.
This is just one type of digital data; other types include ASCII numbers and letters that have
a digital representation as well.
The term ‘signal’ in DSP refers to a variable parameter. This parameter is treated as
information as it flows through an electronic circuit. The signal usually starts out in the
DSP for Embedded and Real-Time Systems. DOI: 10.1016/B978-0-12-386535-9.00001-9
Copyright Ó 2012 Elsevier Inc. All rights reserved. 1

analog world as a constantly changing piece of information.1
Examples of real-world
signals include:
• Air temperature
• Sound
• Humidity
• Speed
• Position
• Flow
• Light
• Pressure
• Volume
The signal is essentially a voltage that varies among a theoretically infinite number of values.
This represents patterns of variation of physical quantities. Other examples of signals are sine
waves, the waveforms representing human speech, and the signals from a conventional
television. A signal is a detectable physical quantity. Messages or information can be
transmitted based on these signals.
A signal is called one dimensional (1-D) when it describes variations of a physical
quantity as a function of a single independent variable. An audio/speech signal is one
dimensional because it represents the continuing variation of air pressure as a function of
time.
Finally, the term ‘processing’ in DSP relates to the processing of data using software programs
as opposed to hardware circuitry. A DSP is a device or a system that performs signal processing
functions on signals from the real (analog) world, primarily using software programs to
manipulate the signals. This is an advantage in the sense that the software program can be
changed relatively easily to modify the performance or behavior of the signal processing. This
is much harder to do with analog circuitry.
Since DSPs interact with signals in the environment, the DSP system must be ‘reactive’ to the
environment. In other words the DSP must keep up with changes in the environment. This is
the concept of ‘real-time’ processing and we will talk about this shortly.
Advantages of DSP
There are many advantages of using a digital signal processing solution over an analog
solution. These include:
1
Usually because some signals may already be in a discrete form. An example of this would be a switch
which is represented discretely as being either open or closed.
2 Chapter 1

• Changeability; it is easy to reprogram digital systems for other applications, or to fine
tune existing applications. A DSP allows for easy changes and updates to the
application.
• Repeatability; analog components have characteristics that may change slightly over time
or temperature variances. A programmable digital solution is much more repeatable due to
the programmable nature of the system. Multiple DSPs in a system, for example, can also
run the exact same program and be very repeatable. With analog signal processing, each
DSP in the system would have to be individually tuned.
• Size, weight, and power; a DSP solution that requires mostly programming means the
DSP device itself consumes less overall power than a solution using all hardware
components.
• Reliability; analog systems are reliable to the extent to which the hardware devices
function properly. If any of these devices fail due to physical condition, the entire system
degrades or fails. A DSP solution implemented in software will function properly as long
as the software is implemented correctly.
• Expandability; to add more functionality to an analog system, the engineer must add more
hardware. This may not be possible. Adding the same functionality to a DSP involves
adding software, which is much easier.
DSP systems
The signals that a DSP processor uses come from the real world. Because a DSP must respond
to signals in the real world, it must be capable of changing based on the changes it sees in the
real world. We live in an analog world in which the information around us changes,
sometimes very quickly. A DSP system must be able to process these analog signals and
respond back to the real world in a timely manner. A typical DSP system (Figure 1-1) consists
of the following:
• Signal source; something that is producing the signal such as a microphone, a radar sensor,
or a flow gauge.
• Analog signal processing (ASP); circuitry to perform some initial signal amplification or
filtering.
• Analog-to-digital conversion (ADC); an electronic process in which a continuously
variable signal is changed, without altering its essential content, into a multi-level (digital)
signal. The output of the ADC has defined levels or states. The number of states is almost
always a power of two e that is, 2, 4, 8, 16, etc. The simplest digital signals have only two
states, and are called binary.
• Digital signal processing (DSP); the various techniques used to improve the accuracy
and reliability of modern digital communications. DSP works by clarifying, or
standardizing, the levels or states of a digital signal. A DSP system is able to
Introduction to Digital Signal Processing 3

differentiate, for example, between human-made signals, which are orderly, and noise,
which is inherently chaotic.
• Computer; if additional processing is required in the system, additional computing
resources can be applied, if necessary. For example, if the signals being processed by the
DSP are to be formatted for display to a user, an additional computer can be used to
perform these tasks.
• Digital-to-analog conversion (DAC); the process in which signals having a few (usually
two) defined levels or states (digital) are converted into signals having a theoretically
infinite number of states (analog). A common example is the processing, by a modem, of
computer data into audio-frequency (AF) tones that can be transmitted over a twisted pair
telephone line.
• Output; a system for realizing the processed data. This may be a terminal display,
a speaker, or another computer.
Systems operate on signals to produce new signals. For example, microphones convert air
pressure to electrical current, and speakers convert electrical current to air pressure.
Analog-to-digital conversion
The first step in a signal processing system is getting the information from the real world
into the system. This requires transforming an analog signal to a digital representation
suitable for processing by the digital system. This signal passes through a device called an
analog-to-digital converter (A/D or ADC). The ADC converts the analog signal to a digital
one by sampling or measuring the signal at a periodic rate. Each sample is assigned a digital
code (Figure 1-2). These digital codes can then be processed by the DSP. The number of
different codes or states is almost always a power of two (2, 4, 8, 16, etc.). The simplest
digital signals have only two states. These are referred to as binary signals.
Figure 1-1:
A DSP system.
4 Chapter 1

Examples of analog signals are waveforms representing human speech and signals from
a television camera. Each of these analog signals can be converted to digital form using ADC
and then processed using a programmable DSP.
Digital signals can be processed more efficiently than analog signals. Digital signals are
generally well-defined and orderly which makes them easier for electronic circuits to
distinguish from noise, which is chaotic. Noise is basically unwanted information. Noise can
be anything from the background sound of an automobile engine, to a scratch on a picture that
has been converted to digital format. In the analog world noise can be represented as electrical
or electromagnetic energy that degrades the quality of signals and data. Noise, however,
occurs in both digital and analog systems. Sampling errors (we’ll talk more about this later)
can degrade digital signals as well. Too much noise can degrade all forms of information
including text, programs, images, audio and video, and telemetry. Digital signal processing
provides an effective way to minimize the effects of noise by making it easy to filter this ‘bad’
information out of the signal.
As an example, assume that the analog signal in Figure 1-2 needs to be converted into a digital
signal for further processing. The first question to consider is how often to sample or measure
the analog signal in order to represent that signal accurately in the digital domain. The sample
rate is the number of samples of an analog event (like sound) that are taken per second to
represent the event in the digital domain. Let’s assume that we are going to sample the signal
at a rate of T seconds. This can be represented as:
Sampling period (T) ¼ 1 / Sampling frequency (fs)
where the sampling frequency is measured in hertz (Hz).2
If the sampling frequency is 8 kilohertz (kHz), this would be equivalent to 8000 cycles per
second. The sampling period would then be:
T ¼ 1 / 8000 ¼ 125 microseconds ¼ 0.000125 seconds
This tells us that, for this signal being sampled at this rate, we would have 0.000125 seconds
to perform all the processing necessary before the next sample arrived (remember, these
Analog-
to-Digital
Converter
1
0
0
-1
0.5 1 1.5 2
Figure 1-2:
Analog-to-digital conversion for signal processing.
2
Hertz is a unit of frequency (of change in state or cycle in a sound wave, alternating current, or other
cyclical waveform) of one cycle per second. The unit of measure is named after Heinrich Hertz, the German
physicist.

samples arrive on a continuous basis and we cannot fall behind in processing them). This is
a common restriction for real-time systems which we will discuss shortly.
If we now know the time restriction, we can then determine the processor speed required to
keep up with this sampling rate. Processor speed is measured not by how fast the clock rate is
for the processor, but how fast the processor executes instructions. Once we know the
processor instruction cycle time, we can determine how many instructions we have available
to process the sample:
Sampling period (T) / Instruction cycle time ¼ number of instructions per sample
For a 100 MHz processor that executes one instruction per cycle, the instruction cycle time
would be:
1/100MHz ¼ 10 nano seconds
125 us / 10 ns ¼ 12,500 instructions per sample
125 us / 5 ns ¼ 25,000 instructions per sample (for a 200 MHz processor)
125 us / 2 ns ¼ 62,500 instruction per sample (for a 500 MHz processor)
As this example demonstrated, the higher the processor instruction cycle execution, the more
processing we can do on each sample. If it were this easy, we could just choose the highest
processor speed available and have plenty of processing margin. Unfortunately, it is not as easy
as this. Many other factors including cost, accuracy, and power limitations must also be
considered. Embedded systems have many constraints such as these, as well as size and weight
(important for portable devices). For example, how do we know how fast we should sample the
input analog signal to accurately represent it in the digital domain? If we do not sample often
enough, the information we obtain will not be representative of the true signal. If we sample
too much, we may be ‘over-designing’ the system, and overly constraining ourselves.
The Nyquist criteria
One of the most important rules of sampling is called the Nyquist Theorem3
, which states that
the highest frequency which can be accurately represented is one-half of the sampling rate.
The Nyquist rate specifies the minimum sampling rate that fully describes a given signal.
Adhering to the Nyquist rate enables accurate reconstruction of the original signal from the
samples. The actual sampling rate required to reconstruct the original signal must be
somewhat higher than the Nyquist rate, because of various quantization errors introduced by
the sampling process.
For example, human hearing ranges from 20 Hz to 20,000 Hz, so to imprint sound to a CD,
the frequency must be sampled at a rate of 40,000 Hz to reproduce the 20,000 Hz signal. The
CD standard is to sample 44,100 times per second, or 44.1 kHz.
3
Named in 1933 after scientist Harry Nyquist.
6 Chapter 1

If a signal is not sampled at the Nyquist rate, the data sampled will not accurately represent
the true signal. Consider the sine wave below:
The dashed vertical lines are sample intervals. The dots are the crossing points on the signal.
These represent the actual samples taken during the conversion process (for example, an
analog-to-digital converter). If the sampling rate in Figure 1-3 is below the required Nyquist
frequency, this causes a problem. If the signal is reconstructed, the resultant waveform, as
shown in Figure 1-4, can occur.
This signal looks nothing like the input. This undesirable feature is referred to as ‘aliasing’.
Aliasing is the generation of a false (or alias) frequency, along with the correct one, when
performing frequency sampling in a given signal.
Aliasing manifests itself differently, depending on the signal affected. Aliasing shows up
images as a jagged edge or stair-step effect. Aliasing affects sound by producing a ‘buzz’. In
order to reduce or eliminate this noise, the output from the ADC process is usually low-pass
filtered to remove the higher frequency signals above the Nyquist frequency. Low-pass
Figure 1-3:
A signal sampled at a rate below the Nyquist rate will not fully represent the true signal.
Figure 1-4:
A reconstructed waveform showing the problem when the Nyquist theorem is not followed.

filtering also eliminates unwanted high-frequency noise and interference introduced prior to
the sampling phase. We will talk more about filtering algorithms in coming chapters.
Let’s assume we want to convert an analog audio into a digital signal for further processing.
We use the term ‘analog’ in an audio context to refer to a signal that represents sound waves
traveling through the air. A simple audio tone, such as a sine wave, will cause the air to form
evenly spaced ripples of alternating high and low pressure. When these signals enter
a microphone (or an eardrum for that matter), they cause sensors to move evenly back and
forth, at the same rate, producing a voltage. The measured voltage coming from the
microphone, plotted over time, will look similar to that shown in Figure 1-5.
If we want to edit, manipulate, or otherwise transmit this signal over a communication link,
the signal must be digitized first. The incoming analog voltage levels are converted into
binary numbers using analog-to-digital conversion. The two important constraints when
performing this operation are sampling frequency (how often the voltage is measured) and
resolution (the size of digital numbers used to measure the voltage, specifically the size or
width of the A/D converter.
Larger ADCs allow for an increased dynamic range of the input signal. When an analog
waveform is digitized we are essentially taking continuous ‘snapshots’ of the waveform at
a certain interval, called the sampling frequency, and storing those snapshots as binary codes
or numbers.
When the waveform is reconstructed from the sequence of numbers, the result will be
a ‘stair-step’ approximation of what we started with (Figure 1-6).
To convert this digital data back into analog voltages, the stair-step approximation must be
‘smoothed’ using a filter. This will produce an output similar to the input (assuming no
additional processing has been performed). However, if the sampling frequency, signal
resolution, or both, are too low, the reconstructed waveform will be of lower quality. Failing
Figure 1-5:
Analog data plotted over time.
8 Chapter 1

to process a signal at the sample rate (or higher) is as bad as a miscalculation in a hard
real-time system such as a CD player. This can be generalized to:
(Number of instructions to process * Sample rate) Fclk * Instructions/cycle (MIPS)
where Fclk is the clock frequency of the DSP device.
The required sampling rate depends on the application. There is a wide range of sampling
rates, from radar and signal processing applications on the high end, where the sampling rate
may be up to 1 gigahertz and beyond to control and instrumentation which require a much
lower sampling rate, in the order of 10 to 100 hertz. Algorithm complexity must also be taken
into consideration. In general, the more complex the algorithm, the more instruction cycles
are required to compute the result, and the lower the sampling rate must be to accommodate
the time for processing these complex algorithms.
Digital-to-analog conversion
In many applications, a signal must be sent back out to the real world after being processed,
enhanced and/or transformed while inside the DSP. Digital-to-analog conversion (DAC) is
a process in which digital signals having a few (usually two) defined levels or states are
converted into analog signals having a very large number of states.
Both the DAC and the ADC are of significance in many applications of digital signal
processing. The fidelity of an analog signal can often be improved by converting the analog
input to digital form using a DAC, clarifying or enhancing the digital signal, and then
converting the enhanced digital impulses back to analog form using an ADC (a single digital
output level provides a DC output voltage).
Figure 1-7 shows a digital signal passing through a digital-to-analog (D/A or DAC) converter
which transforms the digital signal into an analog signal and outputs that signal to the
environment.
Figure 1-6:
Resultant analog signal reconstructed from the digitized samples.

Applications for DSPs
In this section, we will explore some common applications for DSPs. Although there are
many different DSP applications, I will focus on three categories:
• Low cost, good performance DSP applications
• Low power DSP applications
• High performance DSP applications
Low cost DSP applications
DSPs are becoming an increasingly popular choice as low cost solutionsin a number of different
areas. One popular area is electronic motor control. Electric motors exist in many consumer
products,fromwashingmachines torefrigerators.The energyconsumed bythe electricmotorin
these appliances is a significant portion of the total energy consumed by the appliance.
Controlling the speed of the motor has a direct effect on the total energy consumption of the
appliance. In order to achieve the performance improvements necessary to meet energy
consumption targets for these appliances, manufacturers use advanced three-phase variable
speed drive systems. DSP-based motor control systems have the bandwidth required to enable
the development of more advanced motor drive systems for many domestic appliance
applications.
Application complexity has continued to grow as well, from basic digital control to advanced
noise and vibrationcancellation applications. Asthecomplexityofthese applicationshas grown,
there has also been a migration from analog-to-digital control. This has resulted in an increase in
reliability, efficiency, flexibility, and integration, leading to overall lower system costs.
Many of the early control functions used what is called a microcontroller as the basic control
unit. As the complexity of the algorithms in motor control systems increased, the need also
grew for higher performance and more programmable solutions. Digital signal processors
provide much of the bandwidth and programmability required for such applications. DSPs are
now finding their way into some of the more advanced motor control technologies:
• Variable speed motor control
• Sensorless control
Digital-
to-Analog
Converter
1
0
0
-1
0.5 1 1.5 2
Figure 1-7:
Digital-to-analog conversion.
10 Chapter 1

• Field oriented control
• Motor modeling in software
• Improvements in control algorithms
• Replacement of costly hardware components with software routines
Motor control is one example of a low cost DSP application. In this example, the DSP is used
to provide fast and precise PWM switching of the converter. The DSP also provides the
system with fast, accurate feedback of the various analog motor control parameters such as
current, voltage, speed, temperature, etc. There are two different motor control approaches;
open-loop control and closed-loop control. The open-loop control system is the simplest form
of control. Open-loop systems have good steady state performance and the lack of current
feedback limits much of the transient performance. A low cost DSP is used to provide
variable speed control of the three-phase induction motor, providing improved system
efficiency.
A closed-loop solution is more complicated. A higher performance DSP is used to control
current, speed, and position feedback, which improves the transient response of the system
and enables tighter velocity/position control. Other, more sophisticated, motor control
algorithms can also be implemented in the higher performance DSP.
There are many other applications using low cost DSPs. Refrigeration compressors, for
example, use low cost DSPs to control variable speed compressors which dramatically
improve energy efficiency. Low cost DSPs are used in many washing machines to enable
variable speed control, which has eliminated the need for mechanical gearing. DSPs also
provide sensorless control for these devices, which eliminates the need for speed and current
sensors. Improved off-balance detection and control enable higher spin speeds, which get
clothes dryer with less noise and vibration. Heating, ventilating, and air conditioning (HVAC)
systems use DSPs in variable speed control of the blower and inducer, which increases
furnace efficiency and improves comfort.
Power efficient DSP applications
We live in a portable society. From cell phones to personal digital assistants (PDAs),
we work and play on the road! These systems are dependent on the batteries that power
them. The longer the battery life can be extended, the better. So it makes sense for the
designers of these systems to be sensitive to processor power. Having a processor that
consumes less power enables longer battery life, and makes these systems and applications
possible.
As a result of reduced power consumption, systems dissipate lower heat. This results in the
elimination of costly hardware components like heat sinks to dissipate the heat effectively. This

leads to overall lower system cost, as well as smaller overall system size, because of the reduced
number of components. Continuing along this same line of reasoning, if the system can be made
less complex with fewer parts, designers can bring these systems to market more quickly.
Low power devices also give the system designer a number of new options, such as potential
battery back-up to enable uninterruptible operation, as well as the ability to do more with the
same power (as well as cost) budget, to enable greater functionality and/or higher
performance.
There are several classes of systems that are suitable for low power DSPs. Portable consumer
electronics use batteries for power. Since the average consumer of these devices wants to
minimize the replacement of batteries, the longer they can go on the same batteries, the better
off they are. This class of customer also cares about size. Consumers want products they can
carry with them, clip onto their belts, or carry in their pockets.
Certain classes of system require designers to adhere to a strict power budget. These include
those that have a fixed power budget, such as systems that operate on limited line power,
battery back-up, or with a fixed power source. For these classes of systems, designers aim to
deliver functionality within the constraints imposed by the power supply. Examples include
many defense and aerospace systems. These systems also have very tight size, weight, and
power restrictions. Low power processors give designers more flexibility under all three of
these important constraints.
Another important class of power-sensitive systems include high density systems. These
systems are often high performance, or multi-processor systems. Power efficiency is
important for these types of systems, not only because of the power supply constraints, but
also because of heat dissipation concerns. These systems contain very dense boards with
a large number of components per board. There may also be several boards per system in
a very confined area. Designers of these systems are concerned about reduced power
consumption, as well as heat dissipation. Low power DSPs can lead to higher performance
and higher density. Fewer heat sinks and cooling systems enable lower cost systems that are
easier to design. The main concerns for these systems are:
• Creating more functions per channel
• Achieving more functions per square inch
• Avoiding cooling issues (heat sinks, fans, noise)
• Reducing overall power consumption
Power is the limiting factor in many systems today. Designers must optimize the system
design for power efficiency at every step. One of the first steps in any system design is the
selection of the processor. A processor should be selected based on an architecture and
instruction set optimized for power efficient performance. For signal processing intensive
systems, a common choice is a DSP.
12 Chapter 1

As an example of a low power DSP solution, consider a solid state audio player. This system
requires a number of DSP-centric algorithms to perform the signal processing necessary to
produce high fidelity quality music sound. A low power DSP can handle the decompression,
decryption, and processing of audio data. This data may be stored on external memory
devices which can be interchanged like individual CDs. These memory devices can be
reprogrammed as well. The user interface functions can be handled by a microcontroller. The
memory device which holds the audio data may be connected to the micro which reads it and
transfers it to the DSP. Alternatively, data might be downloaded from a PC or internet site
and played directly, or written onto blank memory devices. A digital-to-analog (DAC)
converter translates the digital audio output of the DSP into an analog form to eventually be
played on user headphones. The entire system must be powered from batteries, (for example,
two AA batteries).
For this type of product, a key design constraint would be power. Customers do not like
replacing the batteries in their portable devices. Thus, battery life, which is directly related to
system power consumption, is a key consideration. By not having any moving parts, a solid
state audio player uses less power than previous generation players (such as tapes and CDs).
Since this is a portable product, size and weight are obviously also key concerns. Solid state
devices, such as the one described here, are also size efficient because they contain fewer
parts in the overall system.
To the system designer, programmability is a key concern. With a programmable DSP
solution, this portable audio player can be updated with the newest decompression,
encryption, and audio processing algorithms instantly from the world wide web, or from
memory devices. A low power DSP-based system solution like the one described here could
have system power consumption as low as 200mW. This will allow the portable audio player
to have three times the battery life of a CD player on the same two AA battery supply.
High performance DSP applications
At the high end of the performance spectrum, DSPs utilize advanced architectures to perform
signal processing at high rates. Advanced architectures such as Very Long Instruction Word
(VLIW) use extensive parallelism and pipelining to achieve high performance. These
advanced architectures take advantage of other technologies, such as optimizing compilers, to
achieve this performance. There is a growing need for high performance computing.
Applications include:
• DSL modems
• Base station transceivers
• Wireless LAN
• Multimedia gateways

• Professional audio
• Networked cameras
• Security identification
• Industrial scanners
• High speed printers
• Advanced encryption
Conclusion
Though analog signals can also be processed using analog hardware (i.e., electrical circuits
containing active and passive elements), there are several advantages to digital signal
processing:
• Analog hardware is usually limited to linear operations; digital hardware can implement
nonlinear operations.
• Digital hardware is programmable, which allows for easy modification of the signal
processing procedure in both real-time and non real-time modes of operation.
• Digital hardware is less sensitive than analog hardware to variations such as temperature.
These advantages lead to lower cost, which is the main reason for the ongoing shift from
analog to digital processing in wireless telephones, consumer electronics, industrial
controllers, and numerous other applications.
The discipline of signal processing, whether analog or digital, consists of a large number of
specific techniques. These can be roughly categorized into two families:
• Signal-analysis/feature-extraction techniques which are used to extract useful information
from a signal. Examples include speech recognition, location, and identification of targets
from radar signals, and detection and characterization of changes in meteorological or
seismographic data.
• Signal filtering/shaping techniques which are used to improve the quality of a signal.
Sometimes this is done as an initial step before analysis or feature extraction. Examples of
these techniques include the removal of noise and interference using filtering algorithms,
separating a signal into simpler components, and other time- and frequency-domain
averaging.
A complete signal processing system usually consists of many components and incorporates
multiple signal processing techniques.
14 Chapter 1

CHAPTER 2
Overview of Real-time and
Embedded Systems
Robert Oshana
Chapter Outline
Real-time systems 15
Soft and hard real-time systems 16
Differences between real-time and time-shared systems 16
DSP systems are hard real-time 17
Hard real-time systems 17
Real-time event characteristics 19
Efficient execution and the execution environment 19
Resource management 19
Challenges in real-time system design 20
Response time 21
Recovering from failures 22
Distributed and multi-processor architectures 22
Initialization of the system 22
Processor interfaces 23
Load distribution 23
Centralized resource allocation and management 23
Embedded systems 23
Embedded systems are reactive systems 25
Summary 26
Real-time systems
A real-time system is a system that is required to react to stimuli from the environment
(including the passage of physical time) within time intervals dictated by the environment.
The Oxford dictionary defines a real-time system as:
Any system in which the time at which output is produced is significant.
This is usually because the input corresponds to some movement in the physical world, and
the output has to relate to that same movement. The lag from input time to output time must
be sufficiently small for acceptable timeliness. Another way of thinking of real-time systems
is that they can consist of any information processing activity or system which has to respond
DSP for Embedded and Real-Time Systems. DOI: 10.1016/B978-0-12-386535-9.00002-0
Copyright Ó 2012 Elsevier Inc. All rights reserved. 15

to externally generated input stimuli within a finite and specified period. Generally, real-time
systems are systems that maintain a continuous and timely interaction with their environment
(Figure 2-1).
Soft and hard real-time systems
Correctness of a computation depends not only upon its results but also upon the time at
which its outputs are generated. A real-time system must satisfy response-time constraints or
suffer significant system consequences. If the consequences consist of a degradation of
performance, but not outright failure, the system is referred to as a soft real-time system. If the
consequences are system failure, then the system is referred to as a hard real-time system
(e.g., an anti-lock braking system in an automobile).
A system function (hardware, software, or a combination of both) is considered hard real-time
if, and only if, it has a hard deadline for the completion of an action or task. This deadline
must always be met, otherwise the task has failed. The system may have one or more hard
real-time tasks, as well as other non-real-time tasks. This is acceptable, as long as the system
can properly schedule these tasks in such a way that the hard real-time tasks always meet their
deadlines. Hard real-time systems are also commonly embedded systems. Embedded systems
are specialized systems that are part of a larger system. We will look in more detail at
embedded systems later in the chapter.
Differences between real-time and time-shared systems
Real-time systems are different from time-shared systems in three fundamental areas
(Table 2-1). These include:
• System capacity
• Responsiveness
• Overload
Real-time systems offer a high degree of schedulability, where timing requirements of the
system must be satisfied at high degrees of resource usage.
inputs outputs
environment
Real-Time
System
(state)
Figure 2-1:
A real-time system reacts to inputs from the environment and produces outputs that affect
the environment.
16 Chapter 2

They also ensure worst case latency, guaranteeing that the system will still operate under
worst case response time to events. Real-time systems also offer stability under transient
overload e when the system is overloaded by events and it is impossible to meet all deadlines,
the deadlines of selected critical tasks must still be guaranteed.
DSP systems are hard real-time
DSP systems usually qualify as hard real-time systems. As an example, assume that an analog
signal is to be processed digitally. The first question to consider is how often to sample or
measure the analog signal in order to represent that signal accurately in the digital domain. As
we discussed in Chapter 1, the sample rate is the number of samples of an analog event (such
as sound) that are taken per second to represent the event in the digital domain. We now know
that the signal must be sampled at a rate equal to at least twice the highest frequency that we
wish to preserve. If this signal contains important components at 4 kHz, then the sampling
frequency would need to be at least 8 kHz. The sampling period would then be:
T ¼ 1 / 8000 ¼ 125 microseconds ¼ 0.000125 seconds
This tells us that, for this signal being sampled at this rate, we would have 0.000125 seconds
to perform all the processing necessary before the next sample arrived. When samples are
arriving on a continuous basis, and the system cannot fall behind in processing them, and
must still produce correct results e this is a hard real-time system.
Hard real-time systems
The collective timeliness of the hard real-time tasks is binary e so they will either meet their
deadlines (in a correctly functioning system), or they will not (in which case the system is
infeasible). In all hard real-time systems, collective timeliness is deterministic. This
determinism does not imply that the actual individual task completion times, or the task
execution ordering, are necessarily known in advance.
A computing system being hard real-time says nothing about the magnitudes of the deadlines.
They may be microseconds or weeks. There is a bit of confusion with regard to the usage of
the term ‘hard real-time.’ Some relate hard real-time to response-time magnitudes below
some arbitrary threshold, such as 1 msec. This is not correct, however. Many of these systems
Characteristic Time-shared systems Real-time systems
System capacity High throughput Schedulability and the ability of system tasks to meet all
deadlines
Responsiveness Fast average response time Ensured worst case latency which is the worst-case response
time to events
Overload Fairness to all Stability; when the system is overloaded important tasks
must meet deadlines while others may be starved
Overview of Real-time and Embedded Systems 17

actually happen to be soft real-time. These systems would be more accurately termed ‘real
fast,’ or perhaps ‘real predictable,’ but certainly not hard real-time.
The feasibility and costs (e.g., in terms of system resources) of hard real-time computing
depend on how well known, a priori, are the relevant future behavioral characteristics of the
tasks and execution environment. These task characteristics include:
• Timeliness parameters, such as arrival periods or upper bounds
• Deadlines
• Worst case execution times
• Ready and suspension times
• Resource utilization profiles
• Precedence and exclusion constraints
• Relative importance
There are also important characteristics relating to the execution environment:
• System loading
• Resource interactions
• Queuing disciplines
• Arbitration mechanisms
• Service latencies
• Interrupt priorities and timing
• Caching
Deterministic collective task timeliness in hard (and soft) real-time computing requires that
the future characteristics of the relevant tasks and execution environment be deterministic,
i.e., known absolutely in advance. The knowledge of these characteristics must then be used
to pre-allocate resources so that all deadlines will always be met.
Usually, the future characteristics of the tasks and execution environment must be adjusted
to enable scheduling and resource allocation which meets all deadlines. Different algorithms
or schedules which meet all deadlines are evaluated with respect to other factors. In many
real-time computing applications it is common that the primary factor is maximizing
processor utilization.
Allocation for hard real-time computing has been performed using various techniques. Some
of these techniques involve conducting an off-line enumerative search for a static schedule
which will deterministically always meet all deadlines. Scheduling algorithms include the use
of priorities that are assigned to the various system tasks. These priorities can be assigned
either off-line by application programmers, or online by the application or operating system
software. The task priority assignments may either be static (fixed), as with rate monotonic
algorithms, or dynamic (changeable), as with the earliest-deadline-first algorithm.
18 Chapter 2

Real-time event characteristics
Real-time events fall into one of three categories:
• Asynchronous events are entirely unpredictable. An example of this is a cell phone call
arriving at a cellular base station. As far as the base station is concerned, the action of
making a phone call cannot be predicted.
• Synchronous events are predictable events and occur with precise regularity. For example,
the audio and video in a camcorder take place in a synchronous fashion.
• Isochronous events occur with regularity within a given window of time. For example,
audio data in a networked multimedia application must appear within a certain window of
time when the corresponding video stream arrives. Isochronous is a sub-class of
asynchronous.
In many real-time systems, task and future execution environment characteristics are hard to
predict. This makes true hard real-time scheduling infeasible. In hard real-time computing,
deterministic satisfaction of the collective timeliness criterion is the driving requirement. The
necessary approach to meeting that requirement is static (i.e., a priori) scheduling of
deterministic task and execution environment characteristic cases. The requirement for
advance knowledge about each of the system tasks and their future execution environment to
enable off-line scheduling and resource allocation significantly restricts the applicability of
hard real-time computing.
Efficient execution and the execution environment
Real-time systems are time critical and the efficiency of their implementation is more
important than in other systems. Efficiency can be categorized in terms of processor cycles,
memory, or power. This constraint may drive everything from the choice of processor to the
choice of the programming language. One of the main benefits of using a higher level
language is to allow the programmer to abstract away implementation details and concentrate
on solving the problem. This is not always true in the embedded system world. Some higher
level languages have instructions that are an order of magnitude slower than the assembly
language. However, higher level languages can be effectively used in real-time systems using
the right techniques. We will be discussing much more about this topic in the chapter on
optimizing source code for DSPs.
Resource management
A system operates in real time as long as it completes its time-critical processes with
acceptable timeliness. ‘Acceptable timeliness’ is defined as part of the behavioral or
‘non-functional’ requirements for the system. These requirements must be objectively

quantifiable and therefore measureable (stating that the system must be ‘fast,’ for example, is
not quantifiable). A system is said to be real-time if it contains some model of real-time
resource management (these resources must be explicitly managed for the purpose of
operating in real time). As mentioned earlier, resource management may be performed
statically off-line or dynamically online.
Real-time resource management comes at a cost. The degree to which a system is required to
operate in real time cannot necessarily be attained solely by hardware over-capacity
(e.g., high processor performance using a faster CPU). There must also be some form of
real-time resource management to be cost effective. Systems which must operate in real time
consist of both real-time resource management and hardware resource capacity. Systems
which have interactions with physical devices require higher degrees of real-time resource
management. These computers are referred to as embedded systems which we spoke about
earlier. Many of these embedded computers use very little real-time resource management.
The resource management that is used is usually static and requires analysis of the system
prior to it executing in its environment. In a real-time system, physical time (as opposed
to logical time) is necessary for real-time resource management, in order to relate events
to the precise moments of occurrence. Physical time is also important for action time
constraints as well as measuring costs incurred as processes progress to completion. Physical
time can also be used for logging history data.
All real-time systems make trade-offs of scheduling costs versus performance in order to
reach an appropriate balance for attaining acceptable timeliness between the real-time portion
of the scheduling optimization rules and the off-line scheduling performance evaluation and
analysis.
Challenges in real-time system design
Designing real-time systems poses significant challenges to the designer. One of the most
significant challenges comes from the fact that real-time systems must interact with the
environment. The environment is complex and changing, and these interactions can therefore
become very complicated. Many real-time systems don’t just interact with one, but many
different entities in the environment, each with different characteristics and rates of
interaction. A cell phone base station, for example, must be able to handle calls from literally
Reactive and embedded real-time systems
There are two types of real-time systems: reactive and embedded. Reactive real-time systems
involve constant interaction with the environment (such as a pilot controlling an aircraft). An
embedded real-time system is used to control specialized hardware that is installed within a larger
system (such as a microprocessor that controls anti-lock brakes in an automobile).
20 Chapter 2

thousands of cell phone subscribers at the same time. Each call may have different
requirements for processing. All of this complexity must be managed and coordinated.
Response time
Real-time systems must respond to external interactions in the environment within
a predetermined amount of time. These systems must produce the correct result and produce
it in a timely way. This implies that response time is as important as producing correct results.
Real-time systems must be engineered to meet these response times. Hardware and software
must be designed to support response-time requirements for these systems. Optimal
partitioning of the system requirements into hardware and software is also important.
Real-time systems must be architected to meet system response-time requirements. Using
combinations of hardware and software components, engineering makes architecture
decisions, such as inter-connectivity of the system processors, system link speeds, processor
speeds, memory size, and I/O bandwidth. Key questions to be answered include:
• Is the architecture suitable? To meet the system response-time requirements, the system
can be architected using one powerful processor or several smaller processors.
Can the application be partitioned among the several smaller processors without imposing
large communication bottlenecks throughout the system? If the designer decides to use one
powerful processor, will the system meet its power requirements? Sometimes a simpler
architecture may be the better approach e more complexity can lead to unnecessary
bottlenecks which cause response-time issues.
• Are the processing elements powerful enough? A processing element with high utilization
(greater than 90%) will lead to unpredictable run-time behavior. At this utilization levels
lower priority tasks in the system may get starved. As a general rule, real-time systems that
are loaded at 90% take approximately twice as long to develop due to the cycles of
optimization and integration issues with the system at these utilization rates. At 95%
utilization, systems can take three times longer to develop due to these same issues. Using
multiple processors will help but the inter-processor communication must be managed.
• Are the communication speeds adequate? Communication and I/O is a common bottleneck
in real-time embedded systems. Many response-time problems come not from the
processor being overloaded, but in latencies in getting data into and out of the system. In
other cases, overloading a communication port (greater than 75%) can cause unnecessary
queuing in different system nodes and this causes delays in messages passing throughout
the rest of the system.
• Is the right scheduling system available? In real-time systems tasks that are processing
real-time events must take higher priority. But how do you schedule multiple tasks that are
all processing real-time events? There are several scheduling approaches available and the
engineer must design the scheduling algorithm to accommodate the system priorities in

order to meet all real-time deadlines. Because external events may occur at any time, the
scheduling system must be able to pre-empt currently running tasks to allow higher priority
tasks to run. The scheduling system (or real-time operating system) must not introduce
a significant amount of overhead into the real-time system.
Recovering from failures
Real-time systems interact with the environment which is inherently unreliable. Therefore
real-time systems must be able to detect and overcome failures in the environment. Also,
since real-time systems are also embedded into other systems and may be hard to get at (such
as a space craft or satellite) these systems must also be able to detect and overcome internal
failures as well (there is no ‘reset’ button in easy reach of the user!). Also, since events in the
environment are unpredictable, it is almost impossible to test for every possible combination
and sequence of events in the environment. This is a characteristic of real-time software that
makes it somewhat non-deterministic in the sense that it is almost impossible in some real-
time systems to predict the multiple paths of execution based on the non-deterministic
behavior of the environment.
Examples of internal and external failures that must be detected and managed by real-time
systems include:
• Processor failures
• Board failures
• Link failures
• Invalid behavior of the external environment
• Inter-connectivity failure
Distributed and multi-processor architectures
Real-time systems are becoming so complex that applications are executed on multi-processor
systems that are distributed across some communication systems. This poses challenges to the
designer that relate to the partitioning of the application in a multi-processor system. These
systems will involve processing on several different nodes. One node may be a DSP, while
another may be a more general purpose processor. Some may even specialize in hardware
processing elements. This leads to several design challenges for the engineering team.
Initialization of the system
Initializing a multi-processor system can be very complicated. In most multi-processor
systems the software load file resides on the general purpose processing node. Nodes that are
22 Chapter 2

directly connected to the general purpose processor, for example a DSP, will initialize first.
After these nodes complete loading and initialization, other nodes connected to it may then go
through this same process until the system completes initialization.
Processor interfaces
When multiple processors must communicate with each other, care must be taken to ensure
that messages sent along interfaces between the processors are well defined and consistent
with the processing elements. Differences in message protocol including endianness, byte
ordering, and other padding rules can complicate system integration, especially if there is
a system requirement for backwards compatibility.
Load distribution
As mentioned earlier, multiple processors lead to the challenge of distributing the application,
and possibly developing the application to support an efficient partitioning of the application
among the processing elements. Mistakes in partitioning the application can lead to
bottlenecks in the system and this degrades the full entitlement of the system by overloading
certain processing elements and leaving others under-utilized. Application developers must
design the application to be efficiently partitioned across the processing elements.
Centralized resource allocation and management
In a system of multiple processing elements, there is still a common set of resources including
peripherals, cross bar switches, and memory that must be managed. In some cases the
operating system can provide mechanisms such as semaphores to manage these shared
resources. In other cases there may be dedicated hardware to manage the resources. Either
way, important shared resources in the system must be managed in order to prevent more
system bottlenecks.
Embedded systems
An embedded system is a specialized computer system that is usually integrated as part of
a larger system. An embedded system consists of a combination of hardware and software
components to form a computational engine that will perform a specific function. Unlike
desktop systems which are designed to perform a general function, embedded systems are
constrained in their application. Embedded systems often perform in reactive and time-
constrained environments as described earlier. A rough partitioning of an embedded system
consists of the hardware which provides the performance necessary for the application

(and other system properties such as security) and the software which provides the majority of
the features and flexibility in the system. A typical embedded system is shown in Figure 2-2.
Some of the features of typical embedded system components include:
• Processor core e at the heart of the embedded system is the processor core(s). This can
range from a simple inexpensive 8 bit microcontroller to a more complex 32 or 64 bit
microprocessor. The embedded system designer must select the most cost sensitive device
for the application that can meet all of the functional and non-functional (timing)
requirements.
• Analog I/O e D/A and A/D converters are used to get data from the environment and pass
it back out to the environment. The embedded designer must understand the type of data
required from the environment, the accuracy requirements for that data, and the input/
output data rates, in order to select the right converters for the application. The external
environment drives the reactive nature of the embedded system. Embedded systems
have to be at least fast enough to keep up with the environment. This is where analog
information such as light or sound pressure, or acceleration, are sensed and input into the
embedded system.
• Sensors and Actuator e sensors are used to sense analog information from the
environment. Actuators are used to control the environment in some way.
• Embedded systems also have user interfaces e these interfaces may be as simple as
a flashing LED or can be sophisticated, such as a cell phone or digital still camera interface.
• Application-specific gates e hardware acceleration such as ASIC or FPGA is used for
accelerating specific functions in the application that have high performance requirements.
The embedded designer must be able to map or partition the application appropriately
using available accelerators to gain maximum application performance.
• Software is a significant part of embedded system development. Over the last several years,
the amount of embedded software has grown faster than Moore’s law, with the amount
Processor
cores
Memory
Emulation and
diagnostics
User interface
Application
Specific gates
Analog I/O
Software/
Firmware
Power and
cooling
Sensors
Actuators
Figure 2-2:
Typical embedded system components.
24 Chapter 2

Another Random Scribd Document
with Unrelated Content

steps, and then fell back with a cry of horror. The furniture of the
place was scattered in all directions, and there was blood
everywhere.
“Maria-Teresa!” The Marquis and Dick, both calling out at the same
time, were as suddenly silent again. Both seemed to have heard a
faint voice answering them.
“It’s up there!” shouted the young man, dashing toward a
staircase leading to the first floor. All could now distinctly hear a low,
prolonged moan. Dick, slipping on the stairs in his hurry, rose again
with a white face. His hands were red with blood!

T
III
he first two rooms were empty, but bore unmistakable signs of
a desperate flight and struggle. Then a landing, a door and a
dark cupboard, from which a loud cry for help now resounded
throughout the deserted hacienda. Dick, signing to the Marquis to
turn the light into the corner, bent down, and dragged a body from
the cupboard. It was Libertad!
Covered with knife-wounds, the negro boy was on the point of’
death, struggling for air. They took him into the next room, and
threw open the windows, while Dick questioned him brutally. “Where
is your mistress?” A feeble hand pointed toward the sierra, and Dick
stood away from the dying man. That was all he wanted to know.
The Red Ponchos were already on the road to the mountains with
his fiancée.
He dashed down into the road to find Uncle Francis with little
Christobal. The boy, climbing into the motor had discovered his
sister’s cloak there, and was crying over it. He threw himself into
Dick’s arms, but was roughly pushed aside while the young engineer
raged impotently.
What could he do? Anything for a horse, a mule, something to
carry on the pursuit! The irony of it! That motor there, which had
served for the crime, was useless now on the narrow rocky mountain
pathway which they must follow.
Then little Christobal, listening with wide-open eyes, started. He
had heard a noise at the far end of the court. Could there be horses
in that deserted bodega. It sounded just like hoofs stamping on a
plank flooring. Then the child heard a faint neigh.
Dick had vanished, and Christobal, running toward the farm
buildings, slipped through a half-open door. Yes, there was

something there... llamas... three llamas,.. but thin, miserable
creatures, worn out by the heavy loads of years, and incapable of
carrying even a child. But llamas do not neigh. The boy slipped
round the corner of the building, and stopped short in the shadow.
Sitting motionless a few yards away was a horseman, watching the
house. At his stirrup, attentively immobile as the horseman, was a
llama—one of those light, fine-limbed, long-necked beasts which
carry a man’s belongings and follow him like a dog.
As Christobal caught sight of them, the horse shied. The rider
reined it in, and swore, but his oath was cut short by a shot. A
shadow had risen in the night, only a few feet away, and had fired;
the rider rolled from his saddle, while the shadow, seizing the
horse’s bridle, swung itself into his place. Little Christobal ran toward
it.
“Tell your father I’ve bagged one of them,” shouted Dick, turning
his mount and riding for the sierra.
The child, without answering, ran after the llama, which in its turn
was following the horse. His little fingers caught in its wool, he
checked it with the words one uses to llamas, scrambled up and
dashed after Dick. Uncle Francis, on the roadway, was passed by two
black streaks, and left alone there, speechless.
Meanwhile, in the room on the first floor, Libertad was making his
confession. Natavitad had realized, and had made the Marquis
realize, the great value to them which this might have. Nor, to tell
the truth, did he forget the value of the Marquis as a witness to this
confession, which he regarded in the light of a valuable piece of
fresh evidence in his case against the Indians generally. For this
twofold reason, Natividad was merciless, and forced the negro to
speak till his last breath.
This confession, made in gasps and groans, built up by question
and answer, and cut short by death, showed clearly that the
abduction had been long planned, and that the daughter of the
Marquis de la Torre had been chosen as the victim of the Interaymi

at least two months before the festival. That was as clear as the
wonderful tropical night without.
Two months before, Libertad had first been sounded, and he had
not long resisted the temptation of the money offered him. All he
was asked to do was to drive the motor to a certain spot on a
certain day, without looking to see what was happening behind him.
For this, he was to receive two hundred silver soles, of which fifty
were paid to him in advance.
“And who did you make the bargain with?” demanded Natividad.
“With a clerk from the Franco-Belgian bank who sometimes came
to see the señorita. His name was Oviedo.”
Don Christobal started. Oviedo Huayna Runtu, the intruder of the
Cajamarca trip! If he had planned to kidnap Maria-Teresa at Callao,
that voyage must have been particularly disagreeable to him. That
would explain his close watch over them, and perhaps also the hint
to the police at Cajamarca, which resulted in their hasty return to
Lima.
“When did you first know the date chosen?” questioned Natividad,
holding up the negro, who was choking.
“This morning. Oviedo came to see me. He told me that a man
would say to me, ‘Dios anki tiourata’ (‘good-day,’ in Aimara), and
that I was to obey that man. I was to take the wheel, not turn my
head, and drive where I was told to go.”
Libertad’s story, told in jerky sentences, showed that he did not
really know until the evening what had been plotted. Though he did
not move or look, the sound of the struggle at the open window told
him what was happening. It was then too late to draw back, and,
when the order came, he drove the car to the calle San Lorenzo,
where they stopped for a minute before a low door. Huascar came
out, exchanged a few words with the occupants of the machine, and
ordered him to take the Chorillos road, and not to stop until he had
reached Ondegarda’s hacienda. There was not a sound behind him
throughout the journey.

At the hacienda, when his passengers got out, he had instinctively
glanced sideways, and had seen the señorita, unconscious, being
lifted out by three dwarfs with horribly-shaped heads. They took her
into the casa, while he, more dead than alive, waited where he was,
anxious only to be paid and to get away.
Then they were overtaken by a troop of mounted Indians, all
wearing red ponchos, and led by Oviedo. Huascar was also with
them, and ordered Libertad to come into the house. To his surprise,
he found there half a dozen women, veiled in black, and guarding
the door to another room.
“The mammaconas,” gasped Natividad. “We can have no doubts
now.... Speak, Libertad.... Speak, and God may forgive you.”
“Yes, the mammaconas,” said the negro lad, feverishly.... “But I
did not know.... God will forgive me.... The señorita, too, will forgive
me.... You must save her.... She was so good to me.... And I
betrayed her... betrayed her for two hundred silver soles.... They did
not know I understood Aimara... they said that Atahualpa would
have a beautiful bride.... And they fell on their faces before her
when she passed.”
“You saw her, then?” demanded the Marquis, bending low over the
prostrate figure at his feet to catch the faint words.
“Yes, I saw her.... She was so good.... And I sold her for two
hundred silver soles.”
“Tell us how it happened,” interrupted Natividad. “Was she no
longer unconscious?”
“She came out of the room, held up by women in black veils... the
three dwarfs were dancing around her.... She seemed to be in a
dream... they have terrible poisons and perfumes.... My sweet
señorita... wrapped in a gold veil... her face was hidden... only her
eyes, staring sightlessly before her.... The mammaconas were all
round her... and the dwarfs were dancing. I saw it all, because they
had left me alone, and I looked out of the window... they put her on
a mule... in front of one of the mammaconas... and the others

followed.... Yes, señor, it is true... all these stories you hear in the
ranchos.... Quite true... the dwarfs followed, señor.... Oviedo was
there... they had prepared everything in this hacienda.... I believe
they murdered the owner and all his people....
“Yes, I saw it all.... I did not care then that I had not been paid....
I watched.... And the Red Ponchos carried off my mistress... they are
taking her to the Temple of the Sun.... It is the Interaymi.... But you
will find them first... You must.... And God will forgive me.”
Libertad closed his eyes and fell back, but seemed to recover his
forces with the last flicker of life, and opened them again.
“What happened to you?” asked Natividad. “Was it in trying to
save your mistress?...”
Libertad smiled bitterly, and tried to cross himself, but his arm fell
nerveless by his side.
“Huascar,” he said. “He came into the room, and when I asked him
to pay me, pointed to the two hundred silver soles... they were on
the table there.... Not one over.... It was not much for betraying my
mistress.... I did not know that was what they wanted.... When I
told him so, he asked me what I would have done if I had known....
I answered I would have asked double the amount....”
“What then?”
“Then he drew a knife and came at me.... I ran, but he
followed.... He stabbed me once, and I escaped, but he followed.... I
ran upstairs.... He stabbed me again and again.... When I fell, he
thought I was dead... and I am... I am... dying... oh!... Have mercy!”
Libertad’s last moment had come. The Marquis and Natividad,
bending over him, were startled by the shot outside, and rushed
downstairs. They found Uncle Francis by the motor, staring down the
road. When they asked him where Dick and little Christobal were, he
gazed back as if not understanding, and vaguely answered that he
was looking for them.

Don Christobal and Natividad, turning to look in the direction the
old scientist was staring, suddenly saw two shadows dash across a
moonlit stretch of road and vanish in the darkness of a ravine
leading into the mountains, and spanned above by the railway
bridge. Dick on his horse, little Christobal on his llama, did not even
check for an instant at their hail.
Hardly had the hoof-beats died out in the depths of the ravine
than the sound of galloping horses came from the right, on the
Chorillos road. A moment later, a knot of riders appeared.

H
IV
orses!” exclaimed Natividad. “Then we have them. They are
probably making for the Cuzco, or some place round Titicaca,
But they are bound to pass through Veintemilla’s lines, and
we shall catch them at Canete or Pisco.”
As Natividad had surmised, the riders were cavalrymen sent out
from Chorillos at his order. They ran toward them, Uncle Francis
questioning the Marquis, who did not answer. Indeed, Don
Christobal, doubly anxious now that his son had left his side, could
not contain himself. Hardly had the troopers dismounted than he
swung himself into the nearest saddle, and rode off after Dick.
“Sheer madness,” growled Natividad. “If they ever overhaul the
Indians, they are lost.”
“What are we going to do now?” demanded Uncle Francis. Maria-
Teresa’s fate moved him deeply, particularly from a literary point of
view, but under the circumstances he asked no better than to keep a
little in the background.
“We can only follow at a distance,” replied Natividad.
“Excellent... excellent... find out where they are making for, and all
that sort of thing.”
“There are still laws, a police force and troops in Peru, señor. We
are not afraid of the Indians.”
With which he turned to the four soldiers who had joined them,
and who represented what remained of the military force of the
costa. Uncle Francis, already delighted with Natividad’s plan of
following at a distance, approved of it even more warmly when he
found that this little escort was to accompany them.

Three policemen mounted on mules, coming from the direction of
Callao, now appeared on the road. Natividad at once requisitioned
the mules for his expedition. Before starting, however, he went back
into the casa to write a hurried letter to President Veintemilla,
explaining what had happened. He did so with a certain malice,
remembering that ten years ago this same president had been Chief
of Police, and had threatened to suspend him for his “mad reports.”
One of the policemen, entrusted with the letter, started back
toward Callao at once. The two others were ordered to take charge
at the hacienda and begin a preliminary enquiry. Then Natividad and
Uncle Francis mounted two of the commandeered mules, the third
being taken by the soldier whose horse had been carried off by Don
Christobal. When the soldiers saw that they were heading for the
sierra instead of Chorillos, there was a grumble, but Natividad
silenced them. “Forward,” he ordered, and they, in their turn,
entered the ravine.
“We can, at all events, travel as fast as the mammaconas,” said
the Chief of Police to Uncle Francis.
“The mammaconas? Were they here then?” The scientist,
intensely interested, urged his mount alongside Natividad’s.
“Yes señor... the mammaconas... and three head priests of the
temple... only they may touch the Virgin of the Sun.... señor, for the
past fifteen years I have known all this, but they called me a lunatic.
Why should we suppose that the Indians have changed? Do they not
eat, drink, and get married just as they did five centuries ago? If
their outward customs have not changed, why should their secret
rites have done so? Why, señor, why?... But nobody will believe me.
It all began when I was a young man. I had to investigate a
mysterious crime, the only possible explanation for which was a
religious one. You must not forget that you are dealing with Incas to
this day.... And I got my knuckles rapped.... Five years later, when
the Orellana girl disappeared, they treated me in the same way. So I
let them give what explanation they liked, and worked on my own. I
speak Quichua like a native now, señor. I also learned Aimara, which

is their sacred language in the Cuzco and round Titicaca.... That’s
where they are making for now; some hidden temple, where their
priests have been working since the days of the conquest.”
Uncle Francis looked at his companion suspiciously. Were they all
engaged in a huge practical joke at his expense? This Chief of Police
was singularly calm under the circumstances; off-handed, almost
gay.
“We are sure to catch them, are we not?”
“Of a surety, señor. Dios mio, be content! We will catch them....
How can they possibly escape? We are on their heels; if they stick to
the mountains, they run into our troops; if they go down into the
costa, every corregidor (mayor) is at my orders.”
There was a moment’s silence, and he went on:—
“Will you not put on that cloak at your saddle-bow, señor? The
nights are chilly, and we are nearing the cordilleras.... The only road,
you see. They must have passed here. At dawn, we shall be able to
see their trail distinctly.... If only those crazy people who dashed on
ahead do not make fools of themselves.... A plucky youngster, little
Christobal.... We shall soon overhaul them.... One does not climb
these mountains as a bull jumps over the barrier at the ring....”
Natividad’s garrulous flow of words was interrupted by a chuckle
from Uncle Francis. Not a little astonished, he asked him what he
meant, but Mr. Montgomery contented himself with replying:—“I
understand, I understand.” Natividad, who did not understand, eyed
him doubtfully.
Just before day-break they reached the first masses of the true
Andes. Their mounts did not appear over-tired, and after a two-
hours’ halt at a wayside guebrada, where beasts and men obtained
food, they continued the journey. Over them towered the giant
mountain chain, blazing in the molten light of dawn.
The half-breeds at the guebrada could not, or would not, give
them any information as to those they followed. That the Indian

cavalcade had not stopped there, however, was certain, or larder
and loft would have been empty. Natividad, convinced he would get
nothing else out of the men, forced them, in the name of “the
supreme government,” to exchange two strong mules for two of the
horses.
Shortly after they had started again, they came on unmistakable
traces of a strong party of horse. Thistles, and the great yellow
flower of the amancaes, trampled flat, showed where hoofs had
passed.
“We are close on them now, señor,” said Natividad.
Uncle Francis, coughing knowingly, assented in such a detached
manner that Natividad began to have serious doubts as to the
mental welfare of that illustrious scientist.
Before long, though, he was worrying a great deal more about
something else. So far, there had not been a sign anywhere of the
Indians’ first pursuers. Uncle Francis, on the other hand, was
thoroughly happy, and seemed to be enjoying the scenery.
As they climbed steadily upwards, the road was becoming more
and more dangerous, twisting and turning round the mountain-side.
Peaks, sky, and precipices; in the blue of the distance, a few
mountain goats, all four feet joined together, balancing on some
rocky point.
The cold was now intense, and the soldiers grumbled openly.
When Natividad reminded them that they were serving “the supreme
government,” they let it be inferred that they did not give a tinker’s
damn for the supremo gobesnie, but nevertheless followed.
“Are you sure of those men of yours?” asked Uncle Francis.
“As sure as of myself,” replied Natividad, determined to be
optimistic.
“What are they? Indians?”
“Quichuas, of course.... Where else would we get soldiers?”

“They do not seem to me to be enthusiastic militarists.”
“A grave error, señor. They are delighted to be soldiers. What else
could they be?”
“They are volunteers, then?” questioned the scientist. And to
Natividad’s stupefaction, he produced his note-book.
“No, not volunteers, illustrious señor.... We send troops into the
Indian villages, and arrest every able-bodied man who has not
bolted. Then we enroll them as volunteers.”
“Charming! And you are not afraid that they may turn on you
when you have armed them?”
“Not in the least. After the first few days they decide they are so
much better off under the colors that they would not go back to
their families for anything.... You should see them join in the
recruiting afterwards!... They make very good soldiers.... These men
are only annoyed at being taken into the mountains; they would die
for Veintemilla.”
“So much the better,” concluded Uncle Francis philosophically. And
he added, to Natividad’s growing amazement:—“But why insist on
their coming with us? We can find those other Indians just as well
without their aid.”
Natividad jumped. What kind of a man was this? Then his
attention was suddenly drawn to the road again.
“There, over there! They camped there.”
At this point, the mountain path widened to a kind of little plateau,
on which were unmistakable traces of a recently-pitched camp. The
ashes of the fire had not yet been swept away by the wind, and
remains of food littered one corner. Natividad, convinced that he had
found the first resting-place of the escort of the Virgin of the Sun,
urged on his party.
“It is strange,” he said, “that we should have seen nothing yet of
the Marquis, little Christobal, or your nephew.”

“Why worry? We’ll find them all, sooner or later.”
“What?”
“Sooner or later—some day.... Hello, what’s the matter? This beast
of mine won’t move. Gee up.”
Calm and collected, quite different from the frightened Mr.
Montgomery of the flight from Cajamarca, he urged on his mount,
but the mule refused to answer to his heel. Then Natividad, pressing
forward to see what was the matter, saw the body of a llama
stretched across the narrow path. Dismounting, he lifted its head,
examined the nostrils, and then pushed the body over the edge of
the ravine.
“Little Christobal’s llama,” he pronounced. “The animal has been
ridden to death.... Poor child! I wonder where he is.”
Uncle Francis, busy with his note-book, refused to get excited.
“With my nephew, probably. Even if Dick had left him behind, his
father must have come upon him.”
“That is possible, of course,” said Natividad, doubtfully.
“Is this llama-riding common over here?” questioned the scientist,
intent on acquiring knowledge.
“No. Children sometimes amuse themselves with it if the llama is
willing. Rich people give them to their sons occasionally. Christobal
probably had his.”
“I would never have believed a llama capable of going so far, and
so fast.”
“No pack-llama could. But that was a good one, trained to carry
light weights and travel fast. Probably used to being ridden by
children.... I wonder where they found it... Your nephew’s horse,
too... in the hacienda stables, I suppose.... A tragedy might have
been avoided had they not.”
The little party had ridden on, and now, taking a sharp corner,
came suddenly upon Dick and the Marquis, the former on foot, and

the latter mounted. Little Christobal was not there.

D
V
ick was pale, but the Marquis was livid. So they appeared to
Natividad; as to Uncle Francis, he had not his glasses on, and
noticed nothing disquieting in their appearance.
“Those scoundrels have both my children now,” groaned Don
Christobal in answer to Natividad’s eager questions, and told what
had happened.
Badly mounted for mountain roads, the Marquis had found great
difficulty in following. Several times he had been on the point of
abandoning his horse, but, thinking it might be valuable later on,
had kept to it. Once or twice he had been obliged to dismount and
drag the unwilling beast behind him. At dawn, he reached the
Indians’ camp, which he searched in vain for some personal sign of
his daughter. She was evidently too well guarded. Finally he found
the llama’s body, but being convinced that Dick was with little
Christobal, had not worried overmuch. Then, a little further on, he
found Dick, but alone.
Dick, powerless to interfere, had seen little Christobal carried off
by the same Indians who already held Maria-Teresa. When they
started on their wild ride, and as soon as the road became steeper,
the llama had rapidly outpaced Dick’s horse. Little Christobal, riding
it hard, would not stop, and soon vanished ahead. Two hours later,
Dick had lost his horse in a ravine, throwing himself from the saddle
only just in time, and narrowly saving his own life by clinging to a
projecting rock. He continued his pursuit on foot, and finally came in
sight of the boy, just as the llama, exhausted, burst a blood-vessel
and fell. He had called to little Christobal, but the boy, unheeding,
had run on, crying, “Maria-Teresa! Maria-Teresa!”

They were right on the Indians then, and Dick could see them far
above him on the zig-zagging mountain-path. They had checked
their horses, waiting for the boy to catch up to them. Then one of
the Red Ponchos bent down, lifted him up to his saddle-bow, and
hurried on with his new captive. Dick was too far away to open fire,
and the Indians had at once spurred on, soon leaving him far
behind. The Marquis had come up a short time after.
“You must not despair, Don Christobal,” urged Natividad. “Your
news is not all bad. They are only just ahead, and cannot escape us.
They must pass through Huancavelica, and there we have troops to
help us.”
Natividad ordered one of the soldiers to dismount and give his
mule to Dick. The man was indignant, and continued protesting in a
weird jargon as he trotted afoot behind the cavalcade. In this
manner they reached a point where the road forked, one branch
going on up into the hills, the other stretching down toward the
coast. They had all turned up the former when the dismounted
soldier turned—he would go no further, but would descend to the
coast; and once there he would report to the powers the manner in
which he had been treated by a mere civilian. Natividad wished him
an ironical good-by, and he started, but only to reappear a moment
later, waving a soft felt hat in his hand.
“That belongs to Christobal!” exclaimed the Marquis.
They turned their mounts, grateful for the chance-found sign
which had saved them from a grievous mistake. Natividad alone
hesitated, wondering whether this was not an Indian ruse. They
advanced slowly therefore, until the mud and sand on the banks of a
torrent just below showed beyond doubt that a large number of
mounted men had passed that way and restored Natividad’s serene
belief in the ultimate success of their search.
“So they’re doubling back to the costa. They must have been
warned that the passes were guarded... all they have gained by the

detour is avoiding Chorillos.... Perhaps they are making for Canete....
Well, they must stop somewhere, and then we have them!”
After an hour’s rest, they hurried on again at top speed, one of
the soldiers giving his dismounted comrade a lift behind.
“Did you, then, ever think that we might not catch them?” asked
Uncle Francis of Natividad, with an enigmatical smile.
“Why not, señor?... Between you and me, it is about time we did
catch them.... I for one shall not feel happy if señorita de la Torre
and the boy are still in their hands on the last day of the Interaymi.”
“Do you mean that the boy is in danger?”
“Speak lower, señor, speak lower.... Nothing is too young, too
beautiful or too innocent for the Sun. Do you understand?”
“More or less. More or less.”
“You people do not know what horrors they are capable of.... They
still have their priests.... You might blink at facts if it were only the
ordinary Red Ponchos, but there are also those three monsters....
You always find them together in the old burial-grounds.... When
one dies, the other two are put to death.... Or when a king died,
they sacrificed themselves on his tomb.... They still exist, those
monsters, those high-priests of the sacred slaughters.... They exist,
señor.”
“Do they?”
“You, señor, are a savant, and know about the Temple of Death.
But do you know how many dead were found buried with the
mummy of Huayna Capac? Four thousand, señor! Four thousand
human lives sacrificed to honor the dead—some by suicide, others
strangled, knifed or suffocated.... And the House of the Serpent....
But I prefer not to tell you what happened there.”
“Tell me some other day.... You make an admirable guide. When
we return, I will tell the supremo gobierno how grateful I am to

them for having made the most erudite of police officers my
cicerone.”
“I beg your pardon, señor?”
Natividad, completely taken aback, could only stare at his
interlocutor.
“Nothing, nothing! I am only joking!” Scandalized at such levity,
Natividad turned away with an indignant snort, while Uncle Francis
chuckled. That worthy gentleman had now quite made up his mind
that there was a plot afoot against him, and sternly refused to be
“taken in.” The joke was rather tiring physically, but he would not cry
for mercy. As to all these hair-raising stories, he would take them for
what they were worth. Let them play their pranks till they tired of
them.
The more he thought of it, the more he became convinced of the
truth of his deductions. His antiquarian’s eye rested lovingly on the
traces of that long-dead Inca civilization which they met. Here,
aqueducts that would have made the Romans wonder; there,
remains of the great road which ran from end to end of South
America. They were all dead, those Incas. Yet these people wished
to make him believe that those vanished warriors and priests had
carried off a boy and girl of to-day to offer them as a sacrifice to
equally-forgotten gods!
They had now left the arid ranges and dusty wind behind them,
and reached a little village nestling in green fields at the foot of the
mountain. A babbling stream, tumbling down from the Cordilleras,
had transformed this corner into an oasis of verdure, in which Uncle
Francis would willingly have passed a few hours. But now that they
were in flat country again, Dick, the Marquis and Natividad increased
the pace feverishly. Uncle Francis, still determined not to show that
he had fathomed their plot, was careful not to protest.
Once or twice, they stopped to ask questions, but it was difficult
to obtain information. Hamlets were rare, and the Interaymi festivals
had drawn away nearly the whole population. The few Indians they

met received their questions with evident suspicion, and even
hostility. Nor would money loosen their tongues.
Fortunately, there were half-breeds more ready to talk, and they
learned that Huascar and his companions were riding hard. Nobody
had seen Red Ponchos; presumably the priests had concealed the
ceremonial raiment imposed by their ritual for the reception of the
Bride of the Sun. They were traveling so fast that nobody had had
time to notice whether they had a captive boy or young woman with
them. At the questions on this score all their informants began to
grow uneasy, and turned away with evasive sentences.
Huascar and his men had about two hours’ start, but it soon
became evident that they were gaining ground steadily. Natividad
could not fathom the meaning of the Indians sudden turn toward the
sea, this riding into a town where, normally, everything must be
against them if the alarm was given.
They reached Canete at nightfall, Dick still leading. There was a
big fête on, with torchlight processions and the deafening noise of
fireworks set off by delirious roisterers. Half the native population
was under the influence of drink, and Natividad, trained to
understand the populace, at once saw that the town was in a state
of dangerous effervescence.
Of all the towns in Peru, Canete is perhaps the one which shows
most markedly that strange admixture of the new and old. Factory
chimneys tower to the sky side by side with Inca aqueducts which to
this day bring the water of the Rio Canete to the surrounding
plantations. Just above the town are still the remains of the huge
native fortress demolished some two hundred years ago by the then
viceroy of Mañdelova when he needed materials for the defenses of
Callao.
Natividad’s first visit was to the corregidor, who told him that the
town was celebrating Garcia’s victories. It was now certain that the
rebels had captured Cuzco, and routed the Federal forces. Natividad
then told him of the plight of the Marquis de la Torre’s children. The

Mayor was skeptical, and showed it. Indians committing such a
crime, he said, would never have dared pass through a town.
“They could not stop in the Sierra,” said Natividad, “and had to
make for somewhere. Perhaps they intend taking boat, and reaching
Arequipa by sea. They could get up into the Cuzco that way.”
“That is more than possible,” replied the corregidor, anxious to rid
himself of the troublesome visitor. “A troop of strange Indians has, in
fact, passed through the town. They bought provisions, and then
hurried on to Pisco. They might have a boat ready there....
Personally, I can do nothing for you. I haven’t a single soldier or
policeman to dispose of. They have all gone to fight Garcia.”
At this moment, an extraordinary procession passed under the
corregidor’s windows. A dancing, singing procession, at the head of
which Natividad recognized his four troopers. He opened the window
and shouted menaces, but they passed unheeding.
In a sad mood Natividad rejoined his companions. Without any
explanation, he told them they must follow to Pisco, and they started
again. Natividad, in a brown study meanwhile, would answer no
questions.
Don Christobal, hearing that the Indians were making for Pisco,
grew hopeful. He was known in the town, having a branch business
there, with big guano dépôts, stores in the harbor, and a
considerable coolie station on the Chincha Islands, which are just off
the town. There he could speak with authority, and make the
corregidor listen.
They reached Pisco dog-tired, on mounts that could hardly stand.
Uncle Francis alone displayed a calm and unconcern which would
have convinced the others he was mad, had they had time to notice
him. The news of Garcia’s victory had just reached Pisco, and the
mob was even more delirious than that of Canete.
The Marquis, taking the leadership, led the way to his dépôt and
stores, only to find them completely deserted. There was not a
single employee there to answer his questions.

“To the corregidor’s, then,” he ordered.
The four travelers had entered the main and only street of the
town, and were riding toward the sandy central square when a
thundering feu de joie made them pull up. The Indians were burning
the sacred maize-leaf in honor of Garcia, to the grave danger of the
little blue-and-white houses around. The inhabitants of these, well-
to-do half-breeds, had locked themselves in, or taken to flight.
The madness of alcohol and the madness of fire crackers had
taken firm hold of all that was visible of the population. The mob
had pillaged a pisco distillery, and was enjoying itself thoroughly with
that virulent spirit, which is made from a kind of Malaga grape, and
takes its name from the town.
Natividad, casting round for a guide, found a half-breed sadly
huddled under a doorway. He doubtless was one of those who had
something to lose by the rioting; a house to be burned, or a cellar to
be plundered.
“Follow me,” he said, when asked where the corregidor could be
found.
He led them along a plank pavement which was just beginning to
burn, until they reached the corner of the arena, opposite the
church. Four skinny palms adorned the center of the square, and at
the foot of one of these a mob was dancing round a fire. Above,
something was hanging from a branch. The half-breed pointed to
that thing.
“There is the corregidor,” he said.
Natividad, Dick and the Marquis stopped short, mute with horror.
The half-breed whispered a few rapid words to Natividad, who
turned to run.
“Come on! Come on!” he almost screamed.
“Why this hurry?” demanded Uncle Francis, phlegmatically.
“Why? Why?... Because they are going to eat him!”

“Not really?” drawled the scientist with mediocre interest. “Right
away?”
But Natividad did not notice his tone. He was really running away,
for he had not forgotten a scene in Lima, when the Guttierg brothers
were torn from the presidency they had usurped by the same mob
which had placed them there. Massacred, then hanged over the
cathedral gates, they were finally roasted and devoured by the
populace.
So fast did Natividad flee, that Dick and the Marquis could hardly
keep up with him. Uncle Francis, bringing up the rear, was muttering
to himself:
“Damn nonsense, sir, damn nonsense. They’re not going to
frighten me.”

A
I
requipa was en fête; the entire population of the city and its
campina (suburbs) was packed in the main square and the
adjacent streets to witness the triumphal return of the victor
of the Cuzco—brave General Garcia, who had already been
christened “the good Dictator,” and who had promised his partizans
that within a fortnight he would sweep out of the country President
Veintemilla, the two Chambers, and the whole parliamentary system
which, he declared, had ruined Peru.
This was language the Arequipinos loved and understood. Politics
had always flourished in that part of the country, and all revolutions
began there. And the turbulent inhabitants of Arequipa felt that it
was a terribly long time since they had had a “savior” to cheer.
Now they had one; a particularly picturesque one, who was to
appear on horseback. So they had all donned their Sunday clothes,
and the women had flowers in their hair and more flowers in their
arms to scatter before the hero.
The Indian population, having sold its hens and vegetables in the
market-place, joined the throng.
The square, for the occasion, seemed to have straightened out its
tumble-down arcades, badly shaken by the last earthquake. The
illusion was aided by brilliant-hued carpets, flags, banners and
festoons which blazed in all directions and gave new life to the
dilapidated walls. The cracked old towers of the church, the carved
wooden balconies, flower-adorned galleries, and decorated windows
were black with people. Above the city rose the Misti, one of the
world’s highest volcanoes, wearing a fresh cap, glistening with the
snows of the night.

Bells chimed and cannons roared out. Then came silence, broken
again by the sound of bugles and the roar of a thousand voices. The
procession of the troops had begun. Contrary to European custom, it
commenced with all the impedimenta of the camp. It was like a
rout:—Indians leading mules loaded down with baggage, provisions,
and kitchen utensils; then a regiment of women bent under the
weight of knapsacks, babies, and sacks of food.
The crowd cheered everything wildly, from the llamas loaded with
captured Federal arms to the women, the rabonas, as they are called
out there. These rabonas are a precious institution from the point of
view of the Peruvian soldier; each man has his own, and she carries
his baggage, buys all his food, and prepares his meals.
Then came the troops, Garcia, leading. Mounted on a splendid
horse, wearing a brilliant uniform, he appeared like a star of the first
magnitude in the constellation of his staff. A tall man, he showed
head and shoulders above the generals and colonels prancing
around him. His tri-color plumes waved splendidly in the wind, and
the deafening rant of bugles accompanied him. Handsome, radiant,
happy was he, nonchalantly curling his black mustache and smiling
on all with brilliant white teeth.
Garcia smiled to the ladies as he passed under their balconies, and
the ladies, showering down rose-leaves over horse and rider, called
him by his Christian name, Pedro. In this triumphal fashion, he
slowly rode round the square twice, and then came to a halt in the
middle of it, between two guns, his staff behind him and, before
him, two Indians bearing a standard, a quaint patch-work quilt of a
flag, which was the token of submission of all the tribes to the new
government. These men wore hats covered with variegated plumes,
and had over their shoulders surplice-like tunics.
Five hundred infantrymen and two hundred horse had formed
round the square. Young girls, clad in floating tunics and wearing
Garcia’s colors, advanced toward the general, their hands heavy with
floral crowns. One of them made a little speech, while Garcia
continued curling his mustache and showing his teeth. The speech

over, he gallantly bent down and took all the crowns, passing them
over his arm. Then he lifted a hand to command silence.
“Long live Liberty!” he shouted. A hurricane of cheers arose. Again
he lifted up the crown-charged arm, and again there was silence.
He told them the program of the new Government meant “Liberty
for all, except for evil-doers! With such a program, is there any need
for parliaments?”
“No! No! No!” roared the crowd deliriously. “Long live Garcia!
Death to, Veintemilla! Muera! Muera! Muera el larron de salitre!
(Death to the saltpetre thief! ),” for Veintemilla was popularly
supposed to have largely profited by some recent concessions.
Garcia was an orator, and, wishing to show it once again, told in a
few words the history of the campaign that had ended in the rout of
the “saltpetre thieves” on the Cuzco plains. To be seen and heard by
all, he stood erect in his stirrups.
Then an incredible thing happened. The powers above actually
dared spoil this splendid fête—it began to rain! There was a general
rush for shelter in the crowd. Even the infantrymen lining the square
broke their ranks, while the cavalrymen dismounted, took off their
saddles and loaded them on their heads in guise of umbrellas. As to
those soldierly ladies, the rabonas, they calmly threw their bell-
shaped petticoats over their heads.
Garcia alone did not move. Furious at this spoiling of his triumph,
he threatened his officers with immediate death if they dared leave
his side. He did not even fall back into his saddle, but stood erect
there, his crown-charged arm menacing the heavens.
Then the Chief of Staff approached the Dictator, saluted thrice,
and said:
“Excellency, it is not the fault of the sky. The sky would not have
dared! The roar of your guns compelled the clouds, Excellency.”
“You are right,” replied Garcia. “And since the guns did the harm,
let them repair it.”

Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!
ebookultra.com

DSP for Embedded and Real Time Systems Expert Guide 1st Edition Robert Oshana

More Related Content

Similar to DSP for Embedded and Real Time Systems Expert Guide 1st Edition Robert Oshana (20)

Recently uploaded (20)

DSP for Embedded and Real Time Systems Expert Guide 1st Edition Robert Oshana