An ATE test program automatic generation method and system based on a radio frequency knowledge graph

Abstract

The application discloses an ATE test program automatic generation method and system based on a radio frequency knowledge graph, relates to the technical field of semiconductor testing, solves the problems of difficult structured knowledge extraction of a radio frequency test specification book, a semantic gap between a radio frequency test knowledge graph and ATE program code, and missing automatic constraint solving of multiple ATE platform hardware resources and test requirements, and the method comprises the following steps: structured knowledge extraction and ontology modeling are performed on an unstructured chip specification book by constructing a radio frequency field special natural language processing model, a reasoning radio frequency test knowledge graph containing test parameters, instrument capabilities and ATE platform characteristics is formed, and based on a test intention reasoning engine and a hardware resource constraint satisfaction solving mechanism, end-to-end automatic generation from "natural language test requirements" to "conflict-free executable test programs of multiple ATE platforms such as Advantest, Chroma and NI" is realized.

Description

Technical Field

[0001] This application relates to the field of semiconductor testing technology, and in particular to an automated method and system for generating ATE test programs based on radio frequency knowledge graphs. Background Technology

[0002] Currently, the generation of ATE test programs mainly relies on manual methods, and the typical process is as follows: Test engineers read the chip datasheet and manually extract RF test parameters (such as operating frequency band, output power, EVM, ACPR, noise figure, etc.) and their test conditions (temperature, voltage, signal source configuration, etc.); based on personal experience, they translate the test requirements into test sequences for a specific ATE platform and write the code using native ATE programming languages ​​(such as Advantest's Java, Chroma's C++ test program framework, NI's LabVIEW / TestStand, etc.); they manually configure test instrument resources (signal source, spectrum analyzer, power meter, etc.) to match and schedule hardware resources with test requirements; they debug, verify, and optimize on the ATE platform to finally generate an executable test program.

[0003] The existing technology has the following drawbacks:

[0004] a. The Challenge of Extracting Structured Knowledge from RF Test Specifications: Existing chip datasheets are unstructured PDF documents containing numerous tables, charts, and text descriptions. RF parameters (such as operating frequency band, output power, EVM, ACPR, noise figure, etc.) and their test conditions (temperature, voltage, signal source configuration) are scattered heterogeneously throughout the document. Currently, there is a lack of automated methods to automatically convert this unstructured, heterogeneous information into structured test requirements that can be called by ATE programs. Manual extraction is not only inefficient but also prone to missing key parameters or misinterpreting test conditions, leading to incomplete coverage or incorrect test condition configuration in subsequent test programs.

[0005] b. Semantic gap between RF test knowledge graph and ATE program code: Even if test parameters are extracted manually, existing technology still cannot meet test requirements with clear physical and instrument operation semantics, such as "measuring the P1dB compression point of PA, frequency 2.4GHz, input power -20dBm step 0.5dB". This semantic gap leads to long test program development cycle, high dependence on personnel experience and poor code consistency.

[0006] c. Lack of automated constraint resolution between hardware resources and test requirements on multiple ATE platforms: In RF testing, there are complex matching relationships between hardware constraints such as the power capacity of high-power channels, the frequency range and phase noise performance of signal sources, and the dynamic range of spectrum analyzers, and test requirements. For example, testing the P1dB compression point of a high-power PA requires ensuring that the power range of the power meter and signal source covers the test requirements while avoiding instrument damage; testing the noise figure of a low-noise amplifier requires the signal source to have extremely low phase noise. In existing technologies, the checking and resource scheduling of these constraints rely entirely on manual planning, which easily leads to problems such as instrument resource conflicts (e.g., multiple test items competing for the same signal source) and hardware capability overruns (e.g., requiring the signal source output to exceed its frequency range). The lack of automated conflict detection and resource scheduling methods results in a high failure rate and low resource utilization of test programs on ATE platforms. Summary of the Invention

[0007] The purpose of this application is to overcome the difficulties in extracting structured knowledge from RF test specifications, the semantic gap between RF test knowledge graphs and ATE program code, and the lack of automatic constraint solving for hardware resources and test requirements of multiple ATE platforms in the existing technology, and to provide an automated generation method and system for ATE test programs based on RF knowledge graphs.

[0008] Firstly, a method for automatically generating ATE test programs based on radio frequency knowledge graphs is provided, including:

[0009] Obtain the RF chip specification document and use a pre-trained RF-specific NLP parsing model to parse it to obtain structured data;

[0010] A reasonable RF test knowledge graph is constructed based on the structured data;

[0011] Based on the aforementioned RF test knowledge graph, test intent is understood and hardware resource constraints are solved to generate an optimized test execution plan;

[0012] The test execution plan is then converted into executable test program code for a specific ATE platform.

[0013] In some possible implementations, the RF chip datasheet is obtained and parsed to obtain structured data, including:

[0014] The PDF parsing engine is used to analyze the layout of PDF format RF chip datasheets and to identify text blocks, table areas, and chart areas.

[0015] A dedicated NLP parsing model for the radio frequency (RF) field is constructed and trained. The trained RF-specific NLP parsing model is then used to perform entity recognition and relation extraction on RF chip specification documents. The entities include test parameter entities, physical quantity entities, device port entities, and test condition entities.

[0016] The identified table regions are extracted in a structured manner to form triples: parameter, condition, and constraint value.

[0017] In some possible implementations, a reasonable RF test knowledge graph is constructed based on the structured data, including:

[0018] An ontology model for the field of radio frequency testing is constructed to define entity types, entity attributes, and entity relationships in the knowledge graph. The entity types of the ontology model include: test requirements, device under test, test instruments, test platforms, test methods, and test plans.

[0019] The structured data is imported into a graph database to construct an RF test knowledge graph, wherein the structured data includes RF test requirements and RF domain knowledge.

[0020] In a further implementation, constructing a reasonable RF test knowledge graph based on the structured data also includes:

[0021] The RF test knowledge graph is visualized, and the correctness of the entities and relationships in the RF test knowledge graph is manually verified and corrected.

[0022] In some possible implementations, test requirements are understood and hardware resource constraints are solved based on the aforementioned RF test knowledge graph to generate an optimized test execution plan, including:

[0023] The NLP parsing layer is used to parse the test requirements in natural language input by the user into a formalized test intent representation;

[0024] The test intent representation is subjected to test target identification, port and resource configuration extraction, and test condition structuring, and dependency reasoning is performed based on the RF test knowledge graph;

[0025] Based on the resource_constraints attribute of the ATE platform and the compatible_with instrument compatibility relationship, the optimal hardware allocation scheme is generated.

[0026] Based on the dependencies obtained through reasoning, the test requirements are topologically sorted to generate a linearized test sequence. Timing and triggering conditions are added to each test step in the test sequence to obtain a test execution plan.

[0027] The test execution plan is logically complete. If the check fails, a calibration test or alarm is automatically inserted.

[0028] In a further implementation, the logical completeness check includes checking for circular dependencies, resource deadlocks, or missing calibration steps.

[0029] In some possible implementations, the test execution plan is transformed into executable test program code specific to the ATE platform, including:

[0030] Select the corresponding code generation rules and template library based on the ATEPlatform type specified by the user;

[0031] The instrument operations in the test execution plan are converted into API calls supported by a specific ATE platform;

[0032] Generate a loop structure based on the scan range in the test conditions of the test execution plan, and insert the corresponding calibration code;

[0033] Duplicate instrument configuration instructions are detected and removed. If the test execution plan includes multi-site testing, parallel loop or asynchronous task code is automatically generated, exception handling is added for critical measurement steps, and a complete project file is generated. The project file includes the main test program file, calibration module file, instrument configuration file, and log and report callback functions.

[0034] Secondly, an automated generation system for ATE test procedures based on radio frequency knowledge graphs is provided, including:

[0035] The file acquisition module is used to acquire RF chip specification documents and parse them using a pre-trained RF-specific NLP parsing model to obtain structured data.

[0036] The graph construction module is used to construct a reasonable radio frequency test knowledge graph based on the structured data;

[0037] The plan generation module is used to understand test intent and solve hardware resource constraints based on the RF test knowledge graph in order to generate an optimized test execution plan;

[0038] The code generation module is used to convert the test execution plan into executable test program code for a specific ATE platform.

[0039] Thirdly, a computer-readable storage medium is provided that stores program code for execution by a device, the program code including steps for performing a method as described in any of the implementations of the first aspect above.

[0040] Fourthly, an electronic device is provided, the electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as described in any of the implementations of the first aspect above.

[0041] This application has the following beneficial effects:

[0042] 1. Solve the challenge of extracting structured knowledge from RF test specifications, significantly improving information extraction efficiency and accuracy: Through an RF-specific NLP parsing layer, unstructured specifications are automatically parsed using a dedicated RF NLP parsing model, reducing information extraction time from days to minutes. By constructing an RF domain ontology to guide entity recognition and relation extraction, the extraction accuracy is significantly improved compared to general NLP models.

[0043] 2. Reducing the semantic gap between the RF test knowledge graph and ATE program code to achieve automatic test program generation: This application constructs an RF test knowledge graph to formally represent test parameters, instrument capabilities, and ATE platform characteristics, eliminating the semantic gap between natural language requirements and machine-executable code. Through a test intent inference engine and an ATE code generator, it achieves automatic mapping from semantic requirements such as "measuring the P1dB compression point of the PA, frequency 2.4GHz, input power -20dBm step 0.5dB" to executable code on platforms such as Advantest / Chroma / NI.

[0044] 3. To achieve automatic constraint solving of hardware resources and testing requirements of multiple ATE platforms, reducing resource conflict rate and debugging failure rate: This application models instrument capability constraints and ATE platform resource constraints as constraint satisfaction problems (CSP), and uses a constraint solver for automatic solving and conflict detection. Attached Figure Description

[0045] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0046] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a flowchart of the automated generation method for ATE test programs based on radio frequency knowledge graphs according to Embodiment 1 of this application;

[0048] Figure 2 This is a structural block diagram of the ATE test procedure automated generation system based on radio frequency knowledge graph according to Embodiment 2 of this application;

[0049] Figure 3 This is a schematic diagram of the internal structure of the electronic device according to Embodiment 4 of this application.

[0050] Figure label:

[0051] 100. File Acquisition Module; 200. Map Construction Module; 300. Plan Generation Module; 400. Code Generation Module. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] Example 1

[0054] like Figure 1 As shown, Embodiment 1 of this application relates to an automated generation method for ATE test programs based on radio frequency knowledge graphs, comprising:

[0055] S100: Obtain the RF chip specification document and parse it using a pre-trained RF-specific NLP parsing model to obtain structured data.

[0056] In this step, the unstructured RF chip datasheet (PDF format) is automatically parsed into structured RF test requirements. A PDF parsing engine is used to analyze the layout of the RF chip datasheet, identifying text blocks, tables, and chart areas. Specifically, the steps include:

[0057] S101, PDF layout analysis and region recognition:

[0058] The layout of the RF chip datasheet is analyzed using a PDF parsing engine (such as one based on PyMuPDF or PDFMiner), identifying text blocks, table areas, and chart areas. Specifically, this includes:

[0059] Text block recognition: By analyzing font, font size, and coordinate position information in the PDF document stream, paragraph text, heading text, and list text are identified. For RF chip datasheets, the focus is on identifying text paragraphs containing parameter indicators (such as gain, noise figure, P1dB, IP3, S11, etc.).

[0060] Table Region Recognition: Based on line detection and cell merging algorithms, this function identifies parameter tables in RF chip datasheets. Typical tables in RF chip datasheets include Electrical Characteristics and Absolute Maximum Ratings.

[0061] Chart Region Recognition: The system uses image detection algorithms to identify typical curves (such as gain vs. frequency curves, output power vs. input power curves, S-parameter curves, etc.) in the RF chip datasheet and extracts the chart titles and axis labels.

[0062] S102, Named Entity Recognition in the Radio Frequency Domain:

[0063] A dedicated NLP parsing model for the radio frequency (RF) domain is constructed and trained (i.e., an RF-domain adaptive pre-trained language model (RF-LLM), based on the existing large language model LLM, fine-tuned using RF domain data, to enable the RF-domain dedicated NLP parsing model to perform entity recognition and relation extraction on the content of RF chip specification documents). Named entity recognition and relation extraction are performed on the RF chip specification documents. Named entities include:

[0064] Test parameters include entities such as "P1dB" (1dB compression point), "IP3" (third-order intermodulation point), "S11" (input return loss), "S21" (forward transmission coefficient), "NF" (noise figure), "EVM" (error vector amplitude), and "ACLR" (adjacent channel leakage ratio).

[0065] Physical quantities: such as frequency values ​​(2.4GHz, 5.8GHz), power values ​​(-20dBm, 0dBm, +20dBm), voltage values ​​(3.3V, 5V), temperature values ​​(-40℃, +25℃, +85℃), etc.

[0066] Device port entities: such as "RF_IN" (RF input port), "RF_OUT" (RF output port), "VDD" (power port), "GND" (ground port), etc.

[0067] Test conditions include entities such as "input power starting from -20dBm, in 0.5dB increments", "frequency range from 2.4GHz to 2.5GHz", and "temperature 25℃".

[0068] S103, Structured extraction of parameter tables:

[0069] The identified table regions are structured and extracted to form "parameter-condition-constraint value" triples. Specific steps include:

[0070] Header Recognition: Identifies column headings in the table, such as "Parameter," "Symbol," "TestConditions," "Min," "Typ," "Max," and "Unit." Cell Content Extraction: Extracts the text content of each cell and establishes a correspondence between it and the table header.

[0071] S200. Based on the structured data, construct a reasonable RF test knowledge graph containing test parameters, instrument capabilities, and ATE platform characteristics to form a formal knowledge representation of test requirements, instrument capabilities, and ATE platform characteristics. This specifically includes the following steps:

[0072] S201, Radio Frequency Test Knowledge Graph Ontology Modeling:

[0073] An ontology model for the RF testing domain is constructed, defining entity types, entity attributes, and entity relationships in the RF testing knowledge graph. The ontology model includes the following core entity types:

[0074] TestRequirement: Represents the test requirements obtained from the RF chip datasheet. Attributes include: test_id (test identifier), test_type (test type, such as parameter test, functional test, reliability test), target_parameter (target parameter), frequency_range (frequency range), power_range (power range), temperature_range (temperature range), and spec_limits (specification limits).

[0075] DUT (Device Under Test): Represents the RF chip under test. Attributes include: device_type (device type, such as power amplifier PA, low noise amplifier LNA, mixer), port_count (number of ports), port_configuration (port configuration, such as single-ended / differential), and package_type (package type).

[0076] TestInstrument: Represents the instrument resources required for RF testing. Attributes include: instrument_type (instrument type, such as Vector Network Analyzer (VNA), Spectrum Analyzer (SA), Signal Generator (SG), Power Meter (PM), frequency_range, power_range, port_count, measurement_accuracy, and interface_type (interface type, such as GPIB, LAN, USB).

[0077] ATEPlatform (ATE Platform): Represents the automated test equipment platform. Attributes include: platform_type (platform type, such as Teradyne UltraFLEX, Advantest V93000, NI PXI), programming_language (programming language, such as IG-XL / Visual Basic, SmarTest / C++, LabVIEW / C), max_instrument_slots (maximum number of instrument slots), supported_instruments (list of supported instruments), and resource_constraints (resource constraints).

[0078] TestMethod: Indicates the specific methodology of RF testing. Attributes include: method_name (method name, such as "P1dB Power Sweep", "IP3 Two-Tone Test", "S-Parameter Measurement"), required_instruments (list of required instruments), test_procedure (sequence of test steps), and calibration_requirements (calibration requirements).

[0079] TestPlan: Represents the generated test execution plan, with attributes including: plan_id (plan identifier), test_sequence (test sequence), instrument_allocation (instrument allocation plan), and estimated_test_time (estimated test time).

[0080] Entity relationship definition:

[0081] requires (TestRequirement → TestInstrument): What instrument resources are needed for the test requirements;

[0082] `applies_to(TestMethod → ​​TestRequirement)`: This indicates the test requirement to which the test method applies.

[0083] compatible_with (TestInstrument → ATEPlatform): The compatibility relationship between the instrument and the ATE platform;

[0084] has_port (DUT → Port): What type of port the device under test has;

[0085] measured_by(TestRequirement → TestMethod): The test method used to implement the test requirement;

[0086] allocated_to (TestInstrument → ATEPlatform): The instrument is allocated to the ATE platform;

[0087] depends_on(TestRequirement → TestRequirement): The dependency relationship between test requirements (e.g., P1dB test depends on calibration data from gain test).

[0088] S202, Importing RF Test Knowledge Graph Data:

[0089] Structured RF test requirements and domain knowledge are imported into a graph database to construct an RF test knowledge graph. The specific import process includes:

[0090] Entity node creation: Create entity nodes for each test requirement, device under test, test instrument, ATE platform, and test method. The node attributes correspond to the attribute definitions in the ontology model.

[0091] Relationship edge creation: Based on the defined relationships between entities, create directed edges and label the relationship types. For example, for the P1dB testing requirement, create a `requires` edge pointing to the vector network analyzer and the signal generator, and create a `measured_by` edge pointing to the "P1dBPower Sweep" test method.

[0092] To ensure the correctness of entities and relationships in the RF test knowledge graph, the document also includes RF test knowledge graph visualization and verification: the structure of the RF test knowledge graph is displayed using graph visualization tools, and the correctness of entities and relationships is manually verified.

[0093] In this embodiment, considering the unstructured nature and highly specialized characteristics of RF chip specifications, an adaptive pre-trained language model (RF-LLM) for the RF domain is constructed to achieve high-precision named entity recognition and relation extraction. Furthermore, an ontology for the RF testing domain is defined for the first time, formally modeling test items, RF parameters, test conditions, instrument types, ATE platforms, and their complex relationships to construct a reasonable RF testing knowledge graph, thus solving the problem of automatically converting unstructured RF chip specifications into structured test requirements.

[0094] Secondly, a formalized mapping relationship between RF test parameters and instrument capability constraints was constructed in the RF test knowledge graph, making the implicit knowledge of "what instrument capabilities are required for test needs" explicit and formal, forming a knowledge base that can be automatically reasoned. This is the core foundation for realizing automated constraint solving and code generation.

[0095] S300. Based on the RF test knowledge graph, perform test intent understanding and hardware resource constraint solving to generate an optimized test execution plan.

[0096] In this step, the test requirements in natural language (e.g., "Measure the P1dB compression point of the PA in the 2.4GHz band, with input power starting from -20dBm in 0.5dB steps") are parsed into a formalized test intent representation (including test objectives, device under test (DUT) ports, test parameters, test conditions, etc.). Specifically, this includes the following steps:

[0097] S301. Test Intent Analysis and Formal Representation:

[0098] The process for processing structured test requirements (such as parameter-condition-constraint triples) or user natural language commands from the NLP parsing layer is as follows:

[0099] 1. Test Target Identification: Analyze the core test targets in the requirements, such as "measuring P1dB", "verifying IP3", and "scanning S-parameters". Match the most suitable test method using the TestMethod entity in the RF test knowledge graph.

[0100] 2. Port and resource configuration extraction: Using the relationship between requires and has_port in the RF test knowledge graph, identify DUT ports (such as RF_IN, RF_OUT) and required instrument types (such as VNA, SG), and infer the minimum set of instruments required.

[0101] 3. Structuring Test Conditions: Converting test conditions (frequency, power, temperature, etc.) into test vectors in a unified format. For example:

[0102] Frequency range = [2.4GHz, 2.5GHz], step = 1MHz → Generate scan point list.

[0103] 4. Dependency Reasoning: Utilizing the depends_on relationships in the RF test knowledge graph, preconditions for testing are automatically identified. For example, P1dB testing requires prior small-signal gain testing to determine the linear region.

[0104] S302, Solving hardware resource constraints:

[0105] Based on the resource_constraints attribute of the ATE platform and the compatible_with instrument compatibility relationship, the optimal hardware allocation scheme is generated. The process is as follows:

[0106] 1. Instrument capability matching: Compare the frequency / power range in the test requirements with the frequency_range and power_range attributes of TestInstrument in the RF test knowledge graph, and filter out instrument instances that meet the requirements.

[0107] 2. ATE slot and channel allocation: Based on the ATE platform's max_instrument_slots and the occupied resources, use a knapsack algorithm or greedy strategy to allocate instruments to physical slots and minimize signal routing length.

[0108] 3. Concurrent Test Optimization: If there are no dependencies between test requirements and the ATE platform supports multi-site parallel testing, a parallel test plan will be generated. For example, simultaneously measuring the S-parameters of four DUTs.

[0109] S303. Test Sequence Generation and Verification:

[0110] 1. Test Step Sequencing: The test requirements are topologically ordered according to the Dependency Graph (DAG) to generate a linearized test sequence. For example: Power-on → Small-signal gain → P1dB → Power-off.

[0111] 2. Timing and Trigger Condition Generation: Add a wait time (WAIT), trigger event (such as "when the temperature stabilizes at 25℃±1℃"), and synchronization conditions to each step.

[0112] 3. Logical completeness check: Check for circular dependencies, resource deadlocks, or missing calibration steps. If a problem is found, automatically insert a calibration test or issue an alarm.

[0113] In this embodiment, by formally modeling the instrument capability constraints, hardware resource constraints, and test requirements in RF testing, and combining RF test knowledge graph reasoning with constraint satisfaction problem (CSP) solving, the automatic mapping from test intent to conflict-free instrument configuration and test sequence is realized, solving the problem of automatic constraint solving between hardware resources and test requirements of multiple ATE platforms.

[0114] S400: Convert the test execution plan generated in step S300 into executable test program code for a specific ATE platform. This includes the following steps:

[0115] S401, Platform Adaptation and Template Selection:

[0116] Based on the user-specified ATEPlatform type (e.g., "NI PXI"), the corresponding code generation rules and template library are loaded. Multiple platform templates are predefined for each test method (e.g., P1dB_Power_Sweep). For example:

[0117] a. NI PXI → LabVIEW VI clips or C# code;

[0118] b.Teradyne UltraFLEX → IG-XL Basic macro;

[0119] c.Advantest V93000 → SmarTest Java function.

[0120] S402, Code Generation and Parameter Injection:

[0121] 1. Instrument-Driven API Mapping: Converts instrument operations (such as setPower and measurePower) in the test execution plan into platform-supported API calls. For example:

[0122] a. General representation: sg->setPower(-20dBm);

[0123] b.NI PXI C#: sigGen.OutputPower = -20;

[0124] c.V93000 Java: SG_SetPower(channel, -20);

[0125] 2. Loop and Conditional Structure Unfolding: Generate loop structures based on the scan range (such as power step) in the test conditions. For example, expand `while (inputPower <= STOP_POWER)` into a `for` or `while` loop.

[0126] 3. Calibration code insertion: If calibration_required=true in the plan, call the corresponding platform's calibration function (such as CalibratePowerMeter(port)) before the test cycle.

[0127] S403, Code Optimization and Packaging:

[0128] 1. Redundancy elimination: Detect and remove duplicate instrument configuration commands (such as setting the same frequency range multiple times).

[0129] 2. Parallelization Conversion: If the plan includes multi-site testing, automatically generate parallel loop or asynchronous task code. For example, convert a single-site for loop to Parallel.For.

[0130] 3. Exception handling injection: Add try-catch blocks and timeout checks to critical measurement steps to enhance test robustness.

[0131] 4. Final Packaging: Generates complete project files, including:

[0132] a. Main test program file (.cs, .cpp, .bas, etc.);

[0133] b. Calibration module file;

[0134] c. Instrument configuration files (.ini, .json);

[0135] d. Log and report callback functions.

[0136] For example, the following is the complete pseudocode of the final test program generated in this embodiment:

[0137] TEST_METHOD({{TEST_NAME}})

[0138] {

[0139] / / Instrument initialization

[0140] RfInstrument* vna = RfInstrument::getInstance("{{VNA_INSTRUMENT_ID}}");

[0141] RfInstrument* sg = RfInstrument::getInstance("{{SG_INSTRUMENT_ID}}");

[0142] / / DUT power-on initialization

[0143] powerUpDUT({{VDD_VOLTAGE}}, {{VDD_CURRENT_LIMIT}});

[0144] / / Instrument configuration

[0145] vna->setFrequencyRange({{START_FREQUENCY}}, {{STOP_FREQUENCY}},{{FREQUENCY_STEP}});

[0146] sg->setPowerRange({{START_POWER}}, {{STOP_POWER}}, {{POWER_STEP}});

[0147] / / Calibration

[0148] if ({{CALIBRATION_REQUIRED}}) {

[0149] calibratePower({{CALIBRATION_PORT}});

[0150] }

[0151] / / Power sweep measurement

[0152] double inputPower = {{START_POWER}};

[0153] double outputPower = 0.0;

[0154] double gain = 0.0;

[0155] double prevGain = 0.0;

[0156] bool p1dbFound = false;

[0157] while (inputPower <= {{STOP_POWER}} && !p1dbFound) {

[0158] sg->setPower(inputPower);

[0159] WAIT({{SETTLING_TIME}});

[0160] outputPower = vna->measurePower({{OUTPUT_PORT}});

[0161] gain = outputPower - inputPower;

[0162] if (prevGain > 0 && (prevGain - gain) >= {{GAIN_DROP_THRESHOLD}}) {

[0163] / / Find the P1dB compression point

[0164] results["P1dB"] = inputPower;

[0165] results["P1dB_Gain"] = gain;

[0166] p1dbFound = true;

[0167] }

[0168] prevGain = gain;

[0169] inputPower += {{POWER_STEP}};

[0170] }

[0171] / / Result determination

[0172] if (p1dbFound) {

[0173] if (results["P1dB"] >= {{SPEC_MIN}} && results["P1dB"] <= {{SPEC_MAX}}) {

[0174] testResult = PASS;

[0175] } else {

[0176] testResult = FAIL;

[0177] }

[0178] } else {

[0179] testResult = FAIL;

[0180] errorLog("P1dB compression point not found within powerrange");

[0181] }

[0182] / / Data Records

[0183] logTestData("{{TEST_NAME}}", results, testResult);

[0184] / / DUT power outage

[0185] powerDownDUT();

[0186] }

[0187] In this embodiment, a hybrid code generation strategy of "RF test knowledge graph + template filling + LLM generation" is adopted. The RF test knowledge graph is used to perform semantic constraint verification on the generated code to ensure that the instrument configuration parameters (such as frequency and power) do not exceed the instrument's capabilities. This achieves safe, efficient and automatic generation from RF test semantic requirements to executable code for multiple ATE platforms, bridging the semantic gap.

[0188] Example 2

[0189] like Figure 2 As shown, Embodiment 2 of this application relates to an automated ATE test procedure generation system based on radio frequency knowledge graph, comprising:

[0190] The file acquisition module 100 is used to acquire the RF chip specification document and parse it using a pre-trained RF-specific NLP parsing model to obtain structured data.

[0191] The graph construction module 200 is used to construct a reasonable radio frequency test knowledge graph based on the structured data;

[0192] The plan generation module 300 is used to perform test intent understanding and hardware resource constraint solving based on the radio frequency test knowledge graph in order to generate an optimized test execution plan.

[0193] The code generation module 400 is used to convert the test execution plan into executable test program code for a specific ATE platform.

[0194] It should be noted that other specific implementations of the ATE test program automated generation system based on radio frequency knowledge graph in this embodiment can be found in the specific implementations of the ATE test program automated generation method based on radio frequency knowledge graph described above. To avoid redundancy, they will not be repeated here.

[0195] Example 3

[0196] This application relates to a computer-readable storage medium in embodiment 3, which stores program code for execution by a device, the program code including steps for performing the method as described in any implementation of embodiment 1 of this application;

[0197] The computer-readable storage medium may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM); the computer-readable storage medium may store program code, and when the program stored in the computer-readable storage medium is executed by a processor, the processor is used to perform the steps of the method in any of the implementations of Embodiment 1 of this application.

[0198] Example 4

[0199] like Figure 3 As shown, an electronic device according to Embodiment 4 of this application includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the method in any of the implementations in Embodiment 1 of this application.

[0200] The processor can be a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), graphics processing unit (GPU), or one or more integrated circuits, used to execute related programs to implement the method in any of the implementations of Embodiment 1 of this application.

[0201] The processor can also be an integrated circuit electronic device with signal processing capabilities. In implementation, each step of the method in any of the implementations of Embodiment 1 of this application can be completed by the integrated logic circuitry in the processor's hardware or by software instructions.

[0202] The aforementioned processor can also be a general-purpose processor, digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the functions required by the units included in the data processing apparatus of the embodiments of this application, or executes the methods in any implementation of Embodiment 1 of this application.

[0203] The above are merely preferred embodiments of this application; however, the scope of protection of this application is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in this application, based on the technical solution and its improved concept, should be covered within the scope of protection of this application.

Claims

1. A method for automatically generating ATE test programs based on radio frequency knowledge graphs, characterized in that, include: Obtain the RF chip specification document and use a pre-trained RF-specific NLP parsing model to parse it to obtain structured data; A reasonable RF test knowledge graph is constructed based on the structured data; Based on the aforementioned RF test knowledge graph, test intent is understood and hardware resource constraints are solved to generate an optimized test execution plan; The test execution plan is then converted into executable test program code for a specific ATE platform.

2. The automated generation method for ATE test programs based on radio frequency knowledge graphs according to claim 1, characterized in that, Obtain and parse the RF chip datasheet to obtain structured data, including: The PDF parsing engine is used to analyze the layout of PDF format RF chip datasheets and to identify text blocks, table areas, and chart areas. A dedicated NLP parsing model for the radio frequency (RF) field is constructed and trained. The trained RF-specific NLP parsing model is then used to perform entity recognition and relation extraction on RF chip specification documents. The entities include test parameter entities, physical quantity entities, device port entities, and test condition entities. The identified table regions are extracted in a structured manner to form triples: parameter, condition, and constraint value.

3. The automated generation method for ATE test programs based on radio frequency knowledge graphs according to claim 1, characterized in that, Based on the structured data, a reasonable RF test knowledge graph is constructed, including: An ontology model for the field of radio frequency testing is constructed to define entity types, entity attributes, and entity relationships in the knowledge graph. The entity types of the ontology model include: test requirements, device under test, test instruments, test platforms, test methods, and test plans. The structured data is imported into a graph database to construct an RF test knowledge graph, wherein the structured data includes RF test requirements and RF domain knowledge.

4. The automated generation method for ATE test programs based on radio frequency knowledge graphs according to claim 3, characterized in that, Constructing a reasonable RF test knowledge graph based on the structured data also includes: The RF test knowledge graph is visualized, and the correctness of the entities and relationships in the RF test knowledge graph is manually verified and corrected.

5. The automated generation method for ATE test programs based on radio frequency knowledge graphs according to claim 1, characterized in that, Based on the aforementioned RF test knowledge graph, test requirements are understood and hardware resource constraints are solved to generate an optimized test execution plan, including: The NLP parsing layer is used to parse the test requirements in natural language input by the user into a formalized representation of test intent; The test intent representation is subjected to test target identification, port and resource configuration extraction, and test condition structuring, and dependency reasoning is performed based on the RF test knowledge graph; Based on the resource_constraints attribute of the ATE platform and the compatible_with instrument compatibility relationship, the optimal hardware allocation scheme is generated. Based on the dependencies obtained through reasoning, the test requirements are topologically sorted to generate a linearized test sequence. Timing and triggering conditions are added to each test step in the test sequence to obtain a test execution plan. The test execution plan is logically complete. If the check fails, a calibration test or alarm is automatically inserted.

6. The automated generation method for ATE test programs based on radio frequency knowledge graphs according to claim 5, characterized in that, The logical completeness check includes checking for circular dependencies, resource deadlocks, or missing calibration steps.

7. The automated generation method for ATE test programs based on radio frequency knowledge graphs according to claim 1, characterized in that, The test execution plan is converted into executable test program code for a specific ATE platform, including: Select the corresponding code generation rules and template library based on the ATEPlatform type specified by the user; The instrument operations in the test execution plan are converted into API calls supported by a specific ATE platform; Generate a loop structure based on the scan range in the test conditions of the test execution plan, and insert the corresponding calibration code; Duplicate instrument configuration instructions are detected and removed. If the test execution plan includes multi-site testing, parallel loop or asynchronous task code is automatically generated, exception handling is added for critical measurement steps, and a complete project file is generated. The project file includes the main test program file, calibration module file, instrument configuration file, and log and report callback functions.

8. An automated generation system for ATE test procedures based on radio frequency knowledge graphs, characterized in that, include: The file acquisition module is used to acquire RF chip specification documents and parse them using a pre-trained RF-specific NLP parsing model to obtain structured data. The graph construction module is used to construct a reasonable radio frequency test knowledge graph based on the structured data; The plan generation module is used to understand test intent and solve hardware resource constraints based on the RF test knowledge graph in order to generate an optimized test execution plan; The code generation module is used to convert the test execution plan into executable test program code for a specific ATE platform.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code for execution by the device, the program code including steps for performing the method as described in any one of claims 1-7.

10. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as described in any one of claims 1-7.

Images