Choosing semiconductor intellectual property (IP) is a decision about the entire chip development process. A core may provide the required function yet still create substantial work when its interfaces, timing assumptions, verification models, or physical characteristics do not fit the system.
For an engineering team developing a system-on-chip (SoC), the evaluation therefore needs to answer two questions: does the IP meet the specification, and can the team integrate and verify it within the intended design environment? A product summary can help build a shortlist. A technical evaluation must examine the evidence behind the claims and the work remaining after delivery.
Start with a written description of the function the SoC requires. If the team has not agreed on that requirement, comparisons tend to follow whichever features suppliers emphasize. A requirements baseline gives every candidate the same test.
For a processor core, this includes the instruction set, interfaces, and required peripherals. For an interface controller, it includes the supported transactions and the relevant protocol requirements. Across both cases, the evaluation must also address timing, performance, area, power, and software interaction.
Separate the requirements into the following groups:
Record which requirements are essential and which permit design changes. A core that needs an additional interface block may remain suitable, but the extra block must become an explicit implementation and verification task. It should not emerge as an unexpected dependency during integration.
Soft IP is delivered as synthesizable register-transfer level (RTL) code. The integrator configures and implements it using the target technology and design flow. Hard IP is delivered as an implemented physical block, with the models and documentation needed to incorporate it into the chip. Access to the physical layout depends on who performs the physical integration.
This distinction changes the evaluation. For soft IP, examine configuration, coding portability, synthesis scripts, verification components, and results with the intended library. For hard IP, examine the fixed implementation: dimensions, timing, clock behavior, routing restrictions, power connections, and test structures.
Soft IP offers implementation flexibility, but a supplier’s result in a reference environment does not establish the result in your target environment. Hard IP reduces the implementation work inside the block, but its fixed characteristics become constraints on the surrounding chip. Neither delivery form removes the need for system-level verification.
Documentation determines whether the team can understand and use the design. Missing information forces engineers to reconstruct assumptions through simulation, experiments, or support requests. That effort belongs in the assessment of integration readiness.
Request a user guide that explains the architecture, functionality, inputs and outputs, register map, timing, configuration, and restrictions. It should also identify clock and reset requirements, test structures, verification guidance, version history, and known bugs.
Check whether the documentation distinguishes a supported feature from a qualified claim. For example, a stated timing result needs an associated implementation context. A statement of protocol compliance needs any exceptions. Configurable IP needs legal parameter combinations and restrictions, rather than a list of parameters without usage rules.
A practical review is to trace one operation from start to finish. Can an engineer identify how software or another block initiates it, which signals change, how completion is reported, and what happens if the transaction is interrupted? Gaps in that explanation reveal questions to resolve before selection.
Interfaces can look similar while behaving differently. A source may wait for a receiver to announce readiness before requesting a transfer, while the receiver waits for a request before announcing readiness. Both blocks can work independently and still fail when connected.
Examine the transaction sequence, not just port widths and names. Review request and response behavior, flow control, reads and writes, burst handling, completion, and exceptional conditions. Aborted transactions and interrupts deserve particular attention because resolving a mismatch may require changes beyond a simple signal adapter.
Ask the supplier to explain the interface using timing diagrams and transaction examples. Identify every wrapper or conversion block the SoC will require, assign responsibility for its design, and include its tests in the system verification plan. Interface adaptation is part of the selected solution’s engineering effort.
A reusable IP core should arrive with more than a statement that it has been tested. Evaluate how its verification was planned, which features and configurations were exercised, and what evidence is available to the integration team.
Useful materials include a verification plan, coverage information, bus functional models, interface monitors, test cases, and regression procedures.
Clarify the difference between the supplier’s internal verification suite and the tests delivered to customers. A delivery may contain a subset intended to confirm installation or demonstrate operation. That subset should not be mistaken for the complete evidence used to qualify the IP.
Review configuration coverage as well. A parameterized design can have many legal combinations, and evidence from one combination does not explain the status of all others. Ask how your intended configuration relates to the verification performed and whether the supplied environment can test it.
Code coverage helps identify untested implementation paths, but complete code coverage does not establish complete functional correctness. Functional coverage, directed scenarios, corner cases, random testing, and other verification techniques address different aspects of confidence. Evaluate the combination of evidence rather than accepting a single percentage as a complete answer.
We place substantial weight on evidence from fabricated silicon. A physical prototype allows the design to run in a real environment and, where relevant, execute application software that would be impractical to run extensively in simulation.
For selection, the useful question is how that evidence relates to the exact IP being considered. Ask which revision and configuration were implemented, what environment was used, and which results were measured. Record any differences between that implementation and the proposed delivery.
Silicon experience is valuable evidence, but it does not verify the interactions in a new SoC. Your team still needs to check interfaces, configuration, physical integration, and application behavior. Keep the distinction between evidence about the block and evidence about the completed system.
Timing, area, and power are selection criteria, but comparisons need consistent assumptions. For soft IP, we recommend initial synthesis with the target technology library as a preliminary check of whether the intended goals are achievable.
Request enough information to reproduce the reference result where the delivery permits it. This includes the relevant configuration, scripts, constraints, and reference environment. Reproducing a baseline helps distinguish a problem in the IP or its scripts from a problem in the receiving design environment.
For hard IP, inspect timing models and interface specifications. Input setup and hold requirements, clock-to-output delays, and internal clock insertion delay affect the surrounding design. A nominal operating frequency alone cannot describe these obligations.
Physical planning must accompany this review. Long connections between blocks can change timing behavior, and fixed macros can restrict placement. An early result is useful for screening candidates; final confidence requires the block to be evaluated within the chip’s physical and timing context.
A hard macro occupies a fixed region of the floorplan. Its aspect ratio, pin placement, routing blockages, and access to power and clocks can influence the rest of the chip. Evaluate these characteristics before committing to a floorplan built around the block.
Routing porosity describes the opportunities for chip-level signals to pass through or over a macro. A block that prevents such routing may force long detours. Review the physical models to understand the restrictions and the available routing resources.
Also establish how the macro’s power and ground structures connect to the chip, how its clock tree interacts with system clocks, and how its test structures will be accessed. These are integration requirements that the supplier’s models and documentation need to explain.
For compiled memories, add questions about port configuration, synchronous or asynchronous operation, aspect-ratio options, and built-in self-test. We specifically cautions that a memory test strategy may not cover every failure mechanism, including data-retention problems. Ask what the supplied test actually checks.
Define the delivery package before selection is finalized. Soft IP typically requires RTL, scripts, documentation, and a usable verification environment. Hard IP requires the functional, timing, physical, power, and test information needed for the agreed integration responsibilities.
Processor-related IP may also depend on compilers, debuggers, and other software tools. Establish whether these are supplied directly or obtained from another provider. For peripheral IP, review register documentation and the availability of relevant software support.
During evaluation, use the supplier’s support to resolve real technical questions. Can the team obtain explanations of configuration restrictions, interface behavior, model usage, or known issues? We identifie limited provider support as an integration difficulty. Unanswered questions should remain visible in the decision record.
Once received, place the IP package under revision control with the rest of the project. Preserve the documentation, models, scripts, and verification files together. Reproducibility matters when an implementation must be debugged, modified, or recreated later.
Use the following checklist to organize supplier discussions. For each item, record the evidence reviewed and any unresolved action. A positive answer should point to documentation, a model, a report, or a reproducible evaluation.
| Evaluation area | Question to resolve | Evidence to request |
|---|---|---|
| Functional fit | Does the intended configuration meet the SoC requirements? | Functional specification, feature restrictions, configuration guide. |
| Interfaces | Are normal and exceptional transactions compatible? | Interface specification, timing diagrams, transaction examples. |
| Documentation | Can the team configure, implement, and verify the IP? | User guide, register map, integration instructions, known issues. |
| Verification | What was verified, and which tests are supplied? | Verification plan, coverage evidence, models, monitors, test cases. |
| Silicon evidence | How does previous silicon relate to this revision and configuration? | Prototype details and relevant measured results. |
| Implementation | Are timing, area, and power claims relevant to the target? | Constraints, scripts, reference conditions, initial synthesis results. |
| Hard IP integration | Can the macro fit and connect within the planned chip? | Physical views, dimensions, routing restrictions, clock and power guidance. |
| Manufacturing test | Can the block’s test requirements fit the chip test strategy? | Test models, test access information, patterns and coverage information. |
| Software | Are the required tools and software interfaces available? | Tool requirements, register documentation, driver information. |
| Delivery and maintenance | Is the package complete and reproducible? | Deliverables list, version history, scripts, archive requirements. |
At the end of the evaluation, document which requirements are met, what evidence supports that conclusion, and what work remains. Separate unresolved functionality from implementation uncertainty, missing deliverables, and additional integration tasks.
A candidate may be acceptable even when it needs adaptation, provided the adaptation is understood, assigned, and included in the project plan. Conversely, a feature-rich core can be a poor fit if the team cannot establish its interface behavior, verify its configuration, or integrate its physical implementation.
The strongest selection is one the architecture, RTL, verification, physical design, test, and software teams can explain consistently. Evaluate the IP as a component of the complete SoC, with documented assumptions and a clear path from delivery to verified integration.