Workload Taxonomy for Architects

Workload classes

• Branchy control-flow heavy — frontend and branch predictor sensitive.

• Pointer-chasing / irregular memory — cache MPKI and TLB sensitive.

• Streaming / sequential — prefetch and bandwidth sensitive.

• Producer-consumer / sharing heavy — coherency and false sharing sensitive.

• Burst parallel / accelerator friendly — locality and DMA contract sensitive.

• Latency-critical services — tail latency and QoS sensitive.

WORKLOAD -> ARCHITECTURE MAP

branchy        -> fetch, predict, I-cache
pointer chase  -> D-cache, TLB, LLC, DRAM
streaming      -> prefetch, bandwidth, NoC
sharing        -> coherency, line size, layout
accelerator    -> SRAM tile, DMA, launch overhead
latency SLO    -> QoS, shallow queues, tail control

Architecture deep dive

Computer architecture decisions must be tied to workload metrics and silicon constraints.

Concept diagram

ARCHITECTURE DECISION LOOP

workload → metric → bottleneck mechanism → experiment → design option → validation

Metric graph

METRIC TREND

bad run  ██████████
base     ██████████████
target   ████████████████████

Metrics and artifacts

• IPC/CPI

• latency

• bandwidth

• power

• area

• verification risk

Mini case study

A senior architecture review converts a vague performance issue into a metric, a mechanism, an experiment, and a bounded design choice.

Debug branches

• If the metric is not workload-specific, do not accept the conclusion.

• If the fix has no PPA and verification statement, the review is incomplete.

Senior review question

Ask: what single metric would prove this concept is working or failing on your workload?

Key takeaways

• Connect every architecture claim to a workload and measurable metric.

• State verification and PPA impact before proposing design changes.

Common pitfalls

• Feature-driven design without MPKI/IPC/bandwidth evidence.

• Ignoring coherency and NoC traffic in cache and accelerator sizing.