Vmin Prediction#

Purpose#

This reference application demonstrates how machine learning can be applied to SmarTest Test Program, specifically for reducing Vmin search time.

Minimum Operating Voltage (Vmin) is the lowest voltage at which an integrated circuit operates reliably. Traditional Vmin search is iterative and time-consuming, and requires substantial test equipment resources. By leveraging machine learning, we can predict an optimal starting voltage for each wafer based on its process signatures, resulting in reduced test time and lower costs.

About this tutorial#

The purpose is how to reduce Vmin search time with Vmin prediction.

  • Model training, prediction and evaluation

  • Using application in ACS RTDI Test Program

Compatibility#

  • Ubuntu 20.4 / SmarTest 8 / RHEL79 / Nexus 3.1.0 / Edge 3.4.0-prod / Unified Server 2.3.0

Procedure#

Installation#

Ensure you have the following prepared:

  • An ACS RTDI virtual environment containing an Ubuntu Server VM.

You can use the following commands to download the example Jupyter notebooks and set up the runtime environment, please refer to “Installation”.

Model training, prediction and evaluation#

For detailed guidance on model training, prediction, and evaluation with AutoGluon, please refer to “Model training, prediction and evaluation”. This section covers:

  • Loading and preparing your dataset

  • Training the AutoGluon TabularPredictor model

  • Making predictions on test data

  • Evaluating model performance using various metrics

These steps apply directly to building a Vmin search prediction model using your measurement data.

Using model in ACS RTDI#

Download the example Test Program and application on the Host Controller:

cd ~/apps/
curl http://10.44.5.139/apps/application-vmin-v3.1.0-RHEL79.tar.gz -O
tar -zxf application-vmin-v3.1.0-RHEL79.tar.gz

Container application setup#

After training, the model is located in the AutogluonModels directory. You need to copy the model files to the container application’s directory: ~/apps/application-vmin-v3.1.0/autogluon-vmin-tpi-app/src/AutogluonModels.

Then, we need to implement model loading, receiving request messages from the Test Program, performing prediction, and returning the results to the Test Program:

def run_inference(request: dict) -> str:

    # Load the trained AutoGluon model
    default_relative_path = os.path.normpath(os.path.join(current_dir, "..", "AutogluonModels", "vmin"))
    g_ag_model = os.environ.get("VMIN_MODEL_PATH",default_relative_path)
    predictor = TabularPredictor.load(g_ag_model)

    # receiving request messages
    try:
        # Deep copy and parse the JSON request
        request_cp = copy.deepcopy(request)

        # Extract row data and convert to DataFrame
        row_data = request_cp.get("features")
        df = pd.DataFrame([row_data])
        # Convert all values to numeric, coercing errors to NaN
        df = df.apply(pd.to_numeric, errors='coerce')

        # Make prediction
        predicted_value = predictor.predict(df).iloc[0]
    ......

Test Program Workflow#

The following code shows how to integrate ML predictions into a Vmin search Test Program. This is a reference implementation - you should adapt the search parameters and logic to match your specific Test Program:

while ((line = br.readLine()) != null) {

    // Request ML prediction
    double predictedVmin = receivePredictData(headerLine, line);
    
    // Use prediction to optimize search or fallback
    LinearSearch linearSearch = new LinearSearch();
    linearSearch.setStart(searchVstart).setStop(searchVstop).setStep(searchVstep);
    ......
    
    // If prediction available, start search near predicted value; If prediction failed (NaN), use default range
    double vmin = Double.isNaN(predictedVmin)?
        linearSearch.searchLinear():
        linearSearch.searchLinearWithML(predictedVmin, 0.9);
}

Send feature data to ML model container

The receivePredictData() method constructs a JSON payload containing the feature data and sends it to the AutoGluon model container running in the Edge Server. For detailed information on the prediction request and response format, please refer to “Request a prediction to a running application”.

ML-Optimized Vmin Search Strategy

Vmin search aims to identify the lowest voltage at which a device operates reliably. The LinearSearch class iteratively tests each voltage point to find where the device transitions from pass to fail to identify the voltage threshold.

Each device has different process characteristics, so each device has a different Vmin. ML learns these differences and makes predictions specific to each wafer.

  1. The Challenge: Without any starting point, the Test Program must search from high voltage downward to find Vmin. This requires many test points, especially when Vmin varies significantly between wafers, making the total test time long.

  2. How ML Helps: The ML model predicts the approximate Vmin value based on each wafer’s process data. The Test Program can then start the search near this predicted Vmin, avoiding the need to search from high voltage. This dramatically reduces the number of test points needed.

Handling Prediction Uncertainty with Fallback Mechanism

In some situations, the ML prediction may not match the actual device characteristics. To ensure the test always finds the correct Vmin, the Test Program includes a fallback mechanism that automatically switches to a full-range search if the ML-optimized search does not find a PASS voltage. The fallback mechanism works as follows:

  1. Execute ML-optimized search: Use the predicted Vmin as the starting point with fine step size in a narrow voltage range.

  2. Fallback to full-range search if needed: If no PASS voltage is found, automatically search the full range with a larger step size to quickly find where PASS voltages exist.

This fallback mechanism ensures reliability. In most cases, accurate predictions enable the ML-optimized search to find Vmin quickly. When predictions are less accurate, the fallback guarantees correct Vmin detection. Either way, the process remains safe and typically faster than a traditional search without ML.

Running the Example#

You can follow the steps below to deploy and run this example.

In this example, we use Unified Server as the image repository. Please refer to “Use Unified Server as a Container Registry”. The following steps are required:

  • Configure the hosts for the Host Controller

  • Get the docker certificates from the Unified Server

  • Configure the Project and Account in Harbor

  • Configure Edge Server

Build the Docker image:

cd ~
curl http://10.44.5.139/docker/python_3.10.12-slim.tar -O
sudo docker load -i python_3.10.12-slim.tar
cd ~/apps/application-vmin-v3.1.0/autogluon-vmin-tpi-app/
sudo docker build ./ --tag unifiedserver.local/example-project/autogluon-vmin-tpi-app:latest

Push the Docker image to the Unified Server:

sudo docker push unifiedserver.local/example-project/autogluon-vmin-tpi-app:latest

Configure the Nexus for the ag-app container deployment:

gedit /opt/acs/nexus/conf/images.json

{
    "selector": {
        "device_name": "demo RTDI"
    },
    "edge": {
        "address": "<Edge IP>",
        "registry": {
            "address": "unifiedserver.local",
            "user": "robot$example_account",
            "password": "<Password>"
        },
        "containers": [
            {
                "name": "autogluon-vmin-tpi-app",
                "image": "example-project/autogluon-vmin-tpi-app:latest",
                "environment" : {
                    "ONEAPI_DEBUG": "3",
                    "ONEAPI_CONTROL_ZMQ_IP": "<Host Controller IP>"
                }
            }
        ]
    }
}

gedit /opt/acs/nexus/conf/acs_nexus.ini

[Auto_Deploy]
Enabled=false
...
[GUI]
Auto_Popup=true

To apply the modified configuration, restart Nexus:

sudo systemctl restart acs_nexus

Run the Test Program

cd ~/apps/application-vmin-v3.1.0/
sh start_smt8.sh

For instructions on how to run the Test Program, please refer to “DPAT demo application on RTDI with SmarTest 8” -> “Run the SmarTest Test Program”.

You can view the inference results and search optimization in the console log. The following example shows two devices: one where the ML prediction is accurate and optimizes the search, and another where the prediction differs and triggers the fallback mechanism:

Device 1: ML prediction optimizes search

{"post":{"type":"start_inference","features":{"acs_lot":"acs_lot_001","acs_wafer":16,"acs_ecid_x":3,"acs_ecid_y":4,"ecid_start":"_RARE_","ecid_end":"10/26/2024 21:15","ecid_time":66506.7,"bin":982,"final_bin_txt":"final_bin_txt_002","ecid_lot_id":"ecid_lot_id_001","acs_tester_names":"acs_tester_names_001","acs_last_test_suite":"acs_last_test_suite_018","ecid_parametric_1":1888.513983,"ecid_parametric_2":2143.343698,"test_suite_name":"test_suite_name_089","x_spec":"x_spec_002","FBVDDQ":1.35,"VDD0":0.8,"VDD1":0.8,"VDD2":0.8,"VDD3":0.8,"VDDMS":0.8,"vMin":0.541,"ECID":"ECID_w16_x3_y4"}}}
Real vmin value: 0.541
ML predict value: 0.5410701036453247
Search range: start=0.556, end=0.000, step=0.005
Voltage 0.556V -> PASS
Voltage 0.551V -> PASS
Voltage 0.546V -> PASS
Voltage 0.541V -> PASS
Voltage 0.536V -> FAIL
LinearSearch vmin value: 0.541

ML prediction (0.541V) matches the actual vMin (0.541V) perfectly. The search starts near the prediction and finds the result in just 5 steps, compared to 10+ steps with a standard search from 1.0V.

Device 2: Fallback mechanism when prediction differs

{"post":{"type":"start_inference","features":{"acs_lot":"acs_lot_004","acs_wafer":1,"acs_ecid_x":1,"acs_ecid_y":1,"ecid_start":"12/17/2024 22:24","ecid_end":"12/17/2024 22:33","ecid_time":555577,"bin":1,"final_bin_txt":"final_bin_txt_001","ecid_lot_id":"ecid_lot_id_002","acs_tester_names":"acs_tester_names_001","acs_last_test_suite":"acs_last_test_suite_002","ecid_parametric_1":1585.520839,"ecid_parametric_2":2122.811813,"test_suite_name":"test_suite_name_200","x_spec":"x_spec_005","FBVDDQ":1.35,"VDD0":0.8,"VDD1":0.8,"VDD2":0.8,"VDD3":0.8,"VDDMS":0.8,"vMin":0.595,"ECID":"ECID_w1_x1_y1"}}}
Real vmin value: 0.595
ML predict value: 0.5783701539039612
Search range: start=0.593, end=0.000, step=0.005
Voltage 0.593V -> FAIL
No PASS found, fallback to default range...
Search range: start=1.000, end=0.000, step=0.050
Voltage 1.000V -> PASS
Voltage 0.950V -> PASS
Voltage 0.900V -> PASS
Voltage 0.850V -> PASS
Voltage 0.800V -> PASS
Voltage 0.750V -> PASS
Voltage 0.700V -> PASS
Voltage 0.650V -> PASS
Voltage 0.600V -> PASS
Voltage 0.550V -> FAIL
LinearSearch vmin value: 0.6

The ML prediction (0.578V) differs from the actual vMin (0.595V). The initial search finds no PASS near the prediction, triggering an automatic fallback to the default full-range search (1.0V to 0.0V) with a coarse 0.05V step to locate the passing region, then continues with fine-tuning.

On this page