A shared base of architecture, IP, software and tools from which several products are derived: the platform's definition, a reference architecture with its variation points, the roadmap that commits it, a virtual platform and emulation and FPGA prototypes for early software, reusable IP and a software platform with its SDK, the lead product that proves it, a released baseline, derivative products built from it, long-term support across all of them and the platform's retirement.
Start here: what it is, how the related terms differ, what this lifecycle covers and its phases in order, then the detail.
A platform is a shared base of architecture, IP, software and tools from which several products are derived. Instead of designing each chip or system from the start, a company builds the common core once and lets each product choose a configuration of it and add only what makes it different.
The core usually includes a processor and memory structure, an on-chip interconnect, security features, a set of reusable IP blocks, a software base with its drivers and operating system support, an SDK and the tools to build it all. Around the core, the platform defines variation points: the places where products are allowed to differ, such as memory size, peripherals or performance.
A platform is rarely sold as such. Its value shows in its products: how quickly a new one can be derived, how much it reuses, and how well a fix or a security update reaches every product that shares it.
A platform sits between the blocks it is built from and the products built on it. From smallest to widest:
| Term | What it is | How it differs |
|---|---|---|
| IP block | A reusable design for one function.For example: A processor core or a USB controller. | One building block; a platform holds a qualified set of them. |
| Chip | The everyday word for an integrated circuit. | Informal: it can mean the die, the part or the product. Each derivative chip is taped out on its own. |
| Product | The part, or a set of parts, with datasheet, software, support, qualification, supply commitments and roadmap. | What is sold. A platform's products each run their own product lifecycle. |
| System | The customer's finished equipment, such as a phone or a vehicle controller. | Where products are designed in; system makers can run platforms of their own. |
| Platform | A shared architecture, IP and software base from which several products are derived. | Usually not sold as such; its choices shape a whole family. |
| Lead product | The first product built on a new platform. | Proves the platform on silicon before others reuse it. |
| Derivative | A new product built from an existing design or platform with limited changes. | Reuses most of the platform, but is taped out, qualified and released in its own right. |
| Product family | Products on a shared design that differ in features, memory, package or grade. | The family is what the business sells; the platform is what engineering shares. |
The platform lifecycle is the path of one platform, from the decision to build it to its retirement: defining what its products will share, designing the reference architecture, planning the roadmap of products built on it and committing its development, building and qualifying its IP, software and tools, proving it on a lead product, releasing it as a versioned baseline, then supporting every derivative built on it.
It runs beside many product lifecycles rather than inside one. The platform's own approval and roadmap are business decisions in the product lifecycle; each derivative then starts its own product, SoC and firmware lifecycles from the released baseline. The IP lifecycle builds the reusable blocks it holds.
Virtual platforms, emulation and FPGA prototypes matter even more here than for a single chip: one model or prototype serves every derivative, and the platform software can be proven before the lead product's silicon arrives.
A platform architect and a portfolio or programme manager usually run it, with a platform board deciding what enters the platform. Its gates matter because a mistake in the platform is inherited by every product built on it.
A dotted underline opens the full definition in the glossary.
Credible sources, named for further reading. Standards are available from the body that publishes them.
Platform and derivative products lifecycle: 12 stages, 12 gates of its own and 6 hand-offs to the Product lifecycle, from Platform Strategy & Definition to Platform Retirement.
12 stages, 12 gates of its own and 6 hand-offs to the Product lifecycle, 3 of the gates technical readiness reviews (TR). Each stop opens its stage; each sign opens its gate. Point at a stop or tab to it to read what the stage is for. What the codes mean
In collaboration with The Digital Electronics Blog (opens in a new tab)
A dashed sign with a TR tag is a technical readiness review gate.
An outlined sign with an arrow is a hand-off: the gate is owned by the Product lifecycle, where this lifecycle hands its work on.
In collaboration with The Digital Electronics Blog (opens in a new tab)
Deciding what the platform is for: the markets and the family of products it will serve, what all of them share and where they may differ, what the platform must make cheaper or faster than building each product alone, and the technology it will depend on.
Platform concept approval gate, owned by the Product lifecycle (Concept approval)TR1: Technology feasibility gateTR1, technical readiness reviewPlatform definition approved gate
Defining the architecture every product of the platform shares and the points where products are allowed to differ: the common processor, memory and interconnect structure, the interfaces, the configuration options and the rules a derivative must follow to stay on the platform.
Laying out, against the baselined reference architecture, when the platform and each product derived from it will arrive: the lead product, the planned derivatives, the IP and software versions they need, and the sourcing and licensing of the IP the platform will reuse.
Roadmap approved gate, owned by the Product lifecycle (Plan approval and development commit)
Building the virtual platform every derivative will share: executable models of the reference architecture that run the platform software before silicon exists, with performance and power models to check the architecture against the workloads of each planned product.
Developing, buying and qualifying the IP blocks and subsystems the platform reuses across products, to a reuse standard: configurable, documented, verified for every supported configuration and held in a catalogue with its licence terms.
Building the software every derivative starts from: boot code and firmware, the board support, operating system support, middleware and libraries, and the SDK, toolchains and build system that let each product team configure and build its own software from the shared base.
Running the platform's hardware design at speed on emulators and FPGA prototypes, so the platform software is brought up and the platform's hardware and software are verified together before the lead product's silicon arrives.
Platform proven on prototypes gateTR2, technical readiness review
Proving the platform on its first product: the lead product's chip, boards and software are built from the platform, validated on real silicon and hardware, and the lessons are fed back into the platform before it is released for reuse.
Releasing the platform as a versioned baseline that product teams can build on: the IP catalogue, the software and firmware releases, the SDK, the reference designs, the conformance test suite, the documentation and the training for derivative teams.
Deriving new products from the released platform: each derivative chooses its configuration, reuses what it can, adds only what it must, records any deviation from the platform rules and proves its conformance before it goes through its own chip and product lifecycles.
Derivative approved gate, owned by the Product lifecycle (Concept approval)Derivative conformance verified gateDerivative production release gate
Keeping the platform and every product on it supported for as long as customers need: maintenance releases of IP, firmware, software and tools, security advisories across all derivatives, and roadmap reviews that decide what the next platform version or generation should change.
Platform maintenance release gatePlatform roadmap review gate, owned by the Product lifecycle (Lifecycle review)
Closing the platform in an orderly way once no new products will be derived from it and support commitments run out: the retirement notice, migration guidance to a successor platform, final releases and an archive that lets products still in the field be supported.
Platform retirement notice gate, owned by the Product lifecycle (Discontinuance notice)Platform end of support gate, owned by the Product lifecycle (End of support)
An outlined sign with an arrow is a hand-off: the gate is owned by the Product lifecycle, where this lifecycle hands its work on.
The full lifecycle detail, with its charts, flows, tables and every section, is for registered members. Registration is free and takes a minute. You come back to this page afterwards.