Test point generation method and device, electronic equipment and storage medium
By automating the processing of technical features in chip-related technical documents, comprehensive and standardized test point data is generated, solving the problem of low efficiency in manual test point extraction and improving the completeness and efficiency of chip verification.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI BIREN TECH CO LTD
- Filing Date
- 2026-02-09
- Publication Date
- 2026-05-29
Smart Images
Figure CN122113776A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of chip design and manufacturing technology, and in particular to a test point generation method, apparatus, electronic device and storage medium. Background Technology
[0002] High-performance computing chips, exemplified by graphics processing units (GPUs), integrate tens of billions of transistors, with numerous functional modules and intricate interactions. Before physical manufacturing, rigorous and meticulous pre-simulation verification is essential to identify and correct logical errors in the design. Verification completeness is a core metric for evaluating chip verification quality, aiming to ensure that every function, operating mode, and extreme boundary condition of the chip is fully tested. To achieve verification completeness, all functionalities and scenarios requiring verification coverage need to be identified and defined; this process is typically referred to as test point extraction.
[0003] The relevant technologies rely heavily on manual experience to extract test points, lack systematicity, are inefficient and prone to errors, and make it difficult to ensure the standardization and consistency of verification work.
[0004] Therefore, how to generate test point data efficiently and comprehensively, overcome the inefficiency and omissions of manual extraction, and improve the efficiency and quality of chip verification has become a technical problem that the industry urgently needs to solve. Summary of the Invention
[0005] This application provides a test point generation method, apparatus, electronic device, and storage medium to solve the technical problem of how to generate test point data efficiently and comprehensively, overcome the inefficiency and omissions of manual extraction, and improve the efficiency and quality of chip verification.
[0006] This application provides a test point generation method, including: Read technical documents related to the chip under test from memory; Identify the technical features in the technical documents and classify the technical features into corresponding technical dimensions based on preset feature classification rules; the technical dimensions include at least one of clock reset dimension, interface testing dimension, internal function dimension, chip performance dimension, and chip debugging dimension; Call the test point generation rules corresponding to each technical dimension, process the technical features under each technical dimension, and generate test point data under each technical dimension; Summarize the test point data under various technical dimensions and output the verification test point file of the chip under test.
[0007] In some embodiments, the technical documentation includes at least one of product requirements document, macrostructure specification document, register form, instruction set architecture document, and interface specification form.
[0008] In some embodiments, the test point generation rules corresponding to the clock reset dimension include at least one of the following: Generate test point data related to clock timing; Generate test point data related to reset timing; Generate test point data related to the timing of clock and reset during the power-on / off process.
[0009] In some embodiments, the test point generation rules corresponding to the interface testing dimension include at least one of the following: For advanced extensible interfaces, generate test point data related to typical signal values, signal boundary values, signal combinations, protocol testing, reverse voltage testing, and back-to-back testing; For the handshake mechanism interface, generate test point data related to typical values of accompanying signals, boundary values of accompanying signals, combinations of accompanying signals, protocol testing, reverse pressure testing, and back-to-back testing. For the credit mechanism interface, generate test point data related to credit value matching tests, incomplete request tests, and confirmation delay tests; Generate test point data related to the backpressure combinations of different interfaces that are logically related to the hardware; Generate timing-related test point data for different interface combinations.
[0010] In some embodiments, the test point generation rules corresponding to the internal functional dimensions include at least one of the following: For incomplete request functionality, generate test point data related to incomplete requests along the entire input-to-output chain; For the first-in-first-out queue unit, generate test point data related to empty reverse pressure read test, full reverse pressure write test and empty / full state change test; For the counter unit, generate test point data related to the maximum and minimum value tests; For the arbitrator unit, generate test point data related to concurrency priority testing and polling arbitration balance testing; For memory cells, generate test point data related to address traversal test, back-to-back read test, back-to-back write test, and back-to-back write-read test; For the credit mechanism, test point data related to the impact of credit depletion on different hardware logic is generated; Generate test point data related to data conflicts in write-after-read, read-after-write, and write-after-write scenarios.
[0011] In some embodiments, the test point generation rules corresponding to the chip performance dimension include at least one of the following: Generate test point data related to the path bandwidth; Generate test point data related to bandwidth in different access modes of the cache; Generate test point data related to path delay.
[0012] In some embodiments, the test point generation rules corresponding to the chip debugging dimension include: Generate test point data related to debugging bus access, interrupt mechanisms, or performance counters.
[0013] This application provides a test point generation device, comprising: The read module is used to read technical documents related to the chip under test from the memory; The identification module is used to identify the technical features in the technical document and classify the technical features into the corresponding technical dimensions based on preset feature classification rules; the technical dimensions include at least one of clock reset dimension, interface testing dimension, internal function dimension, chip performance dimension and chip debugging dimension; The processing module is used to call the test point generation rules corresponding to each technical dimension, process the technical features under each technical dimension, and generate test point data under each technical dimension. The output module is used to summarize the test point data under various technical dimensions and output the verification test point file of the chip under test.
[0014] This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the test point generation method described above.
[0015] This application provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the test point generation method described above.
[0016] The test point generation method, apparatus, electronic device, and storage medium provided in this application read technical documents related to the chip under test, identify technical features in the documents, classify the technical features into corresponding technical dimensions, process the technical features by calling test point generation rules, generate test point data, summarize the test point data under each technical dimension, and output the verification test point file of the chip under test. This transforms the previously manual, fragmented, and error-prone test point extraction process into an automated, systematic, and standardized data processing workflow. Through the decomposition of multiple technical dimensions, it ensures that the analysis of the chip design covers all aspects, achieving comprehensive generation of test point data. This greatly improves the completeness and efficiency of chip pre-simulation verification, reduces the risk of tape-out due to missing test points, and provides strong technical support for the design verification of complex chips. Attached Figure Description
[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0018] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a flowchart illustrating the test point generation method provided in this application.
[0020] Figure 2 This is a schematic diagram of the test point generation device provided in this application.
[0021] Figure 3 This is a schematic diagram of the structure of the electronic device provided in this application.
[0022] Figure label: 210: Reading module; 220: Recognition module; 230: Processing module; 240: Output module; 310: Processor; 320: Communication interface; 330: Memory; 340: Communication bus. Detailed Implementation
[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0024] It should be noted that the terms "first," "second," etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps, units, or modules is not necessarily limited to those explicitly listed, but may include other steps, units, or modules not explicitly listed or inherent to such processes, methods, products, or devices.
[0025] In order to address the shortcomings of related technologies, Figure 1 This is a flowchart illustrating the test point generation method provided in this application, as shown below. Figure 1 As shown, the method includes steps 110, 120, 130 and 140.
[0026] Step 110: Read the technical documents related to the chip under test from the memory.
[0027] Specifically, the test point generation method provided in this application is executed by a test point generation device or system. This device can be implemented in software, such as a test point generation program; or it can be a device that executes the test point generation method, such as a mobile terminal, tablet computer, desktop computer, or server.
[0028] The chip under test can refer to any integrated circuit design that requires functional verification, especially suitable for large-scale on-chip systems with complex structures, numerous functions, and heavy verification tasks, such as graphics processing units (GPUs), central processing units (CPUs), network processing units (NPUs), or artificial intelligence (AI) accelerator chips. In a specific embodiment, the method provided in the embodiments of this application can be applied to the pre-simulation verification of GPU chips.
[0029] Technical documentation refers to a collection of electronic documents describing various design details of a chip under test. These documents are the source and basis for chip design and the direct input for verification work. In a specific scenario of this application embodiment, these electronic documents can be stored in local storage (such as hard disks or solid-state drives) or remote network storage (such as servers or cloud storage), and can be in various formats, such as portable document formats, plain text, extensible markup language, Word documents, or markup language documents. The system automatically accesses and reads the contents of these electronic documents through a program interface and loads them into the computer's memory for subsequent processing.
[0030] Step 120: Identify the technical features in the technical documents and classify the technical features into the corresponding technical dimensions based on the preset feature classification rules; the technical dimensions include at least one of the following: clock reset dimension, interface testing dimension, internal function dimension, chip performance dimension, and chip debugging dimension.
[0031] Specifically, a technical feature refers to a valid information unit extracted from technical documents that can characterize a specific aspect of the chip's design (including but not limited to structure, function, performance indicators, timing relationships, operating modes, etc.). For example, in a document describing "This module contains a First In First Out (FIFO) queue with a depth of 64," the phrase "First In First Out (FIFO) queue with a depth of 64" is a technical feature.
[0032] The identification process can be implemented using various computer technologies. In one specific embodiment, it can be achieved using keyword matching. Technical features are located by scanning preset keywords (such as "clock," "bus," "queue," "bandwidth," etc.) and their context in the document. In another specific embodiment, it can be implemented using a natural language processing (NLP) model. NLP models are used to perform syntactic analysis and semantic understanding of sentences, thereby more intelligently extracting technical features describing functions, behaviors, or structures. In yet another specific embodiment, it can be implemented using document structure parsing. For documents with a fixed format (such as register forms), technical features are directly extracted by parsing their structured information such as tables and titles.
[0033] After identifying the technical features, they need to be categorized for subsequent targeted processing. The technical dimensions provided in this application include clock reset dimension, interface testing dimension, internal function dimension, chip performance dimension, and chip debugging dimension.
[0034] The clock reset dimension is used to summarize the technical characteristics related to the clock signal of the chip, such as clock generation and control, synchronous / asynchronous reset signal, and power-on / off timing.
[0035] Interface testing is used to summarize the technical characteristics of how a chip communicates and interacts with other external modules or systems, such as bus interfaces that follow specific protocols and simple handshake interfaces.
[0036] The internal functional dimension is used to summarize the technical characteristics related to the logical behavior and implementation mechanism of each functional unit inside the chip, such as storage unit, computing unit, arbitration unit, data path, etc.
[0037] Chip performance dimensions are used to summarize technical indicators related to chip processing efficiency and response time, such as bandwidth, latency, and throughput.
[0038] The chip debugging dimension is used to summarize the technical features related to auxiliary functions designed to facilitate debugging and performance monitoring for developers, such as debug buses, interrupt mechanisms, performance counters, etc.
[0039] The technical dimensions can also be added, removed, or adjusted according to actual needs. For example, a security dimension or a low-power dimension can be added.
[0040] Pre-defined feature classification rules refer to a series of logical judgment conditions that automatically map identified technical features to the aforementioned technical dimensions. For example, a classification rule could be: "If a technical feature contains the keyword 'AXI', then classify it into the interface testing dimension." These rules can be pre-configured and stored, and executed automatically by the program, thereby achieving automated and standardized classification of technical features.
[0041] Step 130: Call the test point generation rules corresponding to each technical dimension, process the technical features under each technical dimension, and generate test point data under each technical dimension.
[0042] Specifically, test point generation rules are predefined knowledge bases or template libraries, where each rule describes the angles from which to test a certain type of technical feature. These rules translate the experience of senior verification experts into machine-executable instructions. For example, for all technical features categorized into the interface testing dimension, a general generation rule can be applied: "Generate boundary value tests, abnormal protocol sequence tests, and backpressure combination tests for this interface."
[0043] Once a technical feature is categorized into a specific technical dimension, the system automatically invokes the test point generation rules associated with that dimension. The program then instantiates and generates specific test points based on these rules and the specific content of the technical feature.
[0044] Test point data is generated structured information. It is not just a simple text description, but usually one or more data records containing rich metadata. For example, a test point data can be a data structure or object containing the following fields: test point identifier, test point description, module to which it belongs, associated technical features, verification priority, a summary description of the required stimulus, expected results, etc.
[0045] Step 140: Summarize the test point data under each technical dimension and output the verification test point file of the chip to be tested.
[0046] Specifically, all test point data generated across all technical dimensions can be collected and integrated through methods such as deduplication, sorting, and format conversion. Finally, the system outputs a verification test point file. This file is the final product of the method described in this application embodiment and is a highly structured electronic document guiding subsequent verification work.
[0047] Verification testpoint files can take various forms to suit different downstream tools and workflows. In one specific embodiment, a verification testpoint file can be a human-readable document, such as a table or formatted document. In another specific embodiment, a verification testpoint file can be a machine-readable data file, such as a CSV, JSON, or XML file, which can be directly parsed and used by other scripts or tools (such as test case generators or coverage model generators) to achieve a higher level of automation. In yet another specific embodiment, a verification testpoint file can be a code snippet. For example, it can directly generate the basic framework code of a test sequence or functional coverage model that conforms to a specific verification methodology.
[0048] The test point generation method provided in this application reads technical documents related to the chip under test, identifies technical features in the documents, classifies the technical features into corresponding technical dimensions, processes the technical features by calling test point generation rules, generates test point data, summarizes the test point data under each technical dimension, and outputs the verification test point file of the chip under test. This transforms the previously manual, fragmented, and error-prone test point extraction process into an automated, systematic, and standardized data processing workflow. Through the decomposition of multiple technical dimensions, it ensures that the analysis of the chip design covers all aspects, achieving comprehensive generation of test point data. This greatly improves the completeness and efficiency of chip pre-simulation verification, reduces the risk of tape-out due to missing test points, and provides strong technical support for the design verification of complex chips.
[0049] It should be noted that each implementation method of this application can be freely combined, rearranged, or executed individually, and does not need to rely on or depend on a fixed execution order.
[0050] In some embodiments, technical documentation includes at least one of product requirements document, macrostructure specification document, register form, instruction set architecture document, and interface specification form.
[0051] Specifically, a Product Requirement Document (PRD) typically defines the functions, performance targets, and application scenarios that a chip needs to possess from the perspective of the market and users. In this embodiment, reading and parsing the PRD is mainly used to extract the highest-level functional technical features and performance indicator technical features. For example, the PRD may describe that "the chip needs to support video decoding at 60 frames per second at 4K resolution." The program can identify the core technical feature of "video decoding" and classify it into the "internal functional dimension"; at the same time, it can identify the performance target of "60 frames per second at 4K resolution" and classify it into the "chip performance dimension." This ensures that the generated test point data can directly respond to the most original product requirements.
[0052] The Macro-Architecture Specification (MAS) is a top-level design plan written based on the product requirements document, focusing more on technical implementation. It describes the overall chip architecture, the division of major functional modules, the connections between modules, and key data flows. Reading and parsing the MAS is primarily used to identify module-level and system-level technical features. For example, the MAS might describe that "the chip contains one A controller and one B controller, and the two controllers are connected via an AXI bus." The program can identify functional-level technical features such as "A controller" and "B controller," as well as the interface-level technical feature of "the two controllers are connected via an AXI bus." This information is crucial for subsequently generating test point data for inter-module interactions.
[0053] The register table (which can be an Excel or CSV file) defines in detail the addresses, bit fields, names, read / write attributes (read / write, read-only, write-only, etc.) of all programmable registers in the chip, as well as the functional description of each bit field. Registers are the primary interface for software to control hardware behavior. Reading and parsing the structured register table allows for efficient and accurate batch extraction of technical features related to configuration and status. For example, the program can automatically traverse the table, identifying each configurable bit field of each register as a technical feature and categorizing it into chip debugging or internal function dimensions based on its functional description.
[0054] The Instruction Set Architecture (ISA) document defines the format, opcode, and operands of all instructions that a processor can understand and execute. Reading and parsing the ISA document is primarily used to identify technical features related to computation and control flow. For example, a program can parse all arithmetic instructions, logical instructions, memory access instructions, and branch instructions, and categorize them into internal functional dimensions. This is crucial for verifying the processor core's instruction decoding and execution units.
[0055] Interface specification forms detail the input / output interface signal definitions of a chip or its internal modules, including signal names, bit widths, directions, and timing relationships between signals. This typically represents a specific implementation of a standard protocol or a detailed description of a custom interface. Reading and parsing the interface specification form is the most direct source for extracting the technical features required for interface testing. The program can identify the type of each interface, all signals, and their attributes, providing precise input for subsequent generation of protocol-level, timing-level, and boundary value test points.
[0056] The test point generation method provided in this application ensures the breadth and depth of test point generation by using various types of design documents as input sources for automatic analysis; this enables the final output verification test point file to comprehensively reflect the entire design intent from product requirements to specific hardware implementation, thereby greatly improving the completeness of verification.
[0057] In some embodiments, the test point generation rules corresponding to the clock reset dimension include at least one of the following: Generate test point data related to clock timing; Generate test point data related to reset timing; Generate test point data related to the timing of clock and reset during the power-on / off process.
[0058] Specifically, clock and reset are the most basic and critical control signals in digital integrated circuits. Their states and timing relationships directly determine whether the chip can start up normally and operate stably. Within the clock and reset dimension, the test point generation rules for this dimension can be determined based on the testing focus.
[0059] One rule is to generate test point data related to clock timing, aiming to cover all behaviors and scenarios related to the clock itself. When the system detects clock-related technical features, it generates a series of test points according to this rule. In one specific embodiment, test points are generated for the clock gating logic (including soft gating and automatic gating) described in the technical features to verify whether the gating's opening and closing functions are normal. For example, a test point could be generated: "During functional operation, dynamically open / close the module-level clock gating and check whether the function is normal." In another specific embodiment, if the technical feature indicates that the chip supports dynamic voltage and frequency adjustment, test points are generated to verify whether the clock frequency switching process is smooth and stable under different workloads, and whether the function is correct before and after the switching. In yet another specific embodiment, if the technical feature indicates the existence of multiple asynchronous clock domains, test points are generated to verify whether the synchronizer logic used to handle signals across clock domains is reliable.
[0060] Rule Two: Generate test point data related to reset timing, aiming to cover all behaviors and scenarios related to reset signals. When the system detects technical features related to reset, a series of test points are generated according to this rule. In one specific embodiment, test points are generated to verify its basic functionality based on the reset type (synchronous reset or asynchronous reset) indicated by the technical features. In another specific embodiment, reset test points covering different business scenarios are generated. For example, when the chip is performing complex calculations or transmitting large amounts of data, a reset is suddenly applied, and then the chip is checked to see if it can terminate the current operation and reset correctly. This is called in-service reset testing. In yet another specific embodiment, if a module is controlled by reset signals from multiple different sources, test points are generated to verify whether the arbitration logic and final behavior when these reset signals are effective simultaneously or sequentially meet design expectations.
[0061] Rule Three: Generate test point data related to the timing of clock and reset during the power-on / off process. This rule focuses on the correct coordination between clock and reset signals throughout the entire process from power-on to normal operation and from operation to power-off. In one specific embodiment, test points can be generated to verify whether the sequence of power supply, clock, and reset is correct during power-on. In another specific embodiment, test points are generated to verify whether the shutdown sequence of signals during the power-off process of each independent subsystem meets the requirements, ensuring that the currently power-down subsystem does not affect the functionality of other subsystems.
[0062] The test point generation method provided in this application, by applying the above-mentioned test point generation rules for the clock reset dimension, can effectively discover defects caused by improper clock and reset design, and greatly improve the completeness of verification.
[0063] In some embodiments, the test point generation rules corresponding to the interface testing dimension include at least one of the following: For advanced extensible interfaces, generate test point data related to typical signal values, signal boundary values, signal combinations, protocol testing, reverse voltage testing, and back-to-back testing; For the handshake mechanism interface, generate test point data related to typical values of accompanying signals, boundary values of accompanying signals, combinations of accompanying signals, protocol testing, reverse pressure testing, and back-to-back testing. For the credit mechanism interface, generate test point data related to credit value matching tests, incomplete request tests, and confirmation delay tests; Generate test point data related to the backpressure combinations of different interfaces that are logically related to the hardware; Generate timing-related test point data for different interface combinations.
[0064] Specifically, chips or their internal modules do not exist in isolation; they interact with each other through various interfaces to exchange data and control information. In the interface testing dimension, the rules for generating test points for that dimension can be determined based on the testing focus.
[0065] One rule, for Advanced eXtensible Interfaces (AXI), is to generate test point data related to typical signal values, signal boundary values, signal combinations, protocol testing, reverse voltage testing, and back-to-back testing. This rule focuses on: 1. Typical / Boundary Value Tests for Signals: Legal typical and boundary values for various signals (such as transmission bit width (AXSIZE), burst transmission length (Burst Length), etc.), safe and unsafe operations, different types of responses, different locations of valid data, special values for writing data, different address alignments, etc. 2. Combination scenarios of different signals: such as the combination of transmission bit width and transmission length, the combination of various types of atomic operations and addresses, and the address alignment granularity under different transmission bit width scenarios; 3. Protocol testing: Narrow bit width operation test, Outstanding request test, Out-of-order test, Read-write interleaving test, Test that the output signal value needs to be maintained when the Ready signal is not pulled high; 4. Backpressure Testing: Testing the order of Write Address Channel / Write Data Channel (AW / W), backpressure combination testing of Write Address Channel / Write Data Channel (AW / W) and Write Response Channel (B), backpressure combination testing of Read Address Channel (AR) and Read Data Channel (R), backpressure combination testing between Write Address Channel / Write Data Channel / Read Address Channel (AW / W / AR), and backpressure combination testing between upstream and downstream interfaces; 5. Back-to-back test, i.e., sending requests continuously.
[0066] Rule Two: For handshake mechanism interfaces, generate test point data related to typical values of accompanying signals, boundary values of accompanying signals, combinations of accompanying signals, protocol testing, reverse voltage testing, and back-to-back testing. This rule focuses on: 1. Pay attention to the typical and boundary values of each accompanying signal during the valid / ready handshake; 2. The combination scenarios of different accompanying signals need to be considered differently based on the specific business scenarios of each module. For example, for the initialization interface, focus on the initialization configuration under different modes; for the input command interface, focus on different command modes, control domains of different commands, and their functional scenarios; for the return data interface, focus on out-of-order data and special values of data in different formats; for the output request interface, focus on incomplete requests, different request types, combinations of transmission bit width and transmission length, combinations of transmission bit width and starting address (especially in scenarios where requests cross physical memory boundaries), and combinations of valid address positions when multiple addresses are concurrent; for the command sideband signal interface, focus on the combination of different address patterns, command modes, different input formats, and different output formats; for the synchronization interface, focus on the combination of different synchronization modes and synchronization resource identifiers (IDs). 3. Protocol test: Test the output signal value to be maintained when the ready signal is not pulled high; 4. Back pressure test: back pressure test of the valid signal of the input port, back pressure test of the ready signal of the output port, and back pressure combination test between upstream and downstream interfaces; 5. Back-to-back test, i.e., sending requests continuously.
[0067] For interfaces that only support valid signals, please pay attention to the following rules: 1. Typical and boundary values of each accompanying signal when the valid signal is pulled high; 2. The combination scenarios of different accompanying signals need to be considered differently according to the specific business scenarios of each module: For example, for the register configuration interface, pay attention to the security protection and isolation of special registers, the combination of register addresses and read / write modes, the increment and decrement methods of registers, boundary value wrapback, etc.; for the credit increment (Credit Inc) interface, pay attention to the boundary values of credits and the scenario when credits are used up; other types of valid signal interface test points can refer to similar descriptions in the valid signal / ready signal interface test points. 3. Back pressure test: back pressure test of the effective signal at the input port, and back pressure combination test between upstream and downstream interfaces; 4. Back-to-back test, i.e., sending requests continuously.
[0068] Rule 3: For the credit mechanism interface, generate test point data related to credit value matching tests, incomplete request tests, and confirmation delay tests. This rule focuses on: 1. The number of credit / acknowledgment (Credit / Ack) signals must match; 2. In scenarios where the number of incomplete requests in the credit / confirmation signal interface is greater than 1, i.e. before the confirmation signal is returned, continue to send the next credit request to cover the maximum number of incomplete requests. 3. Confirm the signal return delay; both immediate and long-term return scenarios need to be covered. 4. Scenarios involving a combination of incomplete requests and delays, such as when the number of incomplete requests is at its maximum, or when multiple confirmation signals are returned consecutively or at long time intervals.
[0069] Rule 4: Generate test point data related to backpressure combinations of different interfaces that are logically related to the hardware. This rule focuses on backpressure combinations of different interfaces that are logically related to the hardware, including combinations such as pairwise or multiple groups of converging input interfaces, input and output interfaces, multiple input interfaces and one output interface, and one input interface and multiple output interfaces.
[0070] Rule 5: Generate test point data related to the timing of different interface combinations. This rule focuses on: configuring and initializing interfaces should precede the data path; and considering scenarios where configurations or modes are dynamically changed in the business.
[0071] The test point generation method provided in this application, by applying the above-mentioned hierarchical and refined test point generation rules for interface testing dimensions, can automatically create a comprehensive test set covering everything from single interface protocol details to complex system-level interface interactions, thereby achieving comprehensive generation of test point data and greatly improving the completeness and efficiency of chip pre-simulation verification.
[0072] In some embodiments, the test point generation rules corresponding to the internal functional dimensions include at least one of the following: For incomplete request functionality, generate test point data related to incomplete requests along the entire input-to-output chain; For the first-in-first-out queue unit, generate test point data related to empty reverse pressure read test, full reverse pressure write test and empty / full state change test; For the counter unit, generate test point data related to the maximum and minimum value tests; For the arbitrator unit, generate test point data related to concurrency priority testing and polling arbitration balance testing; For memory cells, generate test point data related to address traversal test, back-to-back read test, back-to-back write test, and back-to-back write-read test; For the credit mechanism, test point data related to the impact of credit depletion on different hardware logic is generated; Generate test point data related to data conflicts in write-after-read, read-after-write, and write-after-write scenarios.
[0073] Specifically, the complex functions of a chip are ultimately achieved through the collaborative work of its various internal basic logic units and specific functional modules. Verifying these internal functions is fundamental to ensuring that the chip's behavior conforms to the design specifications. Within the internal functional dimension, the rules for generating test points can be determined based on the testing focus of that dimension.
[0074] One rule is to generate test point data related to outstanding requests across the entire input-to-output chain. This rule focuses on the module's ability to handle multiple outstanding requests.
[0075] Rule 2: For First-In-First-Out (FIFO) cells, generate test point data related to empty reverse pressure read tests, full reverse pressure write tests, and empty / full state change tests. This rule focuses on the behavior of FIFO cells under various boundary conditions.
[0076] Rule 3: For counter units, generate test point data related to maximum and minimum value tests, as well as test point data related to counter unit hold or wrapback tests. This rule focuses on the correctness of the counting behavior.
[0077] Rule 4: For the Arbiter unit, generate test point data related to concurrency priority testing and polling arbitration balance testing. Test scenarios include livelock scenarios where a certain input cannot be arbitrated for a long time. This rule focuses on the correctness and fairness of the arbitration strategy.
[0078] Rule 5: For memory cells, generate test point data related to address traversal (incrementing or decrementing) tests, back-to-back read tests, back-to-back write tests, and back-to-back write-read tests. This rule focuses on the correctness and stability of read and write functions.
[0079] Rule Six: For the credit mechanism, generate test point data related to the impact on different hardware logic when credits are exhausted. This rule focuses on the impact on related logic when credits are exhausted. For example, a multi-output module shares a credit mechanism, and different types of outputs may consume different amounts of credits. The rule will generate test points: "Let one type of output continue to occur, quickly consuming all credits, check whether other types of outputs are correctly blocked at this time, and whether the arbitration logic will lead to livelock in this extreme case."
[0080] Rule Seven: Generate test point data related to data conflicts in Read After Write (RAW), Write After Read (WAR), and Write After Write (WAW) scenarios. This rule focuses on bypass or interlocking logic for resolving data conflicts.
[0081] In addition, special functions need to be analyzed specifically based on the specific characteristics of the module and the hardware design; for example, the cache module needs to consider replacement strategy testing, cacheline-based testing, and set-based testing; the arithmetic logic unit (ALU) module needs to traverse various calculation types, handle special values under different data formats, handle integer (Int) data saturation, handle floating-point (Float) data normalization, and handle bit width conversion; the instruction parsing module needs to list all the operation fields supported by each instruction in detail, and the commonly used operation fields should be tested as high-priority test items.
[0082] The test point generation method provided in this application, by applying the above-mentioned detailed test point generation rules for internal functional dimensions, can accurately detect whether the internal logic function of the module is correct, and achieve comprehensive generation of test point data, which greatly improves the completeness and efficiency of chip pre-simulation verification.
[0083] In some embodiments, the test point generation rules corresponding to the chip performance dimension include at least one of the following: Generate test point data related to the path bandwidth; Generate test point data related to bandwidth in different access modes of the cache; Generate test point data related to path delay.
[0084] Specifically, performance metrics such as bandwidth and latency directly impact user experience and overall system efficiency. Within the chip performance dimension, the rules for generating test points can be determined based on the testing focus of that dimension.
[0085] One rule is to generate test point data related to the bandwidth of the data paths. This rule focuses on whether the bandwidth of the key data paths inside the chip meets the design expectations. Test point data can include: no reverse voltage at the input and full bandwidth, testing whether the output bandwidth is full or whether the idle period (bubble) meets expectations (including one-to-one / many-to-one / many-to-many paths, combinations need to be listed one by one); the response returned by the output path has no reverse voltage and full bandwidth, testing whether the response received by the input path has full bandwidth or whether the idle period meets expectations (including one-to-one / many-to-one / many-to-many paths, combinations need to be listed one by one), etc.
[0086] Rule Two: Generate and cache bandwidth-related test point data under different access modes. This rule focuses on whether cache performance meets design expectations. Test point data includes: When there is no backpressure on the cache input and all read / write requests hit (AllHit), can the bandwidth be fully utilized? When there is no backpressure on the cache input and all read / write requests miss (All Miss), what is the maximum latency that can be supported when the bandwidth is fully utilized? Test with actual latency to see if the bandwidth meets design expectations? When there is no backpressure on the cache input and some read / write requests miss, what percentage of misses, based on actual latency, can the current design achieve full bandwidth?
[0087] Rule 3: Generate test point data related to path latency. This rule focuses on whether the path latency is within the design specifications. Test point data includes: whether the input-to-output latency meets expectations (single-scenario testing); module-level performance verification focuses on whether the bandwidth / latency meets expectations under ideal conditions; system verification also requires testing whether the bandwidth meets the standards in real application scenarios (performance test points are listed according to application scenarios), etc.
[0088] The test point generation method provided in this application, by applying the above-mentioned test point generation rules for chip performance dimensions, allows for refined testing of bandwidth and latency under various ideal and real-world scenarios, greatly improving the completeness and efficiency of chip pre-simulation verification.
[0089] In some embodiments, the test point generation rules corresponding to the chip debugging dimension include: Generate test point data related to debugging bus access, interrupt mechanisms, or performance counters.
[0090] Specifically, verifying debugging characteristics is crucial to ensuring chip observability, diagnosability, and maintainability. Within the chip debugging dimension, test point generation rules can be determined based on the testing focus of this dimension. For example, test point data related to debug bus access, interrupt mechanisms, or performance counters can be generated. These rules focus on whether the chip's debugging functions are reliable and accurate.
[0091] Test point data includes: 1. For the debug bus, this includes traversing and testing all valid debug bus register addresses; testing the behavior of invalid address boundary values; testing the behavior of the maximum address value; and testing the behavior of wrapping around the maximum address value. 2. For the interrupt mechanism, this includes traversing and testing all types of interrupts; testing the accompanying information reported by each interrupt, etc. 3. For performance counters, this includes iterating through and testing all performance counter signals.
[0092] The test point generation method provided in this application applies the above-mentioned test point generation rules for chip debugging. The generated test point data can ensure that the observability and diagnosability of the chip are verified, which greatly improves the completeness and efficiency of chip pre-simulation verification.
[0093] The apparatus provided in the embodiments of this application is described below. The apparatus described below can be referred to in correspondence with the method described above.
[0094] Figure 2 This is a schematic diagram of the test point generation device provided in this application, as shown below. Figure 2 As shown, the device includes: The reading module 210 is used to read technical documents related to the chip under test from the memory; The identification module 220 is used to identify technical features in technical documents and classify the technical features into corresponding technical dimensions based on preset feature classification rules; the technical dimensions include at least one of clock reset dimension, interface testing dimension, internal function dimension, chip performance dimension and chip debugging dimension; The processing module 230 is used to call the test point generation rules corresponding to each technical dimension, process the technical features under each technical dimension, and generate test point data under each technical dimension. Output module 240 is used to summarize test point data under various technical dimensions and output the verification test point file of the chip under test.
[0095] The test point generation device provided in this application reads technical documents related to the chip under test, identifies the technical features in the documents, classifies the technical features into corresponding technical dimensions, processes the technical features by calling test point generation rules, generates test point data, summarizes the test point data under each technical dimension, and outputs the verification test point file of the chip under test. This transforms the previously manual, fragmented, and error-prone test point extraction process into an automated, systematic, and standardized data processing workflow. Through the decomposition of multiple technical dimensions, it ensures that the analysis of the chip design covers all aspects, achieving comprehensive generation of test point data. This greatly improves the completeness and efficiency of chip pre-simulation verification, reduces the risk of tape-out due to missing test points, and provides strong technical support for the design verification of complex chips.
[0096] Figure 3 This is a schematic diagram of the structure of the electronic device provided in this application, such as... Figure 3 As shown, the electronic device may include: a processor 310, a communications interface 320, a memory 330, and a communications bus 340, wherein the processor, communications interface, and memory communicate with each other via the communications bus. The processor can invoke logical commands stored in the memory to execute the methods described in the above embodiments, for example: Read the technical documents related to the chip under test from the memory; identify the technical features in the technical documents and classify the technical features into the corresponding technical dimensions based on preset feature classification rules; the technical dimensions include at least one of clock reset dimension, interface test dimension, internal function dimension, chip performance dimension, and chip debugging dimension; call the test point generation rules corresponding to each technical dimension, process the technical features under each technical dimension, and generate test point data under each technical dimension; summarize the test point data under each technical dimension and output the verification test point file of the chip under test.
[0097] Furthermore, the logical commands in the aforementioned memory can be implemented as software functional units and sold or used as independent products, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several commands to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0098] The processor in the electronic device provided in this application embodiment can call logical instructions in the memory to implement the above method. Its specific implementation method is the same as the aforementioned method implementation method and can achieve the same beneficial effect, which will not be repeated here.
[0099] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the methods provided in the above embodiments.
[0100] The specific implementation method is the same as the aforementioned method implementation method and can achieve the same beneficial effects, so it will not be repeated here.
[0101] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method described above.
[0102] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A method for generating test points, characterized in that, include: Read technical documents related to the chip under test from memory; Identify the technical features in the technical documents and classify the technical features into corresponding technical dimensions based on preset feature classification rules; the technical dimensions include at least one of clock reset dimension, interface testing dimension, internal function dimension, chip performance dimension, and chip debugging dimension; Call the test point generation rules corresponding to each technical dimension, process the technical features under each technical dimension, and generate test point data under each technical dimension; Summarize the test point data under various technical dimensions and output the verification test point file of the chip under test.
2. The test point generation method according to claim 1, characterized in that, The technical documents include at least one of the following: product requirements document, macro structure specification document, register form, instruction set architecture document, and interface specification form.
3. The test point generation method according to claim 1, characterized in that, The test point generation rules corresponding to the clock reset dimension include at least one of the following: Generate test point data related to clock timing; Generate test point data related to reset timing; Generate test point data related to the timing of clock and reset during the power-on / off process.
4. The test point generation method according to claim 1, characterized in that, The test point generation rules corresponding to the interface testing dimension include at least one of the following: For advanced extensible interfaces, generate test point data related to typical signal values, signal boundary values, signal combinations, protocol testing, reverse voltage testing, and back-to-back testing; For the handshake mechanism interface, generate test point data related to typical values of accompanying signals, boundary values of accompanying signals, combinations of accompanying signals, protocol testing, reverse pressure testing, and back-to-back testing. For the credit mechanism interface, generate test point data related to credit value matching tests, incomplete request tests, and confirmation delay tests; Generate test point data related to the backpressure combinations of different interfaces that are logically related to the hardware; Generate timing-related test point data for different interface combinations.
5. The test point generation method according to claim 1, characterized in that, The test point generation rules corresponding to the internal functional dimensions include at least one of the following: For incomplete request functionality, generate test point data related to incomplete requests along the entire input-to-output chain; For the first-in-first-out queue unit, generate test point data related to empty reverse pressure read test, full reverse pressure write test and empty / full state change test; For the counter unit, generate test point data related to the maximum and minimum value tests; For the arbitrator unit, generate test point data related to concurrency priority testing and polling arbitration balance testing; For memory cells, generate test point data related to address traversal test, back-to-back read test, back-to-back write test, and back-to-back write-read test; For the credit mechanism, test point data related to the impact of credit depletion on different hardware logic is generated; Generate test point data related to data conflicts in write-after-read, read-after-write, and write-after-write scenarios.
6. The test point generation method according to claim 1, characterized in that, The test point generation rules corresponding to the chip performance dimension include at least one of the following: Generate test point data related to the path bandwidth; Generate test point data related to bandwidth in different access modes of the cache; Generate test point data related to path delay.
7. The test point generation method according to claim 1, characterized in that, The test point generation rules corresponding to the chip debugging dimension include: Generate test point data related to debugging bus access, interrupt mechanisms, or performance counters.
8. A test point generation device, characterized in that, include: The read module is used to read technical documents related to the chip under test from the memory; The identification module is used to identify the technical features in the technical document and classify the technical features into the corresponding technical dimensions based on preset feature classification rules; the technical dimensions include at least one of clock reset dimension, interface testing dimension, internal function dimension, chip performance dimension and chip debugging dimension; The processing module is used to call the test point generation rules corresponding to each technical dimension, process the technical features under each technical dimension, and generate test point data under each technical dimension. The output module is used to summarize the test point data under various technical dimensions and output the verification test point file of the chip under test.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the test point generation method according to any one of claims 1 to 7.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the test point generation method according to any one of claims 1 to 7.