ISO/IEC TR 5891:2024

Information security, cybersecurity and privacy protection - Hardware monitoring technology for hardware security assessment

This document surveys and summarizes the existing hardware monitoring methods, including research efforts and industrial applications. The explored monitoring technologies are classified by applied area, carrier type, target entity, objective pattern, and method of deployment. Moreover, this document summarizes the possible ways of utilizing monitoring technologies for hardware security assessment with some existing state-of-the-art security assessment approaches. The hardware mentioned in this document refers only to the core processing hardware, such as the central processing unit (CPU), microcontroller unit (MCU), and system on a chip (SoC), in the von Neumann system and does not include single-input or single-output devices such as memory or displays. The hardware monitoring technology discussed in this document has the following considerations and restrictions: - the monitored target is for the post-silicon phase, not for the design-house phase (e.g. an RTL or netlist design); - monitoring is only applied to the runtime system.

Sécurité de l’information, cybersécurité et protection de la vie privée — Technologie de surveillance des matériels pour l'évaluation de leur sécurité

General Information

• Status: Published
• Publication Date: 02-Apr-2024
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Current Stage: 6060 - International Standard published
• Start Date: 03-Apr-2024
• Due Date: 19-Oct-2022
• Completion Date: 03-Apr-2024

Overview

ISO/IEC TR 5891:2024 is a Technical Report that surveys hardware monitoring technologies relevant to hardware security assessment, cybersecurity and privacy protection. The report focuses on post‑silicon, runtime monitoring of core processing hardware in von Neumann systems - specifically CPUs, MCUs and SoCs - and summarizes both academic research and industrial applications. It classifies monitoring techniques by applied area, carrier type, target entity, objective pattern and deployment method, and explains how monitoring data can support state‑of‑the‑art security assessment approaches.

Key technical topics and requirements

The report does not define prescriptive design rules but organizes and explains technical topics that are essential for practical hardware monitoring and security assessment:

• Purpose categories: security detection, debugging, performance tuning, fault tolerance / QoS, physical specification measurement, and application‑specific monitoring.
• Carrier types: middleware, software-only monitors, and hardware‑assisted monitoring solutions; trade‑offs between software and hardware approaches.
• Target entities: classifications that include IP cores, processing units, memory and peripheral devices as monitoring targets (with emphasis on core processing hardware).
• Objective patterns: information content, physical specification measurements and behavioral monitoring.
• Deployment considerations: intrusiveness, online vs offline use, synchronous/asynchronous monitoring, single vs multiple monitors, scalability, resilience and redundancy, compatibility, impact on performance, and lawful/ethical data handling.
• Relationship to existing standards: links to evaluation and physical security standards such as ISO/IEC 15408 (Common Criteria) and ISO/IEC TS 30104, and discussion of certification issues for monitoring hardware.
• Challenges and limitations: complexity in defining hardware security assessment techniques, and limitations of runtime monitoring (post‑silicon only).

Applications and practical value

Hardware monitoring technologies described in ISO/IEC TR 5891 are practical for:

• Runtime hardware security assessment to detect abnormal state transitions or malicious logic.
• Post‑silicon validation and debug of CPU/SoC behavior under real workloads.
• Performance profiling and tuning for embedded systems and SoCs.
• Fault detection and QoS monitoring in safety‑critical or high‑availability systems.
• Supporting security certification and evidence collection during evaluation.

Who should use this standard

• Security assessors and auditors performing hardware evaluations
• SoC and MCU validation teams (post‑silicon)
• Firmware and middleware developers implementing monitoring
• System integrators and OEMs concerned with runtime security
• Certification bodies and compliance officers
• Security researchers exploring runtime threat detection

Related standards

• ISO/IEC 15408 (Common Criteria)
• ISO/IEC 15408‑3 (relationship discussed in the report)
• ISO/IEC TS 30104 (Physical security attacks and mitigation)
• Other evaluation standards cited: ISO/IEC 19790, ISO/IEC 17825

Keywords: ISO/IEC TR 5891, hardware monitoring, hardware security assessment, runtime monitoring, post‑silicon, CPU MCU SoC, cybersecurity standard.

Standards Content (Sample)

Technical
Report
ISO/IEC TR 5891
First edition
Information security, cybersecurity
2024-04
and privacy protection — Hardware
monitoring technology for
hardware security assessment
Sécurité de l’information, cybersécurité et protection de la
vie privée — Technologie de surveillance des matériels pour
l'évaluation de leur sécurité
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Relationship to existing standards . 2
5.1 Standards of security assessment .2
5.2 Relationship to ISO/IEC 15408-3 .3
5.3 Relationship to ISO/IEC TS 30104 .3
6 Background . 3
6.1 Complexity and security .3
6.2 Challenges in defining hardware security assessment techniques .3
7 Hardware monitoring technologies . 4
7.1 Overview .4
7.2 Research in academic areas .4
7.3 Industrial cases .5
7.4 Purpose .6
7.4.1 Security . . .6
7.4.2 Debugging .7
7.4.3 Tuning performance .8
7.4.4 Fault tolerance and QoS .8
7.4.5 Physical specification measurement .9
7.4.6 Application-specific monitoring .10
7.5 Carrier type .10
7.5.1 Middleware .10
7.5.2 Software .11
7.5.3 Hardware-assisted monitors . 13
7.5.4 Software vs. hardware-assisted solutions .16
7.6 Target entity .16
7.6.1 IP cores .16
7.6.2 Processing units . .17
7.6.3 Memory .17
7.6.4 Peripheral devices .18
7.7 Objective patterns .18
7.7.1 Information content .18
7.7.2 Physical specification .18
7.7.3 Behaviours .18
7.8 Deployment method .19
7.8.1 General .19
7.8.2 Intrusiveness .19
7.8.3 Offline or online .19
7.8.4 Synchronous or asynchronous .19
7.8.5 Single or multiple monitors .19
7.8.6 Scalability .19
7.8.7 Resilience and redundancy . 20
7.8.8 Compatibility . 20
7.8.9 Impact on performance . 20
7.8.10 Lawful and ethical data handling regulations and requirements . 20
8 Utilizing monitoring technologies for hardware security assessment .20
8.1 Existing state-of-the-art security assessment approaches . 20
8.2 How hardware monitoring can help .21

© ISO/IEC 2024 – All rights reserved
iii
8.3 Challenges . 22
9 Certification for monitoring hardware .24
Bibliography .27

© ISO/IEC 2024 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2024 – All rights reserved
v
Introduction
Hardware components and the computing ecosystem are becoming increasingly complex. As a result,
it becomes increasingly difficult to evaluate the security of hardware. Even in the design stage, it is quite
difficult to identify abnormal parts that can cause flaws from among millions of source code lines or billions
of transistors, as well as the physical connections between them. Other areas of technology use monitoring
to assist with the evaluation aiming to mitigate such difficulties. In those technologies, runtime activities
such as changes in internal or external status can be monitored to identify deviations from normal behaviour
patterns, and by these means, the evaluation can focus on a small set of patterns that the monitored
subject typically works with. This method now becomes an available option to assist in hardware security
assessment. In such cases, either the target of security assessment is supposed to be “runtime hardware-
behaviour-based security”, or introduced as a proactive approach to security.
Many evaluation and assessment standards, such as ISO/IEC TS 30104, ISO/IEC 19790 and ISO/IEC 17825,
focus on physical security (invasive/nonintrusive) at the hardware boundary. However, they do not focus on
the monitoring data, either offline or in real time.

© ISO/IEC 2024 – All rights reserved
vi
Technical Report ISO/IEC TR 5891:2024(en)
Information security, cybersecurity and privacy protection —
Hardware monitoring technology for hardware security
assessment
1 Scope
This document surveys and summarizes the existing hardware monitoring methods, including research
efforts and industrial applications. The explored monitoring technologies are classified by applied
area, carrier type, target entity, objective pattern, and method of deployment. Moreover, this document
summarizes the possible ways of utilizing monitoring technologies for hardware security assessment with
some existing state-of-the-art security assessment approaches.
The hardware mentioned in this document refers only to the core processing hardware, such as the central
processing unit (CPU), microcontroller unit (MCU), and system on a chip (SoC), in the von Neumann system
and does not include single-input or single-output devices such as memory or displays.
The hardware monitoring technology discussed in this document has the following considerations and
restrictions:
— the monitored target is for the post-silicon phase, not for the design-house phase (e.g. an RTL or netlist
design);
— monitoring is only applied to the runtime system.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 15408-1, Information security, cybersecurity and privacy protection — Evaluation criteria for IT
security — Part 1: Introduction and general model
ISO/IEC/TS 30104:2015, Information Technology — Security Techniques — Physical Security Attacks,
Mitigation Techniques and Security Requirements
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 15408-1, ISO/IEC TS 30104
and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
hardware monitoring
hardware or software component allowing an individual to monitor devices connected to a computer

© ISO/IEC 2024 – All rights reserved
3.2
runtime hardware-behaviour-based security
function of a hardware that protects running physical devices from harm caused by abnormal or unexpected
state transitions
Note 1 to entry: Such transitions come from vulnerability, non-declarations, or malicious logic.
4 Abbreviated terms
CPU central processing unit
DRAM dynamic random-access memory
EDA electronic design automation
FSM finite state machine
I/O input/output
MCU microcontroller unit
NIC network interface controller
RAS reliability availability and serviceability
RTL register transfer level
SoC system on a chip
JTAG Joint Test Action Group
IP intellectual property
CISC complex instruction set computer
QoS Quality of Service
ISA instruction set architecture
ECC error checking and correction
ROM read-only memory
EEPROM electrically erasable programmable ROM
VMM virtual machine manager
FPGA field programmable gate array
5 Relationship to existing standards
5.1 Standards of security assessment
Existing security assessments and technical standards face challenges in addressing hardware
uncontrollability. ISO/IEC TS 30104, ISO/IEC 19790, and ISO/IEC 17825 focus on (invasive/nonintrusive)
physical security at the hardware boundary, but not over the boundary. ISO/IEC TR 20004 complements
the vulnerability analysis of ISO/IEC 15408-3 from the perspective of software. Among these, there are no
relevant hardware standards.
© ISO/IEC 2024 – All rights reserved
5.2 Relationship to ISO/IEC 15408-3
In ISO/IEC 15408-3, vulnerability assessment is defined. This document aims to survey technologies to
support hardware vulnerability assessment that can be done at runtime.
5.3 Relationship to ISO/IEC TS 30104
This document aims to supplement ISO/IEC TS 30104:2015, 7.2 and 7.3.
6 Background
6.1 Complexity and security
Modern circuits are very complex, and their complexity, amplified by time-to-market pressure, is increasing
rapidly in modern computing environments. Consequently, design houses frequently use external IPs, and
most IC design enterprises are fabless.
The complexity of modern systems increases the attack surface. Because the semiconductor industry
has shifted to a horizontal business model for the integrated circuit supply chain, malicious hardware
(hardware Trojans) can be implanted in untrusted phases or components, e.g. commercial IP cores, EDA
tools, fabrication, and assembly services. Such malicious modifications to the original circuitry are inserted
by adversaries to exploit hardware or to use hardware mechanisms to create backdoors in the design.
6.2 Challenges in defining hardware security assessment techniques
It is difficult to address all such security risks because of the complexity of processes and components,
outsourcing of design and fabrication, and the increase in the sophistication of potential attacks.
For a given piece of hardware, especially a complex system such as a modern SoC, it is also difficult to identify
small malicious modifications to the original design (e.g. at the gate-level netlist). Even with trusted source
code, a piece of hardware cannot be guaranteed to be Trojan-free in the post-silicon phase. Traditional tests
(e.g. function coverage tests, fault tests, and random case tests) are less likely to help with such detection
because hardware Trojans are typically activated, i.e. designed to be activated, by specified conditions, such
as specific sequences of instructions, particular combinations of external signals, a timer, or a temperature
threshold. Adversaries can make the Trojan active and launch attacks, then switch it off during hardware
runtime. In other words, traditional methods of auditing the source code or performing manufacturing fault
detection are ineffective for hardware security assessment.
A hardware Trojan is a malicious inclusion or modification of hardware. A hardware Trojan consists of a
trigger circuit and a payload circuit. The trigger circuit activates the payload circuit under a specific
condition, and the payload circuit implements the malicious behaviour of the hardware Trojan. The
hardware Trojan can leak secret information in the hardware or bypass or disable the security functions of
the hardware.
Hardware Trojan detection is applicable in multiple phases of hardware production and distribution.
For example, detection based on the netlist can be applied in the designing phase. Side-channel and logic
approaches can be applied during the manufacturing or in-use phase. Focusing on the fact that a hardware
Trojan alters the behaviour of the circuit, the side-channel approach detects abnormal behaviour from the
side-channel information. The logic-test-based approach generates test patterns to detect hardware Trojans
via the output. Some state-of-the-art approaches use machine learning technologies to detect hardware
Trojans from the netlist or side-channel information of the hardware.
[99-101]
Hardware flaws, such as Meltdown, Spectre and a series of newly revealed flaws, are a result of
pursuing performance, for instance, parallelism, during microarchitecture development. First, they are
difficult to fix, and the fixes can cost more than the gains from hardware optimization. Second, some of
these flaws exist for approximately 10 to 15 years before they are revealed. Traditional detection in the pre-
silicon phase would be unlikely to help since flaws are not malicious modifications. It is claimed that some
advanced security verification techniques are able to find such flaws by chance early in the design lifecycle.
[102]
However, rather than being used in an evaluation approach, such techniques are more likely to assist

© ISO/IEC 2024 – All rights reserved
in design and are probably not available to third parties. For hardware products with commercial IPs, it is
extremely difficult to apply security assessment to the microarchitecture because of the need to preserve
commercial secrets.
7 Hardware monitoring technologies
7.1 Overview
Hardware monitoring technology began in the computer boom period in the 1980s. It was first used to assist
with debugging and later developed into applications in various fields. However, with the rapid development
of computing hardware and networks, especially the emergence of multicore processors and complex
systems, including multicore processor systems, hardware monitoring technology has also undergone
tremendous changes. While the fast-developing software and hardware environment has led to complex
application functions, it also faces increasingly complex security challenges. In cloud computing-based
systems, runtime stability and security are highly important, as they provide online services nonstop. The
unique runtime characteristics of hardware monitoring technology give it a natural advantage in coping
with these scenarios.
Hardware monitoring has made considerable progress in academic fields and industrial applications. It is
widely used in/for the following areas/purposes:
— security
— debugging and testing
— performance analysis, evaluation, and optimization
— system fault tolerance and reliability
— physical parameter measurement and early warning
Although the focus of this document is hardware security assessment, monitoring techniques used for
other purposes have implications for building assessment models. For example, the technology used for
commissioning and reliability analysis is similar to the technology used for replay in the safety assessment
process; the technology used for performance analysis has some consistency with runtime Trojan-based
hardware detection technology. Therefore, in this document, keywords such as “debug” and “performance”
are widely used in literature searches.
7.2 Research in academic areas
On the academic side, different studies have reviewed monitoring technologies from different perspectives.
[1]
Ian Cassar et al. divided runtime monitoring instrumentation techniques into offline and online categories.
Detailed online segmentation ranges from tightly coupled completely synchronous (CS) monitoring
instrumentation approaches, to loosely coupled completely asynchronous (CA) monitoring approaches.
[2]
Heidar Pirzadeh et al. divided monitoring technologies into software and hardware monitoring
technologies and subdivided software monitoring technologies into add-on monitoring, manual
instrumentation, online instrumentation, instrumenting compilers, interpreter instrumentation and OS
instrumentation. In terms of security, cost, flexibility intrusiveness, performance and broadness, various
monitors were compared horizontally.
[3] [4]
Lihua Gao et al. and Frank Cornelis et al. separately subdivided software runtime monitoring technology.
Reference [3] classifies and discusses the different levels of monitoring objectives (functional, module,
architecture, and subsystem), while Reference [4] focuses on non-deterministic events and addresses the
needs of various technologies for external resources (time, order, language, etc.) for subdivision comparison.
[5]
Georgios Kornaros et al. focused on on-chip monitoring technology in a multicore SoC system and
discussed the monitoring technology in detail from the perspective of function and methodology.

© ISO/IEC 2024 – All rights reserved
7.3 Industrial cases
In terms of industrialization, mainstream chip manufacturers and IT service providers also use hardware
monitoring technology in their products.
®1)
Since 2013, Intel has introduced technology in commercial processors that can be enormously helpful
in debugging because it exposes an accurate and detailed trace of activity and has triggering and filtering
capabilities to help with isolating the important traces.
®2)
AMD has provided a similar technology for monitoring and controlling processors. This custom-built
tool is designed specifically for a proprietary line of devices, thus indicating that the hardware and utility
designers work together to provide the best service for their products.
®3)
ARM designed a set of utilities, including various trace macrocells, system and software measurements
for the ARM processor, and a complete set of IP blocks, to debug and trace the most complex multicore SoC.
There are also hardware monitoring programs that are used to read the main health sensors of PC systems:
voltages, temperatures, powers, currents, fan speed, utilization, and clock speeds during runtime.
Hardware security is a complex concept. The types of hardware are very complex. Figure 1 shows a
comprehensive description of hardware monitoring technologies from five perspectives: target entity,
purpose, carrier, objective patterns and deployment.
1)  This tradename is provided for reasons of public interest or public safety. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO or IEC.
2) This tradename is provided for reasons of public interest or public safety. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO or IEC.
3) This tradename is provided for reasons of public interest or public safety. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO or IEC.

© ISO/IEC 2024 – All rights reserved
Figure 1 — Taxonomy of hardware monitoring technologies
7.4 Purpose
7.4.1 Security
The application of hardware monitoring technology for security purposes mainly aims to compare whether
the running behaviour matches expectations. Then, security control is performed based on the matching
results. Security control can terminate the operation of the system, re-execute the target module, or only
record the current events and status to provide offline analysis or security audits.
According to the various monitoring objectives, different monitoring methods are adopted. From the scope
of division, these methods can be divided into those that monitor a certain key hardware in the system
and those that help ensure the safe operation of the entire system. The security of critical hardware can
be divided into the implementation monitoring of malicious Trojan horses and the vulnerability security
protection of hardware operation mechanisms.
Architecture monitoring support for security usually focuses on achieving tamper resistance and
[6]
encryption. Some built-in on-chip technologies, such as control-flow integrity (CFI), can assist users with
high-performance integrity verification. They focus on the anti-attack capability of the core hardware itself.
[7]
Some technology can help defend against control-flow hijacking malware, for example, indirect branch

© ISO/IEC 2024 – All rights reserved
tracking and shadow stacks. The integrity and timeliness of the CFI shadow stack itself is also a key focus of
[8]
attention.
[9]
For detecting Trojans, some approaches rely on a golden chip through a built-in sensor to monitor the
physical characteristics of some key circuits. If an abnormal voltage or current is found, it is identified as
Trojan horse behaviour. In contrast, some approaches do not require a golden chip. Relying on existing
knowledge, these approaches extract the typical characteristics of hardware Trojans and perform pattern
[10][11]
recognition by using RTL or other hardware descriptions such as netlist. Some state-of-the-art
approaches use machine learning technologies to detect hardware Trojans from the Netlist or side-channel
[12-15]
information of the hardware.
The monitoring of the overall system focuses on the upper-level data and event logic and provides security
monitoring in a way that is easier for users to understand. This monitoring approach is more conducive to
[16]
leading a wider range of non-professional users to take effective security measures. Sentry is a system
which collects data through an internal bus connected to the system to determine attack behaviour and acts
as a data filter between the internal system and the external system, providing effective security control.
Hardware monitoring technologies can also leverage real-time anomaly detection algorithms. These
sophisticated tools are capable of tracking deviations from expected behaviour using statistical models,
machine learning, or artificial intelligence to provide immediate alerts on potential security threats.
The following points are also important to consider for the security of hardware monitoring:
a) The role of hardware monitoring in the era of quantum computing also warrants attention. As quantum
computers pose a threat to existing encryption methods, hardware monitoring can play a critical role in
implementing and ensuring the effectiveness of post-quantum cryptography methods.
b) The Hardware Root of Trust (HRoT) is an essential element of hardware security. HRoT serves as a
starting point for trust, ensuring the integrity and confidentiality of subsequent stages in a system's
operation.
c) Monitoring Hardware Performance Counters (HPCs) can also provide valuable insight into the behaviour
of the system and potential security breaches. Analysis of these counters can reveal abnormal patterns
indicative of malware or hardware Trojans.
d) Use of best practices for hardware monitoring would ensure consistent measurement and comparison
of hardware security across different systems, promoting broader and more effective security practices
industry wide.
7.4.2 Debugging
Hardware debugging, which can monitor the runtime behaviour of hardware, is a hardware implementation
monitoring method. Monitoring and debugging computing, especially of a single processor, has become a
[17][18][19]
mature field of development tools and technologies. The JTAG (Joint Test Action Group) interface is
a common standard approach that is used to verify the design and test the functions of an integrated circuit.
Some well-known processor providers have developed their own tracking functions. JTAG uses boundary-
scan technology, which enables engineers to perform extensive debugging and diagnostics on a system
through a small number of dedicated test pins. Signals are scanned into and out of the I/O cells of a device
serially to control its inputs and test the outputs under various conditions.
In some Intel processors, breakpoints can be set on branches, interrupts and exceptions, and single-step
debugging and analysis can be performed from one branch to the next. The enhancements of such processors
make it possible to create last branch record (LBR) and branch tracking storage (BTS) mechanisms.
4)
Processors based on the Intel Core™ microarchitecture also support precise event-based sampling (PEBS),
which stores a set of additional status information for precise event monitoring.
4) Core is the trademark of a product supplied by Intel. This information is given for the convenience of users of this
document and does not constitute an endorsement by ISO or IEC of the product named. Equivalent products may be used
if they can be shown to lead to the same results.

© ISO/IEC 2024 – All rights reserved
There are several hardware approaches for debugging. If the erroneous behaviour is investigated during
the development of a device, then searching for bugs in silicon is also referred to as post-silicon validation
and debug, or just post-silicon validation. Design-for-debug (DFD) techniques are used to localize functional
bugs through logic probing, scan chains, and real-time trace collection and are commonly referred to as
embedded logic analysis methods. Various approaches address debugging support frameworks and interface
[20][21]
standardization for SoCs and debug structures for instrumentation, such as assertion-based on-chip
[22][19]
debug checkers, triggers, and event counters. Typical post-silicon validation techniques are applied to
record the values of the circuit’s internal signals into an on-chip trace buffer and feed the obtained values
[23]
into a simulation framework to reproduce the erroneous behaviour. Due to the vast amount of debug
[24]
data, it is more efficient to record higher-level information such as instruction footprints for processors.
Even though the power of simulators continues to improve linearly, the inability to adequately simulate all
the possible permutations in the pre-silicon stage has led to alternatives, such as emulation and FPGA-based
prototyping before design completion. Chip instrumentation is the key innovation that has enabled more
efficient observation and verification of sustained functional integration combined with faster internal clock
speeds and complex, high-speed I/O. Moreover, runtime debugging is also becoming increasingly important
for multicore systems, especially for detecting race conditions or deadlocks, requiring architectural
enhancements and tool support.
7.4.3 Tuning performance
Performance monitoring is one of the key goals of computing system design. Performance monitoring
objects include execution time, cache hit/miss, CPU and memory occupancy, and the read and write
performance of key storage devices. Reference [25] divided performance monitoring into four categories:
software, hardware, hybrid and built-in on-chip performance counters. The comparison proved that the
on-chip counter is the most efficient. Currently, all mainstream processors provide performance counters.
However, although the hardware is updated very quickly, the complexity of the system itself also increases
geometrically. The performance counters cannot be used to record all events. Therefore, filtering core data
and events becomes key. Reference [26] first proposed a novel hybrid counter array architecture based on
SRAM arrays and discrete counters, which can track many events concurrently.
Reference [27] divided performance profiles into two categories: time-based profiles and event-based
profiles. A time-based profile relies upon interrupting an application's execution at regular time intervals. To
support event-based sampling (EBS), performance-monitoring hardware typically generates a performance
[28]
monitor interrupt when a performance event counter overflows. Alan Mink et al. proposed a hybrid
performance measurement system that collects data and event samples by embedding hardware on the
motherboard; this system can be used for monitoring multiprocessor performance.
For the multicore SoC platform, Reference [29] presented a performance monitoring unit (PMU) for the SoC
on-chip bus. The PMU can measure major performance metrics, such as bus latency for specific leader requests
and the amount of memory traffic in specific durations. The PMU can also measure the contention of the bus
leaders and followers in the SoC. In addition to studies on performance monitoring for the key hardware in
a system, there have been studies on performance monitoring of an overall system. Reference [30] divided
system monitoring into three steps: system monitoring, system modeling and system improvement. The
authors implemented a tool called Charmonto to monitor software and hardware characteristics and used
it for long-term monitoring. Charmonto can run continuously while sampling various types of hardware
[31]
metrics through performance monitor counters (PMCs) with certain frequencies.
7.4.4 Fault tolerance and QoS
Ensuring system reliability involves multiple abstraction layers, from circuits and microarchitectures to
algorithms and application layers. For this reason, various monitoring methodologies have been developed
across these layers to provide runtime self-diagnosis, adaptivity, and self-healing. The majority of all
mechanisms assume asymmetric reliability, taking the conservative view that some components are almost
fault-free, and thus, these mechanisms are expected to protect individual system components such as buses,
network-on-chip, memories and datapaths against transient or permanent errors. Additionally, monitoring
and diagnostic units have modest performance requirements, so they can operate at low voltage and
frequency, and they usually use aggressive built-in redundancy, making them effectively immune to failure.

© ISO/IEC 2024 – All rights reserved
[32]
However, centralized monitoring schemes represent dependability exposure due to their single points of
failure.
Online monitors aim to extract metrics for accurate determination of ageing models, performing complete
[33]
reliability analysis or providing the reliability characteristics of components. Future architectures
contain components that exhibit varying dependability characteristics, such as processor cores with
different arithmetic precisions and memories with different reliability guarantees. Applications will be
allowed to trade off high hardware reliability for high performance through switching modes in mixed-
[34]
mode multicore systems with reconfigurable dual-modular redundancy. Moreover, by using reliability
annotations, compilers can create a mapping that ensures the assignment of reliability-critical code and data
objects to the most reliable components of a system, or operating systems can perform proactive, reliability-
driven thread migration and shadowing (e.g. shadow threads can be assigned to dependable cores with low
thermal stress).
Many modern embedded and distributed systems (including real-time and non-real-time systems) employ
utilization monitors, rate modulators, or model predictive or workload controllers with feedback control
[35][36]
techniques to ensure quality of service. In response to workload variations in unpredictable
environments, dynamic resource allocation can be used to achieve high processor utilization while still
meeting real-time constraints, to enforce appropriate schedulable utilization bounds, or to handle the system
dynamics caused by load balancing for large-scale server clusters. From a different angle, monitors help
to avoid saturation of processors, which can cause a system crash or severe service degradation. However,
these management approaches based on feedback control require an accurate system model, which can be
difficult to obtain for realistic distributed or multicore embedded systems.
Monitoring for sustaining QoS can be crucial for particular application domains. For instance, servers
providing adaptive video streaming services exploit the inherent adaptiveness of video applications to
perform controlled and graceful adjustments to the perceptual quality of the displayed MPEG video stream
in response to fluctuations in the QoS delivered by the underlying infrastructure. Increased efficiency is
attained when the monitoring service is not platform agnostic. In embedded system design, where the
platform cost and its resources are bounded, quality monitoring and control assisted by the system and in
[37]
synergy with the applications is inevitable.
An individual monitoring component could provide metrics related to QoS to the higher abstract layers of the
system. This information is utilized by the higher layers to analyse and react to QoS variations, for example,
switching to the re
...