Thread

1. 20k · 1790074429 · focus · HN ↗

   I always wonder how hardware bugs like this happen with the sheer amount of hardware validation that's done. It'd be fascinating to know how it slipped through the cracks, though I know almost nothing about this side of the industry sadly

   1. vachina · 1790080895 · focus · HN ↗

      The verification plan did not make 0 a bin to cover.
   2. bell-cot · 1790082032 · focus · HN ↗

      That "sheer amount of hardware validation" is always less-than-perfectly spread across a whole lotta billions of transistors, and combinatorics is a harsh mistress.
   3. throwawayffffas · 1790082257 · focus · HN ↗

      Almost definitely an off by one bug.
   4. repstosb · 1790082542 · focus · HN ↗

      Validation can't be better than the quality of the specification. Humans don't create comprehensive, unambiguous specifications for the same reasons that we don't write bug-free code, and need formal validation.

      Brooks talks about this in _Mythical_Man-Month_... if you really could "just implement the specification", then the specification itself would be complete enough to serve as your code. There will always be bugs in both.

   5. RicoElectrico · 1790085994 · focus · HN ↗

      Me too. Hardware bugs that arise out of unanticipated module interactions are understandable. But this is a "you had one job" moment.

      1. mitxela · 1790164404 · focus · HN ↗

         It's most likely a quick patch for a previous bug where the RNG would fail but misreport it as a success with all 0 bits. The quick patch is to make all 0s a failure.

Unofficial Hacker News client; not affiliated with Y Combinator.