An Automated Flow for Reset Connectivity Checks in Complex SoCs having Multiple Power Domains

Manthankumar Tejani, Naveen Jakhar, Siddharth Garg (Freescale Semiconductor India Pvt. Ltd.)

Today’s SoC designers are designing chips which have an optimum balance between performance and power numbers. So, the whole SoC design is divided into different power domains having a set of modules present in each of them. The power domains can be kept powered-on in some modes of operations and can be power gated in some other modes of operations. When a power domain is disconnected from the power supply, the power consumption is reduced to zero in that domain and all the modules in that power domain are power-gated off. It helps in claiming reduced power numbers but it has an adverse effect also. Any status information of such a power domain is lost. So, the ultimate goal is to reduce the power numbers while keeping the functionality of SoC intact. The modules which are power gated need to be in reset state to avoid any malfunctioning inside SoC and to avoid leakage currents. Thus, for complex SoCs having multiple power domains, a need arises for robust verification of reset connectivity of central reset generation module to different modules present in different power domains. In this paper, we will be presenting some potential issues in reset connectivity and an automated verification scheme for the same.

As shown in the figure 1, let us assume an SoC having three power domains: PD0 domain, PD1 domain and PD2 domain.

Figure 1: Different Power Domains in an SoC

PD0 domain is having clock sources, some time-keepers and timers, so it is always kept powered-on across all modes of operation and is termed as Always ON or Always Alive Domain. This domain plays an important role in maintaining device configurations as well as providing basic autonomous functionality with very low power consumption. PD1 domain is kept powered-on in full power modes and low power modes but kept power gated in ultra low power modes. PD2 domain is kept powered-on only in full power modes and kept power gated in low power and ultra low power modes. PD2 domain generally consists of high performance modules. From design’s perspective a module present in a specific power domain should have the reset signal of that specific power domain connected to it. If it is having its reset connected to the reset of some other power domain, then it will result in abnormal behavior.

Let us understand the need of dynamic reset connectivity checks and verification with an example. If a module ‘M’ of PD0 domain is having its reset connected to PD2 domain’s reset, then we can easily detect this reset connectivity issue by running a simple functional check on module ‘M’ in low power modes. Due to the reset connectivity issue, as PD2 domain is power gated in low power mode, so the module ‘M’ will be in reset and it will not work properly. Now, say, another module ‘N’ of PD2 domain is having its reset connected to PD0 domain’s reset. In that case, we can miss the scenario if we don’t have negative tests for PD2 modules in low power. For covering such cases, we need to add a negative test for all such modules present in PD2 domain. We have tried to reduce this overhead of adding new negative tests by introducing an automated flow for dynamic reset connectivity checks for all modules present in different power domains.

In this flow, we need to write a Perl/Shell script which takes design files as input and generates a power domain based Verilog checker for different resets which is then integrated in the testbench environment. The script extracts the total number of power domains present in the design and the modules present in each power domain. After that, the reset signal of each module is extracted from the design. The main reset signal going from central reset generation module to any power domain is termed as “source_reset” and the resets of different modules are termed as “target_resets”. Dynamic checks are generated by the script for checking the reset connectivity between these source_reset and target_reset signals. One to one reset connectivity checks ensure that there is no miss in the reset connections to different modules. Now, we run a simple test which traverses all the different power modes of operation for covering the power ON/OFF conditions for different power domains and the above generated Verilog checks run in parallel to find out any issue in the connectivity. The underlying principle of the generated checks is as follows: in full power modes, all the power domains PD0, PD1 and PD2 are alive and we check that all the modules present in these domains are also alive. Now we make a transition from full power mode to low power mode and check that the modules present in PD0 and PD1 are alive while modules present in PD2 domain are power gated. Finally we make a transition from low power mode to ultra low power mode and check that the modules present in PD0 domain are active and modules of power domains PD1 and PD2 are power gated. The checker finally dumps out a log which contains the list of source_reset and target_reset signals which behaved properly and the ones which resulted in unexpected behavior and showed connectivity issues. This log can be used for post processing and analyzing any connectivity issue.

A sample output checker code generated from this flow is shown below.

**************************************************************
// M0, M1 and M2 are three modules present in power domains PD0, PD1 and PD2 respectively.
wait(`current_mode == `full_power_mode);
if ((M0_reset_asserted) || (M1_reset_asserted) || (M2_reset_asserted))
$display(“ERROR: issue in reset connectivity in full power mode”);

wait(`current_mode == `low_power_mode);
if ((M0_reset_asserted) || (M1_reset_asserted) || (M2_reset_de_asserted))
$display(“ERROR: issue in reset connectivity in low power mode”);

wait(`current_mode[3:0] == `ultra_low_power_mode)
if ((M0_reset_asserted) || (M1_reset_de_asserted) || (M2_reset_de_asserted))
$display(“ERROR: issue in reset connectivity in ultra low power mode”);
**************************************************************

Conclusion:

Using an automated flow for reset connectivity checks for SoCs with multiple modules and power domains not only reduces test coding overhead for verification engineer but also helps in catching SoC design bugs at an early stage of design cycle.