Verification of various SoC features through SV assertions

Rohit Ranjan, Naveen Srivastava, Naveen Jakhar ( Freescale Semiconductor India)

With increasing complexity of SoCs and reduced execution cycle time, System Verilog assertions have become an integral part of verification environment. Assertions help in reducing the number of directed tests with an added advantage of reduction in effort and run-time in addition to providing verification coverage. Assertions can be deployed at various points in the design for verifying multiple aspects like resets, clocks and pads in the SoC. In this article, we will be highlighting the grey areas in which assertions come handy. We will also be discussing the methodology for efficiently generating assertions and then simply integrating them in the testbench environment using plug-n-play technique.

Reset Connectivity:

Keeping in mind Power and Performance factors, SoC designers implement varied SoC architectures which support different power domains. And the modules present in these different power domains have different sets of reset connectivity. So, connectivity of various types of resets going to different power domains and different modules can be checked through assertions. For example, in SoCs with multiple power domains, there is a specific reset signal connected to each power domain. If these connections get swapped, it can lead to fatal scenarios in the chip as well as unwanted power consumption. Also, a particular type of reset is connected to a particular type of IP. For example, the timekeeper of the SoC is supposed to be reset at Power-On-Reset. But due to faulty design, if its reset gets connected to software reset, then its intended functionality goes in vain. We need to have dynamic assertions for checking this kind of reset connectivity. We can define the reset sources as the triggers for assertions and different modules in different power domains as the targets.

Clocking:

Since the SoCs support multiple clock sources along with different modes of operation and these clock sources are configurable through software, so we need to have dynamic checks when these clock sources are getting enabled or disabled to catch any glitch or any abnormal behaviors like crystal failure or loss of reference clock to PLL. These kinds of assertions can be extended to peripheral clocks also. For example, in general we have a central clocking control module in SoC which is generally used for clock_gating the peripherals when these peripherals are not in use. So we can use dynamic assertions for the signals of clock_gating and checking the peripheral_clock_status. An example of the checker for the same has been shown below.

PADS:

Monitoring of pads' state has become an essential part of the verification schemes that are being employed for SoC verification now-a-days. SoC can have different important modes where we need to monitor the pads. Incorrect value on the pads may lead to malfunctioning and unexpected behavior of the integrated SoC system. We will be discussing a few of these modes in detail.

• Reset state of the SoC: Different pads on SoC have a specific state during reset phase of the chip, which is defined by the architecture and design team. Any value other than the defined ones, can lead to different problems which include power leakage and malfunctioning of communication protocols. When the chip is in reset, critical signals are exposed on the pads which are helpful in debugging any issue, so this kind of monitoring is also done via System Verilog assertions.
• During Self-test: When the self-test (LBIST or MBIST) is running on chip, pads should not toggle and remain at their reset value as explained above.
• SoC's Low power states: There are specific low power pads in the SoC which need to retain their values in low power modes or which can be used for generating external wakeups to SoC. These pads come handy for debugging purposes if we have any issue in low power modes.
• When the SoC is in test mode: Usually multiple test modes are available in a SoC for checking the behavior of analog IPs, communication IPs. Whenever we enter a particular test mode, a set of pads are configured to safe state values for their correct behavior. Therefore, we need to monitor state of these set of pads.

Script based assertion generation methodology:

The check points for clocks, resets and pads lead to a huge number of assertions and writing these assertions manually is a tedious task. So we need to have automation for efficiently generating these assertion sets. These signals are usually available in documents provided by the Architecture and Design team. We can run a script on these documents and generate assertions which we can directly integrate in our testbench environment. An example of snippet from one of the documents is shown below:

The corresponding assertion generated using script is shown below:

Conclusion:

Assertions based verification should be an integral part of the SoC verification environment for robust verification. Assertions provide a unique way of generating test points within the design which leads to increased observability of the design. On top of it, script based assertion generation flow saves many valuable man-hours. This integrated approach aids in delivering high quality silicon with reduced cycle time.