Pith. sign in

REVIEW 3 major objections 4 minor 1 cited by

High-Performance ARM-on-ARM Virtualization for Multicore SystemC-TLM-Based Virtual Platforms

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

Pith's one-line read By running target ARM software natively through KVM, a SystemC-TLM multicore CPU model replaces the instruction-set simulator and reports 10x to over 100x speedups on ARM hosts.

desk verdict A real, useful engineering contribution—multicore KVM-based SystemC CPU model without perf counters or kernel patches—but the headline speedups are inflated by comparing the ARM machine against a slower x86 host. read the letter →

arxiv 2505.12987 v2 pith:TKLONO3T submitted 2025-05-19 cs.SE

classification cs.SE
keywords ARM-on-ARMvirtualizationKVMSystemC-TLMmulticoreCPUmodelvirtualplatforminstruction-setsimulatorWFIannotationtemporaldecoupling
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 claims that a multicore SystemC-TLM virtual platform can run target ARM software natively on an ARM host by using Linux's KVM hypervisor, eliminating the instruction-set simulator (ISS) entirely. The CPU model it builds acts as a drop-in replacement for an ISS inside an existing virtual platform, with memory-mapped peripheral accesses trapped by KVM and forwarded to the SystemC simulation. On compute-intensive workloads the platform is reported to run up to 10x faster than an ISS-based reference, and over 100x faster on some benchmarks, while a software watchdog and WFI annotations remove the earlier need for performance counters and custom kernel patches. The outcome matters to anyone doing pre-silicon software development, driver bring-up, or CI/CD testing on ARM targets, where simulation speed is the bottleneck.

What carries the argument

The load-bearing object is the KVM-backed vCPU model embedded in the VCML processor class. For each simulated core, a worker thread calls KVM_RUN to execute target instructions natively on the host; a placeholder SC_THREAD in the SystemC main thread keeps synchronization, and a software-based watchdog thread sends SIGUSR1 to halt KVM_RUN after the wall-clock time corresponding to one quantum. WFI annotation completes the mechanism: the ELF of the target Linux kernel is searched for the cpu_do_idle symbol, a breakpoint is set on the WFI instruction inside it, and when a core reaches the breakpoint the model suspends the core until an interrupt is signaled, skipping idle-loop simulation entirely.

What would settle it

Run the ISS-based A VP64 baseline on the same Apple M2 Pro host used for the ARM-on-ARM measurements and re-measure the Dhrystone and MiBench speedups. If the speedup over a same-host ISS drops well below the reported 10x and 100x figures, most of the gain is host CPU performance rather than native execution through KVM; if the figures roughly hold, the method's claim is confirmed.

Watch

Extended reading notes

Core claim

The central claim is that hardware-assisted virtualization can replace instruction-set simulation inside a SystemC-TLM virtual platform when the host and target share the ARM ISA. Each simulated core is a KVM guest running target software natively; exits from KVM handle MMIO accesses as TLM transactions in the SystemC main thread, and a shared software watchdog bounds each quantum's execution time without relying on hardware performance counters. The paper further shows that idle loops can be skipped by locating the cpu_do_idle symbol in the target kernel's ELF file, placing a breakpoint on its WFI instruction, and suspending the core until an interrupt arrives. On an Apple M2 Pro host, the resulting platform reports up to 10x speedup over the ISS-based A VP64 on parallel Dhrystone and speedups beyond 100x on some MiBench workloads, with a minimum observed speedup of 1.8x across all tested user-space benchmarks.

Load-bearing premise

The speedup figures compare the new platform running on an Apple M2 Pro against the ISS-based baseline running on an AMD Ryzen 9 3900X, with no same-host or speed-normalized comparison; if the host hardware difference accounts for part of the gap, the reported speedups overstate the method's advantage.

Editorial extensions

If this is right

  • Unmodified target ARM operating systems and user-space programs can run natively inside a SystemC-TLM virtual platform, with the KVM-based CPU model serving as a drop-in replacement for the ISS and no other changes to the platform.
  • The approach no longer depends on hardware performance counters or patched kernels, so it works on hosts such as Apple Silicon Linux where standard perf-based guest-instruction counting is unavailable.
  • Combining parallel core execution with WFI annotation brings a multicore Linux boot to under one second for dual- and quad-core configurations, where unannotated sequential boot can take tens of seconds.
  • Speedups are workload-dependent: compute-bound Dhrystone reaches about 10x, small-input MiBench workloads exceed 100x, and communication-heavy NAS benchmarks stay above 1.8x, with the largest gains appearing where dynamic binary translation overhead dominates the ISS baseline.
  • Because KVM exposes only EL0 and EL1 to the guest, the model covers OS and application software but cannot simulate hypervisors at EL2 or trusted firmware at EL3; the authors point to RISC-V-on-RISC-V as the natural next application of the same design.

Reading between the lines

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

  • The reported 10x-to-100x figures are best read as upper bounds: the ARM-on-ARM platform ran on an Apple M2 Pro while the A VP64 ISS baseline ran on an AMD Ryzen 9 3900X, so a same-host ISS comparison would likely narrow the gap; the method's intrinsic advantage is probably a smaller multiple.
  • The ELF-symbol-based WFI annotation is a generalizable pattern: any operating system with a known idle-loop symbol could be annotated the same way, and using debug information to find idle loops automatically would remove the Linux-specific manual step.
  • The largest speedups come from small-input workloads where the ISS's dynamic binary translation cost dominates, which predicts that on long-running, realistic application workloads the advantage will settle near the compute-bound 10x figure rather than the 100x+ outliers.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper presents an ARM-on-ARM approach to CPU modeling in SystemC-TLM virtual platforms. Instead of an instruction-set simulator, the CPU model uses Linux KVM on an ARM host to execute target software natively, trapping MMIO accesses and WFI instructions to maintain interaction with the modeled peripherals. The authors extend this idea to multicore platforms using a parallel execution strategy, replace per-requirement performance-counter-based instruction counting with a software watchdog timer, and introduce WFI annotations by setting breakpoints on the target Linux idle-loop symbol cpu_do_idle. Benchmarks compare the proposed AoA platform with the ISS-based A VP64 on Dhrystone, Linux boot, STREAM, MiBench, and NAS Parallel Benchmarks, claiming up to 10x speedup on compute-intensive workloads and more than 100x on some user-space benchmarks.

Significance. The technique is plausible and well motivated: removing the dependence on custom kernel patches and on specific hardware performance counters is a genuine engineering contribution, and the WFI-annotation workaround is an interesting and practical idea. The implementation is built on open-source components, and the multicore SystemC-TLM CPU model could be a useful drop-in replacement for ISS-based models if the performance claims are substantiated. However, the central quantitative claims are not supported by the data as presented, because the AoA platform and the ISS baseline were benchmarked on different host machines with no same-host or normalized control. The stress-test concern about missing same-host baselines directly lands on the paper's headline results.

major comments (3)
  1. [Section V, Figures 5-7] The central speedup claim compares measurements on different hosts. The AoA platform is benchmarked on an Apple M2 Pro (6 Avalanche and 4 Blizzard cores), while the ISS-based A VP64 baseline runs on an AMD Ryzen 9 3900X, and the reported speedup S is computed as t_A VP64 divided by t_This Work across those two machines. No same-host baseline, normalized comparison, or calibration is reported, so the 'up to 10x' and 'more than 100x' figures conflate the benefit of KVM-based native execution with the M2 Pro's generally higher single-thread and memory performance. The authors should either benchmark both models on the same host (for example, by running A VP64 on the Mac mini under Asahi Linux) or report a hardware-normalized metric using per-host reference benchmarks before the headline speedups can be accepted.
  2. [Section V, Figures 5-7] There are no repeated trials or statistical measures anywhere in the results section. Each reported value appears to be a single measurement, and no error bars, confidence intervals, or variance information are given. Given the large spread of speedups in Figure 7 (from about 1.8x to 165x), the absence of repeated-run statistics makes it impossible to assess whether the reported differences between core counts, quantum values, and parallelization modes are meaningful or within measurement noise. At minimum, the authors should report medians and spreads over several repetitions and state the resolution of the wall-clock timing used.
  3. [Section V-C, Figure 7] The speedups in Figure 7 are attributed primarily to native execution and the overheads of the DBT-based ISS, but the experimental setup also enables WFI annotations for the AoA model and uses A VP64 as the baseline. For the single-threaded MiBench benchmarks, the authors themselves observe that the large speedups on small inputs (up to 165x for Susan S) largely reflect ISS translation caching behavior rather than the raw speed of native execution. This makes the headline 'speedup' a mixture of several factors: host hardware, native KVM execution, WFI annotation, and baseline ISS efficiency. The paper should decompose the contributions, for example by comparing AoA with and without WFI annotations on the same host and against the same baseline configuration.
minor comments (4)
  1. [Abstract] The abstract's phrase 'no special requirements on the host system' overstates the case, since the approach requires an ARM host with virtualization host extensions, Linux, and KVM; it is more accurate to say it requires no custom kernel patches and no special PMU features.
  2. [Figure 7 caption] The legend 'WFI\Cores 1 2 4 8' with entries 'Annotated' and 'KVM-handled' is difficult to parse; the caption should explain what is plotted for each entry and state which configurations use WFI annotations.
  3. [References] Reference [27], cited for the NAS Parallel Benchmarks, points to the 'nasa-jpl/embedded-gcov' repository rather than to the NPB suite; this citation should be corrected.
  4. [Section VI] The concluding paragraph's statement that 'KVM currently only supports EL0 and EL1 for the guest' should specify that this refers to KVM/ARM and should clarify that EL2 and EL3 execution is unsupported for the guest, which is consistent with the paper's stated scope but should be worded precisely.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: this is a measurement study; the speedup claims are empirically measured against an ISS baseline and do not reduce to fitted inputs or self-cited derivations.

full rationale

The paper's central claim is an empirical performance comparison: the proposed ARM-on-ARM KVM-based multicore SystemC-TLM model is benchmarked against the ISS-based A VP64 baseline, and the reported speedups (up to 10x for Dhrystone, more than 100x for some MiBench workloads) are ratios of measured wall-clock times. There is no derivation chain in which an output quantity is defined in terms of an input quantity, no fitted parameter is later renamed as a prediction, and no uniqueness theorem is imported from the authors' prior work to force a modeling choice. Self-citations to prior work by the same authors (refs [3], [16], [17]) provide engineering provenance for the single-core KVM proof of concept and the parallelization technique; they are not used as evidence for the new speedup figures. The benchmark workloads (Dhrystone, Linux boot, STREAM, MiBench, NAS Parallel Benchmarks) are external and independent. The fact that the proposed platform ran on an Apple M2 Pro while the ISS baseline ran on an AMD Ryzen 9 3900X is a potential threat to the validity or fairness of the speedup magnitude, but it is not circularity: the comparison does not reduce to the paper's inputs by construction. No circular step is identified, so the score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No free parameters or invented entities appear in this implementation study. The assumptions are standard engineering domain assumptions about KVM, ARM exception levels, Linux idle behavior, and wall-clock-based cycle estimation.

assumptions (4)
  • domain assumption The host and target architectures are both ARM, and the host provides virtualization extensions with Linux KVM support.
    The entire method depends on same-ISA native execution; ARMv8 VHE and KVM are cited in Section II-B.
  • domain assumption The target workload executes only at exception levels EL0 and EL1.
    Section VI states KVM currently only supports EL0 and EL1 guests, so EL2 hypervisors and EL3 trusted firmware cannot be simulated.
  • domain assumption The target software is a Linux OS whose ELF contains the cpu_do_idle symbol with a recognizable WFI instruction for breakpoint-based idle-loop annotation.
    Section IV-C searches for cpu_do_idle and sets a breakpoint on the WFI instruction; the conclusion notes the approach needs adaptation for non-Linux workloads.
  • domain assumption The number of simulated instructions is approximated from wall-clock KVM runtime divided by the vCPU clock frequency, assuming a constant average execution time per instruction.
    Section IV-A states 'a constant average execution time per instruction is assumed', which makes simulated time sensitive to host scheduling and frequency scaling.

how reviews work

0 comments
Cite this review

Pith. "Pith review of High-Performance ARM-on-ARM Virtualization for Multicore SystemC-TLM-Based Virtual Platforms." pith.science (2026). https://pith.science/paper/TKLONO3T

@misc{pith2026250512987,
  author       = {Pith},
  title        = {Pith review of: High-Performance ARM-on-ARM Virtualization for Multicore SystemC-TLM-Based Virtual Platforms},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TKLONO3T}},
  note         = {Machine review of arXiv:2505.12987}
}
read the original abstract

The increasing complexity of hardware and software requires advanced development and test methodologies for modern systems on chips. This paper presents a novel approach to ARM-on-ARM virtualization within SystemC-based simulators using Linux's KVM to achieve high-performance simulation. By running target software natively on ARM-based hosts with hardware-based virtualization extensions, our method eliminates the need for instruction-set simulators, which significantly improves performance. We present a multicore SystemC-TLM-based CPU model that can be used as a drop-in replacement for an instruction-set simulator. It places no special requirements on the host system, making it compatible with various environments. Benchmark results show that our ARM-on-ARM-based virtual platform achieves up to 10 x speedup over traditional instruction-set-simulator-based models on compute-intensive workloads. Depending on the benchmark, speedups increase to more than 100 x.

Figures

Figures reproduced from arXiv: 2505.12987 by the authors.

Figure 1
Figure 1. vCPU integration using KVM. However, if both architectures match and Virtualization Host Extensions (VHE), such as ARMv8’s VHE [1], are available on the host, the target SW can be executed natively without the need for an ISS [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Multithreaded approach using a SW-based watchdog. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. vCPU model execution loop. Then, the cause of the KVM_RUN exit is determined. In case of an MMIO access, a TLM transaction is sent to the corresponding peripheral. Since, according to the SystemC standard, interactions with other models need to be performed in the main thread, this access has to be shifted back in case of parallel execution [2], [16]. If the exit was caused by an idling core that executed a WFI inst… view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: AoA-based VP. 1) Symbol search: Identify the cpu_do_idle symbol within the target-SW ELF file. 2) Breakpoint setting: Locate the WFI instruction inside this function and set a breakpoint on it. 3) Instruction check: When a vCPU reaches this breakpoint, KVM exits back t…
Figure 5
Figure 5. Figure 5: Bare-metal Dhrystone [19] benchmark. A. Bare-Metal Dhrystone Benchmark The first benchmark executed is a bare-metal Dhrystone [19], which is single threaded and integer based. For multicore sys￾tems, each core executes its own instance of Dhrystone. Thus, a parallel Dh…
Figure 6
Figure 6. Figure 6: a illustrates the wall-clock time required for different core counts without WFI annotations (see Section IV-C, WFI is handled by KVM). While the single-core VP boots Linux in approximately 0.6 s, multicore setups take considerably longer. A non-parallelized boot of an…
Figure 7
Figure 7. Figure 7: Benchmark speedup S of AoA compared to AVP64 for 1 ms quantum and activated parallel execution. instructions is less expensive for ISSs than for AoA due to the needed context switching for exiting KVM [20]. 1) STREAM: The first user space benchmark tested is STREAM [25…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Bridging the Gap: Physical PCI Device Integration Into SystemC-TLM Virtual Platforms

    cs.SE 2025-05 conditional novelty 5.0 of 10

    Real PCIe devices can be integrated into SystemC-TLM virtual platforms using VFIO, achieving up to 480x speedups on AI inference workloads.

Reference graph

Works this paper leans on

32 extracted references · 19 canonical work pages · cited by 1 Pith paper

  1. [1]

    Arm Architecture Reference Manual DDI 0487K.a,

    ARM Ltd, “Arm Architecture Reference Manual DDI 0487K.a,” Mar. 2024

  2. [2]

    IEEE Standard for Standard SystemC® Language Reference Manual,

    IEEE Standards Association and others, “IEEE Standard for Standard SystemC® Language Reference Manual,”IEEE Std 1666-2023 (Revision of IEEE Std 1666-2011), pp. 1–618, Sep. 2023, conference Name: IEEE Std 1666-2023 (Revision of IEEE Std 1666-2011). [Online]. Available: https://doi.org/10.1109/IEEESTD.2023.10246125

  3. [3]

    ARM-on-ARM: Leveraging Virtualization Extensions for Fast Virtual Platforms,

    L. Junger, J. L. Malte Bolke, S. Tobies, R. Leupers, and A. Hoffmann, “ARM-on-ARM: Leveraging Virtualization Extensions for Fast Virtual Platforms,” in2020 Design, Automation & Test in Europe Conference & Exhibition (DATE). Grenoble, France: IEEE, Mar. 2020, pp. 1508–1513. [Online]. Available: https://doi.org/10.23919/DATE48585.2020.9116573

  4. [4]

    Apple details new MacBook Air, MacBook Pro and Mac Mini – all powered by in-house silicon chips|CNN Business,

    R. Iyengar, “Apple details new MacBook Air, MacBook Pro and Mac Mini – all powered by in-house silicon chips|CNN Business,” Nov

  5. [5]

    NISTT: A Non-Intrusive SystemC-TLM 2.0 Tracing Tool,

    N. Bosbach, L. J ¨unger, J. M. Joseph, and R. Leupers, “NISTT: A Non-Intrusive SystemC-TLM 2.0 Tracing Tool,” in2022 IFIP/IEEE 30th International Conference on Very Large Scale Integration (VLSI- SoC), Oct. 2022, pp. 1–6, iSSN: 2324-8440. [Online]. Available: https://doi.org/10.1109/VLSI-SoC54400.2022.9939578

  6. [6]

    machineware-gmbh/vcml,

    MachineWare, “machineware-gmbh/vcml,” Mar. 2024, original- date: 2018-01-22T10:24:21Z. [Online]. Available: https://github.com/ machineware-gmbh/vcml

  7. [7]

    QEMU, a fast and portable dynamic translator

    F. Bellard, “QEMU, a fast and portable dynamic translator.” inUSENIX annual technical conference, FREENIX Track, vol. 41. California, USA, 2005, pp. 10–5555, issue: 46

  8. [8]

    Fast SystemC Processor Models with Unicorn,

    L. J ¨unger, J. H. Weinstock, R. Leupers, and G. Ascheid, “Fast SystemC Processor Models with Unicorn,” inProceedings of the Rapid Simulation and Performance Evaluation: Methods and Tools, ser. RAPIDO ’19. New York, NY , USA: Association for Computing Machinery, Jan. 2019, pp. 1–6. [Online]. Available: https://doi.org/10.1145/3300189.3300191

Show all 32 references
  1. [9]

    An ARMv8 Virtual Platform (A VP64),

    L. J ¨unger, “An ARMv8 Virtual Platform (A VP64),” May 2023, original- date: 2020-04-09T15:34:12Z. [Online]. Available: https://github.com/ aut0/avp64

  2. [10]

    SIM-V: Fast, Parallel RISC-V Simulation for Rapid Software Verification,

    L. J ¨unger, J. H. Weinstock, and R. Leupers, “SIM-V: Fast, Parallel RISC-V Simulation for Rapid Software Verification,” in Proceedings of DVCon Europe 2022, Munich, 2022. [Online]. Available: https://dvcon-proceedings.org/document/sim-v-fast-parallel- risc-v-simulation-for-ra...

  3. [11]

    Simics: A full system simulation platform,

    P. Magnussonet al., “Simics: A full system simulation platform,” Computer, vol. 35, no. 2, pp. 50–58, Feb. 2002, conference Name: Computer. [Online]. Available: https://doi.org/10.1109/2.982916

  4. [12]

    The gem5 simulator,

    N. Binkertet al., “The gem5 simulator,”SIGARCH Comput. Archit. News, vol. 39, no. 2, pp. 1–7, Aug. 2011. [Online]. Available: https://doi.org/10.1145/2024716.2024718

  5. [13]

    Host-compiled simulation of multi-core platforms,

    A. Gerstlauer, “Host-compiled simulation of multi-core platforms,” in Proceedings of 2010 21st IEEE International Symposium on Rapid System Protyping, Jun. 2010, pp. 1–6, iSSN: 2150-5519. [Online]. Available: https://doi.org/10.1109/RSP.2010.5656355

  6. [14]

    Native Simulation of MPSoC Using Hardware-Assisted Virtualization,

    H. Shen, M.-M. Hamayun, and F. Petrot, “Native Simulation of MPSoC Using Hardware-Assisted Virtualization,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 31, no. 7, pp. 1074–1087, Jul. 2012, conference Name: IEEE Transactions on Computer-Ai...

  7. [15]

    KVM/ARM: the design and implementation of the linux ARM hypervisor,

    C. Dall and J. Nieh, “KVM/ARM: the design and implementation of the linux ARM hypervisor,”SIGPLAN Not., vol. 49, no. 4, pp. 333–348, Feb. 2014. [Online]. Available: https://doi.org/10.1145/2644865.2541946

  8. [16]

    Towards High-Performance Virtual Platforms: A Parallelization Strategy for SystemC TLM-2.0 CPU Models,

    N. Bosbach, N. Zurstraßen, R. Pelke, L. J ¨unger, J. H. Weinstock, and R. Leupers, “Towards High-Performance Virtual Platforms: A Parallelization Strategy for SystemC TLM-2.0 CPU Models,” inDesign Automation Conference, Jun. 2024. [Online]. Available: https://doi.org/10.1145/3...

  9. [17]

    Work-in-Progress: A Generic Non-Intrusive Parallelization Approach for SystemC TLM-2.0-based Virtual Platforms,

    N. Bosbach, R. Pelke, N. Zurstraßen, L. Junger, J. H. Weinstock, and R. Leupers, “Work-in-Progress: A Generic Non-Intrusive Parallelization Approach for SystemC TLM-2.0-based Virtual Platforms,” inProceedings of the 2023 International Conference on Hardware/Software Codesign a...

  10. [18]

    Asahi Linux

    Asahi Linux, “Asahi Linux.” [Online]. Available: https://asahilinux.org/

  11. [19]

    Dhrystone benchmark: rationale for version 2 and measurement rules,

    R. P. Weicker, “Dhrystone benchmark: rationale for version 2 and measurement rules,”AcM SIGPLAn notices, vol. 23, no. 8, pp. 49–62, 1988, publisher: ACM New York, NY , USA

  12. [20]

    How the Intel® Simics® Simulator Executes Instructions,

    J. Engblom, “How the Intel® Simics® Simulator Executes Instructions,” Nov. 2023, section: Software. [Online]. Available: https://community.intel.com/t5/Blogs/Products-and-Solutions/Software/ How-the-Intel-Simics-Simulator-Executes-Instructions/post/1543049

  13. [21]

    Making Embedded Linux Easy,

    Buildroot, “Making Embedded Linux Easy,” 2024. [Online]. Available: https://buildroot.org/

  14. [22]

    The Optimal Quantum of Temporal Decoupling,

    N. Zurstraßen, R. Brandhofer, J. Cubero-Cascante, N. Bosbach, L. J ¨unger, and R. Leupers, “The Optimal Quantum of Temporal Decoupling,” in2024 29th Asia and South Pacific Design Automation Conference (ASP-DAC), 2024, pp. 686–691. [Online]. Available: https://doi.org/10.1109/A...

  15. [23]

    The art of temporal decoupling,

    N. Zurstraßen, R. Brandhofer, J. Cubero-Cascante, N. Bosbach, L. J ¨unger, and R. Leupers, “The art of temporal decoupling,” Integration, vol. 101, p. 102314, Mar. 2025. [Online]. Available: https://doi.org/10.1016/j.vlsi.2024.102314

  16. [24]

    Some Notes on Temporal Decoupling (Reposted) – Observations from Uppsala,

    J. Engblom, “Some Notes on Temporal Decoupling (Reposted) – Observations from Uppsala,” Mar. 2022. [Online]. Available: https://jakob.engbloms.se/archives/3467

  17. [25]

    Memory Bandwidth and Machine Balance in Current High Performance Computers,

    J. D. McCalpin, “Memory Bandwidth and Machine Balance in Current High Performance Computers,”IEEE Computer Society Technical Com- mittee on Computer Architecture (TCCA) Newsletter, pp. 19–25, Dec. 1995

  18. [26]

    MiBench: A free, commercially representative embedded benchmark suite,

    M. Guthaus, J. Ringenberg, D. Ernst, T. Austin, T. Mudge, and R. Brown, “MiBench: A free, commercially representative embedded benchmark suite,” inProceedings of the Fourth Annual IEEE International Workshop on Workload Characterization. WWC-4 (Cat. No.01EX538). Austin, TX, US...

  19. [27]

    nasa-jpl/embedded-gcov,

    NASA Jet Propulsion Laboratory, “nasa-jpl/embedded-gcov,” Oct. 2023, original-date: 2022-02-02T19:25:26Z. [Online]. Available: https: //github.com/nasa-jpl/embedded-gcov

  20. [28]

    Entropy-Based Analysis of Benchmarks for Instruction Set Simulators,

    N. Bosbach, L. J ¨unger, R. Pelke, N. Zurstraßen, and R. Leupers, “Entropy-Based Analysis of Benchmarks for Instruction Set Simulators,” inProceedings of the DroneSE and RAPIDO: System Engineering for constrained embedded systems, ser. RAPIDO ’23. New York, NY , USA: Associati...

  21. [29]

    Arm System Memory Management Unit Architecture Specifica- tion,

    ARM, “Arm System Memory Management Unit Architecture Specifica- tion,” no. 3, Feb. 2024

  22. [30]

    Armv8-A virtualization 102142,

    ARM Ltd, “Armv8-A virtualization 102142,” 2019

  23. [31]

    Chandra, L

    R. Chandra, L. Dagum, D. Kohr, R. Menon, D. Maydan, and J. McDon- ald,Parallel programming in OpenMP. Morgan kaufmann, 2001

  24. [2020]

    Available: https://www.cnn.com/2020/11/10/tech/apple- silicon-chips-mac/index.html

    [Online]. Available: https://www.cnn.com/2020/11/10/tech/apple- silicon-chips-mac/index.html

Pith tools

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