Efficient methodology for verification of Dynamic Frequency Scaling of clocks in SoC

Siddharth Garg, Naveen Jakhar, Rohit Ranjan(Freescale Semiconductor India Pvt. Ltd.)

Dynamic Frequency Scaling (DFS) is a feature in power critical SoCs where different clocks going to different modules can switch their frequencies on the fly, even in the middle of ongoing transactions, to reduce power consumption or heat generation. The main challenge is that if any transaction is ongoing and frequency scaling takes place, there should be no loss of data, the chip should not get stuck anywhere and all the modules should work seamlessly across the DFS. In this paper, an approach has been given to verify the integration and functionality of Dynamic Frequency Scaling in the SoC using multiple checks like assertions, frequency monitors and randomized test cases which we can use in the testbench environment. With this approach, multiple design bugs have been uncovered in the SoCs.

The dynamic power (switching power) dissipated per unit of time by a chip using CMOS technology is C.V².A.f, where C is the capacitance being switched per clock cycle, V is voltage, A is the Activity factor indicating the average number of switching events undergone by the transistors in the chip and f is the switching frequency. The voltage required for stable operation is determined by the frequency at which the circuit is clocked, and can be reduced if the frequency is also reduced. Dynamic voltage scaling (DVS) is another power conservation technique that is often used in conjunction with frequency scaling, as the frequency that a chip may run at is related to the operating voltage.

In a SoC, there are huge number of IPs which work on different clock frequencies. Depending on the frequency to be used for particular IP, we can classify the IPs into particular groups. For example, IPs with similar clocking requirements can be placed in one group. This way we can have about five-six groups in the SoC (number depends on number of IPs and complexity of SoCs).

There can be two types of scaling:

1. Linear frequency scaling
2. Nonlinear frequency scaling

Let us assume we have four frequency groups in an SoC. Suppose in a particular scenario, all the four frequencies of the respective groups are being reduced by same ratio (say, all are becoming half of the original), then system should continue to run smoothly without any halt as the ratio between different clocks is still maintained the same. This type of switching can be termed as linear frequency scaling, which is shown in following figure. Note that frequencies in each group are reduced to half without any halt in the system.

Now, let us see a different scenario. Suppose, in any particular case, only few groups are required to be scaled. Here the ratios between different clock groups are becoming different. In this case, we need to halt the system for few clocks till the scaling completes, because if system keeps on running while switching it can lead to data misses and ultimately to potential hang situations in the SoC. This falls in the category of nonlinear frequency scaling, which is shown in following figure. As soon as dfs_trigger comes, handshake mechanism takes place to halt the system and system comes out of halt only after scaling has taken place. Note that frequencies of only two groups (namely, Group1 and Group3) are scaled.

Potential issues in a system with DFS:

Due to a faulty design, there can be following types of issues in the SoC with Dynamic Frequency Scaling feature implemented.

• There can be data loss in a system as the clock on which data is getting sampled switches while transactions are going on.
• The system can hang if some lock situation occurs due to acknowledge signal getting missed from being sampled in a request - acknowledge type handshake mechanism.
• The IPs can get connected to wrong frequency group so they might stop working in some conditions.

Efficient verification methodology to uncover bugs:

To verify all the scenarios with all corner cases of DFS in the SoC, we can use following features in a test bench.

• SV Assertions
• Directed test cases
• Randomization
• Frequency monitors
• Glitch monitors
• Duty cycle monitors

System Verilog based assertions can be used to catch bugs of wrong connectivity of clock groups to different IPs in the SoC.

As all the groups are normally connected to a common clock generation module in the SoC, we can write assertions to check that if a particular clock group is changing its frequency, the IPs which are intended to work on that group should also see a frequency change on their ports.

Directed test cases can be used for functionally covering the working of different IPs across all possible scenarios of DFS. We can start by booting up the chip and then checking that as we switch frequencies, normal functionality of the IPs is not affected and no data loss takes place.

Randomization is an important aspect in the verification of DFS feature in the SoC. We need to randomize the time stamps at which switching takes place so as to cover corner cases also. Some scenario might get hit at one time instance but might work fine if switching takes place at some other time instances.

Frequency monitors are used to check if the frequency going to different groups is as per requirement and is not going out of particular range required for an IP in the SoC as it can lead to timing violations.

Glitch monitors are used to check that no glitch comes on any of the clocks while frequency switching as it might lead to data corruption due to timing violations.

Duty cycle monitors are used to check that duty cycle doesn¡¦t go out of the tolerable range for the IPs which are mainly used for calibration purposes and communication protocols.

The frequency, glitch and duty cycle monitors are Verilog based monitors which monitor negative edges and positive edges of clocks and calculate frequency, pulse width and duty cycle using those edge time stamps.

Conclusion:

DFS is a new era feature in the modern SoCs and its thorough verification is equally important to have a bug free silicon and reduce R&D cost. In this paper, we have presented multiple features in a testbench by which we can do robust verification of the DFS feature in the SoC.