One engineering plan.
From specification to handoff.

Start with a product definition, not a tool list

A turnkey IC programme needs an agreed product specification before implementation begins. The discovery review should establish the intended application, operating conditions, interfaces, performance targets, power budget, package constraints and expected production volumes. Existing RTL, software, reference hardware and validation results help distinguish reusable work from new development. Requirements that remain open should have an owner and a decision date; they should not silently become implementation assumptions.

The output is a scoped engineering plan with clear boundaries. Architecture, RTL, verification, physical implementation, DFT, packaging coordination and post-silicon support can be included where agreed. Foundry access, third-party IP, tool licences, fabrication, assembly and test procurement need explicit ownership. An engineering engagement does not by itself include the commercial purchase of these services.

Architecture and integration planning

Architecture translates the product requirement into blocks, clocks, resets, power domains, memories and external interfaces. Early review should address throughput, latency, buffering, register behaviour, interrupt handling and software visibility. The integration plan records which blocks are supplied by the client, which are licensed from third parties and which need custom development. Each interface needs a defined protocol, timing assumption and verification responsibility.

Low-power intent and test requirements belong in this stage. Retrofitting isolation, retention or scan access after the architecture is fixed can create costly changes. An initial floorplan and memory assessment can expose area and interconnect risks before the RTL is complete. The architecture review closes when the stakeholders agree the block boundaries and the evidence needed to evaluate them.

Verification that follows the specification

The verification plan should map requirements to checks. Depending on the design, the work can include lint, clock-domain and reset-domain crossing review, simulation, assertions, formal checks, functional coverage and integration regressions. A passing test alone does not establish coverage: reviewers need to understand which behaviours were exercised, which remained unreachable and which require a justified waiver.

Changes to RTL, constraints or interface definitions should trigger the appropriate regression scope. Defects need a reproducible test, ownership and closure evidence. Verification completion is a reviewed decision against the agreed plan, with residual risks documented. Coverage percentages should always be accompanied by their measurement scope and exclusions.

Implementation and signoff preparation

The implementation phase connects synthesis, test insertion, floorplanning, placement, clock-tree synthesis and routing. Constraints, libraries, corners and extraction settings must be consistent with the target design environment. Timing, congestion, power and area are evaluated together: a local improvement can cause a regression elsewhere. Reviews should therefore compare a controlled baseline against the changed implementation.

Signoff preparation brings together timing analysis, physical verification, power integrity and the project-specific checks required by the receiving organisation. The acceptance package should identify tool versions, input revisions, analysis corners, exceptions and unresolved violations. A completed flow is not synonymous with clean signoff; the underlying reports and checks determine the result.

Tapeout handoff and post-silicon readiness

The tapeout handoff is a controlled release. The parties agree which layout data, netlists, constraints, reports, checksums and release notes must be delivered, who authorises the release and how any final engineering changes are handled. Foundry-specific requirements are confirmed with the authorised manufacturing partner. Fabrication timelines and yield cannot be inferred from completion of the design work.

Post-silicon planning should begin before silicon arrives. Bring-up firmware, board requirements, test access, expected measurements and fault-isolation procedures reduce ambiguity during initial evaluation. The validation plan should separate functional checks from performance, power and environmental characterisation. Findings return to the issue register with evidence that supports a decision about firmware changes, test changes or a silicon revision.

A practical governance and handoff model

Each milestone should have named inputs, a responsible owner, review criteria and an output package. Weekly technical reviews are useful when they focus on decisions, changes and blockers rather than activity counts. Scope changes should identify effects on schedule, effort, verification and downstream dependencies. The client should be able to see which assumptions have changed and which decisions are still required.

A useful first conversation includes the current specification, design maturity, available collateral, intended technology, schedule constraints and the preferred engagement boundary. Sensitive RTL, PDK material and customer data should be exchanged only through the agreed access process. The final statement of work defines deliverables, acceptance, support boundaries and the treatment of open issues.

Choose a delivery boundary before committing to a programme

A turnkey enquiry should identify the product objective, the starting design state and the endpoint the client wants Avecas to own. A specification-to-implementation assignment differs from a tapeout-support or post-silicon assignment. Separate design delivery from fabrication, packaging, testing and procurement. The statement of work should name the parties responsible for each activity, the required approvals and dependencies on third-party suppliers.

Start with a readiness review: specification completeness, IP availability, authorised tool and PDK access, verification maturity, integration assumptions and the intended acceptance evidence. Convert the gaps into a plan with named owners. Stage commitments around reviews so that an unresolved architecture or licensing dependency is addressed before it becomes a late delivery problem.

A practical programme can use five review gates: requirements baseline, architecture and verification plan, implementation readiness, evidence review and handoff. Each gate needs an owner and an explicit decision. A blocked gate should identify the missing evidence and the downstream activities that depend on it. Schedule and commercial commitments are agreed for the actual programme, not inferred from a generic flow diagram.