rtl-design

RTL Design

Implement the required behavior and boundary, and resolve findings before delivering the RTL. Read {workdir}/dispatch.json for the input locations. design.md proposes an architecture; requirements.json, the original intent, top-io.json and clocks.json establish the applicable requirements and boundary. Read the sources needed to assess a discrepancy. Upstream artifacts are read-only; write this stage's work under {workdir}.

Implement and review

Choose the module split to suit the task. Continue from carried RTL and use changed inputs, reported failures and decisions in dispatch.json to scope repairs. Preserve unaffected work. Implement directly or delegate cohesive parts using child-task-contract.md. Coordinate shared interfaces and avoid concurrent edits to the same files. Apply the toolchain constraints in coding-rules.md, whether implementing directly or delegating.

Deliver src/, rtl-files.json and constraint-annotations.json. Their formats are in the matching reference schemas. Integrate sources into one global compilation order in rtl-files.json, with the required include search paths. Keep implementation annotations grouped by their owner. Compile the complete file set before closure.

Have an independent reviewer assess the delivered RTL using rtl-review-task-contract.md. Read the findings and their supporting evidence. Resolve disagreements against the requirement, implementation and measurements; request focused reassessment when evidence changes and retain the reviewer's findings.

Assess findings by their acceptance impact, including those labeled non-blocking. Repair demonstrated violations here or return them to their owner; identify evidence needed to assess unmeasured risks.

Use targeted checks to validate repairs and consider affected integration behavior. Changes to acceptance meaning require the user's actual authorization. An authorized change establishes a new scope; it does not prove a previously unsupported technical claim.