Integrated Low Power Verification Suite: The way forward for SoC use-case Verification

Naveen Jakhar, ITS Officer, Department of Telecommunications, Government of India

Abstract:

As a result of increasing complexity of the VLSI designs, SoC verification engineers are shifting their focus towards SoC level verification involving real use-case scenarios. These use-cases are the replica of how the SoC will be used by the customers in field. So, it involves verification of multiple IPs working in tandem. Along with the increasing number of IPs being used in an SoC for performing multitudes of operations, VLSI designers are designing SoCs with advanced clocking and reset architectures, multiple mode of operations, support for exit from low power modes using internal/external wakeups and interrupts etc. for being the frontrunners in the field of innovation. So, along with covering the functional operations of the SoC, the use-case needs to cover two important aspects:

1. The impact of changing clock configurations and modes of operations, abnormal clock failure, interrupts, resets and wakeups being generated at any time.
2. How does the SoC recover after the generation/occurrence of these events?

So, we need to create an intelligent and dynamic test suite, based on certain parameters defined in Architecture Design Document (ADD) and SoC guide, which can be used as a backbone for creating robust use-cases. The parameters like number of system clocks and their frequencies, different types of resets, interrupts, wakeups and modes of operations are used to create all the possible combinations of operations and events which can affect the operations of a given SoC. In this article, we will be highlighting the needs and advantages of this kind of Integrated Low Power Verification Suite.

Problem Statement:

The Conventional approach of SoC verification involves functional verification of a module/IP in different modes of operation with a limited number of clocking configurations. For the complex designs, we use modular approach of use-case verification. The use-case approach is specifically meant for the verification of IPs operating in tandem, but it leaves critical holes in the verification. This is high time we look at the SoC use-case verification with a different perspective. Advanced use-case verification scheme can be thought as a combination of use-case verification with Integrated Low Power Verification Test suite acting as its backbone. Let us try to understand the need of development of this kind of verification approach. A customer reported an issue: In an SoC, we have a full power mode called RUN mode and a low power mode called STANDBY mode. It is having a SoC Timer named PER_A.

Fig1. Clock sources to SoC Timer PER_A

SoC Timer PER_A is having two clock sources for running its timer, namely System Clock and Slow RC oscillator as seen from Fig1. It is used for time keeping of SoC, generating interrupts and wakeups from low power modes of operation. Let us consider a use-case where PER_A is used for generating wakeup when we are going from RUN mode to STANDBY mode. But, we have a combination of system clock and other clocks present inside SoC as mentioned in the below table.

Ongoing Mode transition	Mode of Operation	System Clock	SoC Timer PER_A clk	Event
No active transition	Current mode = RUN	ON	Slow RC Clock
No active transition	target mode = STANDBY	OFF	Slow RC Clock
RUN -> STANDBY transition				system wakeup is generated by SoC Timer PER_A

Fig2. Mode transition and wakeup event

As per Fig 2, software initiates a mode transition from RUN mode to STANDBY mode and when the transition is on-going, SoC Timer PER_A generates a wakeup. But this wakeup has no effect on the mode transition. The system powers down system clock but the current mode of operation remains RUN mode and the system remains stuck forever in this situation.

While doing the root cause analysis, we found that the mode controller module ignores the wakeup being generated during the above type of transition and disables the system clock, but the target mode becomes current mode only when the system clock is enabled. So, we need to add a logic for preventing the disabling of system clock before the completion of transition and add a glue which takes care of the wakeup generated during mode transition and aborts such type of mode transition.

So, while creating an Integrated Low Power Verification Suite, we need to take all these parameters into consideration:

1. Number of Modes of Operations of SoC as mentioned in ADD or SoC Guide
2. Clocking Information: Number of System Clocks and other clocks of SoC
3. Type of wakeups and interrupts : Synchronous or Asynchronous events
4. Type of resets present in the system

Now, we shall be discussing how we can convert these document parameters for creating the Integrated Low Power Verification Suite.

(a) Converting Number of Modes of Operations of SoC into meaningful information:

Let us take an example of a hypothetical SoC with different modes of operation and possible mode transitions as described in Fig 3. Now, we shall be using concept of Adjacency Matrix of Network Theory and Graphs for converting this raw information into some meaningful data. The Adjacency Matrix is a square matrix which is used for representing a finite graph. If two vertices of a graph are connected, they are represented by non-zero values and if they are not connected, they are represented by 0 in the corresponding Adjacency Matrix. For example, as seen in Fig 3, it is possible to make a transition from FP1 mode to FP2 mode, so the matrix element will be a non-zero value. FP2 and ULP2 are not connected, it means that no mode transition is possible from FP2 to ULP2, so the corresponding matrix element will be 0.

Fig3. Graph showing Modes of Operations and mode transitions of an SoC

So, on converting the graph shown in Fig 3, we get the following Adjacency Matrix as shown in Fig 4. We term this Adjacency Matrix as Power Matrix.

Fig4. Power Matrix: Adjacency Matrix corresponding to Graph shown in Fig 3

(b) Converting Clocking Information of SoC into meaningful information:

Now let us consider the clocking information of the SoC provided in ADD. As shown in Fig 5, we are having 5 clock sources present in the system, namely CLK_SRC_n where n goes from 1 to 5. Out of these clock sources, CLK_SRC_1, CLK_SRC_2 and CLK_SRC_3 can be used as system clocks. System clock is kept powered down in ultra-low power modes of operations i.e. in ULPn where n varies from 1 to 3.

Fig5. Clocking information in various modes of operation of SoC

Now, we convert the ON/OFF information of clock sources to 1 or 0 and create a Clocking matrix as shown in Fig 6.

Fig6. Clocking Matrix: Clocking information of SoC

Now, Using Clocking Matrix and Power Matrix, we create a three-dimensional matrix which is having all valid combinations of current mode, target mode and clocking information of target mode. From this 3-D matrix, we pick a configuration randomly, and make a transition to the target mode with this configuration. The configurations are passed from Verilog code to C code which is the executed by the software. This process is repeated until we get 100% coverage. The coverage is guaranteed using coverage bins.

(c) Converting Type of events interrupt/wakeup/reset of SoC into meaningful information:

As shown in Fig7, various type of events supported by SoC are interrupt, wakeup and resets. These can be internal or external and synchronous or asynchronous. This information is shown in the form of Event Matrix of SoC. These events can be generated randomly or in sweeping manner. The criteria to decide whether we want to use random events or sweeping events is the current activity going on in the SoC. During the ongoing mode transitions, it is preferred to use sweeping events for robust verification. But if the SoC is operating in any particular mode of operation, first we need to select the type of event as mentioned in Fig7 by using Verilog code and then we can generate these events at random intervals of time.

Fig7. Event Matrix of SoC

The selection of a particular type of event is using constraint based randomization. Also, we need to check how the system recovers after the occurrence of such events.

But if the mode transition is going on, we should use Advanced version of Corner Case Scenario Generation (CCSG) kind of tool for robust verification. All the possible events mentioned in Fig7 are picked up randomly by the Verilog code and then sweeping of the picked event is done by using CCSG tool. The CCSG tool gives a capability to the verification engineer to firstly create possible corner scenarios using its precise sweeping of events. CCSG has been coded in Verilog and it is totally independent to testbench and environment. Fig8 shows various components of Integrated Low Power Verification Suite.

Fig8. Components of Integrated Low Power Verification Suite

1. CCSG tool generates high precision sweeping events on the edges of a test clock which is called local_clk_check as shown in the below code. This clock is asynchronous to the testbench clock, simulator clock and all the clocks being used as system clocks.
2. itr means the iteration count. It is to be decided by the user while running the test. The sweeping continues till the time we have completely covered the entire window of mode transition.

Fig9. Snippet from Verilog code used in CCSG

Along with the generation of these events, we can generate other asynchronous events like loss of lock of PLL or clock failure in the system and then check how the system recovers.

The Verilog code of CCSG is now plugged with Power Matrix and Mode Matrix, which creates an overall combination of generation of interrupts/wakeups/resets/clock failures when the SoC is running a Use-case or when the SoC is making a transition from one mode to other mode while executing a Use-case. These Verilog and C codes can be plugged as the backbone for creating a robust Use-case.

Conclusion and Advantages:

The codes and approach used for Low Power Verification Suite are parameter based and can be easily modified just by changing these parameters. This verification suite can be used as backbone for creating robust Use-case scenarios. So, we don’t need to edit the test flow when we are using this methodology on different SoC. In that sense, this is a very generic approach.

Based on intelligent post-processing, this verification methodology derives and presents meaningful graphical data to the user for first-glance deduction of potential error scenarios and stuck scenarios so that no corner case bugs are left in the design and the Use-case verification is complete in every sense.

Output of a sample use-case using Integrated Low Power Verification Suite:

Fig10. Output after post-processing

References:

http://www.design-reuse.com/articles/39591/corner-case-scenario-generation-tool.html

If you wish to download a copy of this white paper, click here