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

  • How to Use This Course
  • Reading Paths
  • Concept Map
  • Meet DCRouter
  • Glossary
  • Part 0: What Verification Is8
  • Part 1: What Can Go Wrong11
  • Part 2: Specifications as Checkable Rules8
  • Part 3: Observability and Controllability7
  • Part 4: Stimulus11
  • Part 5: Checking11
  • Part 6: Coverage10
  • Part 7: Formal and Simulation10
  • Part 8: Verification Levels and Reuse8
  • Part 9: Planning and Risk9
  • Part 10: Emulation and Prototyping8
  • Part 11: Post-Silicon Validation8
  • Part 12: Bug Economics8
  • Part 13: Debug7
  • Part 14: Sign-Off7
  • Part 15: Verification in Context8
  • Part 16: Case Studies5
    • How to Read an Escape
    • The Pentium FDIV Bug
    • A Chipset Recall
    • Speculative Execution Attacks
    • Writing a Post-Mortem
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 16: Case Studies
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 16: Case Studies
  4. A Chipset Recall

Part 16 · Case Studies · Senior (S)

A Chipset Recall

In January 2011 Intel stopped shipping its 6 Series chipset because some SATA ports could degrade over time. The reported cause was a single transistor biased at too high a voltage: a circuit and reliability defect, not a logic bug. What is documented, why functional verification cannot see this kind of failure, and where in the flow it belongs: circuit checks, reliability analysis, and silicon validation with stress and margins.

On this page

    Note

    Level: Senior (S) · Answers: What can real projects teach us?

    Before this: The Pentium FDIV Bug, Margins and Characterisation

    On 31 January 2011 Intel announced that it had stopped shipping its 6 Series chipset, used with Sandy Bridge processors, code-named Cougar Point (fact C2). Some of its SATA ports, which connect disks and optical drives, could degrade over time. PC makers withdrew systems, and Intel corrected the design and replaced affected parts. The logic of the chipset was not wrong. A circuit was.

    What does an escape that no functional test could see teach about the verification flow?

    What failed (documented)

    Fact

    Source

    Some SATA ports in the 6 Series chipset could degrade over time; Intel stopped shipments and corrected the design with a metal-layer change

    Intel press release, 31 January 2011 (fact C2)

    Reported cause: one transistor in the clocking tree of the 3 Gb/s SATA PLL was driven at too high a voltage for its thin gate oxide, so its leakage could grow over time

    AnandTech, 31 January 2011, reporting Intel's explanation (fact C5)

    Only the 3 Gb/s ports (2-5) were affected, not the 6 Gb/s ports

    Fact C5

    Intel estimated about $700 million to repair and replace affected parts and systems

    Fact C5

    Why functional verification could not see it (the course's reading)

    Everything this course has built assumes that a transistor switches when the logic says it does. RTL simulation, formal proof and emulation all model the design's logic; a correctly designed circuit that wears out because of an electrical stress looks perfect to every one of them on day one and every day after. The failure was in a different layer:

    Layer

    Question

    Verified by

    Logic (this course)

    Does the design compute the right thing?

    Simulation, formal, emulation

    Circuit

    Does each transistor operate within its rated voltages and currents?

    Circuit simulation, electrical rule checks, design reviews

    Reliability

    Will it keep working for its rated lifetime under stress?

    Ageing analysis, accelerated stress testing of silicon (temperature, voltage, time)

    Silicon validation

    Does real silicon work across voltage, temperature and process, now and after stress?

    Characterisation and margin testing (lesson 11.5)

    The defect was time-dependent: ports that worked at first could degrade later. That is why the lesson belongs to reliability and validation: an initial functional test of silicon passes, and only stress over time, or an analysis of the transistor's operating voltage, reveals it.

    The verification-strategy lessons

    • Functional sign-off is not chip sign-off: lesson 14.4's residual risk should name what the functional evidence does not cover, including electrical and reliability risk owned by other teams.

    • Analogue and mixed-signal blocks are a seam: PLLs, PHYs and I/O are where circuit and logic verification meet, and where plans should check who owns which risk (lesson 1.5's integration seams).

    • Validation must include time and stress: a part that passes on day one can fail after months; accelerated stress testing exists to compress that time (lesson 11.5).

    • A metal-layer fix is not free: it still meant new silicon, replacement parts and systems withdrawn from sale (Part 12's cost of late bugs).

    Reading it through the course's questions

    Question

    Answer

    What failed?

    SATA ports that could degrade over time, from an overstressed transistor in a PLL clocking tree (documented)

    Where could it have been caught?

    Circuit-level checks of device operating voltages, reliability analysis, or longer stress testing of silicon (the course's reading)

    Why was it not caught?

    Outside what logic verification models, and time-dependent, so initial silicon tests pass (the course's reading)

    What changed?

    Shipments stopped, a metal-layer fix, replacement at an estimated $700 million (documented)

    Why this matters

    Principal lens. A verification strategy should state its boundary: what the logic evidence covers and which risks (circuit, reliability, analogue, ageing) belong to other teams and other methods. At sign-off, ask for the evidence on both sides of that boundary, especially at analogue and mixed-signal seams such as PLLs and PHYs.

    Interview

    Asked: "Could better functional verification have caught the Cougar Point SATA issue?"

    Weak answer: Yes, with more tests of the SATA ports.

    Strong answer: Not according to the documented cause. Intel's explanation, as reported, was one transistor in the 3 Gb/s SATA PLL's clocking tree biased at too high a voltage for its thin oxide, so leakage could grow over time and ports could degrade. The logic was correct; RTL simulation, formal and emulation all model logic, and the part worked at first. It belongs to circuit checks of operating voltages, reliability analysis and stress testing of silicon over time. The strategy lesson is to state what functional sign-off covers and make sure someone owns the circuit and reliability risks, especially at analogue seams.

    Follow-ups: (1) Who owns reliability risk in a chip project? (2) What is accelerated stress testing?

    Check yourself Why would every RTL simulation of Cougar Point's SATA logic have passed?

    RTL simulation models logic, not transistor voltages or wear-out; the logic was correct and the failure developed over time in a circuit.

    Check yourself What should a sign-off residual-risk statement say about such risks?

    That electrical, analogue and reliability risks are outside the functional evidence, and who owns them with what evidence.

    Key takeaways

    • Cougar Point: an overstressed transistor could degrade SATA ports over time (documented).

    • Logic verification cannot see circuit and reliability failures; they need circuit checks and stress testing.

    • State the boundary of functional sign-off and make sure the other risks are owned.

    Keep going

    Next: Lesson 16.4, Speculative Execution Attacks. When correct behaviour leaks secrets.

    Related topics

    • Part 16 overview: Case Studies

    Previous

    147 / 160

    Next: Speculative Execution Attacks

    Up next

    Up nextSpeculative Execution Attacks

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • How to Read an Escape
    • Writing a Post-Mortem