Skip to content
STIMSMITH

cache

Concept

In the provided verification-oriented evidence, a cache is treated both as a standalone hardware component that can itself be a Design Under Test (DUT) and as a microarchitectural sub-system of a CPU whose RTL structures (tag/data arrays, ways, banks, request FIFOs) must be exercised during verification. Caches are recognised as a source of inter-instruction behavior that high-quality generation-based tests target, as a shared resource in multi-core designs requiring coordinated multiple instruction streams, and as a security-relevant structure subject to timing, occupancy, and speculative-execution attacks. Verification techniques including constrained random instruction streams, Logic Fuzzer table mutators, DPI-based array replacement, and artificial backpressure have all been used to expose cache-related bugs such as CVA6 Bug ID B6 (cache-subsystem arbiter lock with `gnt 0`).

First seen 5/27/2026
Last seen 7/9/2026
Evidence 7 chunks
Wiki v4

WIKI

Overview

In the provided evidence, a cache is discussed from four complementary angles relevant to functional verification:

  • As a standalone Design Under Test (DUT) in a generation-based verification flow: "The DUT may be any design of a component which is verified by the verification apparatus 120, such as but not limited to a processor, an Integrated Circuit (IC), a controller, a BUS, cache, another hardware component, or the like" [abf3b159-2cbe-40c6-8277-c82a112ed74c; 47f43ee0-fd58-4752-93dc-afed86eb3be3].
  • As a microarchitectural feature of a CPU core providing "memory access acceleration such as caching" alongside pipelines, multiple instruction issue, out-of-order execution, and branch prediction [1].
  • As a set of RTL-visible structures and control logic that can be directly fuzzed during verification, including instruction-cache tag and data arrays, cache entries, valid bits, L1 cache ways and banks, and cache-subsystem FIFO/arbiter logic that handles memory requests from the instruction cache [d60c0273-7ab8-4adf-80eb-3de40553c41f; a0199e72-f2b1-4a7c-bcfc-5db02be51c30; 5ec1faf0-7dd6-4f3e-9a23-9ebb8cc14645].
  • As a security-relevant structure whose state changes and access patterns can leak information via timing, occupancy, and speculative-execution channels [arxiv:2309.16172; arxiv:2310.05172].
READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

3 connections
table mutator ← uses 95% 2e
Table mutators fuzz cache tag arrays and valid bits to stress cache behavior.
Logic Fuzzer ← uses 100% 2e
Logic Fuzzer mutates cache tag arrays and valid bits to stress cache behavior.
Design Under Test (DUT) part of → 85% 2e
Cache is one of the hardware components that may constitute the DUT.

LINKED ENTITIES

1 links
Design Under Test (DUT) PART_OF Extracted graph relationship

CITATIONS

7 sources
7 citations — click to expand
[1] A cache is explicitly listed as one of the example Designs Under Test (DUTs) in a generation-based verification flow: 'The DUT may be any design of a component which is verified by the verification apparatus 120, such as but not limited to a processor, an Integrated Circuit (IC), a controller, a BUS, cache, another hardware component, or the like.' Automatic identification of information useful for generation-based verification of designs
[2] Generation-based tests that access the same resource are higher quality because they operate inter-instruction behavior such as 'a cache mechanism,' and the test-generator's design knowledge is used to bias instructions toward interesting microarchitectural events including accesses to specific processor units and memory regions. Automatic identification of information useful for generation-based verification of designs
[3] Caching is one of the CPU 'memory access acceleration' enhancements that 'can break the functional correctness of the core and so require specialist verification techniques including constrained random instruction stream execution.' TVS extends CPU Verification Capability
[4] In multi-core SoCs, 'cores often shares resources such as caches. Hence the need for multiple instruction streams that are generated by a tool that understands the potential bugs in the management of those shared resources.' TVS extends CPU Verification Capability
[5] CVA6 Bug ID B6: a cache-subsystem arbiter lock with `gnt 0` and complete system hang was exposed by creating artificial backpressure at the FIFO's `full` signal; the FIFO queues memory requests coming from the icache, and the `full` signal feeds the arbiter's request logic. Effective Processor Verification with Logic Fuzzer Enhanced Co-simulation
[6] Cache timing attacks include non-speculative cache side/covert channels and cache-based speculative-execution attacks; the Random and Safe (RaS) cache architecture decorrelates cache state changes from memory requests and reports 3.8% average overhead for RaS-Spec against speculative attacks and 7.9%–45.2% overhead for RaS+ variants against both attack classes. Random and Safe Cache Architecture to Defeat Cache Timing Attacks
[7] Most randomized cache designs (CEASER, CEASER-S, MIRAGE, Scatter-Cache, Sass-cache) defend only contention-based attacks and leave cache occupancy unprotected; the cited work demonstrates the first full AES key recovery on a randomized cache design using a cache occupancy attack. Systematic Evaluation of Randomized Cache Designs against Cache Occupancy