Generation moves errors rather than eliminating them: a fact stated wrongly once is now wrong consistently everywhere, at scale, with a build stamp that makes it look authoritative. The integrator's skill shifts from writing connections to auditing them, and that audit needs its own discipline. This lesson is the sceptical half of the automation topic: what to read, what to assert, and the specific ways generated chips go wrong.
Review the description as the design and the generator as a compiler: the description gets the deep read, the generator gets regression tests, and the output gets a sampled audit plus mechanical checks that run every build. The sampled audit reads four things a generator characteristically gets wrong: tie-offs (every tied input listed with its value and its reason, especially address and protection sidebands), unconnected outputs (waivable only one by one), parameter propagation (each instance's values read back from the generated top, not from the request), and naming (generated nets following the project conventions so debug and constraints still match). The mechanical checks are the ones from the earlier lessons running unattended: map overlap and alignment, register-specification rules, connectivity of every instance, and header-versus-decode agreement.
Failure mode | How it looks | Standing guard |
|---|---|---|
Wrong fact, perfectly copied | Every artifact agrees and all are wrong | One source review against the RTL before generation |
Silent tie-off | Unused or forgotten input tied to zero invisibly | Explicit tie list, reviewed; no default ties |
Parameter not propagated | Instance runs at its default, not the requested value | Read parameters back from generated output |
Stale description | Block redelivered, description not updated | Description is a delivery checklist item with version match |
Hand-patched output | Fix vanishes at the next regeneration | Banners, plus regeneration diff in the build |
Where automation stops entirely is equally important to state in a review. It does not judge whether an architecture is right, only whether it is consistently described. It does not express behavioural rules: busy-ignored writes, interrupt semantics and reset ordering still need RTL, tests and prose. It does not resolve clock, reset and power intent, which need their own reviewed descriptions and checks in their own sections. And it can actively hide a missing block: a chip generated from a description that never mentioned the bridge watchdog generates cleanly without one. The description's completeness against the specification is a human review item with a checklist, which is why this topic ends on review rather than on more generation.
The tie list and the unconnected-output list, each entry with a reason; an empty list is a claim that must be true, not a default.
Parameters read back from the generated top for every instance, compared against the request table.
Regeneration produces no diff against the committed output; any diff is either the intended change or a hand-patch being reverted, and the review decides which.
Keep golden copies of generated artifacts per release and diff them deliberately. When silicon or simulation misbehaves near a generated boundary, suspect the description before the RTL: read the instance's facts in the description, then the generated lines, then the RTL port list, in that order. Most assembly bugs are found at the first step, in minutes, which is the return on having a description to read at all.
In the description: the base was stated wrongly once and copied consistently, so every agreement check passes. Only the source review against the map table (or a bench access to the true address) finds it, which is why source review precedes generation.