Download question bank for unit 1

QUESTION BANK FOR UNIT 1:
1) What is design matrix? Explain following design matrix I) power II) time to market III) safety IV)
maintainability V) Unit cost VI) NRE cost VII) Size VIII) Performance XI) Flexibility X) Time-toprototype XI)Correctness.
2) List application of embedded system?
3) What are the important building blocks of embedded system?
4)What is design matrix? Explain following design matrix i) power ii) time to market iii) safety
iv)maintainability
5) What is market window? Why is it so important for product to reach market early in this window?
6)Difference between general purpose system and embedded system. Explain different trends in
embedded system?
7) Explain different trends in embedded system?
8) Explain common design metrics.
9) What are the special considerations in designing embedded system?
10) What is market window and why it is so important for product to reach market early in this window?
11) explain various processor technologies?
12) Write features of Real time embedded system
13) What is time to market design metrics. Calculate losses if product is delayed.
.
14) Explain the current trends and challenges of embedded systems.
15) List three pairs of design metrics that may compete, providing an intuitive explanation of the reason
behind the competition.
16)The design of a particular disk drive has an NRE cost of $100,000 and a unit cost of $20. How much
will we have to add to the cost of the product to cover our NRE cost, assuming we sell: (a) 100 units,
and (b) 10,000 units?
18) What are architecture features and specification of processor to be used in embedded system?
19) What is embedded system? How it differs from general purpose computing system?
20) Explain design goal of embedded system.
21) explain the architecture of a general purpose embedded system?
22)explain the software architecture of an embedded system?
23)write the characteristics of embedded system and classification of embedded system?
24)list commonly used microcontroller in small,medium and large scale embedded system?
25)Explain embedded system technologies?explain in detail what is processor,IC and design
technology?
26) Explain embedded IC technology?
27) what are the different phases and models of software development cycle?
29)Explain with diagram waterfall model for software development.
30)Explain various stages of software development life cycle.
31)Compare waterfall and spiral model of software development.
32)Compare V model and spiral model of software development.
33)Compare V model and Waterfall model.
34)Explain in detail spiral model.
34)Explain advantages, disadvantages of waterfall model.
35)Explain in detail V model with advantages,disadvantages and applications.
36)Explain in detail advantages ,disadvantages and application of spiral model.
Some Questions with answers:
What is design matrix? Explain following design matrix
i) power ii) time to market iii) safety iv) maintainability
What is market window? Why is it so important for product to reach market early in this
window?
Ans:
The embedded-system designer must of course construct an implementation that fulfills desired
functionality, but a difficult challenge is to construct an implementation that simultaneously optimizes
numerous design metrics. For our purposes, an implementation consists of a software processor with an
accompanying program, a connection of digital gates, or some combination thereof. A design metric is a
measurable feature of a system’s implementation.
i) Power: The amount of power consumed by the system, which determines the lifetime of a battery, or
the cooling requirements of the IC, since more power means more heat.
ii) Time to market:
The amount of time required to design and manufacture the system to the point the system can be
sold to customers
iii) Safety: The probability that the system will not cause harm.
iv) Maintainability: Ability to modify the system after its initial range.
Market window:It is a period during which the product would have highest sales.
Design metrics typically compete with one another: improving one often leads to degradation in another.
For example, if we reduce an implementation’s size, its performance may suffer. Some observers have
compared this phenomenon to a wheel with numerous pins, as illustrated in Figure 1.2. If you push one
pin (say size) in, the others pop out. To best meet this optimization challenge, the designer must be
comfortable with a variety of hardware and software implementation technologies, and must be able to
migrate from one technology to another, in order to find the best implementation for a given application
and constraints. Thus, a designer cannot simply be a hardware expert or a software expert, as is
commonly the case today; the designer must be an expert in both areas.
Most of these metrics are heavily constrained in an embedded system. The time-to market constraint has
become especially demanding in recent years. Introducing an embedded system to the marketplace early
can make a big difference in the system’s profitability, since market time-windows for products are
becoming quite short, often measured in months. For example, Figure 1.3 shows a sample market
window providing during which time the product would have highest sales. Missing this window
(meaning the product begins being sold further to the right on the time scale) can mean significant loss
in sales. In some cases, each day that a product is delayed from introduction to the market can translate
to a one million dollar loss. Adding to the difficulty of meeting the time-to-market constraint is the fact
that embedded system complexities are growing due to increasing IC capacities. IC capacity, measured
in transistors per chip, has grown
exponentially over the past 25 years3, as illustrated in Figure 1.4; for reference purposes, we’ve included
the density of several well-known processors in the figure. However, the rate at which designers can
produce transistors has not kept up with this increase, resulting in a widening gap, according to the
Semiconductor Industry Association. Thus, a designer must be familiar with the state-of-the-art design
technologies in both hardware and software design to be able to build today’s embedded systems. We
can define technology as a manner of accomplishing a task, especially using technical processes,
methods, or knowledge. This textbook focuses on providing an overview of three technologies central to
embedded system design: processor technologies, IC technologies, and design technologies. We
describe all three briefly here, and provide further details in subsequent chapters.
Difference between general purpose system and embedded system.
embedded system?
Explain different trends in
Ans: Difference between general purpose system and embedded system
An embedded system is usually classified as a system that has a set of predefined, specific
functions to be performed and in which the resources are constrained. Take for example, a digital
wrist watch. It is an embedded system, and it has several readily apparent functions: keeping the
time, perhaps several stopwatch functions, and an alarm. It also has several resource constraints. The
processor that is operating the watch cannot be very large, or else no one would wear it. The power
consumption must be minimal; only a small battery can be contained in that watch and that battery
should last almost as long as the watch itself. And finally, it must accurately display the time,
consistently, for no one wants a watch that is inaccurate. Each embedded design satisfies its own set
of functions and constraints. This is different from general purpose systems, such as the computer
that sits on a desk in an office. The processor running that computer is termed a ”general purpose”
processor because it was designed to perform many different tasks well, as opposed to an embedded
system that has been built to perform a few specific tasks either very well or within very strict
parameters.
Trends in embedded system:
The following section provides an overview of the emerging technological
trends and implications in the development of embedded systems.
Multi-core processor
8-bit controllers were widespread for quite a long time and are still powering a multitude of
embedded applications, for instance, in home appliances, smartcards and automotive body
electronics. To cater to the need for higher performance, these controllers advanced towards16bit to 32-bit, as used in routers, cell phones and media players.
New applications in the areas of imaging, rendering, compression, multimedia and
recognition demand higher bandwidth, enhanced processing capabilities, quicker response times
and more efficient algorithms. There is a definite requirement of processors with multiple cores
that would improve the throughput of the application while reducing power consumption, cost of
operation and increasing reliability. Thus, semiconductor companies have introduced a single
chip comprising multiple cores. Many of the gaming consoles and network processors use
multicore processors.
During the evolution of the controllers from 8-bit to 32-bit, there were not many
programming or architectural changes except perhaps, the transition to a multi-threaded
architecture. However, multi-core programming requires a paradigm shift for embedded
applications - engineers need to update their architecture, design, programming, debugging and
testing skills to draw the best out of these systems. In the near future, there could be a need to
migrate the existing systems to multi-core platforms so that a genuine multi-processing ability
can be realized by the systems.
These are still early days for the widespread deployment of multi-core processors in
embedded computing. Adoption of these processors will depend how fast the entire
ecosystem responds to the standardization of technology — in terms of debuggers, RTOS,
compilers, integrated development environment (IDE) vendors and programming methodologies.
Companies like QNX, Montavista, Wind River Systems, National Instruments and Mentor
Graphics have taken the lead in defining tools and processes that can be applied to multi-core
systems.
Wireless:
For a long time, embedded devices were mostly operating as stand-alone systems. However, with
the advent of wireless connectivity, the scenario has changed. Both, short-range wireless
protocols like Bluetooth, Zigbee, RFID, near field communications (NFC) and long-range
protocols such as, wireless local area network (WLAN), WiMAX, ong term evolution (LTE) and
cellular communications are bound to witness more widespread applications in the near future.
The recent trends in wireless for use in embedded systems are in the areas of system-on-chip
(SoC) architecture, reduced power consumption and application of short range protocols.
SoC architectures
There have been developments in the architecture of wireless devices targeted towards
low-cost innovative applications. A significant development in this direction is the integration of
a microcontroller with the radio modem in a regular 64-pin out single chip (called systemon-chip architecture). An example of such a device is MC13213 from Freescale. Similar devices
are available from Texas Instruments, Radio Pulse, and other vendors.
Trends and Implications in Embedded Systems Development6
One observation of these devices indicates that few external components are required to design a
platform and the programming paradigm is simple to execute. The critical part in the
development of such devices is the optimization of the printed antenna with the transmitter
and/or receiver. In this case, the conventional RF design methodology needs to be fine-tuned to
get the platform working.
The interconnections from the microcontroller to the radio are internal. In some devices,
sample interconnections are exposed for the purpose of factory testing. The analog and the
digital sections have separate power supply regulators that are internal to the IC. Externally, a
common power source can be used. An optimization cycle gets the platform going and the
components perform continually to ensure that the application development cycle advances
without any further effort towards platform development.
Power consumption
Another key parameter that is used as a differentiator among the available products is ultra-low
power consumption. Zigbee-based applications require battery life to extend up to more than two
years. In this case, smart scheduling of transmission and reception will only help to a certain extent.
The onus is on the device manufacturers to reduce the power consumption, particularly during the
time interval in radio communication. The device should remain in sleep mode the rest of the time.
The current consumption during a radio interface is typically 30–35 mA.
In most of the “sense and transmit” applications, the sensing is scheduled so that the device is mostly
sleeping (for more than 99% of the time) with current consumption of the order of 1–2 uA.
Thus, the sleep mode’s current consumption becomes critical for effective solutions.
Short range protocol:
Short range protocols Zigbee is a consortium of more than 200 major players seeking to tap into the
potential billion-dollar market of wireless sensor networks. The fundamental concept behind this
consortium is interoperability between the devices manufactured by different vendors. To certify a
device as Zigbee-enabled, one needs to comply with certain standards other than the routine RF
regulatory tests. For all such cases, the MAC protocol is the standard defined by IEEE as 802.15.4. It
is possible to define a better algorithm (like an energy-efficient routing protocol for very large
networks) without using either IEEE MAC or the Zigbee stack.
Increased use of open source technology:
Embedded systems have traditionally employed proprietary hardware, software, communication
protocols and home grown operating systems for their development. The payment of royalty to
vendors for using a particular operating system has been a significant overhead faced by the
manufacturers of embedded systems.
This scenario is changing. Embedded Linux is a real time operating system that comes with royaltyfree licenses, advanced networking capabilities and a large base of engineers familiar with the Linux
system. According to a recent report by the VDC Corporation, Embedded Linux (both the free and
the licensed versions) remains an attractive choice for a range of development teams and its use is
poised to see a manifold increase. Even WindRiver, the global leader in device software
optimization, joined the Linux bandwagon in 2005. It now supports both VxWorks and Linux
distributions. Software giant Microsoft, which has a Windows-based system for cellular phones, has
a separate consortium working on an open source Linux-based solution.
An increasing number of manufacturers are providing their source code free of cost to
engineers or other manufacturers. Google has made its Android software—for cellular phones—
available for free to handset makers and carriers who can then adapt it to suit their own devices.
Nokia has concrete plans to make the Symbian OS open source once it completes its acquisition of
Symbian. Increased use of open source technology
Trends and Implications in Embedded Systems Development Eclipse, the open source project for
building development platforms affords an environment that crosses over RTOS boundaries. It
comprises extensible frameworks, tools and runtimes for building, deploying and managing software
throughout its lifecycle.
While open source tools are increasingly being employed in embedded systems development, this by
itself should not be the sole criterion for its selection. Engineers may be tempted to use open source
tools even when it may not be the best possible solution. Further, for any open source tool, there is
always certain tuning required and more so for embedded applications, which are resourceconstrained and have real-time requirements. It is important to weigh all the pros and cons, in terms
of benefits, costs, efforts and facts on a case by case basis.
Security:
In an increasingly interconnected world, security in embedded devices has become critical.
The security requirements for the huge base of connected embedded devices are distinct on account
of their limited memory, constrained middleware, and low computing power. Embedded security is
the new differentiator for embedded devices. Progression in the areas of embedded encryption,
cryptography, trusted computing and authentication.
9) Explain common design metrics.
Ans: Common metrics
–
Unit cost: the monetary cost of manufacturing each copy of the system, excluding NRE
cost
–
NRE cost (Non-Recurring Engineering cost): The one-time monetary cost of designing
the system
total cost = NRE cost +
per-product cost
unit cost * # of units
= total cost / # of units
= (NRE cost / # of units) + unit cost
–
Size: the physical space required by the system
–
Performance: the execution time or throughput of the system
–
Power: the amount of power consumed by the system
–
Flexibility: the ability to change the functionality of the system without incurring heavy
NRE cost
–
Time-to-prototype: the time needed to build a working version of the system
–
Time-to-market: the time required to develop a system to the point that it can be released
and sold to customers
–
Maintainability: the ability to modify the system after its initial release
–
Correctness:Test and Validation
–
safety, many more
Power
Performance
Size
NRE cost
10) What are the special considerations in designing embedded system?
Specifically, special consideration must be given to the following:






Handling of task priority or implicit synchronization
Spinlocks and synchronization
Synchronization between tasks sharing memory
Synchronization between tasks and ISRs sharing memory
Synchronization between ISRs sharing memory
Task-Priority Handling or Implicit Synchronization
In a uniprocessor environment, the software design can assume that a lower-priority task will not
execute when a higher-priority task is ready to execute. In SMP systems, however, the scheduler can
schedule the lower-priority task to another processor. As a result, this assumption is no longer valid. The
design of SMP software must not have any assumptions based on the task priority. In other words, there
should not be any implicit synchronization.
Spinlocks and Synchronization
Spinlock is a special variable that can be used for synchronization between tasks, between tasks and
ISRs, or between ISRs. When a task (or ISR) tries to acquire a spinlock and no other task (or ISR) is
holding that spinlock, it becomes readily available. If any other task (or ISR) tries to acquire this
spinlock, it makes the CPU continuously spin for the lock to be released by the other task (or ISR).
The SMP-capable operating system generally provides two types of spinlocks:
o
Type 1: This type of spinlock is to be used by tasks only. The task spinning on this lock can be
interrupted but not pre-empted.
o
Type 2: This spinlock can be used by both tasks and ISRs. The task spinning on this lock cannot be
interrupted or pre-empted.
Any of the above types of spinlocks can be used based on the design requirements.
Synchronization between Tasks Sharing Memory
In a uniprocessor environment, one and only one task executes at a given point in time. In uniprocessor
systems, raising the task priorities and disabling the interrupts would have handled synchronization
amongst tasks. As tasks of different priorities can execute simultaneously in an SMP system, however,
such implicit locking mechanisms cannot be used. Type 1 Spinlock and other synchronization
mechanisms, such as semaphores, message queues, etc., must be used. Spinlock mechanisms are
supposed to be faster than semaphores or message queues.
Synchronization between Tasks and ISRs Sharing Memory
In a uniprocessor environment, it is a common practice to disable interrupts in the task before accessing
the memory that's shared between the ISR and tasks. In an SMP system, such an approach may lead to
unpredictable behavior. It would disable the interrupt on the CPU on which the task is running while the
ISR may be serviced by another processor. As a result, disabling interrupts cannot be used as a
synchronization mechanism between tasks and ISRs in SMP systems. Instead, Type 2 Spinlock must be
used.
Synchronization between ISRs Sharing Memory
In a uniprocessor environment, synchronization among nested ISRs can be handled by disabling the
interrupts. In an SMP system, however, this approach disables interrupts on the processor on which the
ISR is executing. Meanwhile, another ISR can execute on another processor, which can lead to
unpredictable behavior. Even if the OS provides the support for disabling the interrupts on all of the
processors, it must not be used. Disabling the interrupts could considerably degrade the system
performance. The best way to handle ISR synchronization is to use the Type 2 Spinlock.
Care While Using Spinlocks
If the usage of spinlocks isn't designed properly, it can lead to deadlock situations. Spinlocks must
therefore be used with care. A few considerations should be heeded while using them:
o
A spinlock must not be acquired recursively, as the processor would be continuously spinning on the
lock with no one to release the lock.
o
Spinlocks should be used only to protect a smaller piece of code. Holding a spinlock for longer
durations can lead to slower system performance. (For example, if Task T1 has acquired a spinlock and
another task—T2, executing on another processor—tries to acquire the spinlock, it will not be
available. The CPU spins for the lock to be available. If T1 holds the spinlock for a longer time, the
other processor simply spins, doing nothing effectively.)
o
Acquiring another spinlock while holding a spinlock is allowed, but one must make sure that no other
task or ISR performs a reverse of the same operation. (For example, if Task T1 acquires spinlock s1
and then acquires spinlock s2, and another task—T2—acquires spinlock s2 and spinlock s1, there will
be a deadlock situation.)
What are the important building blocks of embedded system?
Ans:



Microprocessor/ microcontroller
Memory
Register



Ports
Timer
Interrupt
a. Microprocessor/ microcontroller:
The designer of a general-purpose processor builds a device suitable for a variety of
applications, to maximize the number of devices sold. One feature of such a processor is a
program memory – the designer does not know what program will run on the processor, so
cannot build the program into the digital circuit. Another feature is a general datapath – the
datapath must be general enough to handle a variety of computations, so typically has a
large register file and one or more general-purpose arithmetic-logic units (ALUs). An
embedded system designer, however, need not be concerned about the design of a generalpurpose processor. An embedded system designer simply uses a general-purpose processor,
by programming the processor’s memory to carry out the required functionality. Many
people refer to this portion of an implementation simply as the “software” portion.
b. Memory:
While registers serve a processor’s short term storage requirements, memory serves
the processor’s medium and long-term information-storage requirements. We can classify
stored information as either program or data. Program information consists of the sequence
of instructions that cause the processor to carry out the desired system functionality. Data
information represents the values being input, output and transformed by the program.
c. Register:
The assembly-language programmer must know how many registers are available for
general-purpose data storage. He/she must also be familiar with other registers that have
special functions. For example, a base register may exist, which permits the programmer to
use a data-transfer instruction where the processor adds an operand field to the base register
to obtain an actual memory address. Other special-function registers must be known by
both the assembly-language and the structured-language programmer. Such registers may
be used for configuring built-in timers, counters, and serial communication devices, or for
writing and reading external pins.
d. I/O Ports:
The programmer should be aware of the processor’s input and output (I/O) facilities, with
which the processor communicates with other devices. One common I/O facility is parallel
I/O, in which the programmer can read or write a port (a collection of external pins) by
reading or writing a special-function register. Another common I/O facility is a system bus,
consisting of address and data ports that are automatically activated by certain addresses or
types of instructions.
e. Timer:
A timer is a device that generates a signal pulse at specified time intervals. A time
interval is a "real-time" measure of time, such as 3 milliseconds. These devices are
extremely useful in systems in which a particular action, such as sampling an input signal
or generating an output signal, must be performed every X time units.
f. Interrupt:
An interrupt causes the processor to suspend execution of the main program, and
instead jump to an Interrupt Service Routine (ISR) that fulfills a special, short term
processing need. In particular, the processor stores the current PC, and sets it to the address
of the ISR. After the ISR completes, the processor resumes execution of the main program
by restoring the PC.The programmer should be aware of the types of interrupts supported
by the processor (we describe several types in a subsequent chapter), and must write ISRs
when necessary. The assembly-language programmer places each ISR at a specific address
in program memory. The structured-language programmer must do so also; some compilers
allow a programmer to force a procedure to start at a particular memory location, while
recognize pre-defined names for particular ISRs.