IP FIT BEFORE INTEGRATION PAIN
Third-Party IP, Matched to Your Chip Program
TOMPW sells and sources third-party semiconductor IP. We help compare supplier options, confirm the commercial supply route and license scope, and coordinate integration support for your target process.
QUICK ANSWER
Can I buy third-party semiconductor IP through TOMPW?
Yes. TOMPW sells and sources third-party semiconductor IP and helps align supplier options with the target process and integration needs. The IP remains the original supplier's product. We confirm the specific core, commercial supply route, license scope, deliverables and support responsibility in the project quotation; availability is not implied for every vendor or node listed in our guides.
What IP categories does TOMPW cover?
Interface (USB, PCIe, Ethernet, MIPI, DDR/LPDDR), memory (SRAM/ROM compilers, eFlash/eEEPROM controllers), analog & mixed-signal (PLL, ADC/DAC, regulators, SerDes building blocks), transceiver & RF, security & subsystem IP, and subsystem tiles (MCU / DSP / NPU / NoC).
PROJECT EVIDENCE
See what was checked before an IP decision
These published, anonymized project notes describe selection and readiness decisions. They are not a catalog of IP available for every process, or a claim of silicon qualification for a different design.
DDR controller selection for SMIC 40LL
How host interfaces, PHY pairing, verification deliverables and license scope shaped a third-party IP selection.
Read the project note →
Library and PDK gaps before tape-out
Extraction files, capacitor options and PLL terms: checks that go beyond an IP category list.
Read the project note →IP CATEGORIES
Categories that drive most schedule and integration decisions
Choosing IP by category first — interface, memory, analog, RF and subsystem — keeps the foundry choice and integration path open. The descriptions below are planning categories. The supplier, specific core and availability are confirmed in the project quotation.
| Category | Typical content | Main planning concern |
|---|---|---|
Interface IP USB, PCIe, Ethernet, MIPI, DDR/LPDDR controllers & PHYs | Controller + PHY + verification IP | PHY availability per node and per foundry; PHY area and power cost in the target process; controller compatibility with the verification environment. |
Memory IP SRAM/ROM compilers, eFlash/eEEPROM controllers, DRAM I/Fs | Compilers + test patterns + repair | Memory density and redundancy trade-off; eFlash/eEEPROM integration rules; whether the foundry provides an in-house solution or third-party is needed. |
Analog & Mixed-Signal PLL, ADC/DAC, regulators, SerDes building blocks | Hard macro + behavioural models | Foundry-qualified availability, area and power targets, sample rate and resolution trade-offs, ESD/latch-up rating for the target application. |
Transceiver & RF Radio, mmWave, SerDes, BLE/WiFi/5G modems | Hard macro + firmware stack | Process ecosystem (CMOS vs RF-SOI vs SiGe vs GaAs/GaN); regulatory domain if the radio will ship to market; PA linearity vs efficiency targets. |
Security & Subsystem Crypto engines, secure boot, root-of-trust, subsystem tiles | Hard/soft blocks + firmware reference | Certification scope (FIPS, PSA Level, Common Criteria); side-channel resistance; integration with the boot ROM and the rest of the platform. |
Subsystem IP MCU subsystems, DSP cores, AI/ML accelerators, interconnect (NoC/AMBA) | RTL + reference SoC + toolchain | Licensing model (per-use, per-instance, royalty); toolchain lock-in (LLVM, GCC, vendor IDE); whether the subsystem ships as soft or hardened IP. |
Included Scope
What this service is built to handle
- Third-party IP sales and sourcing tied to the target node and ecosystem
- Integration planning across memory, interface and subsystem blocks
- Early flagging of licensing or compatibility risk
- Coordination with design, verification and backend stages
Best Fit
Common situations where this path makes sense
- Teams choosing between multiple process ecosystems
- Programs with limited internal IP procurement experience
- Products mixing vendor IP with custom logic
Deliverables
Typical outputs from TOMPW coordination
- IP planning checklist
- Compatibility review inputs
- Integration risk summary
- Coordination notes for downstream teams
PROCESS-NODE AVAILABILITY
Which IP categories are typically available at each node band
IP vendor offerings differ sharply by node band. The matrix below is a planning view, not a vendor endorsement — availability shifts per project and must be confirmed with the vendor before booking the shuttle.
| Node band | Typical use | Categories typically covered | Notes |
|---|---|---|---|
| Advanced logic (3nm / 5nm / 7nm / 12nm / 16nm) | High-performance SoC, AI accelerator, mobile application processor | Interface, Memory, Analog, Subsystem, Security | Vendor offerings are concentrated here; expect per-project negotiation for MPW use |
| Mainstream logic (22nm / 28nm / 40nm / 55nm / 65nm) | IoT, consumer mixed-signal, RF transceivers, automotive controllers | Interface, Memory, Analog, RF, Subsystem, Security | Broadest IP catalog coverage; most MPW-friendly category for new designs |
| Mature logic / mixed-signal (90nm / 130nm / 180nm / 250nm / 350nm) | Automotive grade-0, industrial, analog-heavy mixed-signal, MEMS interface | Analog, Memory, Interface, Subsystem | Strong analog and power-management IP catalog; foundry-native libraries common |
| Specialty processes (BCD, SOI, SiGe, GaAs, GaN, SiPh, MEMS) | Power, RF front-end, photonics, sensors, harsh-environment analog | Analog, RF, mixed-signal | Vendor list narrows per process; coordinate with the foundry's in-house IP first |
FIVE SEPARATE STAGES
Sourcing, integration and licensing are not the same job
Treating IP as one line item is where programmes get surprised: by a licence that does not permit hardening, a hard macro that cannot move to another foundry, or an integration defect nobody owns. Five stages, five different responsible parties.
01 Sourcing
Where does each IP block actually come from?
- TOMPW
- Sells and sources third-party IP, shortlists candidates for your node and PDK, and confirms the supplier and commercial supply route for the quotation.
- IP vendor
- Holds the IP, owns its roadmap and decides whether it is available for your process.
- You
- Approves the selected core and purchasing route, and accepts the applicable license agreement.
Boundary: The quotation identifies the seller, licensor and support contact. License terms and the parties signing the agreement depend on the supplier and transaction; confirm them before committing the design.
02 Evaluation
Is this block right before you commit schedule to it?
- TOMPW
- Coordinates fit and deliverable review. Any simulation or PPA evaluation is separately scoped with the responsible engineering team, target corners and required models.
- IP vendor
- Supplies the deliverables, models and support entitlement the evaluation depends on.
- You
- Defines the target PPA, interface set and operating corners the evaluation is run against.
Boundary: An evaluation result is valid for the node, library version and corners it was run against. It is not a general promise about the IP.
03 Integration
Does the block behave once it is inside your SoC?
- TOMPW
- Scopes integration support and assigns responsibilities for clock domains, power intent, interface timing and pre-tape-out checks. Engineering execution is agreed separately from the IP purchase.
- IP vendor
- Provides integration documentation, constraints, required file sets and support for defects in the IP itself.
- You
- Owns the top-level architecture and the decision to accept the integrated result.
Boundary: The support agreement defines how IP defects and integration issues are investigated and resolved. Integration effort and acceptance criteria are scoped separately from the license fee.
04 Hardening
Does this need to become a hard macro for this specific PDK?
- TOMPW
- Coordinates the hardening flow: source review and licence permission check, floorplan, synthesis and layout, timing closure and sign-off, power characterisation, verification re-runs and release.
- IP vendor
- Must grant permission to harden. Some agreements gate hardening behind a separate addendum, which is why this is confirmed before work starts.
- You
- Approves the floorplan targets, constraints and the sign-off criteria the macro is released against.
Boundary: A hard macro is committed to one PDK and one library version. Moving foundry or node means re-hardening, and that is new work with its own schedule, not a file conversion.
05 Licensing
What are you actually allowed to do with it, and for how long?
- TOMPW
- Maps the commercial structure — upfront versus royalty, site and subscription terms, university terms, source escrow and continuity — against your volume plan so the model fits how you will ship.
- IP vendor
- Sets the licence terms, pricing and audit rights.
- You
- Accepts the applicable license and any reporting obligations stated in the agreement.
Boundary: The supplier's applicable license defines use, transferability and royalty terms. A TOMPW quotation does not expand those rights; the purchasing route and responsibilities are documented for the specific core.
WHAT TOMPW DOES NOT CLAIM
Three lines this page will not cross
- Third-party IP stays identified with its original supplier. The quotation and applicable license identify the seller, licensor, permitted use, deliverables, royalty terms and support responsibility for that transaction.
- No automatic cross-process migration. IP is characterised against a specific node, process version, library release and set of PVT corners. A different combination is a new evaluation and, for hard macros, new hardening.
- No automatic foundry qualification. Whether a block is foundry-qualified is decided by the foundry against its own programme and PDK version. A block being available for your process is not the same thing as it being qualified for your programme.
IP HARDENING FLOW
From soft IP to a foundry-specific hard macro
Hardening turns synthesizable soft IP into a foundry-specific hard macro: layout, timing closure and power characterized for the target node and library. The steps below are the typical sequence.
- STEP 01
Source review & license check
Confirm soft IP is licensable for hardening on the target PDK, and that the license permits the resulting hard macro to be used in production. Some IP vendors gate hardening behind a separate agreement.
- STEP 02
Floorplan & macro boundary
Block-level floorplan against the target PDK cell library and IO ring conventions. Pin placement chosen for downstream SoC integration, not just for the macro in isolation.
- STEP 03
Synthesis & layout
Logic synthesis with the foundry's standard cell library, then physical implementation: placement, CTS, routing, with timing and power constraints from the SoC target.
- STEP 04
Timing closure & sign-off
Static timing analysis across PVT corners, IR-drop and EM checks, DRC/LVS sign-off against the foundry rule deck. ECO loops until clean.
- STEP 05
Power characterization
Dynamic and leakage power across the operating modes the macro will see in the SoC. Numbers feed into SoC-level power budgeting and PDN design.
- STEP 06
Verification re-runs
Re-run the verification environment against the hardened netlist/GDS. Functional equivalence to the soft IP, plus assertions targeting the new corner behaviors.
- STEP 07
Qualification & release
Foundry sign-off, qualification if required, and release of the hard macro (GDSII + views) into the SoC integration flow with documentation.
SECURITY & SIDE-CHANNEL
Security IP decisions that are not just IP selection
For payment, government, automotive secure-boot and similar applications, security IP decisions interact with package choice, test flow and qualification. The topics below are the recurring ones when reviewing a security IP shortlist.
Certification scope (FIPS, PSA Level, Common Criteria)
Security IP for government, payment or automotive secure-boot use cases often needs a specific certification. The right IP vendor is the one whose deliverable is already mapped to the target certification level — retrofitting certification is far more costly than buying pre-certified IP.
Side-channel resistance (SPA / DPA / fault injection)
Cryptographic IP can leak keys through power, EM, timing or fault behavior. Countermeasures (masking, hiding, redundancy, sensors) are part of the IP choice, not an add-on. Confirm the threat model and target attack tier before vendor selection.
Root of trust and secure boot
A hardware root of trust anchors secure boot, key storage and lifecycle management. The IP choice (PUF vs eFuse vs secure enclave) interacts with the package choice (anti-tamper features), the test flow and the qualification plan.
Anti-tamper detect & lifecycle states
Lifecycle states (production / provisioned / locked / retired) need to be enforced in hardware, not just firmware. The IP must support the target device's lifecycle without breaking mass-programming flows at the test house.
Integration with boot ROM and the rest of the platform
Security IP that ships with a reference boot flow and integration testbench is much easier to drop in. Vendors that ship only the IP core and leave integration to the SoC team add weeks of integration debugging.
CAPABILITY DETAIL
From IP sourcing to a license-clean, integrated design
IP sourcing & fit review
Match IP category to target node and ecosystem: which vendors cover the foundry/PDK, which families are hardened vs soft, and which carry licensing restrictions that affect MPW versus full mask. Reviews cover interface, memory, analog, RF and subsystem categories.
License-term review & MPW compatibility
Confirm whether an IP vendor supports MPW use at all, whether a separate evaluation agreement is required for prototype runs, and whether MPW production royalty differs from full-mask terms. TOMPW can flag common restrictions based on prior projects.
Integration planning across categories
Coordinate how memory compilers, interface PHYs, analog macros and subsystems are stitched into the SoC floorplan, with verification IP aligned to each interface protocol. Includes clock/reset distribution and pad-ring planning.
Hardening & re-qualification
When soft IP needs to be hardened for the target PDK (or ported to a second foundry), we help plan and coordinate the hardening flow: layout, timing closure, power characterization, verification re-runs and re-qualification.
Verification IP (VIP) alignment
Ensure verification IP matches the controller/protocol version and supports the same simulator environment as the rest of the SoC testbench. Catch mismatches early before regression build-out begins.
Cross-foundry portability assessment
For programs that may dual-source or migrate to a second foundry, evaluate what stays portable (soft IP, firmware) and what requires re-qualification (memory compilers, hard macros, IO libraries). Produces a cost-and-schedule view of the migration option.
Royalty vs upfront licensing advice
Help frame the right mix of upfront fees vs per-die royalties for the expected production volume and the MPW-to-mask transition. Cover royalty caps, conversion options and audit clauses that often appear late in commercial terms.
ENGAGEMENT PATTERNS
Typical shapes of IP coordination work
The examples below describe representative forms of engagement. They are illustrative of the type of work and are not specific client records, names, volumes or results.
Multi-foundry IP selection for a connectivity SoC
For a connectivity SoC targeting two foundries, compare interface, memory and analog candidates against each PDK. Identify which blocks need a new license, implementation or qualification before choosing a second source.
IP license review before MPW shuttle booking
Before using a third-party PHY on an MPW run, check whether the proposed license covers prototyping, evaluation and the later production design. Resolve restrictions with the supplier before committing the IP to the design.
Hardening controller IP for a newer node
When a soft controller needs a hard implementation on another node, scope license permission, physical implementation, characterization and verification separately from buying the RTL.
Memory compiler swap to reduce die size
For an area-constrained design, compare memory compiler configurations, operating corners and physical views on the actual PDK. Check layout and verification consequences before treating a smaller option as a replacement.
Security IP for a payment application
For a payment SoC, request the supplier's security evaluation scope and check which implementation and configuration it covers. Plan boot ROM and lifecycle integration without assuming a core's certification certifies the complete chip.
RELATED GUIDES
Go deeper on each IP decision
Each guide below covers one decision in the IP plan, from deliverable form through licensing to the integration checks before tape-out. Browse the full IP & licensing topic →
IP fit planning before tape-out
The checklist that prevents a late IP surprise.
Read guide →Soft, firm and hard IP
What you receive, and who carries the integration risk.
Read guide →IP licensing models explained
Upfront fees, royalties, subscriptions and escrow.
Read guide →The IP vendor landscape
Who sells what, and how to shortlist per function.
Read guide →Arm vs RISC-V for an ASIC
How the architecture decision actually gets made.
Read guide →IP integration pitfalls: CDC, UPF, timing
The four failures that derail IP-heavy programs.
Read guide →
Execution Notes
Commercially important details buyers usually ask later
- Source material highlights interface, memory, analog and transceiver IP categories.
- IP decisions should be made with foundry and schedule implications in view.
- The supplier, licensor, deliverables and support responsibility are identified for each IP quotation.
Next Move
Send IP, node and license context together
IP choice is upstream of foundry, package and test. The earlier a license-compatible shortlist is ready, the fewer late surprises at MPW booking or full-mask sign-off.
Email IP contextFAQ
Questions buyers ask around IP and licensing
Yes. TOMPW sells and sources third-party semiconductor IP and helps align supplier options with the target process and integration needs. The IP remains the original supplier's product. We confirm the specific core, commercial supply route, license scope, deliverables and support responsibility in the project quotation; availability is not implied for every vendor or node listed in our guides.
Interface (USB, PCIe, Ethernet, MIPI, DDR/LPDDR PHYs and controllers), memory (SRAM/ROM compilers, eFlash/eEEPROM controllers), analog (PLL, ADC/DAC, regulators, SerDes building blocks), transceiver/RF, security/subsystem IP, and subsystem tiles (MCU/DSP/NPU/NoC).
Sometimes. Several IP vendors restrict MPW use, require a separate evaluation agreement, or charge a higher per-die royalty on prototype runs. Confirm license terms with the IP vendor before booking a shuttle — TOMPW can flag common restrictions from past projects.
Portability depends on the category. Hard IP (memory compilers, standard cell libraries, hard macros) is foundry-specific by definition. Soft IP and firmware can port across PDKs but must be re-qualified — plan for that re-qualification cost when multi-foundry sourcing is a goal.
Hardening converts synthesizable soft IP into a foundry-specific hard macro: layout, timing closure and power are characterized for the target node and library. It is needed when predictable timing closure matters, when the block must be used as a hard macro in physical design, or when the foundry requires a hard deliverable.
Upfront (one-time) fees typically buy a license plus access to the GDSII or RTL, though exact deliverables vary by vendor and license agreement; royalty fees are per-die charges during production. Prototype volumes sometimes include a royalty cap or a one-time conversion option, subject to the vendor's standard terms. The right mix should match your expected production volume and the MPW-to-mask transition plan.
Related Services
Adjacent steps in the same silicon program
ARCHITECTURE TO RTL
ASIC / SoC Design
Support architecture, RTL and integration planning for teams moving from specification to implementation.
FIRST-SILICON CONFIDENCE
Design Verification
Strengthen first-silicon confidence with structured verification, validation planning and downstream debug preparation.
ONE PARTNER · FULL DELIVERY PATH
Turnkey ASIC Solutions
Unify design support, tape-out, packaging, test, board work and delivery under one execution-facing partner.
FOUNDRY COVERAGE
Foundries TOMPW coordinates for this path
IP planning is tied to foundry ecosystem choice. TOMPW's foundry network spans advanced logic, mature analog, RF-SOI, SiGe and compound processes.
PLANNING TOOLS
Delivery checks and IP-led planning tools
Review type-specific delivery views and separate the licensor, seller and support owner, alongside unit-cost, royalty and tape-out estimates.
IP Cost & Licensing Estimator
Model IP licence fees, per-die royalties, support and integration effort across program volume — with the buy-vs-build break-even point.
Open tool →Wafer & Unit Cost Calculator
Turn a wafer run into a per-chip cost: dies per wafer, yield, packaging and test, plus a target margin.
Open tool →Tape-out Budget Estimator
Full program model: DPW, yield, packaging, HBM, test, NRE and volume → unit cost, price and gross margin.
Open tool →Third-Party IP Delivery Checker
Check third-party IP delivery views and responsibilities. Optionally match local files against a trusted manifest using SHA256, size and relative path.
Open tool →