A random instruction test case generation method and device

Abstract

This application provides a method and apparatus for generating random instruction test cases, relating to the field of automated testing technology. First, target instructions or instruction sequences are encapsulated into C inline functions using inline assembly or macro definition, forming a unified function library. Next, a function parameter constraint system is constructed, defining parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function. Then, a multi-level nested structure is built based on the C inline functions to organize the instructions, where each level node is associated with a corresponding C inline function name and constraints. Finally, based on a YAML configuration file, the target C inline functions are determined from the multi-level nested structure and combined to generate random instruction test cases. The YAML configuration file includes at least the number of iterations, a random seed, a random strength factor, and test content configuration. The solution provided in this application has the advantages of improved verification efficiency and applicability to different scenarios.

Description

Technical Field

[0001] This application relates to the field of automatic testing technology, and more specifically, to a method and apparatus for generating random instruction test cases. Background Technology

[0002] In critical scenarios such as processor architecture verification, compiler backend testing, instruction set simulator development, and hardware security side-channel analysis, high-quality, high-coverage instruction-level test cases are the foundation for ensuring the correctness and robustness of system functions.

[0003] Traditional instruction test case generation methods rely on manually writing test sequences. However, this method depends on engineers' deep understanding of instruction semantics, register dependencies, memory aliases, and exception triggering conditions, which is extremely inefficient and makes it difficult to cover complex instruction combinations, edge address access, and multi-threaded race conditions.

[0004] In summary, existing technologies suffer from low efficiency in generating random instruction test cases and limited applicability. Summary of the Invention

[0005] The purpose of this application is to provide a method and apparatus for generating random instruction test cases, so as to solve the problems of low efficiency and limited applicability of random instruction test cases in the prior art.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: On one hand, embodiments of this application provide a method for generating random instruction test cases, the method comprising: By using inline assembly or macro definition, target instructions or instruction sequences are encapsulated into C inline functions to form a unified function library; Construct a function parameter constraint system to define parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function; The instructions are organized into a multi-level nested structure based on the C inline functions, wherein each level node is associated with the corresponding C inline function name and constraints; Based on the YAML configuration file, the target C inline function is determined from the multi-level nested structure, and random instruction test cases are generated by combining them; wherein, the YAML configuration file includes at least the number of iterations, random seed, random intensity factor, and test content configuration.

[0007] Optionally, the test content configuration includes one or more of the following configuration items: The number of instructions limits the number of instructions in a single generated random instruction test case. The variable pool is used to define the types and value ranges of available registers or variables; A memory pool is used to limit the range of available addresses for memory access instructions and to define initialization rules. Instruction set, used to limit the range of target C inline functions that can be selected; Immediate number range, used to limit the random generation interval of immediate numbers; Initialization code is used to perform register or memory initialization operations before the instruction sequence is generated; Instruction generation templates are used to define fixed instructions, random parameters, wildcards, and repetition counts.

[0008] Optionally, the memory pool supports one or more of the following initialization rules: All-zero initialization; All-inclusive initialization; Generate sequence values ​​by adding a step size to the base address; Random number initialization; Random values ​​within a specified address range; Map to a fixed address or a fixed immediate value.

[0009] Optionally, the instruction generation template supports one or more of the following random patterns: Fixed instructions with fixed parameters; Fixed instructions combined with random parameters; Hierarchical wildcard commands are combined with the number of repetitions; Multiple ranges of random addresses or data; Execution involves a random combination of multiple instruction groups, with sequential execution within the same instruction group.

[0010] Optionally, the variable pool supports defining a set of variables according to data type and variable name range, and the initial value of the variables is zero by default; non-zero initial values ​​are achieved through assignment instructions in the initialization code.

[0011] Optionally, the instruction set is referenced using the hierarchical path expression of the multi-level nested structure, with different levels connected by separators to limit the range of instructions that can be randomly invoked.

[0012] Optionally, the multi-level nested structure is divided into top-level libraries, major categories, subclasses, bit widths, and instructions, with each level node associated with a corresponding C inline function name, parameter constraint mnemonic sequence, and instruction format constraint.

[0013] Optionally, the function parameter constraint system includes a parameter constraint mnemonic definition module; the parameter constraint mnemonic includes one or more of the following: REG is used to identify register or variable parameters; IMM is used to identify integer immediate values; FLOAT is used to identify immediate floating-point numbers; REG_OR_IMM is used to identify registers or integer immediate values; REG_OR_FLOAT is used to identify registers or floating-point numbers; REG_REF is used to identify variable references.

[0014] Optionally, the function parameter constraint system further includes a parameter data type definition module; the parameter data type definition module is used to define one or more of the following attributes of the parameter: data format type, bit width, whether it is a non-negative number, and whether it is a floating-point number.

[0015] On the other hand, embodiments of this application also provide a random instruction test case generation device, the random instruction test case generation device comprising: The instruction encapsulation module is used to encapsulate target instructions or instruction sequences into C inline functions through inline assembly or macro definition, forming a unified function library; The parameter constraint module is used to build a function parameter constraint system, defining parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function; The organization instruction construction module is used to construct multi-level nested structure organization instructions based on the C inline functions, wherein each level node is associated with the corresponding C inline function name and constraints; The test case generation module is used to determine the target C inline function from the multi-level nested structure based on the YAML configuration file, and combine them to generate random instruction test cases; wherein, the YAML configuration file includes at least the number of iterations, random seed, random intensity factor and test content configuration.

[0016] Compared with the prior art, this application has the following advantages: This application provides a method and apparatus for generating random instruction test cases. First, target instructions or instruction sequences are encapsulated into C inline functions using inline assembly or macro definition, forming a unified function library. Next, a function parameter constraint system is constructed, defining parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function. Then, a multi-level nested structure is constructed based on the C inline functions to organize the instructions, where each level node is associated with a corresponding C inline function name and constraints. Finally, based on a YAML configuration file, the target C inline functions are determined from the multi-level nested structure and combined to generate random instruction test cases. The YAML configuration file includes at least the number of iterations, a random seed, a random strength factor, and test content configuration.

[0017] This application utilizes C inline function encapsulation technology to deeply bind instructions to code, forming a unified function library, which significantly improves the reusability and maintainability of test cases. Furthermore, by constructing a function parameter constraint system, it ensures that every generated instruction is a valid and executable test case, eliminating the need for manual screening and significantly improving verification efficiency. In addition, the modular, multi-level nested instruction library structure supports flexible expansion to new instruction types, thus making it applicable to different scenarios.

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 An exemplary flowchart of the random instruction test case generation method provided in the embodiments of this application.

[0021] Figure 2 This is a schematic diagram of the data types provided in the embodiments of this application.

[0022] Figure 3 Example diagram of function constraints provided for embodiments of this application.

[0023] Figure 4 This is a schematic diagram of a configuration file provided in an embodiment of this application.

[0024] Figure 5 A schematic diagram of the VAR_LIST field provided in an embodiment of this application.

[0025] Figure 6 A schematic diagram of the MEM_LIST field provided in an embodiment of this application.

[0026] Figure 7 A schematic diagram of an electronic device provided in an embodiment of this application.

[0027] In the picture: 201 - Processor; 202 - Memory; 203 - Communication interface. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0029] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0030] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0031] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Some embodiments of this application are described in detail below with reference to the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0032] In existing technologies, for SoC (System on Chip) verification, prototype verification, and SLT (System Level Test) scenarios, there are technical solutions based on instruction-level random testing. The core logic is to simply encapsulate ARM architecture-related instructions and generate instruction sequences using a random algorithm for chip functional verification. Specifically, existing technologies encapsulate a single test instruction into a basic execution unit, allowing random configuration of some parameters (such as register addresses and immediate values). Multiple instruction units are then combined into a continuous test sequence through random scheduling to simulate the actual operation of the chip and achieve basic functional verification. This approach has the following problems: (1) Incomplete instruction encapsulation and lack of standardization: Existing solutions simply wrap instructions without forming a systematic function-level encapsulation and failing to achieve deep binding between instructions and functions. This results in poor reusability and maintainability of test cases and makes them unsuitable for complex SoC verification scenarios. In contrast, this application solves the problems of non-standard encapsulation and poor reusability by constructing a standardized function-level encapsulation system and deeply binding instructions and functions.

[0033] (2) The random mechanism is simple and the coverage is insufficient: the random logic of the existing solution is only at a single level, which can only realize simple parameter randomness or instruction sequence randomness, and cannot realize the progressive randomness of "parameter randomness → function sequence randomness". This results in limited coverage of test cases and difficulty in fully verifying chip functions. However, this application realizes the progressive randomness of parameters and function sequences by constructing a multi-level random mechanism, which greatly improves the test coverage.

[0034] (3) Lack of a sound constraint mechanism: The existing solution has not built an effective constraint system. Randomly generated test cases are prone to invalid or illegal scenarios (such as parameter mismatch, address misalignment, etc.), which require manual intervention to screen, resulting in low efficiency.

[0035] (4) Poor scalability: The existing solution lacks modular design for instruction management, cannot flexibly adapt to different types of instructions (such as DSP instructions, cache-related instructions), and is difficult to meet diverse verification needs, resulting in limited applicable scenarios.

[0036] In view of this, in order to solve the above problems, this application provides a method for generating random instruction test cases. As an optional implementation, please refer to [link to relevant documentation]. Figure 1 The method includes: S102 encapsulates target instructions or instruction sequences into C inline functions through inline assembly or macro definition, forming a unified function library.

[0037] S104 constructs a function parameter constraint system, defining parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function.

[0038] S106, constructs multi-level nested structure organization instructions based on C inline functions, where each level node is associated with the corresponding C inline function name and constraints.

[0039] S108. Based on the YAML configuration file, determine the target C inline function from the multi-level nested structure and generate random instruction test cases; wherein, the YAML configuration file includes at least the number of iterations, random seed, random intensity factor and test content configuration.

[0040] To overcome the limitations of current chip verification methods that commonly employ instruction-level random testing, which often only encapsulates single instructions and lacks unified abstraction and structured management, resulting in poor test case reusability, insufficient coverage, and frequent illegal test cases, this application provides a systematic method for generating random instruction test cases. Its core lies in using C inline functions as basic units to codify and standardize instruction behavior, and controlling the random process through hierarchical organization and configuration. Specifically, this application encapsulates target instructions or instruction sequences into C inline functions, constructs a function parameter constraint system, and organizes instructions into a multi-level nested structure based on these functions. This is then combined with YAML configuration files to drive random selection and combination, thereby achieving automatic generation of random instruction test cases.

[0041] Specifically, this application uses a computer system as the implementation device for interpreting text. First, it encapsulates the target instructions or instruction sequences into C inline functions using inline assembly or macro definitions, forming a unified function library. The C inline functions described in this application refer to lightweight functions defined in the C language environment using inline assembly syntax or preprocessor macros supported by the GCC compiler, which can be expanded and executed at compile time. Their encapsulation includes the instruction itself, register operation logic, and necessary side-effect control, thereby transforming low-level hardware instructions into software interfaces that can be directly called, combined, and constrained by high-level languages.

[0042] Building upon this foundation, this application also constructs a function parameter constraint system, defining parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function. Parameter types include register variables, integer immediate values, floating-point immediate values, register or immediate value compatibility types, register or floating-point value compatibility types, and variable references. Address ranges are used to limit the memory address range operable by memory access instructions. Instruction combination methods specify the calling order, dependencies, or parallelism possibilities between multiple instructions; for example, encapsulating "read-write-read" or continuous read / write instructions into a single function, allowing one function to correspond to multiple instructions. Value range constraints target the specific numerical domain of each parameter, such as a 32-bit unsigned integer, a memory address with 8-byte alignment requirements, or a floating-point immediate value conforming to a specific format.

[0043] Furthermore, this embodiment constructs a multi-level nested structure to organize instructions based on the aforementioned C inline functions. Each level node is associated with a corresponding C inline function name and constraints. This multi-level nested structure is divided step by step according to "top-level library - category - subcategory - bit width - instruction". For example, the top-level library is INST_LDST_ALIGN_LIBS (memory access alignment instruction library), its next-level category is LD (load instruction), and the next-level subcategory is LD_NM (normal single register load). It is then subdivided according to bit width into B4 (4 bytes), B2 (2 bytes), and B1 (1 byte), and finally points to specific instructions such as LDR (load register), LDRH (half-word load), and LDRB (byte load). Each level node is bound to a unique C inline function name (such as ldst_ldr), parameter constraint mnemonic sequence (such as r?, 1align4), and instruction format constraints (such as the address must be 8 bytes aligned), thereby realizing the unified binding of function name, parameter format, and hardware semantics, ensuring modularity and scalability.

[0044] Finally, based on the YAML configuration file, the target C inline function is determined from the multi-level nested structure, and random instruction test cases are generated by combining them. The YAML configuration file includes at least the number of iterations, a random seed, a random strength factor, and test content configuration. The number of iterations controls the overall test case generation rounds; the random seed ensures that the generated results are reproducible and traceable under the same configuration; the random strength factor adjusts the coupling degree between parameter randomness and instruction sequence randomness; and the test content configuration covers the number of instructions, variable pool, memory pool, instruction set, immediate value range, initialization code, and instruction generation templates, etc., so that the test logic is completely free from hard coding, achieving decoupling between verification intent and implementation details, and improving the maintainability and cross-platform adaptability of the test cases.

[0045] In summary, this application uses C inline functions as a carrier to connect four key links: instruction semantic abstraction, parameter formal constraints, structured classification organization, and declarative configuration-driven approach. This transforms random testing from an experience-driven, manual intervention-based, extensive model into a modelable, verifiable, reproducible, and scalable engineering method.

[0046] The steps in the method provided in this application are described in detail below: Because existing technologies simply wrap single test instructions without establishing a structured and semantic binding relationship between the instructions and functions in high-level programming languages, they cannot achieve parameter passing, call composition, and cross-platform reuse through function interfaces. This results in the need to repeatedly write low-level assembly code every time a new instruction is added or the verification logic is modified, leading to high maintenance costs and weak scalability. Therefore, this embodiment encapsulates the target instruction or instruction sequence into C inline functions through inline assembly or macro definition, forming a unified function library. This aims to solve the problems of poor test case reusability, low maintainability, and difficulty in adapting to complex SoC verification scenarios caused by incomplete instruction encapsulation and lack of standardization in existing technologies.

[0047] Specifically, this embodiment encapsulates instructions and instruction sequences into C functions using inline assembly or macro definitions. This encapsulation process strictly adheres to the definition specifications for inline functions in the GNU Compiler Collection (GCC) manual. Inline assembly refers to directly embedding assembly instructions into the C source code and explicitly specifying register mappings and memory access behaviors through input / output constraint lists, thereby ensuring the compiler can correctly generate machine code for the target architecture. Macro definitions, on the other hand, define parameterizable code fragments as preprocessor directives, performing text substitution before compilation. This is suitable for encapsulating instruction sequences with fixed patterns but variable parameters. In this process, each target instruction or each group of instruction sequences with cooperative semantics is encapsulated into an independent C inline function with a clearly defined signature. All such functions together constitute a logically unified, interface-consistent function library that can be directly called by advanced testing frameworks.

[0048] It is evident that by encapsulating target instructions or instruction sequences into C inline functions, instructions are transformed from primitive, hardware-oriented low-level operation units into high-level software components with type safety, explicit parameter declaration, and controllable calling context. Furthermore, this provides the necessary prerequisites for subsequently building function parameter constraint systems, organizing multi-level nested instruction structures, and driving YAML configurable random generation.

[0049] After encapsulating C inline functions, a function parameter constraint system is constructed. It should be noted that existing technologies lack a formalized and parsable semantic identification mechanism for the input and output parameters of the encapsulated instruction functions. This means they cannot distinguish whether a parameter should be passed a register number or an immediate value, nor can they express whether the parameter must be a non-negative integer, meet specific alignment requirements, or participate in floating-point operations. Consequently, the random engine can only rely on empirical rules or hard-coded judgments when generating instruction calls, resulting in poor fault tolerance and weak legality guarantees. This ultimately leads to a large number of generated test cases failing to execute on the chip or triggering uncontrollable exceptions, resulting in low verification efficiency. Based on this, this application addresses the problem in existing technologies where the lack of an effective constraint system leads to invalid or illegal scenarios in randomly generated test cases (such as mixing register parameters with immediate values, address misalignment, and misuse of floating-point operands as integers), requiring manual intervention for screening. This is addressed by implementing a function parameter constraint system, including a parameter constraint mnemonic definition module and a parameter data type definition module.

[0050] In one implementation, the function parameter constraint system includes a parameter constraint mnemonic definition module, which defines parameter constraint mnemonics. These mnemonics include one or more of the following: REG (to identify register or variable parameters); IMM (to identify integer immediate values); FLOAT (to identify floating-point immediate values); REG_OR_IMM (to identify register or integer immediate values); REG_OR_FLOAT (to identify register or floating-point numbers); and REG_REF (to identify variable references). Specifically, REG corresponds to the symbol r or $, indicating that a register name or variable name should be passed to this parameter position, suitable for scenarios where the source / destination register needs to be specified in arithmetic or storage instructions; IMM corresponds to the symbol i or #, indicating that an integer immediate value should be passed to this parameter position, i.e., a constant value directly written into the instruction code, used to ensure the validity of address offsets, bitmasks, and other configurations; FLOAT corresponds to the symbol f or ., indicating that a floating-point immediate value should be passed to this parameter position, adapting to the testing requirements of vector floating-point arithmetic instructions; REG_OR_IMM corresponds to the symbol i or #, indicating that an integer immediate value should be passed to this parameter position, i.e., a constant value directly written into the instruction code, used to ensure the validity of address offsets, bitmasks, etc.; REG_OR_IMM corresponds to the symbol f or ., indicating that a floating-point immediate value should be passed to this parameter position, adapting to the testing requirements of vector floating-point arithmetic instructions; REG_OR_IMM corresponds to the symbol i or #, indicating that an integer ... The symbols ?, ir, or ri indicate that the parameter position can flexibly accept either a register name or an integer immediate value, improving the applicability of the same function under different testing strategies; REG_OR_FLOAT corresponds to the symbols %, fr, or rf, indicating that the parameter position can accept either a register name or a floating-point immediate value, used to support instruction verification of mixed data types; REG_REF corresponds to the symbol &, indicating that the parameter position is passed a reference address to a variable, used to implement the association constraints between multiple parameters inside the function, such as ensuring that the load address and the store address point to the same memory block.

[0051] Furthermore, the function parameter constraint system also includes a parameter data type definition module. This module defines the parameter's data format type, bit width, whether it is non-negative, and whether it is a floating-point number. The data format types include int, uint, char, uchar, float, double, ldouble, and their underscore variants (such as int32_t, uint8_t, etc.). Each type corresponds to a unique bit width SZ value (e.g., int32 corresponds to 4 bytes, uint64_t corresponds to 8 bytes), a non-negative flag PN value (0 indicates it can be negative, 1 indicates it must be non-negative), and a floating-point flag FP value (0 indicates non-floating-point, 1 indicates floating-point). This definition method allows the system to automatically verify whether the parameters to be filled conform to the data type constraints declared in their location before generating instructions, thereby preventing illegal combinations from the source.

[0052] For example, data types can be as follows Figure 2 As shown. In addition, the function parameter constraint system also includes defining instruction constraints; for example, examples of function constraints are shown below. Figure 3 As shown.

[0053] In other words, instruction constraints define the rules for combining parameters, indicating which parameters are outputs, whether addresses need to be aligned, and what relationships exist between parameters. Through instruction constraints, output / output direction, alignment constraints, and parameter associations can be determined. For example, in the instruction "get_cpu_id r=", "r" is explicitly an output parameter; or, in the instruction "ldr_pair", the address must be 8-byte aligned, implementing alignment constraints. Parameter associations manifest as relationships such as "the value of the second parameter cannot be equal to the first parameter," which will not be elaborated upon here.

[0054] Building upon this foundation, by setting parameter constraint mnemonics, parameter data types, and instruction constraints, a "progressive constraint layer" can be achieved: syntax layer - type layer - structure layer. Specifically, syntax layer constraints are manifested by defining the basic type of parameters through mnemonics, physical layer constraints are manifested by defining the bit width and numerical attributes of parameters through data types, and structure layer constraints are manifested by defining the logical relationships, alignment rules, and input / output directions between function parameters through instruction constraints.

[0055] By using a two-layer structured definition of mnemonics and data types, the parameter usage rules that were originally implicit in the programmer's experience are transformed into explicit constraint information that can be recognized, verified, and inherited by machines. This not only enables the random engine to generate all legal parameter combinations autonomously without relying on manual rules, but also provides a unified interpretation basis for parameter constraint fields configured in subsequent YAML, significantly improving the quality of test case generation and the level of automated verification.

[0056] When constructing a multi-level nested structure to organize instructions, this application designs the instruction organization structure as a multi-level nested structure with clear hierarchical logic, so that the generation process of random instruction test cases can take into account systematicity, configurability and fine-grained constraint capabilities. The multi-level nested structure is divided into top-level library, major category, subclass, bit width and instruction level by level, and each level node is associated with the corresponding C inline function name, parameter constraint mnemonic sequence and instruction format constraint.

[0057] In this application, the hierarchical division is presented as a tree-like classification system: the top level is the top-level library, used to aggregate instruction sets with similar functions; below the top-level library are major categories, used to distinguish the basic semantic types of instructions; below the major categories are further subdivided into subcategories, used to describe the differences in the operation objects or behavioral patterns of instructions; below the subcategories are divided by bit width, used to distinguish different implementation forms of the same semantic instruction in terms of data width; the bottom level is the specific instruction, corresponding to the executable atomic-level target instruction or instruction sequence. In this process, each node is associated with three key pieces of information: first, the C inline function name, that is, the name of the wrapper function corresponding to the instruction or instruction sequence represented by the node in the unified function library; second, the parameter constraint mnemonic sequence, used to identify the category attributes of each parameter under the node, such as REG for register parameters, IMM for immediate values, etc.; third, the instruction format constraint, used to limit the specific encoding rules of the instruction corresponding to the node at the assembly level, including operand placeholders, alignment requirements, and format templates, etc.

[0058] For example, in the field of memory access alignment instructions, there exists a top-level library called INST_LDST_ALIGN_LIBS, which stands for top-level memory access alignment instruction library. This top-level library has a main category called LD, which stands for Load Instructions. The LD category has a subcategory called LD_NM, which stands for Load Normal Single Register. The LD_NM subcategory is further divided into three nodes based on bit width: B4, B2, and B1, corresponding to 4-byte, 2-byte, and 1-byte bit widths, respectively. Node B4 is associated with the C inline function name LDR, mapping to the function ldst_ldr, with the instruction format constraint format:r=?, 1align 4, indicating that the instruction contains one register operand and the memory access address must be 4-byte aligned. Node B2 is associated with the C inline function name LDRH, mapping to the function ldst_ldrh, with the instruction format constraint format:r=?, 1align 2; The B1 node is associated with the C inline function name LDRB, which maps to the function ldst_ldrb. Its instruction format constraint is format:r=?, 1 align1. In addition, there is another subclass LD_PAIR under the LD category, namely Load Pair Registers (LD_PAIR). Its B8-bit wide node is associated with the C inline function name LDRD, which maps to the function ldst_ldrd. Its instruction format constraint is format:?,r,r, 0 align8, indicating that the instruction contains two register operands and the starting address must be aligned to 8 bytes.

[0059] By constructing a hierarchical tree-like classification system, the problem of difficulty in uniformly modeling and differentiating the characteristics of instructions at different abstraction levels during the random generation of instruction test cases can be solved. This leads to a lack of structured test coverage, the inability of parameter constraints to dynamically adapt to instruction semantics, and inconsistent generation behavior of similar instructions due to differences in bit width or format. It is evident that by dividing the system into multi-level nested structures according to the top-level library, major category, subclass, bit width, and instruction, and by associating each level node with the corresponding C inline function name, parameter constraint mnemonic sequence, and instruction format constraint, this embodiment achieves the structured accumulation of instruction knowledge and the granular binding of constraint conditions. This allows the YAML configuration file to flexibly specify target nodes at any level, thereby driving the test case generation module to accurately call C inline functions that meet the semantic, bit width, and format requirements, and automatically inject matching parameter constraints and instruction encoding rules. Ultimately, this achieves a highly controllable, highly consistent, and high-coverage random test case generation effect.

[0060] After constructing a multi-level nested structure to organize instructions, random instruction test cases need to be generated based on the YAML configuration file. It should be noted that this application uses a multi-level random generation technology based on YAML configuration files to decouple the test content configuration into several independent, semantically clear, and flexibly combinable configuration items. This allows users to precisely control the generation boundaries and behavioral characteristics of random instruction test cases in a declarative manner, thereby significantly improving the controllability, reproducibility, and domain adaptability of test cases while ensuring broad test coverage.

[0061] Specifically, the test content configuration includes one or more of the following configuration items: number of instructions, used to limit the number of instructions in a single generated random instruction test case; variable pool, used to define the types and value ranges of available registers or variables; memory pool, used to limit the available address range and initialization rules of memory access instructions; instruction set, used to limit the range of target C inline functions that can be selected; immediate value range, used to limit the random generation interval of immediate values; initialization code, used to perform register or memory initialization operations before the instruction sequence is generated; and instruction generation template, used to define fixed instructions, random parameters, wildcards, and repetition counts.

[0062] For example, the configuration file is as follows Figure 4 As shown, the number of instructions corresponds to the INST_NUM field in the YAML configuration. Its function is to control the number of instructions contained in a single test case, thereby directly constraining the length of a single randomly generated instruction sequence. The variable pool corresponds to the VAR_LIST field in the YAML configuration, which defines the set of available variables in the format "data type:variable name range". For example, the VAR_LIST field is as follows: Figure 5 As shown.

[0063] Here, `uint32_t:c0,c1-2` represents the declaration of variables c0, c1, and c2 as unsigned 32-bit integers. Furthermore, in one implementation, the variable pool supports defining a set of variables by data type and variable name range, with the default initial value being zero; non-zero initial values ​​are achieved through assignment instructions in the initialization code. For example, all variables are initialized to zero by default; if a non-zero initial value is required, it is achieved by executing an assignment instruction in the initialization code, such as `CLIB.mov :c0,#0x30000000`. Additionally, all variables are only randomly selected from the `VAR_LIST`; variables outside of `VAR_LIST` are not supported. The memory pool corresponds to the MEM_LIST field in the YAML configuration. It defines the available memory address range and its initialization method in the form of an address range combined with a separator and an initialization rule identifier, such as 0x30000100~0x300001ff. 'zero' indicates that all memory units within the address range 0x30000100 to 0x300001ff are initialized with all zeros. Furthermore, the memory pool supports one or more of the following initialization rules: all-zero initialization; all-one initialization; generating sequence values ​​by adding a step size to the base address; random number initialization; random value selection within a specified address range; mapping to a fixed address or a fixed immediate value. Among them, all-zero initialization means writing the value 0 to all cells within a specified memory address range; all-one initialization means writing the value 1 to all cells within a specified memory address range; generating sequence values ​​by adding a step size to the base address means generating continuously increasing initial memory values ​​by using the starting address as the base address and incrementing by a preset step size; random number initialization means independently generating pseudo-random values ​​for each cell within a specified memory address range; random value selection within a specified address range means randomly selecting values ​​within another preset address range and writing them in batches to the current memory segment; mapping to a fixed address or a fixed immediate value means uniformly setting the contents of the current memory segment to the value at a fixed memory address or uniformly setting it to a fixed immediate value.

[0064] For example, the MEM_LIST field is as follows Figure 6 As shown. Furthermore, if you want to initialize a specified address range with a special value, you can do so by executing LDST.STR using INITIALIZE, for example: INITIALIZE: - LDST.STR:#0x30080000,#0x30000000 Unless otherwise specified, all addresses will be randomly selected from MEM_LIST.

[0065] Based on this, test cases include directed test cases and undirected test cases. Directed test cases represent memory pools with specified addresses, while undirected test cases represent memory pools randomly selected from the MEM_LIST. When generating test cases, if the number of required test cases is less than or equal to the preset number of directed test cases, all generated test cases are directed test cases. If the number of required test cases exceeds the preset number of directed test cases, the excess directed test cases are supplemented by undirected test cases. For example, if there are 100 directed test cases, and the total number of required test cases is 100, then all generated test cases are directed test cases. If the total number of required test cases is 200, then 100 of the generated test cases are directed test cases, and the other 100 are undirected test cases, with the memory pool address for the undirected test cases being randomly selected from the MEM_LIST.

[0066] The instruction set corresponds to the INST_LIST field in the YAML configuration. The instruction set uses a hierarchical path expression with a multi-level nested structure, with different levels connected by separators to limit the range of instructions that can be randomly invoked. Specifically, to allocate a random range of instructions, instructions are categorized into several classes using multi-level constraints, and then combined using INST_LIST. Different levels are connected by ".". For example, for the instruction set: INST_LIST: - LDST_ALIGN.LD.LD_NM.B4 - LDST_ALIGN.ST.ST_NM.B4 Specifically, LDST_ALIGN.LD.LD_NM.B4 indicates the step-by-step locating of specific instructions from the top-level library LDST_ALIGN, the major class LD, the subclass LD_NM, and the bit width B4, thus limiting the range of C inline functions that can be randomly called in this test. Unless otherwise specified, all instructions will be randomly selected from INST_LIST.

[0067] The immediate value range corresponds to the IMM_LIST field in the YAML configuration. It defines the legal value range of immediate values ​​in the form of a list of consecutive address intervals. For example, 0x30000000-0x300001ff and 0x30080000-0x300801ff together constitute two non-overlapping random sampling intervals. If not specified, all instructions will only be randomized in IMM_LIST.

[0068] The initialization code corresponds to the INITIALIZE field in the YAML configuration. It consists of one or more assembly instructions that can be executed independently before the instruction sequence is generated. It is used to perform preprocessing operations such as register assignment or memory writing.

[0069] The instruction generation template corresponds to the INSTRUCTIONS field in the YAML configuration. It organizes the instruction sequence by instruction group (such as g0, g1). Within each instruction group, instructions are executed sequentially, while different instruction groups are combined and executed according to a random strategy. Each instruction template can contain fixed instructions, wildcard parameters, random parameter ranges, and repetition counts. For example, LDST.LDR ×1c*,#[0x30000000~0x300001ff 0x30080000~0x300801ff] means that the LDST.LDR instruction is called once, the target register is randomly selected from the c* variable, and the immediate address value is randomly selected from two specified address ranges.

[0070] For example, instruction groups are represented as: INSTRUCTIONS: g0: - DSP.QADD:a0,#0x1000,#0o1000 - DSP.QADD :c*,a0,a1 g1: - DSP.QADD :c0,s0,s1 - DSP.QADD :c1,#0x1000,#0x32 The above instructions indicate that all functions within g0 / g1 are executed sequentially, forming different function sequences, and these different function sequences are randomly combined and executed.

[0071] Furthermore, the instruction generation template supports one or more of the following random modes: fixed instructions with fixed parameters; fixed instructions with random parameters; hierarchical wildcard instructions with repetition counts; random addresses or data across multiple instruction groups, with sequential execution within the same instruction group. Specifically, fixed instructions with fixed parameters mean that the instruction type and all operands remain unchanged; fixed instructions with random parameters mean that the instruction type is fixed, but at least one operand is randomly selected within a preset range; hierarchical wildcard instructions with repetition counts use wildcards to match a class of instructions and generate them repeatedly a specified number of times; random addresses or data across multiple instruction groups involve independently and randomly sampling address or data operands within multiple non-contiguous address ranges; and random execution across multiple instruction groups, with sequential execution within the same instruction group, involves first dividing the instructions into several logical groups (e.g., g0, g1), determining the instruction order within each group, while dynamically determining the call order between groups based on a random strategy.

[0072] For example, the instruction generation template is shown in the table below:

[0073] It's important to note that in random instruction testing scenarios, it's difficult to simultaneously ensure the diversity, controllability, and reproducibility of test cases. The fundamental reason is that traditional random testing methods typically employ a globally uniform random strategy, lacking independent control over key dimensions such as the number of instructions, variable resources, memory layout, instruction granularity, and initialization state. This leads to issues like coverage blind spots, resource out-of-bounds errors, uncontrollable behavior, or untraceable results in the generated test cases. This application, however, subdivides the test content configuration into seven orthogonal configuration items, using YAML—a structured, highly readable, and easily editable text format with version control. This allows each configuration item to be independently enabled, disabled, or parameterized, decoupling the originally coupled and intertwined random control logic into a clear, stable, and verifiable configuration file. Therefore, this test content configuration not only provides engineers with an intent-oriented configuration interface but also builds an scalable and reproducible random test governance framework at the underlying level, effectively supporting the high-reliability hardware-software co-verification requirements under complex instruction set architectures.

[0074] In summary, the random instruction test case generation method provided in this application includes at least the following technical points: 1. Structured management of multi-level nested instruction libraries: Organized hierarchically according to "top-level library - major category - subclass - bit width - instruction", with unified binding of function names, parameter formats and alignment constraints, modular and extensible.

[0075] 2. YAML configuration-driven random test case generation: By controlling the number of iterations, random seeds, and strength through global parameters, the test logic and code are decoupled, making test cases reproducible and easy to maintain.

[0076] 3. Pooling and fine-grained constraints on variables and memory: It supports defining variable pools by type and range; it supports multiple memory address segments and various initialization rules to achieve controllable random memory access.

[0077] 4. Flexible instruction template generation mechanism: It supports wildcard instructions, repetition count configuration, and mixed constraints of fixed / random / range parameters, enabling the rapid construction of high-coverage memory access test sequences.

[0078] 5. Unified parameter syntax and automatic parsing: Using symbolic normalization to express input and output, multiple parameters, and alignment rules, valid instructions can be dynamically generated without hard coding.

[0079] Based on the above implementation, this application embodiment also provides a random instruction test case generation device, including: The instruction encapsulation module is used to encapsulate target instructions or instruction sequences into C inline functions through inline assembly or macro definition, forming a unified function library.

[0080] The parameter constraint module is used to build a function parameter constraint system, defining parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function.

[0081] The organization instruction construction module is used to construct multi-level nested structure organization instructions based on C inline functions, where each level node is associated with the corresponding C inline function name and constraints.

[0082] The test case generation module is used to determine the target C inline function from a multi-level nested structure based on the YAML configuration file, and combine them to generate random instruction test cases; wherein, the YAML configuration file includes at least the number of iterations, random seed, random strength factor and test content configuration.

[0083] Please see Figure 7 This application provides an electronic device including at least one processor 201 and at least one memory 202. The processor 201 and the memory 202 are directly connected to each other, or communicate with each other through a communication interface 203, or are electrically connected through one or more communication buses or signal lines to achieve data transmission or interaction. The memory 202 stores program instructions that can be executed by the processor 201. The processor 201 can call the program instructions to execute the program instructions to implement any of the random instruction test case generation methods provided by the above-described various implementation methods.

[0084] The memory 202 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0085] The processor 201 can be an integrated circuit chip with signal processing capabilities. The processor 201 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0086] Understandable. Figure 7 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 7 The more or fewer components shown, or having the same Figure 7 The different configurations shown. Figure 7 The components shown can be implemented using hardware, software, or a combination thereof.

[0087] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for generating random instruction test cases, characterized in that, The method includes: By using inline assembly or macro definition, target instructions or instruction sequences are encapsulated into C inline functions to form a unified function library; Construct a function parameter constraint system to define parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function; The instructions are organized into a multi-level nested structure based on the C inline functions, wherein each level node is associated with the corresponding C inline function name and constraints; Based on the YAML configuration file, the target C inline function is determined from the multi-level nested structure, and random instruction test cases are generated by combining them; wherein, the YAML configuration file includes at least the number of iterations, random seed, random intensity factor, and test content configuration.

2. The random instruction test case generation method according to claim 1, characterized in that, The test content configuration includes one or more of the following configuration items: The number of instructions limits the number of instructions in a single generated random instruction test case. The variable pool is used to define the types and value ranges of available registers or variables; A memory pool is used to limit the range of available addresses for memory access instructions and to define initialization rules. Instruction set, used to limit the range of target C inline functions that can be selected; Immediate number range, used to limit the random generation interval of immediate numbers; Initialization code is used to perform register or memory initialization operations before the instruction sequence is generated; Instruction generation templates are used to define fixed instructions, random parameters, wildcards, and repetition counts.

3. The method for generating random instruction test cases according to claim 2, characterized in that, The memory pool supports one or more of the following initialization rules: All-zero initialization; All-inclusive initialization; Generate sequence values ​​by adding a step size to the base address; Random number initialization; Random values ​​within a specified address range; Map to a fixed address or a fixed immediate value.

4. The method for generating random instruction test cases according to claim 2, characterized in that, The instruction generation template supports one or more of the following random patterns: Fixed instructions with fixed parameters; Fixed instructions combined with random parameters; Hierarchical wildcard commands are combined with the number of repetitions; Multiple ranges of random addresses or data; Execution involves a random combination of multiple instruction groups, with sequential execution within the same instruction group.

5. The method for generating random instruction test cases according to claim 2, characterized in that, The variable pool supports defining a set of variables by data type and variable name range, and the initial value of the variables is zero by default; non-zero initial values ​​are achieved through assignment instructions in the initialization code.

6. The method for generating random instruction test cases according to claim 2, characterized in that, The instruction set is referenced using hierarchical path expressions of the multi-level nested structure, with different levels connected by separators to limit the range of instructions that can be randomly invoked.

7. The method for generating random instruction test cases according to claim 1, characterized in that, The multi-level nested structure is divided into top-level library, major category, subclass, bit width and instruction level by level. Each level node is associated with the corresponding C inline function name, parameter constraint mnemonic sequence and instruction format constraint.

8. The method for generating random instruction test cases according to claim 1, characterized in that, The function parameter constraint system includes a parameter constraint mnemonic definition module; the parameter constraint mnemonic includes one or more of the following: REG is used to identify register or variable parameters; IMM is used to identify integer immediate values; FLOAT is used to identify immediate floating-point numbers; REG_OR_IMM is used to identify registers or integer immediate values; REG_OR_FLOAT is used to identify registers or floating-point numbers; REG_REF is used to identify variable references.

9. The method for generating random instruction test cases according to claim 1, characterized in that, The function parameter constraint system also includes a parameter data type definition module; the parameter data type definition module is used to define one or more of the following attributes of the parameter: data format type, bit width, whether it is a non-negative number, and whether it is a floating-point number.

10. A random instruction test case generation device, characterized in that, The random instruction test case generation device includes: The instruction encapsulation module is used to encapsulate target instructions or instruction sequences into C inline functions through inline assembly or macro definition, forming a unified function library; The parameter constraint module is used to build a function parameter constraint system, defining parameter types, address ranges, instruction combination methods, and value range constraints for each encapsulated C inline function; The organization instruction construction module is used to construct multi-level nested structure organization instructions based on the C inline functions, wherein each level node is associated with the corresponding C inline function name and constraints; The test case generation module is used to determine the target C inline function from the multi-level nested structure based on the YAML configuration file, and combine them to generate random instruction test cases; wherein, the YAML configuration file includes at least the number of iterations, random seed, random intensity factor and test content configuration.

Images