Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • Architecture Metrics Reference
  • Workload Taxonomy for Architects
  • Architecture Glossary
  • Computer Architecture Cheatsheet
  • Pipeline Fundamentals14
  • Memory Hierarchy15
  • NoC and Interconnect Architecture6
  • Coherency and Memory Ordering9
  • Performance Analysis9
  • Accelerator Architectures6
    • Accelerators for the Architect
      • When an Accelerator Pays Off
      • Dataflow Patterns as Reuse Contracts
      • Systolic Execution and Utilization Cliffs
      • Locality, Scratchpads and Tile Sizing
      • DMA and Double Buffering
      • Integration, Launch Cost and Signoff
  • SoC Architecture Tradeoffs9
  • Architecture Interview Prep14
Loading lesson

‹Accelerators for the Architect
  1. Topics
  2. Computer Architecture
  3. Accelerator Architectures
  4. Accelerators for the Architect
  5. When an Accelerator Pays Off

Computer Architecture · All levels

When an Accelerator Pays Off

Amdahl bounds and offload costs decide whether an accelerator wins, shown with worked numbers.

On this page

    Amdahl sets the ceiling

    Only the acceleratable fraction matters. If 60% of runtime can run 8 times faster, the whole runs about 2.11 times faster, not 8.

    The rest is serial ballast. It caps every proposal before RTL starts.

    Diagram
    Amdahl: S = 1 / ((1 - f) + f / s), f = 0.6, s = 8
    denominator = 0.4 + 0.6 / 8 = 0.4 + 0.075 = 0.475
    S = 1 / 0.475 = 2.105... ≈ 2.11x

    Kernel mix share

    Plan

    End-to-end result

    Conv 50%, attention 30%, elementwise 20% (sums to 100%)

    Accelerate conv 4x only

    1 / (0.5 + 0.5 / 4) = 1 / 0.625 = 1.60x

    Same mix

    Accelerate conv 4x and attention 2x

    Serial 0.2 + 0.5/4 + 0.3/2 = 0.475, so 1 / 0.475 = 2.11x

    Offload must beat the CPU

    An offload wins when launch plus movement plus remote compute beats local compute. Fixed costs dominate small kernels.

    Assume a 500 GB/s link and decimal MB. A 3 MB tile moves in 3e6 / 5e11 = 6e-6 s = 6 us.

    Diagram
    Offload budget: T = T_launch + T_xfer + T_acc + T_return
    large kernel: 2 us + 6 us + 4 us + 1 us = 13 us vs 20 us on CPU -> offload wins (20 / 13 = 1.54x)
    small kernel: 2 us + 2 us + 1 us + 1 us = 6 us vs 5 us on CPU -> offload loses

    Prototype with kill criteria

    A prototype plan names the measurement that kills the pattern. Vague plans drift into schedule slips.

    Example gates: kill the systolic candidate if median shapes fall below 60% utilization, or if spill traffic exceeds the stated bytes-per-operation budget.

    Axis (1-5)

    Dense 256x256 GEMM on systolic

    Divergent loop on systolic

    Operation regularity

    5

    2

    Reuse under real shapes

    5

    2

    Divergence tolerance

    3

    1

    Compiler maturity

    4

    2

    Common mistakes

    Common pitfall

    Ranking patterns by peak TOPS repeats the legacy error. Peak matters only when the Amdahl fraction is large and tiles actually reach the array.

    Interview

    Likely probes: Amdahl arithmetic and the offload inequality.

    • Write S = 1 / ((1 - f) + f / s) and substitute before claiming any speedup.

    • List launch, transfer, compute and return separately; small kernels lose on fixed cost.

    • Name one kill criterion with a number before committing RTL.

    Check yourself A kernel is 80% acceleratable at 5x. What is the end-to-end speedup?

    1 / (0.2 + 0.8 / 5) = 1 / (0.2 + 0.16) = 1 / 0.36 = 2.78x.

    Check yourself The array is fast but each job pays 3 us of launch plus transfer for 1 us of compute. What decides the outcome?

    The fixed cost. Batch more work per launch or keep the kernel on the CPU.

    Related topics

    • Roofline and tuning

    • Performance method

    Previous

    58 / 86

    Next: Dataflow Patterns as Reuse Contracts

    Up next

    Up nextDataflow Patterns as Reuse Contracts

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Systolic Execution and Utilization Cliffs
    • Locality, Scratchpads and Tile Sizing
    • DMA and Double Buffering