IP FIT BEFORE INTEGRATION PAIN

IP Planning That Matches the Manufacturing Target

IP sourcing is not only a licensing problem. It affects schedule, integration complexity, verification load and the choice of process ecosystem.

Teams choosing between multiple process ecosystemsPrograms with limited internal IP procurement experienceProducts mixing vendor IP with custom logic

Discuss IP sourcing Back to all services

Circuit board image used for IP and integration services

QUICK ANSWER

Can TOMPW help with IP sourcing, fit and licensing for an ASIC program?

Yes. TOMPW is not an IP vendor — the value is in IP sourcing, fit, license and integration support across interface, memory, analog, RF and subsystem IP. We review MPW vs full-mask license terms, plan hardening for the target PDK, and align third-party IP with the chosen foundry ecosystem.

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).

Read the IP fit planning guide→Open the glossary

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, not TOMPW products or endorsements.

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.

Read the IP fit planning guide Open the glossary

Included Scope

What this service is built to handle

IP sourcing support tied to 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

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

A fabless team needed to choose IP families for a connectivity SoC that would run on two foundries for supply-chain reasons. We mapped interface, memory and analog candidates against each foundry's PDK and surfaced where re-qualification cost would dominate.

IP license review before MPW shuttle booking

An early-stage team planned to use a third-party PHY on an MPW run. We reviewed license terms, found a MPW-use restriction, and sourced an evaluation license in time to keep the shuttle slot without losing the block.

Hardening controller IP for a newer node

A team moving to a smaller node needed an existing soft controller hardened against the new PDK. We coordinated the hardening flow, including timing closure, power characterization and re-verification, so the macro was ready for the next tape-out.

Memory compiler swap to reduce die size

A power-management IC was area-constrained. We reviewed memory compiler options, flagged a denser alternative supported by the foundry, and coordinated qualification so the swap did not break the existing layout.

Hardening controller IP for a tighter PDK

An existing soft controller needed to be hardened against a newer PDK the team was moving to. We coordinated the hardening flow end-to-end: source review, floorplan, layout, sign-off and verification re-runs, so the macro was ready for the next tape-out.

Security IP for a payment application

A payment SoC needed a crypto engine with a specific certification level already mapped. We narrowed the vendor list to those with the target certification in place, and coordinated the integration with the boot ROM and lifecycle management.

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 website positions TOMPW as an integration partner, not an IP catalog owner.

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 context

FAQ

Questions buyers ask around IP and licensing

No. TOMPW is not an IP vendor. The value is in IP sourcing, fit, license and integration support around the third-party IP your project already plans to use. Specific IP availability is confirmed per project, not from a fixed internal list.

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