Different Stages of IP Verification
In short: IP verification happens in seven stages, from the smallest unit up to the finished chip running real workloads: unit level, module level, SoC level, design-flow tool checks, interoperability, customer module and SoC verification, and finally customer and system-level use. Each stage catches a different class of bug, so a problem found early is far cheaper than one found near tapeout.
When a design team buys semiconductor intellectual property (IP) from a third party, quality is a big worry. This is even more true for highly configurable IP, because each customer picks options to match their own product. The on-chip interconnect fabric is a common example: it is configured many different ways, and its quality decides whether a chip works on the first try. This post walks through the different stages of IP verification and why each one matters.
Thorough verification pays for itself. The cost of adding configurability is tiny compared with the cost of slowing down a tapeout. Configurability lets customers build in many ways, but that same freedom makes corner-case verification very important. To trust a block, the safest choice is IP that has already proven itself in production chips, verified across many design and production levels.
A simple way to picture it
Think of building a car. You do not bolt every part together and drive it off a cliff to see what breaks. First you test each part on its own: the brake pad, the spark plug, the sensor (unit level). Then you test finished sub-assemblies like the whole engine on a test bench (module level). Then you test the full car in the lab (SoC level). Then you make sure the factory tools that build it are calibrated (tool checks). You confirm parts from different suppliers fit together (interoperability). The buyer test-drives it in their own city (customer verification). And finally real drivers use it for years in all weather (system-level use). Skipping any stage means a fault slips through to a more expensive place to fix.
The seven stages of IP verification
If a team wants the least risk and a quick path to market, it should judge an IP block against these seven levels. Each answers a different question and each has its own “why”.
| Stage | What it checks | Why it matters |
|---|---|---|
| 1. Unit level | The smallest units and elements inside the IP. | Bugs found here are cheap to fix. A miss at this level shows up again, and worse, at every stage above it. |
| 2. Module level | The IP in the exact configuration a customer will use, meeting the required performance and topology, and working with neighbouring blocks. | The vendor should verify this first with representative examples so customers start from a known-good base. |
| 3. SoC level | Representative customer configurations inside sample SoC designs, including performance drift from one release to the next. | Confirms the IP behaves and performs when dropped into a whole chip, not just in isolation. |
| 4. Design-flow tool checks | The tools that configure and generate the IP, whether command-line, GUI, or both. | If the generator produces wrong output, even a perfect IP design ships broken. |
| 5. Interoperability | Transaction and communication protocols such as AMBA and any proprietary ones, plus EDA-tool and verification-IP integrations. | A block that cannot talk cleanly to its neighbours or to the customer toolchain causes integration delays. |
| 6. Customer module and SoC verification | The customer-configured IP during their design, tapeout, bring-up, and debug phases. | The customer must reach the same or higher confidence as if their own team had hand-coded the block. |
| 7. Customer and system-level use | System-house and end-customer lifecycle testing with real workloads. | Real deployment reveals problems that no amount of prediction can. First-hand use is the final proof. |
The last two stages carry the most weight. Here the IP vendor needs the right people, culture, processes, and internal verification discipline, not only to ship quality IP but to help customers verify their own configurations. That takes a relationship of trust, because a customer only learns the real problems once the IP ships in volume. As the source puts it, anticipation is not the same as first-hand knowledge.
Why quality takes years to build
The price of configurability is small next to its possible impact on chip delivery, so a vendor must prove its processes, procedures, and experience to earn customer confidence. A new technical benefit has to clearly outweigh the risk to function, quality, and schedule. This is why it takes roughly ten years to build a strong IP company:
- The provider builds the product and gets it designed into a wide set of applications.
- The customer then has to deliver a working SoC using that IP.
- System houses put those chips into their own products.
- Finally the customer ships enough volume to prove the quality helps their business.
- Only after all of this can the value of that quality be measured properly.
Along the way the vendor must keep up with technology changes and specific customer requests while holding support and quality steady. That is hard, which is why companies such as ARM, Synopsys, Imagination, Tensilica, and Arteris were not built overnight. Reaching all seven verification levels plus production-volume success simply takes time.
Commercial IP versus building it in-house
Reaching these seven levels needs exposure to a wide range of SoC designs across many systems. A commercial vendor that sees hundreds of designs usually ends up with higher quality than an internal team that sees only a handful. Internal interconnect groups, except at the very largest chip companies, see a small number of designs and a narrow set of methodologies, so they hit fewer corner cases.
A useful rule of thumb: the greater the number and variety of successful system design-ins, the higher the quality and the greater the value of configurability. Volume and variety are what shake out the rare bugs.
Interoperability and the ecosystem
A configurable IP is one of hundreds of components in an SoC, so the ecosystem around it matters. Its interfaces to other blocks must be tested and their interoperability assured. ARM AMBA standards are the most widely used, so vendors must track and implement the stream of AMBA developments to keep customer integration trouble-free. Customers also use many EDA tools and flows, which all have to be tested with the IP. The vendor should finish this ecosystem testing early, before integration issues start hitting schedules.
A worked example: verifying a configurable interconnect fabric
To make the seven stages concrete, here is how they play out for a configurable AMBA interconnect that a customer will drop into their SoC:
- Unit: verify each arbiter, each buffer, and each address decoder on its own with directed and random traffic.
- Module: generate the exact fabric the customer ordered (say four masters and six slaves, a given data width) and verify ordering, arbitration fairness, and back pressure.
- SoC: place that fabric in a sample chip with a real CPU, DMA, and memory controller, then run traffic that mixes all of them and measure latency and throughput.
- Tool: confirm the generator that produced this fabric configuration output matches the settings the customer picked.
- Interoperability: attach a third-party AMBA verification IP and confirm every transaction type is legal on the bus.
- Customer verification: the customer integrates the fabric, runs their bring-up sequences, and debugs any mismatch against the spec.
- System use: the finished chip runs the customer end-application for long soak tests to catch rare, workload-dependent issues.
For the checks used inside these stages, see our guides on assertions for protocol rules, functional coverage for closure, and the SoC verification flow for how blocks come together into a chip. AXI and coherency details are covered in our AXI protocol and cache coherency guide.
Why quality makes commercial IP possible
Verification and quality are not the only factors. New standards appear often, and configurability has to keep supporting that change. Improvements in results and productivity must also lower overall chip cost. So choosing IP is a trade-off between technical benefit, cost saving, and quality risk. When the technical benefit is high enough, the quality risk becomes worth taking.
Low-power processor cores, configurable processors, high-performance GPUs, and network-on-chip interconnects were once unproven ideas from small companies. Today they sit in some of the most complex chips ever made. That happened through solid quality programs and strong global support, which built a cycle of customer comfort, adoption, and further investment. A quality electronic system is made of quality chips, which are in turn made of fully verified components, so buyers should judge any candidate IP against these seven levels before trusting it.
Common mistakes when verifying IP across stages
- Skipping unit level to save time. A unit bug then reappears at SoC level, where it is far harder to find and fix.
- Verifying only one configuration. Highly configurable IP needs several representative configurations, not just the default.
- Ignoring the generator tool. A correct design still ships broken if the configuration tool emits the wrong output.
- Treating interoperability as an afterthought. Protocol and tool mismatches found late in integration wreck schedules.
- Assuming vendor sign-off is enough. The customer must still verify their own configuration in their own SoC.
- No release-to-release drift checks. A new IP version can quietly change performance; compare against the previous release.
Source: the seven-levels framing follows the EDN article “The 7 levels of IP verification”.
Expected result, in plain words
There is no single simulation output for this topic; it is a process, not one test. When the seven stages are followed, the practical result is that most bugs are caught at unit and module level where they are cheap, very few reach SoC and customer stages, and almost none reach the end customer. If bugs keep appearing late, that is the signal an earlier stage was rushed. Confirm the exact metrics against your own project data and tool reports.
Frequently asked questions
What are the different stages of IP verification?
There are seven: unit level, module level, SoC level, design-flow tool checks, interoperability, customer module and SoC verification, and customer plus system-level use. Each stage catches a different class of bug.
Why is unit-level verification so important?
It is the cheapest place to find bugs. Any issue missed at unit level reappears at every stage above it, where it is much harder and more expensive to isolate and fix.
What is the difference between module-level and SoC-level IP verification?
Module level checks the IP in the exact configuration a customer will use and its links to neighbouring blocks. SoC level places that configuration inside a sample chip with a real CPU, DMA, and memory to check behaviour and performance in a full system.
Why do we verify the IP configuration or generation tool?
Because a correct IP design still ships broken if the tool that configures and generates it produces the wrong output. Testing the generator, whether command-line or GUI, protects against that.
What does interoperability verification cover?
It confirms the IP follows standard protocols such as AMBA and any proprietary ones, and that it works with the EDA tools and verification IP that customers use, so integration does not stall.
Why are the customer and system-level stages the most important?
Because real deployment reveals problems that prediction cannot. First-hand use in the customer SoC and in end products under real workloads is the final proof of quality.
Why does it take so long to build a trusted IP company?
Reaching all seven verification levels plus production-volume success across many designs and systems takes years. That breadth of exposure is what shakes out rare corner-case bugs.
Is commercial IP higher quality than in-house IP?
Often yes, because a commercial vendor sees hundreds of designs and many methodologies, hitting far more corner cases than an internal team that sees only a few designs.
