Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Detect corner-case issues with post-silicon testing

Posted: 19 Nov 2015 ?? ?Print Version ?Bookmark and Share

Keywords:multi-cores? clock-tree? ADAS? powertrain? IP?

Automotive SoCs are becoming more and more complex with the integration of multi-cores, dense clock-tree, increased analogue & mixed signal (AMS), complex power & reset management, innovative ADAS/powertrain sub-systems, various interfaces, and other highly configurable modules. Throughout the development cycle, there are various pre-post silicon test scenarios executed on IP/SoC level with the objective being to uncover the system-level integration issues in the device. These observations would lead to certain design/documentation changes, resulting in a more robust customer solution.

However, there may still be some corner case issues encountered, when certain sequences and combinations of events occur on device that have never been exercised in device testing. This paper consolidates the various areas identified for post-silicon stress tests on automotive SoC to enable early detection of system level issues:
???Clock Synchronisation issues
???Regression on implemented Finite State Machines (FSM)
???Rigorous low power mode Entry/exit
???Performance aspects around Master-Slave interconnects (Crossbar)
???System behaviour on Illegal register accesses

Let's now discuss each one of these areas one by one with the illustrations of the issues identified during the stress tests.

Clock synchronisation issues
Dense clock trees are implemented in SoCs with a number of configurable clock sources for driving the cores and peripherals. Moreover, these clock sources have associated dividers to allow further configurability. Most of the times, all the possible clock synchronisation issues between system and peripheral clocks cannot be caught by verification tools due to resources/time/computing limitations. This impromptu becomes an important area to focus during the post-silicon validation.

Validation engineers should implement randomisation in their code to vary the clock sources and dividers while peripherals and core are communicating. This can help catch some combinations where different clock frequencies for Cross-bar and peripheral clock cause functional failures, which can then be properly documented/implemented to avoid issues in the customer applications.

Regression on implemented FSM
Every module which has a FSM implemented inside (figure 1) must be thoroughly verified for the correct state transition at all the desired events and ensure that not only the system doesn't malfunction for all the valid mode state-transitions but also that the system should be able to recover properly for all in-valid mode transitions.

Figure 1: FSM implementation with in SoC.

Getting these transitions covered during post-silicon is even more challenging. Reset generation module is a critical module which controls the system behaviour on reset assertions from various sources/events. Validation tests must be developed on RGM to observe that effect of periodic assertion of external reset signal on device and whether the device comes out of reset fine everytime with a different set of configurations or not. A simplified illustration of the RGM validation setup is shown below:

Figure 2: RGM stress validation setup.

1???2?Next Page?Last Page

Article Comments - Detect corner-case issues with post-...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top