Path: EDN Asia >> Design Centre >> Test & Measurement >> Finding faults with cross-corner testing
Test & Measurement Share print

Finding faults with cross-corner testing

14 Apr 2014  | Pallavi Raj , Archana Tripathi, Amresh Kumar

Share this page with your friends

Freescale's QorIQ SoCs include multiple processor cores that utilise GigaHertz clocks. The SoCs also include DDR memory, high speed interfaces, and internal buses. As speeds and complexity increase and die-sizes shrink, maximum frequency of the high speed modules across process, temperature, and voltage variations has grown in importance. Design teams heavily rely on the data generated from ATE and from validation boards.

Validation of FMAX (maximum frequency) data and its correlation with tester results is important to ensure that we properly select SoCs that match a customer's targeted speed. But, ATE and validation boards do have differences. With ATE, the pre-generated tester patterns that mimic the real devices—flash or DDR memories—interact with the SoC. Validation boards use real devices and thus actual flash or DDR memories are interacting with the SoC. Furthermore, the size of the test cases run on the ATE are usually smaller because of tester time and memory limitations. On the validation board, we can run long patterns that invoke multiple modules. The tester is capable of automatically handling multiple silicon units, patterns, and shmoo plots, which is a limitation for the validation board.

Typically, board PVTF (process, voltage, temperature, frequency) validation starts in middle of validation cycle, when the functional test cases are stable. It includes speed hunting and shmoo plotting.


Figure 1: Speed hunting uses a shmoo plot to find where a device passes.


Speed hunting
The process of selecting speed-limiting test cases from a random set is known as speed hunting, this is typically done for high-speed interfaces such as those used with DDR or Cores. These patterns give the worst FMAX of interface under test, but it takes time to generate test scenarios using speed hunting.

Figure 1 shows how speed hunting works. This algorithm starts at a high frequency point where a test case is suspected to fail. F1 (frequency) indicates a point where the first random test case failed. F80 (frequency) indicates a point where the 80th random test case failed and F1K (frequency) is the point where the first fail occurred after 1000 runs. P is the point where no failure was seen up to 7 hours of run. The failing test case at F1 is certainly useless. The failing test case at F80 was more stressful than the previous 79 test cases and the failing test case at F1K was more stressful than the previous 999 test cases. At this voltage, test scenario at F1K is the best candidate for further investigation. The test cases run self-checking code and failure is reported when the output of test case fails to match expected values.


Shmoo plotting
For shmoo plotting, first step is to identify test cases that we want to run under different conditions, usually high functional coverage or speed-hunted test cases. For different processes parts, we vary voltage, frequency, temperature and run scenario for speed critical, new modules or other system stress tests. In stress tests, cores and interfaces run concurrently, which generates core stress, platform stress, and DDR stress. These scenarios are very close to real applications.

1 • 2 • 3 • 4 Next Page Last Page


Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.


Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming


News | Products | Design Features | Regional Roundup | Tech Impact