Inspection and Process Record Audit for Semiconductor Packaging and Testing: Workflow Orchestration

Semiconductor packaging and testing inspection and process record audit involves data from wafer test maps, MES systems, bonders and molding equipment

What Data Looks Like for This Category

Semiconductor packaging and testing inspection and process record audit involves data from wafer test maps, MES systems, bonders and molding equipment logs, ATE tester data, X-ray/SAM test results, and customer specifications. Data updates occur per production batch, per individual chip test, with daily updates. Daily associated documents include packaging process cards, bonding and molding parameter sheets, incoming wafer maps, test program version files, yield reports, and failure analysis reports. Fields cover process parameters and test results such as test bin distribution, bond pull strength values, molding thickness, and more.

What Constraints These Characteristics Impose on Workflow Orchestration

Multi-source data access requires configuring multiple tool nodes in the workflow to pull production and test data from different sources separately. Use variables to uniformly manage dynamic parameters linked to batches, preventing parameter confusion across batches. Frequently updated production data requires workflow trigger nodes to bind events for each batch or individual chip test, triggering processes as required. Variations across multiple document types and fields require adding a parameter mapping node to the workflow, standardizing log fields from different devices into a unified format needed for audits. High-time-consuming batch alignment steps should include a pre-check node in the workflow to automatically match incoming wafer map information with physical batch details, cutting down manual verification costs.

Configuration Settings

Configuration ItemRecommended SettingRationale
variablesBind batch ID, test program version, incoming wafer map IDUniformly manage dynamic parameters associated with batches to avoid parameter conflicts, and align with the variable management logic of FastGPT v4.17.0
Node trigger rulesBind device data reporting events corresponding to nodeIdEnsure audit processes only start after testing is complete, reducing invalid executions
Variable initial valuesPreset as the yield benchmark value for the current batch, support runtime updatesAdapt to frequently updated production data, resolve issues where variables cannot be synchronized in real time
Failure retry count3 times, 10-second intervalAddress temporary network or interface fluctuations when pulling device logs
Parameter mapping rulesMap bin codes from ATE testers to failure classification fieldsStandardize the format of multi-source device data, unify audit standards
Node timeout threshold15 seconds, calibrated based on actual testingAdapt to response times for device data pulls

Three Common Mistakes

  • Tool calls directly return errors with missing parameter prompts after the workflow initiates a query. The cause is that dependent parameters for the corresponding node are not configured in variables, causing the tool call to fail to obtain the test program version associated with the batch.
  • Global variables cannot be updated or initial values do not take effect. The cause is that variables are not configured for runtime update mode, only fixed initial values are preset, and dynamic data from production batches is not bound.
  • Audit results cannot match incoming wafer map information. The cause is that no parameter mapping rules are configured, and batch numbers in device logs are not associated and matched with incoming wafer map IDs.

How to Confirm Proper Configuration

  • Trigger a simulated production event for a batch, check whether the workflow automatically starts the audit node.
  • View parameter values in variables, confirm whether they update synchronously with simulated batch information.
  • Call a tool node to pull ATE tester data, check whether the parameter mapping rule correctly converts bin codes into failure classifications.
  • Simulate a tool call failure scenario, confirm whether the preset failure retry mechanism is triggered.

The values provided are common starting points and should be measured against the reader's own samples.