For a system-on-chip (SoC) project, semiconductor IP deliverables can include source code, models, implementation scripts, verification components, physical data, software examples, and documentation. The appropriate package depends on whether the IP is delivered as synthesizable RTL or as an implemented physical block, and on which organization performs the remaining design work.
Start by Defining the Delivery Boundary
Before drawing up a file list, establish who will configure, synthesize, physically integrate, verify, and manufacture the IP within the final chip. Those responsibilities determine which files each participant needs.
Soft IP is supplied as synthesizable register-transfer level (RTL) code. The integrator implements the selected configuration using a target technology library and design flow. The package therefore needs to support installation, configuration, simulation, synthesis, and subsequent integration.
Hard IP has already been physically implemented. Its delivery emphasizes the models, physical information, test data, and documentation required to design the surrounding chip. The physical layout must reach the party responsible for physical integration; it is not necessarily delivered directly to every user of the IP.
1. RTL and Configuration Files for Soft IP
The central soft-IP deliverable is the synthesizable design. In a specific project, the agreed package must make clear which language representations are supplied and supported, and which files belong to the selected implementation.
For configurable IP, the RTL must be accompanied by the information needed to select a valid configuration. Parameters may change widths, interfaces, registers, or other design features. A list of parameter names is insufficient if the receiving team cannot determine which combinations are legal.
Configuration instructions should identify supported settings, restrictions, and the steps used to generate the design. Where configuration tools or scripts are supplied, explain their inputs and outputs. The documentation, verification files, and software examples must remain consistent with the generated configuration.
An integration example also has practical value. A correctly documented instantiation shows how the block connects to the surrounding design and reduces errors in port names and connections. The example should be identifiable as belonging to the delivered revision.
2. Installation and Synthesis Scripts
A reusable soft core should include the scripts needed to install and synthesize it in the intended environment. These scripts carry part of the supplier’s implementation knowledge: how files are assembled, how the design is configured, and which constraints apply.
A reference run provides a baseline. If the core produces the expected result in the reference environment but encounters a problem in the target environment, the team has a more useful starting point for investigation. It can compare the libraries, constraints, and scripts rather than treating every failure as an unexplained IP defect.
Reference results should state their configuration and conditions. They provide evidence about a particular implementation, rather than a guarantee that timing, area, and power will be identical in another technology or floorplan.
3. Verification Environments and Delivered Test Cases
The verification package allows the receiving team to check installation and reuse suitable components during SoC verification. Depending on the core, it can contain a testbench, bus functional models, monitors, device models, test sequences, and automatic response checking.
A bus functional model generates transactions at an interface. A monitor observes activity and checks protocol behavior. Other models represent connected devices or provide expected responses. Together, these components help the integrator exercise the core without rebuilding the entire verification environment.
Clarify the scope of the tests that accompany the delivery. Customers may receive a subset of the supplier’s full internal suite. Such tests can demonstrate correct installation and basic operation without constituting the complete evidence used to verify the design.
The handoff should therefore distinguish verification components, customer test cases, and qualification evidence. Explain how to run the supplied tests, how success is reported, and which configurations they exercise. For configurable IP, the test environment should be compatible with the selected parameter settings.
Automatic checking is especially important. A useful installation test produces a result the team can assess and repeat. A waveform file without documented expectations leaves the recipient responsible for reconstructing what constitutes correct behavior.
4. Functional Models for Hard IP
Hard IP needs functional representations that let engineers develop and verify the rest of the chip without depending on the physical layout as their simulation model. Large blocks may require several representations because software development and detailed hardware verification have different needs.
An instruction-set architecture model can support processor software development by representing instruction behavior while omitting implementation detail. A behavioral model can represent a block’s operations at a higher level. A bus functional model can concentrate on the transactions required to exercise neighboring blocks.
More detailed models serve tasks that require closer correspondence to the implementation. The supplier should explain what each model represents, which details it omits, and when the recipient should use it.
Some model representations may be compiled or otherwise packaged to protect implementation information. The important handoff question is whether the supplied representation works in the receiving environment and supports the intended task. Source access and executable model delivery are different arrangements and should be described accurately.
5. Timing and Power Models
A hard macro’s timing model allows its behavior to participate in chip-level timing analysis. It must provide the information needed to connect the macro’s timing requirements with the surrounding logic.
The supporting documentation should identify input setup and hold requirements, clock-to-output delays, loading assumptions, and any combinational interface timing. Internal clock insertion delay also matters because it affects the timing seen at the macro boundary.
Power models have a different purpose. They allow the integrator to include the macro in estimates of power dissipation and power-distribution behavior, including IR drop. A functional simulation model cannot automatically substitute for this information.
For both timing and power, make the applicable configuration and assumptions clear. The user guide should connect performance claims with the models or measurements supporting them. Otherwise, the team may have numbers in a document but no reliable way to use them in system analysis.
6. Physical Layout and Floorplanning Information
The physical integration team needs a representation of the hard macro that supports its assigned work. Where that team performs physical integration, GDSII layout data forms part of the relevant delivery.
Floorplanning information must describe more than the block’s outer dimensions. Relevant details include footprint, aspect ratio, pin locations, routing restrictions, and the ability to route signals through or over the macro.
A physically complete macro may still be difficult to use if the surrounding design cannot reach its pins or must make lengthy routing detours.
Include power and ground connection guidance, clock and reset requirements, and the physical models needed by the integrator. The handoff should explain the purpose of each representation so that physical design engineers can distinguish planning views from the detailed manufacturing layout.
7. Manufacturing Test Models and Patterns
Functional verification checks the design’s behavior. Manufacturing test addresses whether fabricated devices operate as intended. A complete delivery arrangement needs to support both activities.
For hard IP, the test structures are already part of the macro, so the supplier must explain how they connect to the chip-level test strategy.
Scan-based designs require the relevant automatic test-pattern generation information, patterns, and control details. Other test approaches require their own patterns and instructions for applying them. The patterns must reach the party responsible for manufacturing test, even when they are not supplied directly to the IP’s end user.
The package should identify test access, test operation, and the scope of coverage. These details allow the chip team to account for the macro when assembling its test infrastructure rather than discovering an incompatible test requirement late in implementation.
8. Software Support and Configuration-Aware Examples
Software-related deliverables depend on the complexity of the IP. For a simple peripheral, a register manual and functional description may provide a starting point. More complex blocks benefit from low-level routines or examples that show how to operate the hardware correctly.
Lets use a timer as an example: basic functions can demonstrate register access, enabling operation, selecting a count, and setting a mode. These routines give software developers a defined foundation for application-specific code.
Processor IP also needs information about compatible compilers, debuggers, and operating-system support. The supplier may provide some elements itself and identify third-party sources for others. The delivery should state that division clearly.
Configuration must remain consistent across hardware and software. If parameter settings alter addresses or data widths, examples based on another configuration can mislead the software team. Configuration tools should account for the associated example code where applicable.
9. A User Guide That Connects the Deliverables
The user guide is the entry point to the delivery package. It should explain the architecture and function, show the block diagram, describe interfaces and registers, document timing, and identify supported configurations.
It should also connect the design to its implementation and verification resources: which scripts to use, which models support each task, how test structures are accessed, and what the integrator must do about clocks, resets, power, and floorplanning.
Restrictions deserve explicit treatment. Document protocol exceptions, unusual asynchronous circuitry, combinational interfaces, configuration limits, and departures from the supplier’s normal design guidelines. Include the revision history and known bugs so that users understand the exact package they have received.
Claims and assumptions should be distinguishable. A stated feature is more useful when the user can identify its conditions and, where possible, reproduce the evidence. Documentation should reduce dependence on undocumented knowledge held by the original designers.
Soft IP and Hard IP Deliverables Checklist
The following checklist is the delivery categories. The exact contents depend on the IP and the agreed integration responsibilities; every package does not require every possible model.
| Category | Soft IP | Hard IP |
|---|---|---|
| Design representation | Synthesizable RTL and configuration information. | Implemented layout supplied to the responsible physical integrator. |
| Implementation support | Installation and synthesis scripts, constraints, and an agreed reference flow. | Physical integration instructions, interface assumptions, and model usage guidance. |
| Verification package | Testbench components, customer test cases, and execution instructions. | Functional models, verification components, and appropriate detailed simulation representations. |
| Timing and power | Documented reference results and conditions; information needed to assess the target implementation. | Timing and power models with applicable assumptions and specifications. |
| Physical information | Implementation guidance where relevant. | Footprint, pins, routing restrictions, power connections, and floorplanning models. |
| Manufacturing test | Testability guidance and information needed for the chosen implementation strategy. | Embedded test structure descriptions, patterns, models, and test access information. |
| Software | Register documentation, low-level examples, and development-tool information as applicable. | Software support information and processor or peripheral models as applicable. |
| Documentation | User guide, restrictions, version history, and known issues. | User guide plus detailed physical, clock, power, model, and test integration guidance. |
Keep Customer Deliverables Separate from the Supplier’s Design Archive
The supplier’s complete development archive and the customer’s integration package serve related but different purposes. The customer needs the agreed files required to use the IP. The supplier needs the development material required to reproduce, repair, enhance, and release it again.
We emphasizes preserving source files, scripts, documentation, verification environments, and other development data together under revision control. The receiving team should likewise place its delivered package under revision control alongside the chip project.
This does not imply that customers automatically receive every internal design artifact or the full internal verification suite. It means the delivery boundary must be explicit, and each organization must retain a coherent version of the material for which it is responsible.
Define a Reproducible Handoff
A practical handoff organizes the package around what the receiving team needs to do. Identify the supplied revision and configuration, locate the user guide, run the installation checks, and confirm that the models and scripts support the agreed integration tasks.
Record missing files, unresolved questions, and dependencies before the package becomes the foundation of further implementation. Separate files that belong with the chip team from those that must reach the physical integration or manufacturing test teams.
Complete semiconductor IP deliverables allow engineers to move from a purchased design to a working integration flow. The goal is a package whose design data, models, scripts, tests, software examples, and documentation agree with one another and can be used again when the project changes.