Automated validation of multiple clock signals in SoC designs
Article By : Atulesh Kansal and Himanshu Aggarwal
The complexity in clocking subsystems in SoC designs is paving the way for automation to validate multiple combinations of clock signals.
The demand for new and upgraded features is increasing day by day in modern semiconductors. This may include multiple power domains to support low power and full power modes and multiple clock domains to support the interfaces with different working frequencies. Major challenge comes when there are multiple clock and power domains. This article will touch upon multiple clocking domains in a system-on-chip (SoC) design.
SoCs these days have multiple clock platforms whose range may vary from 2 to 20 clocks or even more. But how do we plan to cover all these clocking combinations? Do we plan to cover each scenario manually, validating each and everything at all frequencies with different dividers? That’s a lot of work. So, this article will demonstrate a fully-automated methodology based on Python scripting to cover the validation of multiple clock signals.
Clock randomization
With the increasing number of clocks, the coverage of one-dimensional configuration space increases. One-dimensional coverage refers to the number of configurations possible while switching various clocks with different settings in a single-power mode. As the number of power modes—low power modes or fully functional modes—increase day by day, one-dimensional coverage is not enough to rule out the corner scenarios. Consequently, we need to have two-dimensional coverage. Two-dimensional coverage matrix includes the mode transitions from low power modes to fully functional modes and vice-versa.
While drafting two-dimensional coverage, we need to take care of some of the constraints that may arise from architectural limitations, safety considerations, and logical dependencies of one clock on another. Missing these constraints may lead to adding up unnecessary validation time. So, considering all the constraints, we can randomize the system clock selection and check the working of SoC in different conditions.
Randomizing clock is very important as some of the features might work as expected at fast clock but might not work at slow frequencies and at inaccurate clocks.
Figure 1 The one-dimensional matrix example represents one of the possible scenarios in an SoC which can have nth number of possible clocks and nth number of possible power modes.
As seen in the above one-dimensional matrix example, millions of combinations will be formed on the basis of such matrix, and verifying these combinations even through automation will be a few months long work. Our validation cycle might not be that much longer. Additionally, some of the combinations might be redundant and might not have an application use case such as the one which involves inaccurate RC clocks, which are just used for booting purpose in silicon. So, it’s important to remove those combinations.
Figure 2 A one-dimensional matrix example shows reduced number of combinations.
Figure 2 depicts the final combinations which will have a use case on customer side. Hence, finding out not applicable scenarios will help us reduce the combinations from millions to a few thousands, which can be easily covered in the validation cycle.
Figure 3 represents the flow diagram that we should keep in mind while implementing the framework for the two-dimensional matrix to test the final reduced number of possible scenarios, so that no bug is missed from this perspective.
Figure 3 The flow diagram shows how to implement a two-dimensional matrix.
Methodology setup and overview
Flow mentioned in Figure 4 and Figure 5 can be used to implement a setup for validating clocking modules with randomized parameters without manual efforts. In this setup, various instruments such as function generator, oscilloscope, power supply, and logic analyzer can be used. For example, in our validation setup, we used Keysight’s Infinium DSO 2.5-MHz S series oscilloscope and AFG3235C series function generator from Tektronix.
Figure 4 An overview of setup and interface is shown here with board and PC.
Figure 5 The flow diagram demonstrates how the clock randomization automated methodology (CRAM) setup is used.
Various parameters are selected and are further randomized through Python, then stored in Excel, and through excel, they are then passed as parameters in our C code. Next, the interface is created with all the instruments that are going to be used in our setup through PyVisa and standard commands for programmable instruments (SCPI). The SCPI commands are the standardized IEEE commands used for various read and write operations. Among the instruments that we use are function generator that is used to provide different input waveforms and oscilloscope that is used to capture the output data and various results which are stored as screenshots in some common location.
After picking up the parameter from Python constraint file and creating an interface with the instruments required, the code is compiled and then executable and linking format (ELF) is loaded in the silicon to check out scenario. The testcase is executed with those randomized parameters till all the configurations are complete.
The results are captured through the serial port or UART device and the snapshots are further captured from oscilloscope to verify the results taken. All this is possible if there is a provision to bring out system clock and other available clocks to pad, so they can be used for debug and automation purposes. If the clock is available at GPIO, in that case, it can also be checked if the clock is generated as per expectation or no. We can also check the accuracy or consistency of the clock.
All such clock sources, clock dividers and phase dividers should be checked in every possible mode, especially in low-power mode.
So, with this setup, we can exhaustively validate various combinations of clocking and modes supported in SoC. We can see the clock snippets taken during one of the randomization processes in Figure 6 and Figure 7. In these snippets, we can see various parameters—such as duty cycle, mean frequency, minimum frequency, maximum frequency, and frequency range—can be captured as required and can be further verified. It will help the user catch any glitch or unexpected variation in the clocks or the system path.
Figure 6 This is how to get information on various parameters from oscilloscope through automation and then verify those parameters on oscilloscope itself.
Figure 7 The SoC designers can get information on various parameters for the clock frequency observed from oscilloscope through automation and verify those parameters on oscilloscope itself.
Multiple configuration coverage
We have seen the challenges in validating multiple clocking combinations manually and how the clock randomization automated methodology or CRAM helps in overcoming these challenges. In the final analysis, we can say that with this automated methodology, we can get more coverage with reduced effort. It’s a completely inhouse developed methodology, so no licensing fee is required. Last but not the least, due to automation, chances of human errors while measuring clock frequencies are also ruled out in this setup.
This article was originally published on EDN.
Atulesh Kansal is senior lead design engineer at NXP Semiconductors India Pvt. Ltd.
Himanshu Aggarwal is senior design engineer at NXP Semiconductors India Pvt. Ltd.
