Pre-Silicon Fairness Evaluation for DUT Testing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current pre-silicon testing environments struggle to detect fairness issues, such as livelock and starvation, due to the use of fixed quiesce cycles, which mask fairness problems and require costly post-silicon corrections.

Innovation Solution

A computer-implemented method dynamically sets a quiesce point based on the state of drivers executing on processors, allowing for continuous command driving until fairness issues are identified, enabling pre-silicon detection and correction of fairness problems.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If fixed quiesce cycles are used in pre-silicon testing, then the testing process is simple and predictable, but fairness issues such as livelock and starvation cannot be detected

Engineering Contradiction:
Improvefairness detection capabilityVSAvoidtesting process complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The quiesce point is changed from a fixed predetermined value to a dynamic value that is adjusted based on runtime state information. The testing system continuously monitors state metrics and adaptively sets the quiesce point to optimize fairness detection while maintaining testing efficiency.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The testing system implements feedback mechanisms where state information from runtime execution is fed back to dynamically adjust the quiesce point. This feedback loop enables the system to detect fairness issues by comparing expected versus actual traffic progression and adjusting testing parameters accordingly.

Inventive Principle:
Principle #23Feedback

2Reliability

If fixed quiesce cycles are used, then test execution time is predictable and controlled, but fairness problems are masked and require costly post-silicon corrections

Engineering Contradiction:
Improvedesign qualityVSAvoidtest floor debug time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs fairness evaluation during pre-silicon testing rather than waiting for post-silicon validation. By detecting and reporting fairness issues in the simulation environment, the system enables corrections to be made before silicon fabrication, preventing costly re-spins and reducing overall development time.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent replaces physical silicon testing with virtual pre-silicon simulation testing that includes fairness evaluation capabilities. This substitution allows fairness issues to be detected in software simulation before actual hardware is manufactured, eliminating the need for expensive post-silicon debugging.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

3Measurement precision

If new commands are continuously driven on interfaces, then fairness issues can be detected, but the testing process becomes complex and requires dynamic state monitoring

Engineering Contradiction:
Improvefairness issue detectionVSAvoidstate monitoring complexity
Core Design Contradiction:
Measurement precisionVSDifficulty of detecting and measuring

Solution Approach 1:

The testing system automatically monitors its own state and adjusts the quiesce point based on runtime conditions without requiring external intervention. The system self-manages the complexity of state monitoring and fairness evaluation, making the process easier to implement and maintain.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS10678670B2Evaluating fairness in devices under test
Publication Date: 2020.06.09 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US10678670B2 patent drawing
  • US10678670B2 patent drawing
  • US10678670B2 patent drawing

AI summary

Pre-silicon fairness evaluation to detect fairness issues pre-silicon. Drivers drive a plurality of commands on one or more interfaces of a device under test to test the device under test. State associated with the device under test is checked. Based on the state, a determination is made as to whether the drivers are to continue driving commands against the device under test. Based on determining that the drivers are to continue driving the commands, a further determination is made as to whether a predefined limit has been reached. Based on determining the predefined limit has been reached, ending the test of the device under test in which the test fails.