The IP market is not one market. It is several overlapping ones: foundry-approved programmes, broad EDA portfolios, specialist providers, and open-source cores — each with different economics and different risk.
Shortlisting is mostly about matching the source to the function. Processor cores, interface PHYs, memory compilers and analog blocks do not come from the same place, and treating them as one purchase decision is where schedules slip.
Foundry IP Programmes
Most foundries maintain an approved IP list for each node, sometimes with negotiated terms for their customers. Using approved IP matters because the foundry has already reviewed the core against its process design kit.
The practical benefit is reduced integration risk and faster signoff. The trade-off is that approved IP is tied to that foundry, and availability varies by node — advanced nodes usually have deeper catalogues than older ones.
Large Portfolio Vendors
Broad EDA and IP vendors supply interface controllers and PHYs, memory compilers, analog building blocks and security cores alongside the tools you already use.
The advantage is integration with the tool flow and a single commercial relationship across many blocks. Specialist vendors may still win on a specific function, particularly for high-performance or unusual requirements.
Processor Core Specialists
CPU and GPU cores are a distinct category, dominated by a small number of specialist providers plus the open instruction-set ecosystem. Here the decision is rarely purely technical: software toolchain maturity, ecosystem support and long-term roadmap matter as much as the core itself.
Licensing for processors also tends to be more structured, with separate terms for the core, the debug infrastructure and any associated software.
Open-Source and Community Cores
Open instruction-set architectures and community-maintained cores remove licence fees and, in many cases, royalties. They are a genuine option for teams with the engineering capacity to integrate and validate them.
The cost moves rather than disappears: verification, toolchain support and long-term maintenance become your responsibility. For safety or security-critical functions, the qualification evidence burden is the deciding factor.
- No licence fee or per-die royalty for most open cores
- You own verification, maintenance and toolchain integration
- Qualification evidence for safety or security use is your burden
A Shortlisting Method
Start from the foundry and node, because that constrains everything else. Then split your IP needs by category and evaluate each against three questions: is it proven at this node, what is the deliverable form, and what does it cost across my volume curve?
Check silicon provenance specifically. A core that has taped out at the node on a similar process variant is a very different risk from one that has only been validated in a different foundry's process.
- Confirm availability and proven status at your exact foundry and node
- Compare deliverable form, not just price — soft RTL and hard macro are different products
- Model total cost across the volume curve including royalties
- Ask what support and node-port commitments are included
