Computer Architecture · All levels
Dataflow Architecture Choices — Interview Drills
Interview Drills for Dataflow Architecture Choices (Accelerator Architectures).
Interview drills
Practice aloud for Accelerator Architectures → Dataflow Architecture Choices. Use METRIC → HYPOTHESIS → FIX → REGRESSION.
Explain Dataflow Architecture Choices to a hiring manager in 60 seconds.
[INT][ARCH][TOPIC]
Q: Explain Dataflow Architecture Choices to a hiring manager in 60 seconds.
A:
Design compute-data movement choreography (weight-stationary, output-stationary, streaming, tiled) for stable efficiency across workload diversity.
FOLLOW-UP TRAP: Tool list without mechanism.What report proves Dataflow Architecture Choices is done?
[INT][ARCH][TOPIC]
Q: What report proves Dataflow Architecture Choices is done?
A:
Name the primary architecture metric report and acceptance criteria.
FOLLOW-UP TRAP: No metric — only 'looks good'.What breaks if Dataflow Architecture Choices is done poorly?
[INT][ARCH][TOPIC]
Q: What breaks if Dataflow Architecture Choices is done poorly?
A:
Downstream performance, power, verification, software, or implementation failures.
FOLLOW-UP TRAP: Only mentions runtime, not silicon risk.10+ year interview answer bar
At senior/principal level, the interviewer is testing ownership judgment more than vocabulary. Answer Dataflow Architecture Choices through failure mode, evidence, tradeoff, and release decision.
You inherit a late-stage Dataflow Architecture Choices failure one week before release. What do you do in the first hour?
[INT][ARCH][STAFF]
Q: You inherit a late-stage Dataflow Architecture Choices failure one week before release. What do you do in the first hour?
A:
Freeze the workload/model/RTL tag, name the failing metric (Accelerator Architectures closure dashboard), confirm counter setup, cluster the issue by structure or workload phase, assign the first experiment, and publish a validation/owner plan before changing architecture.
FOLLOW-UP TRAP: Jumping directly to a larger cache, wider pipe, or extra NoC link without preserving evidence.When would you stop trying to improve Dataflow Architecture Choices and escalate?
[INT][ARCH][STAFF]
Q: When would you stop trying to improve Dataflow Architecture Choices and escalate?
A:
Escalate when the remaining risk crosses ownership boundaries, consumes shared margin, changes signed-off assumptions, or threatens Memory subsystem sizing and runtime policy complexity.. Bring exact report lines and options, not vague concern.
FOLLOW-UP TRAP: Escalating without data or continuing alone after a cross-team decision is needed.Whiteboard diagram to draw
VISUAL MODEL — Accelerator Architectures / Dataflow Architecture Choices
workload / trace
│
▼
metric symptom (IPC, MPKI, bandwidth, latency, stalls)
│
▼
likely microarchitectural mechanism
│
┌───────┼────────┐
▼ ▼ ▼
pipeline memory fabric/coherency
stalls misses queues / ordering
│ │ │
└───────┼────────┘
▼
bounded design change
│
▼
validation workload + PPA regressionArchitecture deep dive
Accelerators win on locality and bandwidth contracts, not peak OPS alone.
Concept diagram
ACCELERATOR DATAFLOW
Host CPU ── commands ──► Queue / scheduler
▲ │
│ completion ▼
Coherent memory ◄── DMA ── Local SRAM ──► Compute array
▲ │
└ tiles ┘
Peak TOPS matters only when data reaches the array at the needed rate.Metric graph
UTILIZATION BREAKDOWN
compute active ██████████████████ 58%
DMA wait ██████████ 31%
host sync █████ 15%
cache/coherency ████ 12%
idle bubbles ███████ 22%
Low utilization is usually a system integration problem.Metrics and artifacts
accelerator utilization
DMA bandwidth
kernel launch overhead
coherency invalidation rate
Mini case study
NPU met TOPs target but end-to-end inference slow — DMA and weight fetch dominated. Architecture added on-chip SRAM tile and double-buffering.
Debug branches
If util low, check launch overhead and host sync first.
If BW high, examine weight layout and sparsity support.
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.
Study notes
Re-read this topic with one concrete workload.