Lease caches make eviction prescriptive by assigning a compiletime or profile-derived lease to each memory reference, enabling program-guided cache management. This paper presents a reproducible hardware-software evaluation of lease-based cache programming: we implement a lease-cache prototype (CLAM and SHEL) on a single-core RISC-V emulated on an Altera Cyclone-V FPGA and compare its measured behavior to a PLRU baseline and to Belady's OPT computed by an offline Rust simulator. We collect sampled reuse statistics and full traces from PolyBench/C kernels to produce per-reference leases and optimal miss counts. Lease programming closes most of the gap to OPT (average normalized score 67/100), with multi-scope (SHEL) assignments giving higher and more stable gains than single-scope (CLAM); triangular iteration spaces remain the hardest class to optimize. We also show lease-cache rationing is robust to modest under-allocation. The results motivate practical use of lease programming in resource-constrained, fixed-size caches and point to opportunities for runtime adaptation to handle highly irregular access patterns.
Historically, software engineers and hardware engineers represent disparate groups that don't talk to each other. Because the two don't interact much, neither knows much of the other's discipline, and therefore those they teach learn little of the other's discipline. This is problematic because computer design (hardware) and computer security (software) are intimately dependent on each other, and when system designers fail to understand both topics, catastrophe results. For example, critical vulnerabilities like buffer overflows and Spectre/Meltdown arose because designers inadvertently bypassed protections that could have ensured robust security. Moreover, teaching security and hardware as separate disciplines obscures the root causes of vulnerabilities, leading to solutions that fail to tackle the fundamental flaws. This paper shows howan understanding of both hardware and security will help one to recognize the dependences and dangerous gaps that exist between the two. Hopefully such awareness can help prevent the future undermining of system security via unintended design consequences.
Machine learning (ML) workloads (e.g., deep neural networks (DNNs), convolutional neural networks (CNNs)) have grown significantly in size and complexity. With such growth in ML workloads, memory performance has emerged as a critical bottleneck in specialized hardware accelerators (e.g., AI accelerators) for ML workloads. The AI accelerators feature tightly-coupled on-chip SRAM and compute units in systolic array architectures that demand high memory reuse efficiency to maintain throughput. In this paper, we present a comprehensive analytical memory modeling framework that leverages reuse distance analysis to predict SRAM-level behavior for ML workloads on AI accelerators. Our model extends traditional reuse distance analysis by incorporating dataflow semantics, spatial and temporal reuse dynamics, and architectural buffer constraints. Using our model, we measure and report key memory metrics such as SRAM hit rate, miss rate, bandwidth utilization, and latency. The metrics are also derived from trace-level analysis generated by accelerators like ScaleSim. We evaluate our model across input-stationary, weight-stationary, and output-stationary mappings across a broad range of DNN and CNN benchmarks on AI accelerator, showing how reuse behavior varies by dataflow architecture and applications. Our results offer architectural insights that inform efficient buffer sizing and dataflow configuration to maximize on-chip memory efficiency and reduce off-chip traffic.
Efficient memory access patterns play a crucial role in determining the overall performance of applications by exploiting temporal and spatial locality, thus maximizing cache locality. The Reuse Distance Histogram (RDH) is a widely used metric to quantify temporal locality, measuring the distance between consecutive accesses to the same memory location. Traditionally, calculating RDH requires program execution and memory trace collection to obtain dynamic memory access behavior. This trace collection is often time-consuming, resource-intensive, and unsuitable for early-stage optimization or large-scale applications. Static prediction, on the other hand, offers a significant speedup in estimating RDH and cache hit rates. However, these approaches often lack accuracy, as predictions are made without executing the program or observing the complete memory access pattern. Specifically, when arrays are used inside nested loops, predicting the access patterns of array references without observing their exact execution sequence presents a significant challenge. This paper presents a novel static analysis framework for predicting the reuse profiles of array references in programs with nested loop structures, independent of runtime information. By analyzing loop bounds, access patterns in smaller problem sizes, and predictive equations, our method predicts array access patterns and estimates reuse distances and cache hit rates at compile time. This paper extends our previous study by incorporating a deeper analysis and improving prediction by addressing previously unhandled reuse patterns. We evaluated our technique against a widely accepted traditional trace-driven profiling tool, Parallel Reuse Distance Analysis (PARDA). The results demonstrate that our static predictor achieves comparable accuracy while offering orders-of-magnitude improvement in analysis speed, excluding setup time. This work presents a practical alternative to dynamic reuse profiling for array applications with multiple loops, paving the way for integration into compilers and static performance modeling tools.
Hardware exploits such as Spectre and Meltdown underscore the increasing need to validate hardware security properties. To account for known exploits we suggest Hybrid logic, an extension of Modal logic, for its concise description of security problems. We further suggest that compiling known exploits into a database would be a helpful tool for testing designs against security properties. We demonstrate a hybrid logic description for Spectre and describe its benefits. We reflect further on the unique challenges of sharing security information about hardware vulnerabilities. We conclude that careful thought is required to achieve responsible disclosure processes for hardware vulnerabilities.
