Key concerns for verifying SoCs

There's always the option to deploy more resources to verify the complex design in less cycle time
assuming that there are enough resources present in the industry, but this will also lead to an
increase in the manufacturing cost. This is not good for a company in terms of gross margins. So in
this case, the main question that arises is "What to verify at SoC level?"

For this, one must understand the basic difference between SoC verification and intellectual
property (IP) verification. While designing a SoC, IP is generally delivered by a third party, or it is
developed in-house and we can assume it has been verified by the IP level verification test-suite.
The SoC team integrates the IP as per the defined functionality in the specifications. Then, the SoC
verification team has to verify the chip level functionality, which mainly focuses on the integration
of IP. Each IP block supports many features, so it is very important to understand which features
need to be verified at the SoC level. For Example, an IP block can have a number of interrupt
outputs, but the SoC team can only verify the interrupts that are connected at the SoC level.

Figure 1: Important areas during SOC verification.

Some important concerns during SoC level verification include:

1. Pin muxing in the chip: The number of pins in a SoC is directly related to the chip cost and
determined by customer requirements, so the SoC is restricted with limited pins as compared
to the number of pins required by IP to interface to the external world. In order to use the
SoC pins efficiently, they are interfaced to the internal IP via a complex muxing logic at the
SoC level. It is very important to verify this logic.
2. Protocol checks: Protocol checkers should be added at module boundaries.
 3. Initial sequences for the SoC bringup: This mainly includes the reset and boot-up sequences.
Apart from reset sequence checking, a typical SoC can have multiple ways to boot-up , e.g.
from internal or external memory. Checking the boot from all possible sources can be one
area of focus.
4. Memory and register access: Focus here can be to ensure that design can configure registers
and memory to enable various SoC level scenarios.
5. Control and data paths in the design: The focus here is to cover datapaths that involve
configuring transactions with the external world (interface protocols at SoC like LIN, CAN,
UART, etc.), configure masters of transactions to work in parallel (processor, DMA etc), and
excitation of functional paths for interrupts.
6. Analog modules: Special focus on analog block integration verification is needed as
traditional digital verification may not model analog behavior properly. It is recommended
that behavioral models for analog modules be written in VAMS (Verilog-AMS) in order to
emulate behavior on silicon as closely as possible.
7. Low power feature: Low power is an important feature in the SoC because it is a key
requirement for applications like energy metering, smart phones or tablets. Tests should
check low power entry and exit. With the advanced simulation techniques of verifying low
power intent (like CPF or UPF), these patterns can verify low power intent with the addition
of low power structures like isolation cells or level shifters at the RTL stage itself.
8. Polarity check: Polarity of the connection of the output port of one module to the input port
of the other module.
9. Gate level simulation: The point here is to catch timing related issues, constraint validation
glitches, combinational logic on reset path, etc.
10. SPICE simulations: These are used to verify the analog functionality in the chip. Digital
simulation may be limited by the accuracy of behavioral models of analog blocks and the
limitations of modeling analog behaviur in traditional HDL languages. SoC simulations can
be run with few analog blocks in SPICE and the rest of the system in digital to verify analog
block integration.
11. System level use cases: Special consideration needs to be given to the application-level use
cases that excite the control and data paths for multiple applications running in parallel.
These are the application scenarios that the customer will finally run on the SoCs and adds
confidence in verification. This can be targeted to find any bottleneck in the design, such as
processor latency, DMA path latency, and/or interrupt priorities in customer use cases.

Title-1
Efficient Verification Strategy
As per the VLSI industry trend, the complexity of the chips is increasing while cycle time is
reducing. So, even after so much planning on "what to verify," it may still not be possible to verify
upcoming complex designs. As a result, designers need to plan for automation needs in the
verification cycle to help verify the entire design while maintaining quality standards and on time
delivery. The following steps can help to make the verification process more efficient:

Effectiveness of the test-suite: The verification plan should be made from the system level
architecture document (Chip Spec) so that each feature mentioned in the Chip Spec is mapped to at
least one test-pattern in the verification suite. The test patterns must be reviewed and checked for
the feature (verified by that pattern) and map it to the corresponding feature in the Chip Spec. The
test-patterns must contains proper comments, as per the pattern intent.

Automatic test-pattern generation: Tests that check basic features (like the memory and the register
access) can be generated through automation.

Self-checking patterns: Test patterns must check the intended functionalities and should indicate
pass or fail, depending on the checks intended. Some of the checks could be to verify the number of
interrupts occured vs expected or expected values of status registers at end of a transaction. Having
automated checks can save a lot of debugging time on failures.

Automated checks in Testbench: Monitors and assertions should be enabled in the testbench to
perform automated checks for key functionalities. Clock monitors and low power mode entry
sequences are a few of the checks that can be helpful.

Reusable test-suite: A verification test-suite should be made in such a way that it is fully reusable.
That way, for every new SoC it is simply a plug and play with some minor adjustments in case
there are some new features of that IP that is to be used in the SoC. Test cases should be coded in a
high level language so that they are independent of the processor and easily reusable for different
SoCs. This avoids the extra effort of test-suite creation every time an SoC changes and reduces the
verification cycle time. Test suite reuse could be of two types: horizontal (SoC to SoC) or vertical
(IP to SoC). Both enhance efficiency.

Leverage pre-silicon platform: It takes a lot of simulation time for the long patterns to run in a
verification environment. To improve cycle time, the verification plan must identify key scenarios
that have very large simulation times to be run on pre-silicon platform.

Randomization: Use randomization in the test bench for hitting the corner cases in the design. Some
of the parameters that can be randomized are:
• Values written in the register’s read/write patterns
• Number of resets to be given in the pattern
• Pin used for wakeup from low-power mode
• Latency in the wakeup from low-power mode
• Wakeup pulse duration

The following help hit the corner cases that may be difficult to target in a directed scenario:

 Intelligent pattern selection for gate-level simulations: Gate-level simulations are very slow
as compared to RTL simulations, so the test pattern suite should be selected carefully. For
example, all of the patterns that are part of the RTL simulation need not be run at gate level.
Target those patterns that exercise IO paths, digital-analog interactions, clock gating and
clock switching muxes for glitch detection etc.
 Regressions: SoC level regressions must be enabled at very early stages in the verification
cycle to review progress against overall test completion.
 IP Level regressions : An IP level regression suite must be run on IP releases delivered to
the SoC team, so that the SoC team can focus on SoC level defects.
  Formal verification of IOMuxing: Efficently verify the IO path. As there are limited pins on
chip and with increasing logic in chip, the number of functionalities muxed on each pin are
increasing. So, covering all of the paths by directed patterns might not be possible. Formal
checks can be done for IOMuxing verification as a quick and efficient method.
 Coverage: Design coverage (Toggle, Code, FSM) must be enabled to collect the coverage
data in each regression run so as to see the coverage holes and cover them. This ensures that
you are progressing towards the end goal. Add the cover points and cover groups for that
cover points in the testbench and collect the functional coverage to check whether all the
assertions and monitors are covered as per the test-suite.
 Low power feature: Verify in both RTL and gate level simulations in order to ensure proper
low power cells insertion in the design.

When to Stop?
This is the question that arises in the mind of every verification engineer while giving the sign off
on a design. Indeed, it is an important one. Here are few pointers. Even if gate count increases
linearly, the possible states in design may increase exponentially. It may not be possible to verify
all possible states of the design. A clearly defined set of coverage goals ensures that the verification
efforts are focused towards convergence with quality in limited time. Module level verification
enables coverage data collection at IP level. Complete code coverage (line, expression, block, FSM
and toggle) reports can be generated at module level. Functional coverage and assertion coverage
data can also be collected at this level as well.

For SoC level integration checks, the toggle coverage can be an important metric. The code
coverage (line, expression, block) for logic coded by the SoC team (like clocking logic, some glue
logics etc) should be reviewed and analyzed thoroughly in order to cover all of the required logic in
the verification. It can help to enhance the test-suite that covers the gaps. Functional coverage can
also be collected for the assertions so as to check that all the sequences have happened correctly.

For analog components, one can define functional coverage and assertions for the behavioral
models to ensure that the regular operating modes are verified. For low-power modes coverage, the
power format files can be easily used to collect a functional coverage database of low-power states.
This coverage closure (no holes left as per specifications) ensures that we have not missed anything
in respect to the verification of design functionality.

Please note: The views expressed in the article by the authors represent their personal opinions.

References:

1. Shortage of Verification Resources in the Semiconductor industry by Dr. Mike Bartley,

Chakravarthi M.G. Test and Verification Solutions .
2. What makes an optimal SoC verification strategy by Gaurav Jalan Manager - Design
Verification SmartPlay Technologies India Pvt. Ltd

If you liked this feature, and would like to see a bi-weekly collection of related features
delivered directly to your inbox, sign up for the Test & Measurement newsletter.

About the Authors

Deepak Mahajan: Working as a verification engineer at Freescale Semiconductor, India Pvt Ltd
having two years of experience and mainly responsible for SoC verification activities. Received
graduation in E.C.E from the Thapar University.

Gurinder Singh Baghria: Working as a design engineer at Freescale Semiconductor, India Pvt Ltd
having two years of experience and mainly responsible for SoC physical design activities.
Floorplanning, power planning/estimation and IR drop analysis (static/dynamic) are the main
expertise and focus areas. Received B.Tech degree in Electronics instrumentation and control from
the Thapar University.