From promising IP to a deliverable semiconductor product

The product extends beyond the design

A working hardware block can be a major technical achievement and still be far from a deliverable product. Customers also need a stable interface, usable software, evaluation support, predictable supply and a clear way to resolve problems. Product execution connects those requirements to the engineering plan.

For a fabless organisation, the challenge is especially visible because work crosses company boundaries. The design team, foundry, packaging provider, test house, IP suppliers and customer each hold part of the information. A programme can appear healthy inside one team while a dependency elsewhere threatens the release.

I think of execution as a sequence of commitments backed by increasingly strong evidence. Early exploration should answer whether a problem is worth solving. Development should establish whether the chosen solution can meet its requirements. Release should establish whether the organisation can deliver and support it repeatedly.

Connect the customer problem to acceptance

A useful product requirement describes the outcome and the conditions under which it matters. It should not unnecessarily prescribe an internal implementation. “Support this sustained sample rate within this power envelope” leaves room for architectural judgement. “Use this many pipeline stages” may constrain the solution before the trade-off is understood.

Requirements need owners and priorities. When cost, performance and schedule conflict, the team should know which requirement is essential and which can change. A controlled baseline is useful because it makes changes visible; it should not make legitimate learning impossible.

Translate each important requirement into an acceptance method. Some can be demonstrated in simulation, others through analysis or prototype testing, and some require production or qualification evidence. Record that distinction early. It prevents a late discovery that a promised capability has no practical test method.

Make gates resolve decisions

The names and number of gates should fit the project. A small reusable IP block does not need the ceremony of a complex SoC. The essential principle is that a gate changes a decision or releases a commitment. A meeting that only repeats status adds little.

Possible outcomes include proceeding, holding for a specific condition, revising scope or stopping. A stop can be a successful use of engineering judgement when the remaining value no longer justifies the cost. Continuing solely because effort has already been spent creates a different kind of risk.

Plan the parallel work

Firmware, boards, test development, packaging and documentation should progress alongside the core design. Waiting for silicon to begin software integration or test preparation turns predictable work into a release delay. Models, emulation and FPGA prototypes can reduce uncertainty earlier, although each has a defined scope and cannot replace every later measurement.

Make partner inputs explicit in the schedule. A foundry deliverable, a licensed IP update or a package design review should have an owner, acceptance criteria and a consequence if late. Include recovery options where a dependency is difficult to replace.

Track resources by critical skill, not only by total headcount. Ten available engineers do not resolve a bottleneck that requires a specific verification, analogue or physical-design capability. Portfolio decisions should reflect those constraints before several programmes promise the same person’s time.

Readiness reporting should combine completed evidence, unresolved decisions and the next commitments. Distinguish a risk that may happen from an issue that has already occurred. Assign a response owner and a trigger for escalation, rather than leaving the team with an undifferentiated list of concerns.

A product becomes deliverable when engineering, operations and customer expectations converge on the same definition of ready. That alignment is a technical responsibility and a leadership responsibility. It is what turns a good design into a result that another organisation can adopt with confidence.

Further reading

• OpenTitan — Hardware development stages
• NASA — Systems Engineering Handbook