Errata are the published list of known bugs in a chip. Each entry describes a deviation from the specification, what it means for a system, how to avoid it, and whether it will be fixed. Customers design boards, firmware and software around this list, so it is part of the product.
This article describes what an erratum contains, how entries move through their life, and how errata differ from specification updates.
5 min read | Beginner
What You'll Learn
- List the parts of an erratum entry
- Distinguish errata from specification clarifications and changes
- Follow an erratum from discovery to fixed stepping
- Write an erratum that customers can act on
What an Erratum Contains
- Identifier and title: a stable number and a short description.
- Problem: the exact conditions under which the chip deviates from the specification.
- Implication: what a system will see, such as a hang, wrong data or a lost interrupt.
- Workaround: what firmware, software or board designers should do, or "none identified".
- Status: which steppings are affected, and whether a fix is planned.
The description must be precise enough for a customer to decide whether their system can ever hit the conditions, without revealing more design detail than needed.
Quick Check
Q: Why is the "implication" field as important as the problem description?
Show Answer
Customers need to know what they would see if the bug occurred, so they can judge its severity for their product and recognize it when debugging their own systems. A problem described only in internal terms does not tell them that.
Errata and Specification Updates
Not every published change is a bug. Documents of known issues typically separate:
- Errata: the chip does not behave as specified.
- Specification clarifications: the specification was unclear; the text is improved, the chip is unchanged.
- Specification changes: the specification is changed to match what the chip does, when the behaviour is acceptable and fixing it is not worth it.
Life of an Erratum
An erratum starts as a sighting, becomes a confirmed bug, gets a workaround, and is then published. Its status changes over time: "fixed" in a later stepping, or "no fix planned" when the impact is low and a fix is not worth the risk.
Entries are never deleted, since older steppings remain in the field. Each document lists, per stepping, which errata apply.
Quick Check
Q: An erratum is fixed in stepping B. Why does the errata document still list it?
Show Answer
Parts of stepping A are still in customers' systems and stock. Those customers need the workaround, and anyone supporting a mix of steppings needs to know which parts are affected.
In Practice
Errata documents are usually public, or shared under agreement with customers, and are updated regularly. Customers' firmware and operating systems often check the stepping at boot and apply the listed workarounds automatically. The decision whether an erratum is fixed in silicon feeds into Metal Fix or Full Respin.
Common Mistakes
Mistake #1: Describing the bug only in internal terms
Customers need conditions and implications they can recognize.
Mistake #2: Removing fixed errata from the document
Older steppings remain in the field; keep the entry and update the status.
Mistake #3: Calling a specification problem an erratum
Use clarifications and specification changes where the chip is not at fault.
Practice Exercise
Challenge: Write an Erratum
A bug: when a DMA transfer of exactly 4 KB crosses a page boundary while the link enters a low-power state, the last 64 bytes may not be written. Firmware can prevent the link from entering the low-power state during DMA, at a small power cost. Write the problem, implication, workaround and status fields for the first stepping, with a fix planned in the next.
Hint
Conditions, visible effect, action, steppings.
Solution
Problem: a 4 KB DMA write that crosses a page boundary while the link enters its low-power state may not write the final 64 bytes. Implication: silent data corruption in the destination buffer.
Workaround: firmware disables entry to the link low-power state while DMA is active. Status: affects stepping A; fix planned for stepping B.
Summary
- An erratum gives the problem, implication, workaround and status of a known bug.
- Errata differ from specification clarifications and changes.
- Entries stay in the document after a fix, with status per stepping.
- Customers rely on errata to design and debug their systems.
