Performance, Energy and Resource Optimization

Introduction and Context

Embedded systems are designed to perform a defined function within limits imposed by time, memory, energy, cost, thermal dissipation, reliability, and physical size. Optimization is therefore not equivalent to making a program execute as quickly as possible. A faster implementation may consume more energy, require a larger memory, generate additional heat, or reduce determinism. The engineering objective is to obtain an acceptable balance among competing constraints.

Performance and resource optimization must be evidence-based. Source-code intuition is often unreliable because modern processors use caches, pipelines, branch predictors, DMA engines, interrupts, compilers, and operating-system services. Consequently, optimization requires a measurement methodology, an explicit system model, representative workloads, and quantitative trade-off analysis.

This chapter considers execution time, worst-case execution time (WCET), throughput, latency, memory utilization, energy, power, and thermal behavior. It also explains profiling, benchmarking, optimization strategies, validation, and an illustrative industrial application.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish latency, execution time, throughput, utilization, power, and energy.

2. Estimate and measure WCET while recognizing the limitations of measurement alone.

3. Design meaningful profiling and benchmarking experiments.

4. Analyze static, stack, heap, cache, and DMA memory use.

5. Relate dynamic power, energy, temperature, and workload behavior.

6. Formulate multi-objective optimization problems for embedded systems.

7. Select suitable software, hardware, compiler, and architectural optimizations.

8. Evaluate optimization results without compromising correctness, safety, or real-time guarantees.

1. A System Model for Optimization

A useful abstraction is to represent an embedded application by a workload \(W\), hardware platform \(H\), software configuration \(S\), and operating environment \(E\). Measured behavior can be written conceptually as

\[

Y = F(W,H,S,E),

\]

where \(Y\) may include execution time, memory use, energy, temperature, and output quality. The function is rarely simple: changing a compiler option can alter code layout and cache behavior; increasing clock frequency can reduce execution time but increase power; moving data to a faster memory can improve throughput while increasing energy.

Optimization begins by identifying constraints. Typical hard constraints include:

• deadline: every control iteration must finish before its period;
• memory capacity: code, data, stack, and dynamic allocations must fit;
• energy budget: average or peak energy must remain below a specified limit;
• thermal limit: junction temperature must remain within the device rating;
• reliability and safety: timing and numerical behavior must remain valid;
• throughput: the system must process a required number of samples or frames per second.

Soft objectives may include lower cost, longer battery life, smaller size, better accuracy, or lower average temperature. A practical optimization problem is often expressed as minimizing a weighted objective,

\[

J = w_t T + w_e E + w_m M + w_p P,

\]

subject to hard constraints. Here, \(T\) is a selected time metric, \(E\) energy, \(M\) memory, \(P\) power, and the \(w\)'s are dimension-normalized priorities. A weighted sum is useful for engineering comparison, but it should not replace explicit safety or deadline constraints. When no design dominates all others, the alternatives form a Pareto frontier: improving one objective necessarily worsens at least one other objective.

2. Performance Measures

2.1 Execution time, latency, and throughput

Execution time is the elapsed time required to perform an operation. Latency is the delay between an input event and the corresponding output or response. In a pipeline, latency and throughput differ: a pipeline can have a long end-to-end latency but accept new inputs frequently.

For \(N\) completed operations in elapsed interval \(\Delta t\), average throughput is

\[

X = \frac{N}{\Delta t},

\]

with units such as operations per second, samples per second, or frames per second. If each operation requires a fixed time \(T_o\) and operations are sequential, \(X=1/T_o\). This reciprocal relationship does not apply directly when operations overlap through pipelining, parallelism, DMA, or multiple cores.

For a periodic task with period \(P\), the utilization contribution of task \(i\) is

\[

U_i = \frac{C_i}{P_i},

\]

where \(C_i\) is its execution time per activation. The total utilization is \(U=\sum_i C_i/P_i\), assuming the tasks share a processor and the measured execution times refer to the same scheduling model. Utilization close to one leaves little room for interrupts, operating-system activity, and execution-time variation. A utilization value alone does not prove schedulability; task deadlines, priorities, release jitter, blocking, and scheduling policy must also be considered.

2.2 Best-case, average, and worst-case execution time

Best-case execution time is the shortest time under a defined environment. Average execution time describes expected behavior for a specified workload distribution. WCET is an upper bound on execution time for all permitted inputs and system states under stated assumptions. WCET is not simply the largest value observed in a test run.

Two main approaches are used:

1. Measurement-based analysis. Execute representative and stress workloads, instrument the system, and identify high observations. This is practical and captures hardware interactions, but it cannot prove that untested paths or rare cache states were covered.

2. Static or hybrid analysis. Analyze control-flow paths, instruction timing, caches, pipelines, and bounds, often using tools or abstract interpretation. This can provide stronger guarantees, but may be difficult for complex processors and can produce conservative bounds.

A sound engineering practice combines static reasoning with measurement. The analyst documents assumptions such as processor frequency, cache state, interrupt behavior, compiler version, input bounds, and peripheral timing.

If a task has measured or analytically justified WCET \(C_{wc}\), period \(P\), and deadline \(D\), a necessary condition for a single non-preemptive task is \(C_{wc}\leq D\). For a set of real-time tasks, the appropriate schedulability test depends on the scheduling algorithm. It is unsafe to substitute average execution time for WCET when deadlines are hard.

2.3 Variability and statistical reporting

Measurements should report more than a mean. Useful quantities include minimum, maximum, median, percentiles, standard deviation, and confidence intervals. A percentile is a statistical description, not a hard guarantee. For example, a 99.9th percentile below a deadline still permits occasional larger values unless the application explicitly accepts probabilistic service.

Repeated measurements should control sources of variation: cache warm-up, branch predictor state, interrupt activity, background tasks, thermal state, supply voltage, and measurement overhead. Warm-cache and cold-cache cases may need to be reported separately.

3. Measurement, Profiling, and Benchmarking

3.1 Instrumentation methods

Common methods include:

• Software timers: processor cycle counters, operating-system clocks, or timestamp reads. They are flexible but introduce measurement overhead and may be affected by counter width or frequency changes.
• GPIO tracing: a GPIO is toggled at the start and end of a code region and observed with an oscilloscope or logic analyzer. Pulse width gives elapsed time, while pulse frequency can reveal task rate. This method has low conceptual complexity but includes I/O transition delay.
• Hardware performance counters: counters can record cycles, instructions, cache misses, branch events, stalls, and bus transactions. Events are processor-specific and require careful interpretation.
• Trace and debug units: instruction trace, real-time trace, or sampling profilers reveal control flow with less source modification, but may require specialized hardware and generate substantial data.
• External power measurement: a current shunt, power monitor, or energy analyzer measures supply behavior. It must account for sensor bandwidth, voltage variation, board overhead, and measurement disturbance.

Instrumentation should be validated. For example, if inserting two timestamp reads adds 200 cycles, a measured 100-cycle function cannot be interpreted without correction or a longer repeated measurement.

3.2 Profiling workflow

A disciplined workflow is:

1. Define the workload, constraints, and success metrics.

2. Establish a functional baseline with regression tests.

3. Measure end-to-end behavior and identify dominant regions.

4. Profile time, memory, energy, and hardware events.

5. Form a hypothesis about the bottleneck.

6. Change one important factor at a time where practical.

7. Rebuild, measure, and verify functional equivalence.

8. Test representative, boundary, stress, and fault conditions.

9. Record configuration, tool versions, compiler flags, and environmental conditions.

The phrase “optimize the bottleneck” is important. If a region accounts for fraction \(f\) of total execution time and is improved by speedup \(s\), Amdahl’s law gives the overall speedup

\[

S_{total}=\frac{1}{(1-f)+f/s}.

\]

Here, the non-optimized fraction is \(1-f\), and the optimized fraction becomes \(f/s\). The equation assumes the fractions are measured consistently and that optimization does not alter other costs. For example, if \(f=0.60\) and the region is made twice as fast, \(S_{total}=1/(0.40+0.30)=1.43\), not 2. This result discourages effort spent on small regions unless they affect another constraint such as energy or memory.

3.3 Benchmark design

A benchmark must represent the intended deployment. Synthetic benchmarks are useful for controlled comparisons but may misrepresent data locality, branch behavior, and peripheral interaction. Application benchmarks should include normal, boundary, peak-load, error-recovery, and communication-heavy cases.

Comparisons require controlled variables. The same compiler, optimization level, clock configuration, input data, memory placement, and thermal starting state should be used unless one of these is the variable under study. Results should include uncertainty and be repeated after power cycles or firmware updates when state retention matters.

4. Memory Optimization

4.1 Memory categories

Embedded memory analysis should separate:

• Program memory: instructions, constants, exception tables, and metadata;
• initialized data: variables with startup values copied into RAM;
• zero-initialized data: variables cleared during startup;
• stack: automatic variables, saved registers, and call frames;
• heap: dynamically allocated objects and allocator metadata;
• buffers: communication, audio, image, sensor, and DMA buffers;
• memory-mapped regions: peripheral registers and external devices;
• retained or nonvolatile memory: calibration, logs, and configuration.

A linker map identifies static allocation and section sizes. Stack analysis requires measuring high-water marks or performing a justified static analysis. Filling the stack with a known pattern at boot and later finding the deepest overwritten address provides a practical high-water estimate, although it depends on test coverage. Heap analysis must consider fragmentation, allocation failure, lifetime, and concurrency. In safety-critical systems, static allocation is often preferred because it makes bounds and failure behavior more predictable.

4.2 Memory hierarchy and locality

Access time and energy depend on the memory level. Registers and tightly coupled memory are usually predictable; caches can be fast when data and instructions exhibit locality but introduce hit/miss variability. External memory may provide capacity at the cost of latency, bus energy, and contention.

Important forms of locality are:

• temporal locality: recently used data are likely to be used again;
• spatial locality: nearby addresses are likely to be used;
• instruction locality: loops and compact functions remain in instruction memory or cache.

Data layout can therefore matter as much as algorithmic complexity. Structure-of-arrays layouts may improve vectorization and sequential access, whereas array-of-structures layouts may simplify access to complete records. The correct choice depends on the access pattern.

4.3 Memory optimization techniques

Practical techniques include reducing data width after numerical range analysis, placing time-critical data in predictable memory, reusing buffers with non-overlapping lifetimes, compressing infrequently accessed data, eliminating unused code, selecting suitable library implementations, and avoiding unnecessary copies. DMA can reduce processor copying, but buffers must satisfy alignment, ownership, cache-coherency, and lifetime requirements.

Reducing precision is not automatically safe. Quantization may increase control error, saturate signals, or alter machine-learning classification. Numerical range, error tolerance, overflow behavior, and test evidence must be documented.

5. Energy, Power, and Thermal Behavior

Power is the rate of energy use. For time-varying power \(P(t)\), energy over interval \([t_0,t_1]\) is

\[

E=\int_{t_0}^{t_1}P(t)\,dt.

\]

For approximately constant power, \(E=P\Delta t\). Electrical power for a supply is \(P=VI\\), where \(V\) is voltage and \(I\) current. Units must be consistent: watts equal joules per second, and watt-hours must be converted to joules using \(1\,\text{Wh}=3600\,\text{J}\).

Dynamic CMOS power is commonly approximated by

\[

P_{dyn}\approx \alpha C V^2 f,

\]

where \(\alpha\) is switching activity, \(C\) effective switched capacitance, \(V\) supply voltage, and \(f\) clock frequency. This is a model, not a complete device law. Leakage, short-circuit current, memories, regulators, peripherals, and external components add power. Lowering frequency can reduce dynamic power but lengthen active time; therefore energy does not necessarily decrease unless voltage, workload, and sleep behavior are also considered.

A useful decomposition is

\[

E_{task}=E_{active}+E_{memory}+E_{peripheral}+E_{transition},

\]

where the terms are engineering accounting categories and may overlap depending on the measurement boundary. The boundary must be stated: MCU-only energy differs from energy drawn from the battery because of regulator losses and other board loads.

5.1 Duty cycling and energy per operation

If a device alternates between active and sleep states, average power can be approximated by

\[

P_{avg}=\frac{\sum_i P_i t_i}{\sum_i t_i},

\]

provided the state powers and durations represent the same observation interval. Sleep is beneficial only when wake-up energy, latency, state restoration, and missed events are acceptable.

Energy per operation is

\[

E_{op}=\frac{E}{N},

\]

for \(N\) completed operations measured over the same interval. It is often a better comparison than instantaneous power when implementations have different execution times.

5.2 Thermal model

A first-order steady-state thermal model is

\[

T_j=T_a+P\theta_{JA},

\]

where \(T_j\) is junction temperature, \(T_a\) ambient temperature, \(P\) dissipated power, and \(\theta_{JA}\) junction-to-ambient thermal resistance in degrees Celsius per watt. This model assumes steady state and a specified package, board, airflow, and mounting condition. It is not adequate for short transients or systems with significant thermal capacitance.

A transient lumped model uses thermal resistance \(R_{th}\) and thermal capacitance \(C_{th}\), with time constant \(\tau=R_{th}C_{th}\). A step in power does not produce an instantaneous temperature jump in a real package; temperature approaches a new equilibrium. Detailed systems may require a multi-node thermal network or computational thermal analysis.

Temperature affects leakage, oscillator frequency, timing margins, sensor accuracy, and reliability. Thermal throttling can create a feedback loop: increased workload raises temperature, temperature increases leakage or invokes throttling, and the resulting performance changes timing and energy.

6. Optimization Strategies and Trade-offs

6.1 Algorithmic optimization

Algorithmic complexity often offers the largest gains. Replacing repeated searches with indexed access, reducing redundant transforms, exploiting sparsity, choosing fixed-point arithmetic where justified, or reducing sample rates can lower both execution time and energy. However, asymptotic complexity does not predict all embedded costs: a theoretically superior algorithm may have poor locality, large constant factors, or unsuitable memory requirements.

6.2 Compiler and code optimization

Compiler optimization levels, link-time optimization, inlining, loop transformations, profile-guided optimization, and dead-code elimination can improve performance. Inlining may remove call overhead but increase code size and instruction-cache pressure. Fast-math transformations can violate IEEE numerical semantics and may be unsuitable for control, finance, or safety applications. Every compiler change should be accompanied by numerical and functional regression tests.

Common source-level techniques include reducing unnecessary copying, using appropriate data types, limiting expensive divisions, improving loop locality, batching peripheral transfers, and avoiding unbounded dynamic allocation. Hand-written assembly or intrinsics are justified only when profiling demonstrates a stable bottleneck and the additional maintenance cost is acceptable.

6.3 Hardware and architectural methods

Hardware acceleration, DSP instructions, SIMD, FPGA fabric, DMA, multicore execution, caches, and tightly coupled memory can improve throughput. Their costs include transfer overhead, synchronization, driver complexity, verification effort, power, and sometimes nondeterministic contention. An accelerator is beneficial when computation saved exceeds setup and communication costs.

Clock and voltage scaling can trade performance against power. A design should be evaluated using deadline slack, active energy, sleep energy, and transition overhead—not frequency alone. Peripheral selection and sensor duty cycling may produce greater battery-life gains than optimizing arithmetic instructions.

6.4 Real-time and energy-aware scheduling

Schedulers can exploit slack by running noncritical work at reduced frequency, batching wake-ups, or entering sleep states. Yet batching increases latency and may create burst power or buffer requirements. Priority changes can reduce response time for one task while increasing blocking or delay for another. Optimization must preserve schedulability under worst-case interference, not merely improve average traces.

7. Worked Quantitative Example

Consider a sensor node that processes one sample every 10 ms, so its period is \(P=10\) ms. Its baseline task requires 2.5 ms per sample, giving utilization

\[

U=\frac{2.5}{10}=0.25.

\]

Suppose profiling shows that filtering consumes 60% of execution time. A revised filter is twice as fast. By Amdahl’s law,

\[

S=\frac{1}{(1-0.60)+0.60/2}=\frac{1}{0.70}=1.4286.

\]

The new total execution time is

\[

T_{new}=\frac{2.5}{1.4286}\approx1.75\text{ ms},

\]

and utilization becomes \(1.75/10=0.175\). The optimization creates approximately 8.25 ms of nominal period slack rather than reducing the task to 1.25 ms, because the remaining 40% was unchanged.

Now compare energy. Assume the baseline active power is 120 mW and the node is active for 2.5 ms per sample. Active energy is

\[

E_{active}=0.120\text{ W}\times0.0025\text{ s}=0.00030\text{ J}=300\,\mu\text{J}.

\]

If the optimized implementation consumes 150 mW for 1.75 ms, its active energy is

\[

E_{active,new}=0.150\times0.00175=0.0002625\text{ J}=262.5\,\mu\text{J}.

\]

Thus, despite higher active power, active energy falls by 12.5%. This conclusion excludes sleep-transition energy and any changes in sensor, memory, or regulator consumption; those must be measured separately.

8. Illustrative Case Study: Battery-Powered Vibration Monitor

Background

The following is an illustrative case based on a common industrial embedded application. A battery-powered node samples a motor vibration signal, extracts spectral features, and transmits an alarm or periodic summary. The required sampling rate is 12.8 kHz, the feature result must be available within 50 ms, and the device must operate for at least one year on a fixed battery.

Problem

The first prototype met the functional requirement but failed in three ways: feature extraction occasionally exceeded 50 ms, RAM usage left little margin for communication buffers, and average battery current was higher than the energy budget. Temperature also increased in an enclosed housing during continuous monitoring.

Analysis

Profiling showed that the fast Fourier transform accounted for 68% of CPU time, while data copying between acquisition, processing, and communication buffers accounted for 14%. A trace revealed that cache misses increased when the communication stack was active. A linker map showed that static memory was nearly full, and stack high-water measurements under ordinary tests did not include the diagnostic path. Current measurements separated the sensor, processor, radio, and regulator contributions.

The team identified four distinct bottlenecks rather than assuming that processor speed alone was the solution:

1. arithmetic and transform cost;

2. unnecessary memory movement;

3. excessive radio wake time;

4. continuous active operation.

Approach and solution

The transform was changed to use a library implementation with DSP instructions after numerical equivalence tests. Samples were placed in a double buffer so that DMA could fill one buffer while the processor analyzed the other. Buffer ownership rules and cache maintenance were explicitly implemented. The communication protocol was changed from frequent small transmissions to a scheduled summary packet, subject to alarm-latency requirements.

The processor remained at the original frequency because the optimized transform met the deadline with margin. Between sample blocks, the node entered a low-power state. A watchdog and wake-up deadline were retained to handle abnormal behavior. Stack limits were revised using stress tests that exercised diagnostics, and a runtime allocation failure path was added even though normal operation used static buffers.

Outcome

The optimized design reduced feature-extraction time sufficiently to meet the 50 ms deadline in measured worst-case scenarios, reduced copying, and lowered radio-on time. Average power decreased even though short active intervals had relatively high instantaneous power. Thermal measurements showed a lower steady-state temperature in the enclosure. The final acceptance evidence included timing traces, memory maps, energy measurements at the battery boundary, numerical comparison of features, radio fault tests, and regression tests across compiler and firmware builds.

Learning points

The case illustrates that optimization is a system activity. A faster transform alone would not have solved radio energy, memory margin, or thermal behavior. DMA introduced coherency and ownership obligations. Low-power modes improved average energy but required wake-up analysis. Most importantly, every gain was accepted only after functional, timing, numerical, and reliability verification.

9. Challenges, Limitations, and Governance

Measurement-based optimization can miss rare paths, while static WCET analysis can be overly conservative. Hardware counters may count events ambiguously, and external power measurements can include board components that obscure processor behavior. Thermal results depend strongly on enclosure, airflow, PCB layout, and ambient conditions. Benchmarks may also become obsolete when workloads, compilers, or silicon revisions change.

Optimization may introduce governance risks. Removing checks, weakening authentication, disabling logging, or using undefined behavior can create security and safety vulnerabilities. Energy-saving modes must not compromise emergency response or fail-safe behavior. In regulated products, configuration changes may require traceability, hazard analysis, requalification, and documented verification. Timing and energy traces can contain operationally sensitive information; measurement data should therefore be managed according to security and privacy policies.

Artificial intelligence is relevant when embedded models require optimization. Quantization, pruning, operator fusion, knowledge distillation, and hardware-aware neural architecture search can reduce memory and energy. However, model compression may change accuracy, bias, uncertainty, and behavior on rare inputs. Edge-AI optimization must evaluate accuracy, latency, energy per inference, memory, explainability requirements, and safety—not only benchmark score.

10. Contemporary Developments and Best Practices

Current embedded platforms increasingly combine heterogeneous cores, NPUs, configurable accelerators, memory-protection units, advanced power states, and sophisticated trace facilities. Digital twins and automated design-space exploration can compare frequency, memory placement, accelerator use, and scheduling policies before hardware deployment. Energy harvesting and intermittent computing introduce additional constraints: progress may need to survive power loss, and energy availability becomes a stochastic resource.

Recommended practices are:

• define measurable requirements and the measurement boundary;
• preserve a functional baseline and automated regression suite;
• measure end-to-end behavior before optimizing local code;
• use WCET reasoning for hard real-time constraints;
• report distributions and test conditions, not only averages;
• inspect linker maps, stack margins, heap behavior, and DMA buffers;
• measure energy at the relevant supply boundary;
• test thermal behavior in the intended enclosure and ambient range;
• optimize the dominant bottleneck while checking secondary effects;
• change one major variable at a time when causal interpretation matters;
• retain traceability for compiler, hardware, configuration, and test versions;
• revalidate security, safety, numerical accuracy, and maintainability after optimization.

Chapter Summary

Performance, energy, memory, and thermal behavior are coupled properties of an embedded system. Execution time and throughput must be distinguished from latency, and average measurements must not be confused with WCET. Profiling and benchmarking are useful only when workloads, instrumentation, environmental conditions, and measurement boundaries are controlled and documented. Amdahl’s law demonstrates why optimization should focus on dominant regions.

Memory optimization requires analysis of program sections, stack, heap, buffers, locality, and DMA coherency. Energy is the integral of power over time; reducing power does not necessarily reduce energy unless active duration and transition behavior are also considered. Thermal models connect dissipated power to temperature, but their assumptions must be respected. Algorithmic, compiler, architectural, scheduling, and hardware techniques offer different trade-offs. A defensible optimization preserves functional correctness, real-time guarantees, numerical quality, security, safety, and maintainability.

Key Terms

WCET: An upper bound on execution time under stated assumptions.

Latency: Delay between an event and its corresponding response.

Throughput: Number of completed operations per unit time.

Utilization: Fraction of processor capacity consumed by a task or task set.

Profiling: Measurement and analysis of resource consumption by program regions.

Benchmark: A defined workload used to compare implementations.

Amdahl’s law: Relation showing the maximum overall speedup from improving part of a system.

Cache locality: Tendency of access patterns to reuse nearby or recently used data.

Stack high-water mark: Maximum observed depth of stack usage.

Heap fragmentation: Loss of usable contiguous memory caused by allocation and release patterns.

DMA: Direct memory access that transfers data without continuous processor copying.

Power: Rate of energy consumption, measured in watts.

Energy per operation: Energy consumed divided by the number of completed operations.

Duty cycling: Alternating active and low-power states to reduce average consumption.

Thermal resistance: Temperature rise per unit dissipated power under specified conditions.

Pareto frontier: Set of alternatives for which improving one objective worsens another.

Deadline: Latest acceptable completion time for a task.

Quantization: Representation of numerical values with reduced precision or discrete levels.

Measurement boundary: Explicit definition of which components and energy flows are included in a result.

Review Questions

Short Answer Questions

1. Distinguish execution time, latency, and throughput.

2. Why is the maximum observed execution time not necessarily a WCET guarantee?

3. State two limitations of measurement-based WCET analysis.

4. What information can a linker map provide?

5. Why can reducing clock frequency fail to reduce energy per operation?

Long Answer Questions

1. Explain a complete profiling and benchmarking workflow for a real-time embedded application.

2. Discuss memory hierarchy, locality, cache behavior, and DMA issues in resource optimization.

3. Derive and interpret the dynamic CMOS power approximation, including its limitations.

4. Compare algorithmic, compiler, hardware, and scheduling optimizations.

5. Explain how thermal behavior can affect performance, energy, reliability, and real-time guarantees.

Analytical / Application Questions

1. A task consumes 3 ms every 12 ms. Its dominant region represents 50% of execution time and is improved by a factor of four. Calculate the new total execution time and utilization, assuming all other costs remain unchanged.

2. Design an experiment to compare two firmware versions for latency, energy per operation, memory use, and thermal behavior. Specify controls, measurements, workloads, and acceptance criteria.

3. A battery-powered device meets its deadline but exceeds its energy budget. Propose a prioritized optimization plan and explain the trade-offs and verification evidence required.

Multiple Choice Questions with Answers

Question 1

Which metric is defined as completed operations divided by elapsed time?

A. Latency

B. Throughput

C. Utilization

D. Thermal resistance

Correct Answer: B. Throughput

Question 2

A region accounts for 60% of execution time and is made twice as fast. What is the overall speedup according to Amdahl’s law?

A. 1.25

B. 1.43

C. 1.60

D. 2.00

Correct Answer: B. 1.43

Question 3

Which technique provides a practical estimate of maximum stack depth during tested execution?

A. Counting source-code lines

B. Measuring battery voltage

C. Stack pattern high-water analysis

D. Increasing the heap size

Correct Answer: C. Stack pattern high-water analysis

Question 4

For a time-varying power P(t), which expression gives energy over an interval?

A. E=P/t

B. E=V/I

C. E=∫P(t)dt

D. E=P+ t

Correct Answer: C. E=∫P(t)dt

Question 5

In the approximation P_dyn ≈ αCV²f, which variable represents switching activity?

A. α

B. C

C. V

D. f

Correct Answer: A. α

Question 6

What is a major limitation of using the largest observed execution time as WCET?

A. It always includes all possible input paths

B. It cannot guarantee coverage of untested rare paths

C. It is independent of hardware state

D. It is necessarily more conservative than static analysis

Correct Answer: B. It cannot guarantee coverage of untested rare paths

Question 7

Which optimization most directly reduces unnecessary processor copying between acquisition and processing buffers?

A. DMA double buffering

B. Increasing diagnostic logging

C. Disabling all interrupts

D. Increasing numerical precision

Correct Answer: A. DMA double buffering

Question 8

A task executes for 2.5 ms every 10 ms. What is its processor utilization?

A. 0.025

B. 0.25

C. 2.5

D. 4.0

Correct Answer: B. 0.25

Question 9

The simplified steady-state relation Tj = Ta + PθJA assumes primarily that the system is:

A. At steady state with specified thermal conditions

B. Operating with zero power

C. Using only dynamic power

D. Independent of package and airflow

Correct Answer: A. At steady state with specified thermal conditions

Question 10

Why may an accelerator fail to improve total system performance?

A. It always increases algorithmic complexity

B. Transfer and setup overhead may exceed computation savings

C. It cannot use memory

D. It eliminates all synchronization requirements

Correct Answer: B. Transfer and setup overhead may exceed computation savings