What belongs in a turnkey IC-design project brief

Start with the product decision

A turnkey IC-design discussion becomes productive when it begins with the product, not a list of tool names. Describe what the chip must do, the system it belongs to and the decision that the next engineering phase must support. Explain whether the programme is exploring feasibility, implementing an agreed architecture or preparing a defined release package.

Include the current design state. A new concept, an existing RTL block and a subsystem that already has verification results require different work. Share what is known and mark what remains undecided. An honest list of gaps makes scope estimation more reliable than a polished presentation that leaves critical assumptions implicit.

Define the technical baseline

The brief should identify interfaces, operating modes, clocks, reset behaviour and the workload behind performance requirements. For power, performance and area targets, state the measurement conditions and how competing priorities will be resolved. A frequency number without a workload or implementation context gives little guidance for an architecture tradeoff.

Record the intended process and library environment if selected, along with access requirements and restrictions. If technology selection is still open, make it a discovery task with its own decision criteria. Avoid presenting a node name as evidence that every required IP, memory or package option is available and qualified for the product.

Make ownership visible

Separate client-owned inputs, engineering responsibilities and third-party dependencies. Identify who approves the architecture, supplies licensed IP, resolves interface changes and accepts the final package. Include the role of foundry, packaging, test and board partners where those activities are in scope.

A responsibility matrix is useful only when it describes actual decisions. Instead of assigning a broad label such as verification, specify ownership of the test plan, environment, regression review and exclusions. This makes it easier to detect a gap between teams before it becomes an integration problem. Escalation paths should be clear enough to use when a decision is time-sensitive.

Plan milestones around evidence

Milestones should describe what a reviewer can inspect. An architecture milestone might require agreed interfaces and a requirements traceability map. A verification milestone might require reviewed scenarios, results and exclusions. An implementation milestone needs its defined reports and conditions. The exact artifacts depend on the programme.

Dates should be connected to input readiness and review availability. A schedule that assumes a library, IP release or client decision will arrive on time should record that dependency. If it changes, review the impact on the affected stages rather than silently compressing verification or signoff preparation to preserve a date.

Define the release boundary

Turnkey can mean different things to different teams. State whether the package ends at a verified block, an implementation database, a tapeout preparation review or a broader coordination scope. Do not assume that fabrication, packaging, production test or post-silicon support is included merely because the engagement is called turnkey.

The acceptance plan should identify the required files, report conditions, reproducibility instructions and open-item treatment. Separate delivery from acceptance: transferring an archive does not prove that the receiver can use it or that every engineering criterion is satisfied. Agree a review and correction process before the handoff.

A discovery meeting that produces decisions

Use the first review to walk through one representative product operation from input to output. Identify the hardware blocks, software responsibilities and external dependencies involved. Ask what the operation must do under a stall, reset, error or power transition. This turns a broad product description into concrete interfaces and helps the team see which disciplines must participate in the next phase.

Then separate three lists: material already available, decisions the client can make and questions that require engineering investigation. Assign a named role to each item and identify the evidence needed to close it. Some questions can be answered in a short document review; others need a prototype, simulation or implementation experiment. Treating every unknown as the same kind of task makes estimates less useful.

End with a proposed discovery package: the questions to answer, the inputs needed, the review meeting and the artifact that will support the next commitment. Record what is outside that package. A bounded first phase gives both teams something concrete to accept and provides a better basis for a larger programme. It also makes clear which schedule assumptions can be trusted and which depend on evidence that has not yet been produced.

Use the first discussion to reduce uncertainty

A useful first call can focus on the top unresolved decisions: the architecture boundary, available collateral, technology assumptions and release target. Share a compact input inventory in advance and keep confidential material within an agreed access process. The objective is to leave with a bounded next step, not to pretend every estimate is already final.

This engineering brief is general planning guidance. It is not a customer announcement or a promise of a specific delivery outcome. Avecas’s turnkey page describes the six-stage approach and the questions used to shape a project-specific statement of work.

What to bring. What to review.

Questions before you begin.