Cache Hierarchy & Average Memory Access Time Simulator

Model how a memory hierarchy serves a working set — and what actually bounds the workload — then run it: the simulation executes on the ChipFoundryServices compute pool. A working set of W bytes spans W/line cache lines; each level's cumulative hit rate follows a Zipf coverage law H(cov) = cov1-locality where cov = capacity / working set — more capacity or higher locality lifts the curve toward 100 %. The telescoping Average Memory Access Time = tL1 + (1-H1)·tL2 + (1-H2)·tL3 + (1-H3)·tmem charges each level only for the accesses that miss above it. LLC MPKI = (1-H3)·API sets the miss stream; the MLP-aware stall CPI = API·(Average Memory Access Timecyc-tL1)/MLP shrinks as memory-level parallelism hides latency. The miss stream demands clock·API·(1-H3)·line bytes/s per core; compared against the effective memory bandwidth it decides the regime. The node returns the per-level hit rates, the Average Memory Access Time in ns and cycles, the MPKI, the stall CPI and slowdown, the bandwidth demand and the operating regime (L1-resident / cache-resident / bandwidth-bound / latency-bound / capacity-bound). Reduced-order educational model. See also the HBM bandwidth, KV-cache, FlashAttention, quantization, systolic array, 3D-parallelism, SerDes link-budget, chiplet packaging, power & thermal, transistor I-V, die-yield and lithography simulators and the compute-pool status.

AI inference (HBM) LLC-resident HPC Latency-bound Capacity-bound
Average Memory Access Time broken down by level. Each bar is a level contribution to the average memory access time (ns) — tL1, (1-H1)·tL2, (1-H2)·tL3 and the memory term (1-H3)·tmem. The tallest bar (dark outline) is where your latency actually goes; the key metrics at right show overall hit rate, LLC MPKI, stall CPI and the bottleneck
Left: overall hit rate vs total cache capacity — the hit curve climbs toward the dashed 100 % ceiling as capacity grows (▯ marks your hierarchy). Right: the hit budget — the L1 hit rate, the local hit rates at L2 and L3, and the overall hit rate that survives to feed the core
Developer API — same simulation over HTTP (load-balanced across the pool): 
curl -X POST https://www.chipfoundryservices.com/edge/cache \
  -H "Content-Type: application/json" \
  -d '{"working_set_mb":96,"l1_kb":64,"l2_kb":1024,"l3_mb":32,"line_bytes":64,
       "l1_cycles":4,"l2_cycles":14,"l3_cycles":50,"mem_ns":100,"clock_ghz":3.0,
       "locality":0.85,"accesses_per_kinst":350,"mem_bw_gb_s":3350,"mlp":8,"num_cores":8}'
Returns JSON with outputs (format, working_set_fits_in, l1_hit_percent, l2_local_hit_percent, l3_local_hit_percent, overall_hit_percent, miss_to_memory_percent, l1_coverage_percent, l2_coverage_percent, l3_coverage_percent, amat_ns, amat_cycles, amat_l1_ns, amat_l2_ns, amat_l3_ns, amat_mem_ns, l1_mpki, llc_mpki, stall_cpi, effective_cpi, slowdown_x, bw_demand_gb_s, bw_util_percent, eff_mem_bw_gb_s, mlp_needed_per_core, l3_enabled, verdict), the full profile (48-point hitrate_vs_capacity, amat_vs_ws and amat_vs_locality sweeps, plus l3_mb, overall_hit_percent, amat_ns, l1_hit_percent, l2_local_hit_percent, l3_local_hit_percent, amat_l1_ns, amat_l2_ns, amat_l3_ns, amat_mem_ns), the serving node, and compute_ms. Endpoint aliases /edge/amat, /edge/cachehierarchy, /edge/memoryhierarchy, /edge/llc, /edge/missrate, /edge/mpki.