Pith. sign in

REVIEW 2 major objections 4 minor 89 references

A Centralized Performance Monitoring Architecture for Heterogeneous Multicore SoCs

T0 review · 2 major / 4 minor · reviewed 2026-08-08 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that centralizing hardware performance monitoring into an Event-Unit/APMU architecture, with a dedicated side-core processor, delivers microsecond-scale regulation loops and 2-cycle counter reads without perturbing…

desk verdict A real RTL implementation of a centralized monitoring architecture for heterogeneous SoCs; the regulation case study's quantitative claims need held-out validation, but the architecture and artifact are solid and deserve peer review. read the letter →

arxiv 2608.04247 v1 pith:ZCVOV4ID submitted 2026-08-04 cs.AR

Mohammed Sajjad Jafri , Abdur Rahman , Emon Sarkar , Mahdi Hassen , Gopishankar Thayyil , Ashwin Krishna Mani , Rodolfo Pellizzoni This is my paper · ORCID
classification cs.AR
keywords hardwareperformancecounterscentralizedmonitoringeventunitAPMURISC-VmulticoreSoCAXI4snoopingmemorybandwidthregulationreal-timeresourcemanagement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that the usual way of watching what a multicore chip is doing—scattered hardware counters inside each CPU, cache, and memory controller, read by software on the very cores being measured—is the bottleneck. It proposes a centralized alternative: small Event Monitoring Units (EVUs) embedded in each component send structured event packets to an Advanced Performance Monitoring Unit (APMU), which holds programmable counters and a small dedicated processor that filters, correlates, and acts on the data. The claim is that this removes per-sample overhead from application cores, cuts counter-read latency to two cycles, and makes cross-component correlation cheap enough for real-time resource regulation. If correct, it gives RISC-V-class embedded SoCs a unified observability layer they currently lack, demonstrated by a memory-regulation loop that holds execution-time variation to 20.7% under heavy interference.

What carries the argument

The load-bearing object is the EVU-APMU interface together with the APMU itself. Each EVU packages local microarchitectural events into packets carrying an Event ID, an Event Info field with metadata such as transaction size or latency, and a Source ID identifying the core, agent, or privilege context that triggered the event; the logical layer defines these semantics while the physical layer handles signaling and clock-domain crossing through asynchronous FIFOs. The APMU combines programmable counters that filter by Event, Source, and Port IDs and operate in simple-count or functional modes (accumulate, conditional increment, keep-min/keep-max) with a lightweight RISC-V processing element extended by custom instructions for two-cycle counter reads and writes and for Wait-for-Pending/Wait-for-Overflow synchronization. This lets monitoring policies run as load-and-run components on the APMU-PE rather than as application code or kernel modules, so all filtering, correlation, and control logic stays off the application cores.

What would settle it

Run the regulation case study with a held-out interference workload whose mix of LLC reads/writes and memory reads/writes differs from the four synthetic stressors, using the Table III coefficients; if the weighted memory activity no longer keeps execution-time variation near 20.7% or the token-bucket overshoot exceeds the per-period total budget (68.8 tokens), the generalizability claim is refuted.

Watch

Extended reading notes

Core claim

The paper's central discovery is that decoupling event generation from event processing resolves the three chronic limitations of distributed hardware performance counters: monitoring overhead and interference on application cores, temporal skew when correlating counters across subsystems, and fragmented software interfaces. In the proposed architecture the APMU-PE acts as a specialized side core executing monitoring and control logic directly inside the monitoring subsystem, waking through Wait-for-Pending and Wait-for-Overflow instructions only when selected counters change. The prototype shows one regulation-loop iteration costs 1,039 cycles (3.02 $\mu$s at 344 MHz), counter reads take 2 cycles, and a 25% bandwidth allocation keeps the largest execution-time variation at 20.7%, versus 138.9% without regulation. Function-level profiling via PC markers attributes counter deltas exactly to code regions with no binary modification and no application-core overhead, separating stable access counts from inflated latency metrics under interference.

Load-bearing premise

The regulation coefficients in Eq. (1) and Table III are fitted using the same synthetic stressor benchmarks that later serve as interference, so if those coefficients do not represent other memory-access mixes, the reported 20.7% execution-time stability bound and the -55-token overshoot do not generalize.

Editorial extensions

If this is right

  • Regulation loops can run at microsecond granularity (3.02 $\mu$s per iteration) with 2-cycle counter reads, shrinking the overshoot window that polling-based regulators suffer.
  • Application cores see no per-sample overhead regardless of sampling rate, because monitoring code runs on the APMU-PE and wakes only on hardware events.
  • Profiling and counter attribution require no binary instrumentation or traps: entry and exit program counters are loaded into the EVU, and counter deltas are scoped exactly to function windows, eliminating interrupt skid.
  • The architecture is extensible: custom monitors, such as hardware contention-tracking units, can be wrapped as EVUs, and OS or hypervisor access can be gated through MMU, IOMMU, and IOPMP so the APMU acts as a safe active control agent.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: the same centralized event pipeline could serve security monitoring, for example detecting cache side-channel activity or cryptomining by correlating LLC and memory events, because the APMU-PE offloads the analysis from application cores.
  • Beyond the paper: if the regulation coefficients do not generalize, the programmable counters and processing element make retuning cheap, suggesting the durable contribution is the infrastructure rather than the specific 20.7% bound.
  • Beyond the paper: a hardware token bucket or dedicated throttle logic inside the APMU could shorten the 1,039-cycle loop further, since the loop is currently software running on a small core.
  • Beyond the paper: the standardized EVU-APMU interface could serve as an open interface for non-core monitors such as GPUs, DMA engines, and accelerators on RISC-V platforms, giving them a single access path similar to x86 uncore PMUs.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 4 minor

Summary. The paper proposes a centralized performance monitoring architecture for heterogeneous multicore SoCs, consisting of distributed Event Monitoring Units (EVUs) that capture microarchitectural events and forward them over a standardized interface to a central Advanced Performance Monitoring Unit (APMU). The APMU combines programmable counters with a lightweight processing element (APMU-PE) to perform filtering, aggregation, correlation, and control actions without involving application cores. The authors implement an RTL prototype with AXI4 Snooping Units (SPUs) and CV A6-EVUs, integrate it into a quad-core PULP-based RISC-V platform, and evaluate it on FPGA and ASIC (22 nm) flows. Two case studies are presented: a token-bucket memory bandwidth regulator inspired by MemPol, and function-level profiling/counter attribution via PC markers. Reported results include 2-cycle counter reads, a 1,039-cycle regulation iteration (3.02 us at 344 MHz), a maximum 20.7% execution-time variation under 25% bandwidth regulation, and accurate per-function counter attribution with no binary modification.

Significance. If the reported results hold, the paper makes a useful contribution: a concrete, open-source RTL implementation (Zenodo artifacts [87], [88]) of a centralized side-core monitoring architecture that can be integrated into a real RISC-V platform. The hardware resource numbers (APMU at 4.49% of FPGA LUTs, no critical-path impact in ASIC) and the synthetic validation of counter attribution are strengths. The architecture's decoupling of event generation from processing addresses a real gap in embedded SoC observability. However, the quantitative claims of the regulation case study, and the lossless-collection scope, need additional validation before the results can be taken as general.

major comments (2)
  1. [Section VI-C, Eq. (1) and Table III] The four activity coefficients (alpha_LLCr=1, alpha_LLCw=0, alpha_MMr=0.612, alpha_MMw=0.440) are computed by equating the cumulative memory activities of the four synthetic stressor benchmarks LLCr, LLCrw, MMr, and MMrw. The regulation experiments in Figures 7 and 8 then use exactly the same four synthetic benchmarks as the interfering cores, with SDVB workloads only as the core under analysis. The reported maximum 20.7% execution-time variation and -55 token overshoot are therefore in-sample (resubstitution) estimates: the regulator has been calibrated on the same interference classes on which it is evaluated. The claim that the approach 'effectively stabilizes the execution time of a task under analysis independently from the activity of interfering cores' is not supported beyond these four stressor patterns. Please add a held-out interference workload (for example, SDVB benchmarks as interferers or a mixed synthetic pattern) to demonstrate generalization, or explicitly scope the stability claim to the evaluated interference set.
  2. [Section IV-A and Section VI-A] The paper acknowledges that 'event loss cannot be prevented if the long-term event production rate exceeds the APMU frequency.' In the ASIC implementation, the core-side SPUs run at 800 MHz while the APMU runs at 344 MHz, and the CDC FIFO depth of 3 is validated only with the four synthetic memory stressors. This does not establish lossless collection for arbitrary workloads or for maximum-rate event streams (for example, one AXI transaction per cycle), so the 'low-latency event collection' part of the central claim remains unproven beyond the tested benchmarks. Please provide an event-rate analysis or a stress test at the maximum sustainable event rate, and state the lossless-collection scope accordingly.
minor comments (4)
  1. [Section VI-B] In the Synthetic Benchmarks paragraph, 'benckmark' should be 'benchmark'.
  2. [Section VI-C, Figure 7] The caption says the trace exhibits 'LLC writes, then memory writes, then LLC writes again,' but the text does not identify which synthetic benchmark is being regulated or the exact configuration (polling period P, token bucket depth w, and budget) used for the trace; please state these details in the caption or surrounding text.
  3. [Section VI-D] The validation of the attribution mechanism reports that measured counter deltas differed by at most 1 from expected values, but it does not specify the number of trials or the source of the one-count discrepancy; a brief explanation would clarify the precision of the result.
  4. [Section IV-C and Section VI-C] The statement that 'the application cores only involvement in the regulation/monitoring loop is in loading the policy into the APMU-PE's instruction scratchpad' is contradicted by the regulation mechanism described in Section VI-C, where the APMU raises interrupts through the PLIC and the application core executes a lightweight ISR to halt itself. Please qualify the statement to exclude the enforcement interrupt handler or clarify that the ISR is not part of the monitoring loop.

Circularity Check

2 steps flagged · score 6.0 of 10

Regulation case-study effectiveness is partly circular: the alpha coefficients are calibrated by equating memory activity across the four synthetic stressors, and the 'constant weighted average' and 20.7% stability are then demonstrated using those same stressors as interference.

  1. self definitional [Section VI-C, 'Computing the coefficients' (Eq. (1), Table III) and 'Effectiveness of regulation' (Figure 7 discussion)]
    "We then compute the coefficients by equating the derived cumulative memory activity for each of the four cases: ... For similarity with [10], we set α LCCr = 1 and then derive the other 3 parameters based on Equation 1. ... When memory write activity increases, the number of individual counter events decreases accordingly; yet the weighted average remains constant throughout. This demonstrates that our regulation correctly accounts for the different costs of LLC versus memory traffic."

    The alpha coefficients are not independently measured; they are the solution to the constraint that total weighted memory activity A_i(t) be equal across the four synthetic stressor classes (LLCr, LLCrw, MMr, MMrw). Eq. (1) literally equates the derived cumulative memory activity for the four cases and solves for alpha. Therefore the observation that the 'weighted average remains constant' across those same stressor phases is the calibration constraint restated, not an empirical validation of the cost model. The constant-weighted-average claim is true by construction for the calibration benchmarks.

  2. fitted input called prediction [Section VI-C, 'Computing the coefficients' versus 'Effectiveness of regulation' (Figures 7-8)]
    "To compute coefficients α LLCr, α LLCw, α MMr, α MMw, we thus use the following approach: we execute on all cores one of the four synthetic benchmarks, and measure the cumulative bandwidth of LLC reads, LLC writes, MM reads and MM writes over all cores. We then compute the coefficients by equating the derived cumulative memory activity for each of the four cases: ... Figure 8 shows the effects of regulation on SDVB benchmarks ... running together with 3 synthetic stressors ..."

    The four activity weights are calibrated on the same four synthetic stressor benchmarks that later constitute the interference in the regulation experiments; the SDVB benchmarks appear only as the core under analysis, never as interferers. The reported 20.7% execution-time variation and the related overshoot bound are therefore resubstitution statistics on the calibration workload family: the regulator has been tuned to treat exactly the traffic classes on which it is scored. No held-out interference workload is used, so the case study cannot support generalization of the quantitative stability claim beyond the calibrated stressor mix.

full rationale

The core architecture claims are not circular: the APMU, EVUs, and SPUs are implemented in RTL and measured against external function-level expectations, the profiling case study is validated with known event counts, and the resource-utilization and loop-latency numbers are independent implementation measurements. The paper also does not rely on load-bearing self-citation; the cited prior work (MemPol, BRU, coherence-aided regulation) is external, and the self-cited artifact links are not used as evidence for the architecture's validity. However, the memory-regulation case study is partially self-referential. Equation (1) fits the four activity coefficients by equating the weighted memory activity of the four synthetic stressor classes, and then Figure 7's 'weighted average remains constant' observation is simply that same equality displayed as a trace. Likewise, the 20.7% execution-time stability bound in Figure 8 is obtained with those same synthetic stressor classes as the interfering cores, making it an in-sample result rather than a generalization to arbitrary memory-access mixes. The paper explicitly acknowledges a related limitation in Section IV-A: event loss cannot be prevented if long-term production exceeds APMU frequency, and the FIFO depth of 3 is validated only on the synthetic stressors. These issues affect the generality of the regulation case study, but they do not undermine the independent, externally verified architecture and profiling contributions. Overall, partial circularity in the regulation case study warrants a score of 6.

Assumptions & free parameters 7 free parameters · 5 assumptions · 2 invented entities

Central design is an engineering architecture rather than a derivation, so the ledger is dominated by platform assumptions and configuration choices. The only fitted quantities in the paper are the four regulation coefficients, which are calibrated from the same synthetic benchmarks later used as interference. The invented entities, EVUs and APMU, are supported by shipped RTL artifacts, so they carry reproducibility evidence but no independent external validation.

free parameters (7)
  • alpha_LLCr (anchor) = 1 (chosen)
    Set to 1 in Eq. (1) so the other coefficients are relative weights; this normalization is a free choice.
  • alpha_LLCw = 0
    Solved from Eq. (1) using measured cumulative bandwidths of the four synthetic stressor benchmarks.
  • alpha_MMr = 0.612068966
    Solved from Eq. (1) using the same measured bandwidths.
  • alpha_MMw = 0.439655172
    Solved from Eq. (1) using the same measured bandwidths.
  • regulation period P = 2000 cycles
    Chosen for the token bucket in the Figure 8 evaluation; it directly affects overshoot and latency numbers.
  • token bucket depth multiplier w = 2
    Maximum bucket level is w times per-period budget; a configuration choice, not optimized or swept.
  • EVU-APMU CDC FIFO depth = 3
    Determined empirically from functional simulations with memory stressors (Section VI-A); sufficient for the tested event rates but not for all rates.
assumptions (5)
  • domain assumption AXI4 SPU routing does not alter functional behavior of the monitored bus.
    Section V-A routes the original bus through SPU logic and asserts no functional change, but provides no equivalence proof or timing impact analysis.
  • domain assumption The long-term event production rate at each EVU stays below the APMU processing frequency.
    Section IV-A states event loss cannot be prevented if the long-term rate exceeds APMU frequency; the prototype relies on this holding and a FIFO depth of 3.
  • domain assumption CV A6 commit PC and acknowledge signals are accurate enough for PC-marker attribution.
    Section V-B and VI-D use pipeline commit signals to scope function-level counters; validation is limited to synthetic tests with deltas at most 1.
  • domain assumption RISC-V HPCs on the target platform do not support counter-overflow interrupts.
    Section II-A states this limitation for Zicntr, Zihpm, and CV A6 and uses it to justify polling-based regulation; broader RISC-V extensions are not discussed.
  • ad hoc to paper Coefficients fitted to the four synthetic benchmarks are representative of contention costs for other workloads.
    Eq. 1 equates measured bandwidths of the stressors to solve alpha; the regulation evaluation then uses those stressor classes as interference, so generalizability is assumed rather than tested.
invented entities (2)
  • Event Monitoring Unit (EVU) independent evidence
    purpose: Captures microarchitectural events at each IP and transmits standardized event packets to the APMU.
    Two concrete implementations, the AXI4-SPU and CVA6-EVU, plus open-source RTL are provided, so the design can be externally synthesized or simulated; no external validation is reported.
  • Advanced Performance Monitoring Unit (APMU) independent evidence
    purpose: Central aggregation, programmable counters, and a dedicated processing element for monitoring and control policies without using application cores.
    Full RTL, resource utilization, frequency, and functional measurements are given, giving external falsifiable handles; the evaluation is still from the authors' own implementation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Centralized Performance Monitoring Architecture for Heterogeneous Multicore SoCs." pith.science (2026). https://pith.science/paper/ZCVOV4ID

@misc{pith2026260804247,
  author       = {Pith},
  title        = {Pith review of: A Centralized Performance Monitoring Architecture for Heterogeneous Multicore SoCs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZCVOV4ID}},
  note         = {Machine review of arXiv:2608.04247}
}
read the original abstract

Hardware Performance Counters (HPCs) are widely used to enable event-driven software mechanisms such as profile guided optimization, performance analysis, and dynamic resource management in real-time systems. However, in modern embedded System-on-a-Chip (SoCs), different components - including processors, accelerators, interconnects, and memory controllers - typically implement separate and heterogeneous HPC modules. This distributed monitoring infrastructure requires multiple software interfaces and complicates the collection, synchronization, and correlation of performance data across the system. In this work, we propose a centralized performance monitoring architecture to efficiently collect, correlate, and process architectural events across multiple hardware components. Our design introduces Event Monitoring Units (EVUs) that capture and forward microarchitectural events to an Advanced Performance Monitoring Unit (APMU). The APMU integrates programmable counters and a specialized processing element to support flexible, event-driven software mechanisms. We implement our design for an AXI4-based system and integrate it into a RISC-V based SoC platform, which lacks advanced cross-component performance monitoring support. We demonstrate the effectiveness of our approach through case studies on real-time resource regulation, application profiling, and counter attribution.

Figures

Figures reproduced from arXiv: 2608.04247 by the authors.

Figure 1
Figure 1. Each EVU is placed close to a hardware IP block [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. APMU Block Diagram with M EVUs. Functional decomposition. The APMU exposes two pri￾mary capabilities: (1) event aggregation & selection, (2) pro￾grammable counting & analysis. Event aggregation collects incoming packets from multiple EVU ports and applies pro￾grammable selection criteria (Event ID, Source ID, context identifiers) so that downstream logic only processes relevant data. Programmable counters support bo… view at source ↗
Figure 3
Figure 3. SPU Block Diagram. Event Event Info No event NA Read request Size of transaction, unaligned transfer Write request Read response Request latency, clock spent in contention Write response TABLE I: AXI4 SPU Event Table B. CVA6 Event Unit (CVA6-EVU) The RISC-V CVA6 core [73] is used as our application core. The CVA6 core exposes its native PMU signals as micro￾architectural event outputs. Our lightweight EVU wrapper si… view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Simplified view of the PULP-based platform. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Contention Results: Synthetic Benchmarks. Latency is [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: Contention Results: SDVB Benchmarks (sim input). [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Memory regulation trace under 25% bandwidth allo [PITH_FULL_IMAGE:figures/full_fig_p012_7.png]
Figure 8
Figure 8. Figure 8: Regulation results: SDVB Benchmarks (sim input). [PITH_FULL_IMAGE:figures/full_fig_p012_8.png]
Figure 9
Figure 9. Figure 9: Per-iteration breakdown of findDisparity(). Store count drops sharply after iterations C0–C1, indicating most pixels find their best stereo match early. than trapping to the kernel. Since the binary must be modified and rebuilt based on the profiled function(s), we arg…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

89 extracted references · 79 canonical work pages

  1. [87]

    M. S. Jafri et al. he-soc: Centralized Performance Monitoring on a PULP-based SoC (EMSOFT 2026 artifact). Zenodo, https://doi.org/10. 5281/zenodo.21543104, 2026

    work page 2026

  2. [88]

    M. S. Jafri et al. APMU Software: Bare-metal case-study software (EM- SOFT 2026 artifact). Zenodo, https://doi.org/10.5281/zenodo.21543106, 2026

    work page doi:10.5281/zenodo.21543106 2026

  3. [1]

    https://developer.arm.com/documentation/ddi0598/ latest/

    Memory system resource partitioning and monitoring (MPAM), for A- profile architecture. https://developer.arm.com/documentation/ddi0598/ latest/

  4. [2]

    https://www.intel.com/content/www/us/en/architecture-and-technology/ resource-director-technology.html

    Intel Resource Director Technology (RDT) Framework. https://www.intel.com/content/www/us/en/architecture-and-technology/ resource-director-technology.html

  5. [3]

    AXI performance monitor, Zynq UltraScale+ Device Tech- nical Reference Manual (UG1085)

    AMD Xilinx. AXI performance monitor, Zynq UltraScale+ Device Tech- nical Reference Manual (UG1085). https://www.xilinx.com/products/ intellectual-property/axi perf mon.html

  6. [4]

    Kanev et al

    S. Kanev et al. Profiling a warehouse-scale computer.SIGARCH Comput. Archit. News, 43(3S):158–169, 2015

    2015

  7. [5]

    Adl-Tabatabai et al

    A.-R. Adl-Tabatabai et al. Prefetch injection based on hardware monitoring and object metadata.SIGPLAN Not., 39(6):267–276, 2004

    2004

  8. [6]

    Oh et al

    D.-J. Oh et al. MaPHeA: A framework for lightweight memory hierarchy-aware profile-guided heap allocation.ACM Trans. Embed. Comput. Syst., 22(1), 2022

    2022

Show all 89 references
  1. [7]

    Yun et al

    H. Yun et al. MemGuard: Memory bandwidth reservation system for efficient performance isolation in multi-core platforms. InRTAS, pages 55–64, 2013

    2013

  2. [8]

    M. G. Bechtel and H. Yun. Denial-of-service attacks on shared cache in multicore: Analysis and prevention.CoRR, abs/1903.01314, 2019

    1903 arXiv

  3. [9]

    Dagieu et al

    N. Dagieu et al. Memguard: Memory bandwidth management in mixed criticality virtualized systems. 2016

    2016

  4. [10]

    Z ¨upke et al

    A. Z ¨upke et al. MemPol: Policing core memory bandwidth from outside of the cores.Real-Time Systems, 2024

    2024

  5. [11]

    Saeed et al

    A. Saeed et al. Memory Latency Distribution-Driven Regulation for Temporal Isolation in MPSoCs. InECRTS, pages 4:1–4:23, 2023

    2023

  6. [12]

    Farshchi et al

    F. Farshchi et al. BRU: Bandwidth regulation unit for real-time multicore processors. InRTAS, pages 364–375, 2020

    2020

  7. [13]

    Na et al

    S. Na et al. Common counters: Compressed encryption counters for secure GPU memory. InHPCA, pages 1–13, 2021

    2021

  8. [14]

    Barrera et al

    J. Barrera et al. Contention tracking in GPU last-level cache. InICCD, pages 76–79, 2022

    2022

  9. [15]

    Roy et al

    P. Roy et al. Designing secure performance metrics for last level cache. InIPDPSW, pages 383–392, 2023

    2023

  10. [16]

    P. P. Bhade and S. Sinha. Detection of cache side channel attacks using thread level monitoring of hardware performance counters. InMCSoC, pages 210–217, 2021

    2021

  11. [17]

    Pradhan et al

    A. Pradhan et al. Predictable memory bandwidth regulation for Dy- namIQ Arm systems. InRTCSA, pages 126–137, 2025

    2025

  12. [18]

    Chen et al

    J. Chen et al. CARE: Coordinated augmentation for elastic resilience on DRAM errors in data centers. InHPCA, pages 533–544, 2021

    2021

  13. [19]

    https://perf.wiki.kernel.org/index.php/Main Page

    Perf wiki. https://perf.wiki.kernel.org/index.php/Main Page

  14. [20]

    R ¨ohl et al

    T. R ¨ohl et al. Overhead analysis of performance counter measurements. InICPPW, pages 176–185, 2014

    2014

  15. [21]

    Lo et al

    D. Lo et al. Run-time monitoring with adjustable overhead using dataflow-guided filtering. InHPCA, pages 662–674, 2015

    2015

  16. [22]

    https:// www.man7.org/linux/man-pages/man1/perf-stat.1.html, 2024

    Linux man-pages project.perf-stat(1) Linux manual page. https:// www.man7.org/linux/man-pages/man1/perf-stat.1.html, 2024. Accessed: 2026-06-05

    2024

  17. [23]

    Gottschall et al

    B. Gottschall et al. TIP: Time-proportional instruction profiling. In MICRO, pages 15–27, 2021

    2021

  18. [24]

    Yi et al

    J. Yi et al. On the precision of precise event based sampling. InAPSys, pages 98–105, 2020. 14

    2020

  19. [25]

    Das et al

    S. Das et al. SoK: The challenges, pitfalls, and perils of using hardware performance counters for security.IEEE S&P, pages 20–38, 2019

    2019

  20. [26]

    https://developer.arm.com/Architectures/ CoreSight%20Architecture

    CoreSight architecture. https://developer.arm.com/Architectures/ CoreSight%20Architecture

  21. [27]

    Intel® 64 and IA-32 Architectures Soft- ware Developer’s Manual, V olume 3 (3A, 3B, 3C & 3D): Sys- tem Programming Guide

    Intel Corporation. Intel® 64 and IA-32 Architectures Soft- ware Developer’s Manual, V olume 3 (3A, 3B, 3C & 3D): Sys- tem Programming Guide. https://cdrdv2-public.intel.com/843836/ 325384-sdm-vol-3abcd-dec-24.pdf, 2024

    2024

  22. [28]

    Arm Architecture Reference Manual Supplement: Sta- tistical profiling extension, for Armv8-A

    Arm Ltd. Arm Architecture Reference Manual Supplement: Sta- tistical profiling extension, for Armv8-A. https://developer.arm.com/ documentation/109429/0100/, 2017

    2017

  23. [29]

    https://developer

    AMBA AXI and ACE protocol specification issue f.b. https://developer. arm.com, 2017

    2017

  24. [30]

    Waterman et al.The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213

    A. Waterman et al.The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213. 2019

    2019

  25. [31]

    Zicntr” and “Zihpm

    “Zicntr” and “Zihpm” counters — RISC-V extension. https://wiki.riscv. org/display/HOME/Ratified+Extensions, 2023

    2023

  26. [32]

    https://developer.arm.com/documentation/100095/0003/?lang=en

    ARM Cortex-A72 MPCore Processor Technical Reference Manual. https://developer.arm.com/documentation/100095/0003/?lang=en

  27. [33]

    https://www.intel.com/content/www/us/en/developer/articles/technical/ intel-sdm.html

    Intel 64 and IA-32 Architectures Software Developer Manuals. https://www.intel.com/content/www/us/en/developer/articles/technical/ intel-sdm.html

  28. [34]

    https://riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+ Technical+Specifications, 2024

    RISC-V capacity and bandwidth QoS register interface (CBQRI). https://riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+ Technical+Specifications, 2024

    2024

  29. [35]

    https://wiki.riscv.org/ display/HOME/Ratified+Extensions, 2024

    RISC-V quality-of-service (QoS) identifiers. https://wiki.riscv.org/ display/HOME/Ratified+Extensions, 2024

    2024

  30. [36]

    Torvalds and Linux Kernel Contributors

    L. Torvalds and Linux Kernel Contributors. Linux kernel perf events directory. https://github.com/torvalds/linux/tree/master/kernel/ events, 2024

    2024

  31. [37]

    Browne et al

    S. Browne et al. A portable programming interface for performance evaluation on modern processors.Int. J. High Perform. Comput. Appl., 14(3):189–204, 2000

    2000

  32. [38]

    Reinders.VTune Performance Analyzer Essentials

    J. Reinders.VTune Performance Analyzer Essentials. Intel Press, 2005

    2005

  33. [39]

    Tutorial: Linux kernel profiling with perf

    Perf Wiki. Tutorial: Linux kernel profiling with perf. https://perf.wiki. kernel.org/index.php/Tutorial, 2023

    2023

  34. [40]

    uncore(5) — uncore performance coun- ters

    Hewlett Packard Enterprise. uncore(5) — uncore performance coun- ters. HPE Cray Programming Environment Documentation, ver- sion 24.03, 2023. https://cpe.ext.hpe.com/docs/24.03/performance-tools/ man5/uncore.html, accessed 2026-06-17

    2023

  35. [41]

    NVIDIA Nsight Systems

    NVIDIA Corporation. NVIDIA Nsight Systems. https://developer. nvidia.com/nsight-systems, 2024

    2024

  36. [42]

    Yang et al

    Y . Yang et al. Exploration and exploitation of hidden PMU events. arXiv:2304.12072, 2023

    2023 arXiv

  37. [43]

    Li et al

    A. Li et al. Tintin: a unified hardware performance profiling infrastruc- ture to uncover and manage uncertainty. InOSDI, 2025

    2025

  38. [44]

    G. W. Dunlap et al. ReVirt: enabling intrusion analysis through virtual- machine logging and replay.SIGOPS Oper. Syst. Rev., 36(SI):211–224, 2003

    2003

  39. [45]

    O’Callahan et al

    R. O’Callahan et al. Engineering record and replay for deployability. In USENIX ATC, pages 377–389, 2017

    2017

  40. [46]

    Bhatia et al

    S. Bhatia et al. Lightweight, high-resolution monitoring for troubleshoot- ing production systems. InOSDI, pages 103–116, 2008

    2008

  41. [47]

    T. A. Khan et al. DMon: Efficient detection and correction of data locality problems using selective profiling. InOSDI, pages 163–181, 2021

    2021

  42. [48]

    Zhai et al

    Y . Zhai et al. HaPPy: hyperthread-aware power profiling dynamically. InUSENIX ATC, pages 211–218, 2014

    2014

  43. [49]

    Dasari et al

    D. Dasari et al. Response time analysis of COTS-based multicores considering the contention on the shared memory bus. InIEEE TrustCom, pages 1068–1075, 2011

    2011

  44. [50]

    D ´ıaz et al

    E. D ´ıaz et al. Modelling multicore contention on the AURIX™ TC27x. InDAC, pages 1–6, 2018

    2018

  45. [51]

    Program instrumentation options

    GCC Team. Program instrumentation options. Using the GNU Compiler Collection (GCC), 2024. https://gcc.gnu.org/onlinedocs/gcc/ Instrumentation-Options.html, accessed 2026-06-17

    2024

  46. [52]

    Uprobe-tracer: Uprobe-based event tracing

    Srikar Dronamraju. Uprobe-tracer: Uprobe-based event tracing. The Linux Kernel documentation, 2024. https://docs.kernel.org/trace/ uprobetracer.html, accessed 2026-06-17

    2024

  47. [53]

    Uprobes in 3.5

    Jonathan Corbet. Uprobes in 3.5. LWN.net, May 2012. https://lwn.net/ Articles/499190/, accessed 2026-06-19

    2012

  48. [54]

    Fried et al

    J. Fried et al. Caladan: mitigating interference at microsecond timescales. InOSDI, 2020

    2020

  49. [55]

    Gifford et al

    R. Gifford et al. DNA: Dynamic resource allocation for soft real-time multicore systems.RTAS, 2021

    2021

  50. [56]

    Xu et al

    C. Xu et al. dCat: dynamic cache management for efficient, performance-sensitive infrastructure-as-a-service. InEuroSys, 2018

    2018

  51. [57]

    Nowotsch et al

    J. Nowotsch et al. Multi-core interference-sensitive WCET analysis leveraging runtime resource capacity enforcement. InECRTS, pages 109–118, 2014

    2014

  52. [58]

    Cho et al

    J. Cho et al. Real-time detection on cache side channel attacks using performance counter monitor. InICTC, pages 175–177, 2019

    2019

  53. [59]

    C. P. Chenet et al. A survey on hardware-based malware detection approaches.IEEE Access, 12:54115–54128, 2024

    2024

  54. [60]

    Intel Threat Detection Technology (Intel TDT)

    Intel Corporation. Intel Threat Detection Technology (Intel TDT). https://www.intel.com/content/www/us/en/architecture-and-technology/ threat-detection-technology-brief.html, 2024. Accessed: 2026-06-05

    2024

  55. [61]

    Saeed et al

    A. Saeed et al. Memory utilization-based dynamic bandwidth regulation for temporal isolation in multi-cores. InRTAS, pages 133–145, 2022

    2022

  56. [62]

    Cardona et al

    J. Cardona et al. Maximum-contention control unit (MCCU): Resource access count and contention time enforcement. InDATE, pages 710–715, 2019

    2019

  57. [63]

    Wessman et al

    N.-J. Wessman et al. De-RISC: the first RISC-V space-grade platform for safety-critical systems. InIEEE SCC, pages 17–26, 2021

    2021

  58. [64]

    de Lecea et al

    A. de Lecea et al. Improving timing-related guarantees for main memory in multicore critical embedded systems. InRTSS, pages 265–278, 2023

    2023

  59. [65]

    Pujol et al

    R. Pujol et al. Tracking coherence-related contention delays in real-time multicore systems. InACM/SIGAPP SAC, pages 461–470, 2023

    2023

  60. [66]

    Sullivan et al

    C. Sullivan et al. Per-bank bandwidth regulation of shared last-level cache for real-time systems.RTSS, pages 336–348, 2024

    2024

  61. [67]

    Izhbirdeev et al

    I. Izhbirdeev et al. Coherence-aided memory bandwidth regulation. In RTSS, pages 322–335, 2024

    2024

  62. [68]

    R. L. Cruz. A calculus for network delay. I. network elements in isolation.IEEE Trans. Inf. Theory, 37(1):114–131, 1991

    1991

  63. [69]

    Arm Architecture Reference Manual for A-profile architecture

    Arm Ltd. Arm Architecture Reference Manual for A-profile architecture. https://developer.arm.com/documentation/ddi0487/latest, 2023

    2023

  64. [70]

    https://developer.arm.com/Architectures/ System%20MMU%20Support

    Arm System MMU support. https://developer.arm.com/Architectures/ System%20MMU%20Support

  65. [71]

    https://wiki.riscv.org/display/HOME/ RISC-V+Technical+Specifications

    RISC-V technical specifications. https://wiki.riscv.org/display/HOME/ RISC-V+Technical+Specifications

  66. [72]

    https://open-src-soc.org/2022-05/media/slides/ RISC-V-International-Day-2022-05-05-14h10-Perinne-Peresse.pdf

    RISC-V IOMMU architecture overview. https://open-src-soc.org/2022-05/media/slides/ RISC-V-International-Day-2022-05-05-14h10-Perinne-Peresse.pdf

    2022

  67. [73]

    Zaruba and L

    F. Zaruba and L. Benini. The cost of application-class processing: Energy and performance analysis of a linux-ready 1.7-GHz 64-bit RISC- V core in 22-nm FDSOI technology.IEEE Trans. Very Large Scale Integr. (VLSI) Syst., 27(11):2629–2640, 2019

    2019

  68. [74]

    Kurth et al

    A. Kurth et al. An open-source platform for high-performance non- coherent on-chip communication.CoRR, abs/2009.05334, 2020

    2009 arXiv

  69. [75]

    https://ibex-core

    Ibex: An embedded 32-bit RISC-V CPU core. https://ibex-core. readthedocs.io/en/latest/

  70. [76]

    Rossi et al

    D. Rossi et al. Energy efficient parallel computing on the PULP platform with support for OpenMP. InIEEEI, pages 1–5, 2014

    2014

  71. [77]

    PULP platform

    PULP Platform. PULP platform. https://pulp-platform.org, 2014

    2014

  72. [78]

    Valente et al

    L. Valente et al. Shaheen: An open, secure, and scalable RV64 SoC for autonomous nano-UA Vs. InIEEE Hot Chips, pages 1–12, 2023

    2023

  73. [79]

    Valente et al

    L. Valente et al. A heterogeneous RISC-V based SoC for secure nano- UA V navigation.IEEE Trans. Circuits Syst. I, pages 1–14, 2024

    2024

  74. [80]

    Sinigaglia et al

    M. Sinigaglia et al. A heterogeneous system-on-chip with an 83 GFLOp/s, 1.2 TFLOp/s/W parallel programmable accelerator for real- time on-device learning in autonomous nano-UA Vs.IEEE Open J. Solid- State Circuits Soc., 2026

    2026

  75. [81]

    https://www

    AMD Virtex UltraScale+ FPGA VCU118 evaluation kit. https://www. xilinx.com/products/boards-and-kits/vcu118.html

  76. [82]

    Tedeschi et al

    R. Tedeschi et al. Culsans: An efficient snoop-based coherency unit for the CV A6 open source RISC-V application processor. arXiv:2407.19895, 2024

    2024 arXiv

  77. [83]

    AXI LLC: A Parameterizable AXI4- Compliant Last-Level Cache

    PULP Platform Contributors. AXI LLC: A Parameterizable AXI4- Compliant Last-Level Cache. https://github.com/pulp-platform/axi llc,

  78. [84]

    Newsome et al.RISC-V Debug Specification, Document Version 1.0- STABLE

    T. Newsome et al.RISC-V Debug Specification, Document Version 1.0- STABLE. 2019

    2019

  79. [85]

    Yun et al

    H. Yun et al. Palloc: Dram bank-aware memory allocator for perfor- mance isolation on multicore platforms. InRTAS, pages 155–166, 2014

    2014

  80. [86]

    S. K. Venkata et al. SD-VBS: The san diego vision benchmark suite. InIISWC, pages 55–64, 2009

    2009

  81. [2025]

    Accessed: 2026-03-26

    2026

Pith tools

Reviewed August 8, 2026 · model on record in the stance chip above.