Inside Nvidia B200 Pipeline Hazards: Why Static Analysis Falls Short
An empirical study of Nvidia B200 pipeline hazards, exposing a predicate under-stall bug and measured RAW latency floors for FFMA and DFMA.
On-silicon microbenchmarking of Nvidia's B200 reveals how compiler schedulers can report full dependency coverage yet still produce silently corrupted results. The root cause is under-stalling: a consumer instruction issues before a producer's result is committed to the register file, and the hardware simply executes on stale data without raising an exception.
The centerpiece finding is a predicate-consumer bug in a classic loop back-edge pattern, where an ISETP instruction computes a condition later read by a branch. The scheduler correctly tracked the branch's execution guard predicate (P0) but missed the actual branch-condition operand (P1) as a use. This caused the ISETP→BRA RAW dependency to go unencoded entirely — the branch issued after only ~4 cycles instead of waiting out the modeled 13-cycle predicate latency, reading a stale value and taking the wrong execution edge.
The piece also documents measured latency floors for fixed-latency arithmetic: FFMA (FP32) requires 4 cycles before its result can be safely read, while DFMA (FP64) requires 8 — exactly double, reflecting the deeper FP64 pipeline. Notably, floating-point recurrence chains are needed to expose these hazards reliably, since integer chains can be silently forwarded around by hardware bypass networks.
For compiler and GPU backend engineers, the takeaway is that Nvidia does not publish pipeline depths or scoreboard semantics, so architectural models are approximations at best. Without direct on-silicon validation probes, under-stall correctness bugs can slip past even seemingly complete test suites.