Test instruction generation method and device, electronic equipment, medium and product

Abstract

The embodiment of the invention discloses a test instruction generation method and device, electronic equipment, a medium and a product. The method comprises the steps that hardware constraint information of a specified processor architecture is obtained, and the hardware constraint information comprises a plurality of threads supported by the specified processor architecture, the number of operators to be executed by each thread and an address space corresponding to each thread; for each thread, according to the number of operators to be executed by the thread, calling different operators through each execution engine, and generating a target operator queue corresponding to the thread; determining a test instruction stream corresponding to a target operator queue of the thread according to the address space corresponding to the thread; wherein each target operator in the target operator queue corresponds to one test instruction in the test instruction stream, and an output address of at least one test instruction in the test instruction stream is an input address of a subsequent test instruction; and generating a test instruction file of the specified processor architecture according to the test instruction stream corresponding to each thread.

Description

TECHNICAL FIELD

[0001] The present application relates to, but is not limited to, the technical field of computer technology, and in particular to a test instruction generation method and device, electronic equipment, medium and product. BACKGROUND

[0002] Single Instruction Multiple Data (SIMD) instruction set architecture is a common parallel computing architecture, which processes multiple data elements simultaneously through one instruction to improve operation efficiency. In order to verify the correctness and stability of the processor using the instruction set architecture, test instructions conforming to hardware constraints can be generated for testing. In related technologies, a random instruction generator is usually used to generate test instructions to simulate various possible execution scenarios.

[0003] However, in actual use, the test instructions generated by the random instruction generator are usually for general instruction set architectures and cannot be directly applied to other special instruction set architectures. Moreover, the generated test instruction sequences are usually logically independent of each other, which can only test the execution function of a single instruction and cannot verify the correctness and stability of processing continuous, multi-step composite computing tasks, thereby failing to simulate complex behaviors close to actual computing task running, resulting in a huge difference between the verification environment and the actual working environment of the chip and seriously reducing the credibility of the verification result. SUMMARY

[0004] Therefore, the embodiments of the present application provide at least a test instruction generation method, device, electronic equipment, medium and product.

[0005] The technical solutions of the embodiments of the present application are implemented as follows: In one aspect, the embodiments of the present application provide a test instruction generation method, which comprises: obtaining hardware constraint information of a specified processor architecture, wherein the hardware constraint information comprises a plurality of threads supported by the specified processor architecture, a number of operators to be executed by each thread, and an address space corresponding to each thread; for each thread, generating a target operator queue corresponding to the thread by calling different operators through each execution engine according to the number of operators to be executed by the thread; determining a test instruction stream corresponding to the target operator queue of the thread according to the address space corresponding to the thread, wherein each target operator in the target operator queue corresponds to one test instruction in the test instruction stream, and the output address of at least one test instruction in the test instruction stream is the input address of a subsequent test instruction; generating a test instruction file of the specified processor architecture according to the test instruction stream corresponding to each thread.

[0006] In some embodiments, the generating, for each thread, a target operator queue corresponding to the thread according to a number of operators to be executed by the thread, comprises: allocating a number of invocations to each of the execution engines randomly to obtain an execution engine queue, wherein each of the execution engines invokes a different operator each time, and the length of the execution engine queue matches the number of operators; allocating a computing operation mode to each of the operators invoked by each of the execution engines randomly in sequence according to the order of the execution engine queue to obtain a target operator queue, wherein each target operator is used to execute a different computing operation mode.

[0007] In some embodiments, the determining, according to an address space corresponding to the thread, a test instruction stream corresponding to the target operator queue of the thread, comprises: obtaining data constraints corresponding to each of the computing operation modes from the hardware constraint information; determining the test instruction stream of the thread according to the data constraints corresponding to each of the target operators in the target operator queue and the address space corresponding to the thread.

[0008] In some embodiments, the hardware constraint information further comprises instruction specification information corresponding to the specified processor architecture; and the determining, according to the data constraints corresponding to each of the target operators in the target operator queue and the address space corresponding to the thread, the test instruction stream of the thread, comprises: generating address information of a first target operator in the address space corresponding to the thread according to the data constraints corresponding to the first target operator, wherein the address information comprises an input start address and an output start address; generating address information of a subsequent target operator having a dependency relationship with the first target operator based on a pre-set instruction dependency relationship; generating the remaining bit segments of each of the target operators in the target operator queue randomly according to the instruction specification information to obtain each test instruction in the test instruction stream of the thread, wherein the remaining bit segments are the remaining bit segments of the test instruction corresponding to the target operator except for the address bit segments; determining the test instruction stream corresponding to the thread according to the test instruction corresponding to each of the target operators.

[0009] In some embodiments, the generating, based on a pre-set instruction dependency relationship, address information of a subsequent target operator having a dependency relationship with the first target operator, comprises: In sequence of the target operator queue, the output start address of a current target operator is sequentially taken as an input start address of a next target operator, until the next target operator is the last target operator.

[0010] In some embodiments, the generating the test instruction file of the specified processor architecture according to the test instruction stream corresponding to each thread comprises: generating a return instruction at the end of the test instruction stream of each thread; outputting the test instruction stream of all the threads in a preset format to obtain the output test instruction file.

[0011] In some embodiments, the method further comprises: randomly determining threads to be synchronized from the plurality of threads; randomly inserting a synchronization instruction into the test instruction stream corresponding to each thread to be synchronized to obtain a test instruction stream corresponding to each thread to be synchronized.

[0012] In another aspect, an embodiment of the present application provides a test instruction generation device, the device comprising: an obtaining module configured to obtain hardware constraint information of a specified processor architecture, wherein the hardware constraint information comprises a plurality of threads supported by the specified processor architecture, a number of operators to be executed by each thread, and an address space corresponding to each thread; a first generating module configured to, for each thread, generate a target operator queue corresponding to the thread by calling different operators through each execution engine according to the number of operators to be executed by the thread; a determining module configured to determine a test instruction stream corresponding to the target operator queue of the thread according to the address space corresponding to the thread, wherein each target operator in the target operator queue corresponds to a test instruction in the test instruction stream, and an output address of at least one test instruction in the test instruction stream is an input address of a subsequent test instruction; a second generating module configured to generate a test instruction file of the specified processor architecture according to the test instruction stream corresponding to each thread.

[0013] In another aspect, an embodiment of the present application provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program running on the processor, and the processor implements any of the methods provided in the embodiments of the present application when executing the program.

[0014] In another aspect, an embodiment of the present application provides a computer storage medium storing executable instructions, when the executable instructions are executed by a processor, the processor executes any one of the methods provided by the embodiments of the present application.

[0015] In still another aspect, an embodiment of the present application provides a computer program product comprising a computer program or instructions, when the computer program or instructions are executed by a processor, the computer program or instructions implement any one of the methods provided by the embodiments of the present application.

[0016] In an embodiment of the present application, a test instruction generation method is provided. Hardware constraint information of a specified processor architecture is obtained, wherein the hardware constraint information comprises a plurality of threads supported by the specified processor architecture, a number of operators to be executed by each thread, and an address space corresponding to each thread. For each thread, a target operator queue corresponding to the thread is generated by invoking different operators by each execution engine according to the number of operators to be executed by the thread. A test instruction stream corresponding to the target operator queue of the thread is determined according to the address space corresponding to the thread. Each target operator in the target operator queue corresponds to a test instruction in the test instruction stream, and an output address of at least one test instruction in the test instruction stream is an input address of a subsequent test instruction. A test instruction file of the specified processor architecture is generated according to the test instruction stream corresponding to each thread. In this way, by generating test instructions according to the hardware constraint information of the specified processor architecture, customized test instructions can be generated for the specified processor architecture, which can ensure that the generated test instructions conform to the hardware specification of the specified processor architecture, and can save computing resources for screening invalid test cases. By constraining the output address of at least one test instruction in the test instruction stream to be the input address of a subsequent test instruction, an instruction sequence with a chained dependency relationship can be automatically constructed to simulate a continuous scenario in a real computing scenario, which can reduce the difference between the verification environment and the actual working environment of the chip and improve the credibility of the verification result. Moreover, by independently generating a test instruction stream corresponding to each thread, the use scenario of multi-thread cooperation can be verified, which can expand the verification scenario of the test instruction and enhance the verification of the concurrent processing capability and stability of the chip.

[0017] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, rather than limiting the technical solutions of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0018] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0019] Figure 1is a flowchart of a test instruction generation method provided by an embodiment of the present application; Figure 2 is another flowchart of a test instruction generation method provided by an embodiment of the present application; Figure 3 is a block diagram of a test instruction generation device provided by an embodiment of the present application; Figure 4 is another flowchart of a test instruction generation method provided by an embodiment of the present application; Figure 5 is a hardware entity diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0020] In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions of the present application are further described in detail below in combination with the drawings and embodiments, and the described embodiments should not be regarded as limiting the present application, and all other embodiments obtained by those skilled in the art without making creative efforts fall within the scope of protection of the present application.

[0021] In the following description, "some embodiments" are described, which describe a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict. The term "first / second / third" referred to is only to distinguish similar objects, and does not represent a specific order of the objects. It can be understood that "first / second / third" can be interchanged in a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the present application and are not intended to limit the present application.

[0023] In the following description, the terms thread, operator, test instruction stream, etc. referred to are core concepts in the present application. In order to facilitate understanding, these terms are first explained: 1) Thread: In processor architecture, a thread refers to an independent execution unit that can execute instructions concurrently. In the present application, each thread has a specific address space and supports a certain number of computing operations (i.e. operators). Through multi-thread parallel processing, test coverage and verification efficiency can be improved.

[0024] 2) Operator: In this application, an operator refers to a functional module or computational pattern in the execution engine for completing a specific computational task, such as addition, multiplication, convolution, etc. Different operators correspond to different instruction structures and parameter configurations, which are the basic elements for generating test instructions.

[0025] 3) Test instruction stream: refers to a data sequence composed of multiple test instructions, used to simulate the actual instruction flow running on a specified processor architecture. Each test instruction corresponds to a target operator, and generates input / output addresses according to hardware constraint conditions to meet the dependency relationship and data flow requirements between threads.

[0026] 4) Address space: In this application, the address space refers to the memory area allocated for each thread, used to store input, output tensors and other intermediate data. The size and distribution of the address space directly affect the generation logic of the test instructions and data consistency.

[0027] 5) Synchronization instruction: in a multi-threaded environment, the synchronization instruction is used to coordinate the execution order between different threads, ensuring that certain operations start after other operations are completed, thereby simulating the concurrent control mechanism in the real scenario.

[0028] 6) Return instruction: an instruction inserted at the end of the test instruction stream, used to identify the end of the thread execution and jump to the termination point of the instruction stream, ensuring the integrity of the entire test process.

[0029] 7) SIMD Core (Single Instruction, Multiple Data Core): the core of the single instruction multiple data architecture, which is a processor architecture capable of processing multiple data items simultaneously, suitable for image processing, deep learning and other fields. This application focuses on a random instruction generation method based on custom SIMD Core, which has the characteristics that the format and bit segment of each instruction are defined according to the special specification, so strict constraint verification is required.

[0030] Single instruction multiple data instruction set architecture is a common parallel computing architecture that processes multiple data elements simultaneously through a single instruction, thereby improving computational efficiency. In order to verify the correctness and stability of the processor using this instruction set architecture, test instructions that meet the hardware constraints can be generated for testing. In related technologies, a random instruction generator is usually used to generate test instructions to simulate various possible execution scenarios.

[0031] But in actual use, the test instructions generated by the random instruction generator are usually for general instruction set architecture and cannot be directly applied to other special instruction set architecture, and the generated test instruction sequence is usually independent in logic, which can only test the execution function of a single instruction and cannot verify the correctness and stability of processing continuous, multi-step composite computing tasks, thereby causing the inability to simulate the complex behavior close to the actual computing task running, resulting in a huge difference between the verification environment and the actual working environment of the chip, which seriously reduces the reliability of the verification result.

[0032] To solve the above problems, the application provides a test instruction generation method, which generates test instructions according to the hardware constraint information of a specified processor architecture, can generate customized test instructions for the specified processor architecture, can ensure that the generated test instructions conform to the hardware specification of the specified processor architecture, can save computing resources for screening invalid test cases, and can automatically build an instruction sequence with a chain dependency relationship by constraining the output address of at least one test instruction in the test instruction stream to be the input address of the subsequent test instruction, to simulate the continuous scene in the real computing scene, can reduce the difference between the verification environment and the actual working environment of the chip, and improve the reliability of the verification result. Moreover, the test instruction stream corresponding to each thread is independently generated, which can be used to verify the use scenario of multi-thread cooperative work, can expand the verification scenario of the test instruction, and can enhance the verification of the concurrent processing capability and stability of the chip.

[0033] The test instruction generation method provided by the embodiments of the application can be executed by a computer system, which can be a server, a development terminal or other devices with processing capability. That is, the test instruction generation method of the embodiments of the application can be run in any programming language supported environment through a software program, or can be deployed on an automated verification platform for large-scale test instruction generation.

[0034] Figure 1 is a flowchart of the test instruction generation method provided by the embodiments of the application, which will be described below in combination with the steps shown in Figure 1 As shown in Figure 1 , the method comprises the following steps S101 to S104: Step S101, obtaining the hardware constraint information of a specified processor architecture.

[0035] The hardware constraint information can be basic data used to guide the generation of subsequent test instructions, and can include but is not limited to a plurality of threads supported by a specified processor architecture, a number of operators to be executed by each thread, and an address space corresponding to each thread. The hardware constraint information can be used to determine whether the structure and content of the instruction stream conform to the physical characteristics of the specified processor. For example, in a SIMD core, the SIMD core can support a maximum of 8 concurrent threads, each thread can execute 32 operators, and the address space of each thread is 64KB or 128KB, etc. In this way, the parameters in the hardware constraint information can be extracted from the chip design document, or by parsing the instruction set description file (such as YAML format) to obtain the parameters in the hardware constraint information.

[0036] In the case of a multi-threaded architecture of the specified processor, different threads can be executed in parallel, thereby improving instruction throughput and test coverage. The number of operators refers to the maximum number of operations that can be executed by each thread. The operator is a basic functional module in the execution engine of the specified processor, such as addition, multiplication, convolution, etc. These operators are usually corresponding to specific instructions. The address space is a memory region allocated for each thread, which can be used to store input tensors, output tensors and intermediate results. The size and distribution of the address space determine the address dependency relationship between instructions in the instruction stream, ensuring the correctness and effectiveness of the instructions. For example, if the address space of a thread is 64KB, all instructions belonging to this thread must use address values not exceeding this range.

[0037] In this step, by reading the instruction set specification document of the processor, the key parameters can be extracted by using Python script to generate a configuration file containing the number of threads, the number of operators and the address space, etc. The configuration file can be a structured machine-readable configuration file (such as YAML format or JSON format). The file completely defines the hardware rule set that must be followed in the subsequent test instruction generation process, ensuring the effectiveness, executability and compliant access to hardware resources of the generated instructions on the target architecture.

[0038] Step S102, for each thread, according to the number of operators to be executed by the thread, different operators are called by each execution engine to generate a target operator queue corresponding to the thread.

[0039] The execution engine can be a virtual machine environment, a compiler front end, or a simulator, which can be responsible for executing specific types of calculations in the processor, such as vector calculation engine, scalar calculation engine, load / store engine, special function engine, etc. Each engine can execute one or more specific operators. The operator represents an atomic, indivisible calculation or operation instruction type, which can be instantiated as an instruction after being assigned specific parameters.

[0040] Considering that real-world computing tasks (such as image processing, scientific computing) are almost not completed by a single instruction, but are composed of a series of associated computing steps. By generating a queue, instead of just random isolated instructions, the working state of the processor under the driving of the real application program can be highly simulated, so that deeper design defects can be found.

[0041] Therefore, in this step, for each thread, an actual operator quantity can be randomly generated for the current thread according to the operator quantity to be executed by the thread, and based on the actual operator quantity, a sequence with a length consistent with the actual operator quantity can be randomly generated, and each element in the sequence can represent each execution engine for executing the test computing task. The actual operator quantity can meet the operator quantity constraint to be executed by the thread. By randomly scheduling different execution engines, it can be ensured that all computing units have a probability of being called, which can avoid verification vulnerabilities.

[0042] For example, in the case of an actual operator quantity of 4, a sequence can be randomly generated, which can be represented as: VEC_ENGINE, LDST_ENGINE, VEC_ENGINE, SCL_ENGINE, …. Where VEC_ENGINE can represent a vector engine, and LDST_ENGINE can represent a load and store engine.

[0043] After obtaining the execution engine sequence, for each execution engine in the execution engine sequence, a target operator can be randomly selected from the operators supported by the execution engine, as a target operator, to obtain an operator queue composed of multiple specific operators, and the operator queue is the target operator queue.

[0044] For example, VEC_ENGINE can support, but is not limited to, VADD (vector addition), VSUB (vector subtraction), VAND (vector bitwise AND), and the like; LDST_ENGINE can support, but is not limited to, LOAD (load), STORE (store), PACK (data packing), and the like, VADD can be randomly selected as the target operator of the first VEC_ENGINE, LOAD can be selected as the target operator of the first LDST_ENGINE, and VAND can be selected as the target operator of the second VEC_ENGINE, and accordingly, an ordered queue composed of specific operators can be obtained: VADD, LOAD, VAND, …, and this queue is the target operator queue.

[0045] Step S103, determining a test instruction stream corresponding to the target operator queue of the thread according to the address space corresponding to the thread.

[0046] Each target operator in the target operator queue corresponds to a test instruction in the test instruction stream, and the output address of at least one test instruction in the test instruction stream is the input address of a subsequent test instruction.

[0047] Each thread in the designated processor has an independent memory address range, and the memory in the address range can store the instruction operands, intermediate results and final results of the thread to avoid resource conflicts between threads.

[0048] In this step, each target operator in the target operator queue can be allocated an operand address in the address space.

[0049] In some embodiments, for the first operator in the target operator queue, an unoccupied address can be randomly selected according to the operation requirements of the operator, or an initial input address can be allocated from the address space of the thread according to a preset allocation rule, and the output address for storing the calculation result of the operator can also be allocated in the same way. The output address needs to meet the hardware constraints of the processor such as memory alignment requirements and address range limitations. For example, if the first operator is an int8 vector addition, according to the operation requirements corresponding to the vector addition, it can be determined that it needs 2 input vectors and 1 output vector, so the input address 1 of the first input vector can be randomly determined as 0x0000~0x00FF from the address space of the thread, the input address 2 of the second input vector can be randomly determined as 0x0100~0x01FF, and the output address can be randomly determined as 0x0200~0x02FF.

[0050] After obtaining the operand address, the target operator can be translated into a test instruction conforming to the architecture specification of the designated processor according to the instruction template.

[0051] The instruction template can be generated based on the hardware constraint information of the designated processor architecture, different operator types can correspond to different instruction templates, and the instruction template can include multiple instruction bit segments, each instruction bit segment can correspond to different encoding information.

[0052] In some embodiments, the instruction bit segment can include but is not limited to an operation code bit segment, a source operand address bit segment, a destination operand address bit segment, a data type bit segment, a vector length bit segment, and a condition bit segment.

[0053] After obtaining the operand address, a corresponding instruction template can be selected from a predefined template library according to the type of the target operator, and then a plurality of instruction bits of the target operator can be filled according to the operand address. For example, the operation type of the operator can be mapped to an operation code, and the corresponding operation code bit segment can be filled in; the allocated input address can be encoded as the value of the source operand bit segment, and the source operand address bit segment can be filled in; the output address can be encoded as the value of the destination operand bit segment, and the destination operand address bit segment can be filled in; and according to the data type (such as int8), the vector length (such as 8 elements), and other information of the operator, the corresponding remaining bit segments can be filled in, and thus the first test instruction can be obtained.

[0054] In some embodiments, for the remaining operators in the target operator queue, when allocating the input address thereof, the output address of the previous instruction can be forced to be at least one input address of the current instruction, while a new output address (which can be an input of the next instruction) is allocated for the current instruction, and so on to form a data dependency chain. For example, if the second operator is an int8 vector multiplication, the input address 1 is constrained to be the output address (0x0200~0x02FF) of the first instruction, the input address 2 can be allocated a new address (0x0300~0x03FF), and the output address can be allocated 0x0400~0x04FF. Then the second operator can be converted into the instruction: VMUL.Int8 0x0400, 0x0200, 0x0300 (dependent on the result of the first instruction). If the third operator is an int8 vector subtraction, the input address 1 can be constrained to be the output address (0x0400~0x04FF) of the second instruction, and thus a longer dependency chain can be formed.

[0055] After obtaining the operand addresses of the remaining operators in the target operator queue, the same steps as those for the first target operator can be used to translate the remaining operators into the remaining test instructions in accordance with the instruction templates, so as to conform to the specified processor architecture specification.

[0056] Finally, the test instruction stream including the first test instruction and the remaining test instructions can be obtained.

[0057] In this way, the instructions generated based on the thread-specific address space can avoid address conflicts during multi-thread testing, and by associating the output address of the current instruction with the input address of the subsequent instruction, the instruction stream is no longer an isolated instruction set, but simulates a continuous process in which data is processed in multiple steps in a real task. Compared with independent instructions that can only test the correctness of a single function, the chain-dependent instruction stream can verify the correctness of the processor when processing a composite calculation.

[0058] In step S104, a test instruction file of the specified processor architecture can be generated according to the test instruction stream corresponding to each thread.

[0059] The final output test instruction file can contain the test instruction streams of all threads and be organized in a certain format. The test instruction file can be in binary format, text format, or other standard formats suitable for the target processor.

[0060] The test instruction file is used to provide the prototype verification team, software team, or simulation platform for further functional testing, performance evaluation, or debugging. In actual implementation, the developer packs the test instruction streams of each thread into a unified test instruction file according to the agreed format, and adds necessary metadata (such as version number, timestamp, etc.) to facilitate subsequent management and calling. In addition, the developer can insert synchronization instructions and return instructions in the test instruction file to enhance the diversity and completeness of the test scenario.

[0061] By using the above technical solution, the test instruction is generated based on the hardware constraint information of the specified processor architecture, so that the customized test instruction can be generated for the specified processor architecture, ensuring that the generated test instruction conforms to the hardware specification of the specified processor architecture, and saving the computing resources for screening invalid test cases. By constraining the output address of at least one test instruction in the test instruction stream to be the input address of the subsequent test instruction, the instruction sequence with a chain-like dependency relationship is automatically constructed to simulate the continuous scenario in the real computing scenario, which can reduce the difference between the verification environment and the actual working environment of the chip, and improve the credibility of the verification result. Moreover, by independently generating the test instruction stream corresponding to each thread, the use scenario of multi-thread cooperative work can be verified, which can expand the verification scenario of the test instruction, and enhance the verification strength of the concurrent processing capability and stability of the chip.

[0062] In some embodiments, the above step S102 can be implemented by steps S1021 and S1022: Step S1021, randomly assigning a call number to each execution engine to obtain an execution engine queue.

[0063] Each execution engine calls a different operator each time, and the length of the execution engine queue matches the number of operators.

[0064] In this step, first, the supported execution engines of the specified processor architecture are determined based on the hardware constraint information of the specified processor architecture. Next, a call number is randomly assigned to each execution engine, and the assigned call number is randomly expanded to obtain a flat and ordered execution engine queue. The length of the queue is less than or equal to the maximum number of operators supported by the thread.

[0065] For example, the execution engines supported by the specified processor architecture can include, but are not limited to, a VEC_ENGINE (vector engine), an LDST_ENGINE (load store engine), and an SCL_ENGINE (scalar engine), 3 invocations can be assigned to the VEC_ENGINE, 2 invocations can be assigned to the LDST_ENGINE, and 1 invocation can be assigned to the SCL_ENGINE (scalar engine), and then an execution engine queue can be obtained, which can be represented as VEC, VEC, VEC, LDST, LDST, SCL. The execution engine queue explicitly specifies the order of instruction generation: first, 3 vector instructions are generated, then 2 load store instructions are generated, and finally 1 scalar instruction is generated. In this way, the test generator can be forced to use all types of engines by randomly assigning the number of invocations, avoiding test vulnerabilities.

[0066] In a possible implementation, when generating the execution engine queue, the invocation behaviors of the same execution engine can be clustered together, considering that a real program usually continuously loads data first, then performs a series of vector calculations, and finally stores the results, which can be closer to a real scenario than a completely random instruction sequence.

[0067] It should be noted that in the execution engine queue, each execution engine invokes a different operator.

[0068] Step S1022, randomly assign a calculation operation mode to each operator invoked by each execution engine in sequence according to the order of the execution engine queue, and obtain a target operator queue.

[0069] Each target operator is used to perform a different calculation operation mode.

[0070] In this step, the execution engine queue can include multiple entries, each entry can correspond to an invocation operation of an execution engine, and for each entry in the execution engine queue, an operator can be randomly selected from the operators supported by the engine, and a calculation operation mode can be randomly assigned to the operator.

[0071] An operator refers to a basic operation that can be performed by the execution engine. For example, for a vector arithmetic engine (VEU), it can support various arithmetic operations on vectors, including but not limited to ADD vector addition, SUB vector subtraction, MUL vector multiplication, and other operation operations. The operator is any one of the multiple operation operations that the VEU can perform, and the specific operation is not limited here.

[0072] The calculation operation mode refers to the specific operation type of the same operator. For example, for a vector arithmetic engine (VEU), the calculation operation mode refers to the ADD vector addition, SUB vector subtraction, MUL vector multiplication, and other operation operations.

[0073] In the case of obtaining the execution engine queue, the mapping relationship of each execution engine and the supported calculation operation mode can be obtained from the hardware constraint information. For example, the LSU (memory access engine) supports three calculation operation modes of memory loading (LDR), memory storage (STR), and aligned loading (ALDR); the VEU (vector arithmetic engine) supports three calculation operation modes of vector addition (ADD), vector multiplication (MUL), and fused multiply-add (FMA).

[0074] According to the order of the execution engine queue, each entry in the current execution engine queue to be processed can be extracted in turn, and the current extracted entry can be marked as the current operator, for example, the first element "LSU" in the queue is extracted first, and the second element "VEU" is extracted after the processing is completed, until all entries in the queue are traversed; then based on the hardware constraint, all calculation operation modes supported by the current entry can be filtered out (which can be marked as "initial available mode set"), for example, when the current engine is LSU, the initial available mode set is {LDR, STR, ALDR}; the "previous call record" of the execution engine in the queue is queried, if there is an allocated calculation operation mode, the used modes are excluded from the initial available mode set, to obtain the "final available mode set", for example, the current engine is the second call of LSU in the queue, and the "LDR" mode has been allocated in the first call, so the final available mode set is {STR, ALDR}; if the execution engine is the first call (no previous record), the final available mode set is consistent with the initial available mode set.

[0075] After obtaining the available calculation operation mode of the current engine, the calculation operation mode can be randomly allocated. An algorithm (such as a uniform random sampling algorithm) that meets the test randomness requirement is used to randomly select a calculation operation mode from the final available mode set as the mode corresponding to the current engine call, for example, "STR" is randomly selected from {STR, ALDR}.

[0076] After the operators in the execution engine queue are assigned with corresponding computing operation modes, target operators can be generated and added to the queue. The combination of the current engine and the randomly assigned computing operation mode can form a target operator (such as "LSU-STR", representing an operator for performing memory storage operation on LSU), and the target operator can be sequentially added to the target operator queue. The above steps can be repeated for each operator in the execution engine queue until all elements in the execution engine queue are traversed, at which time the length of the target operator queue is consistent with the execution engine queue, and each element is a compliant operator with "engine-mode" matching and no repeated mode, for example, the target operator queue generated based on the queue [LSU, VEU, LSU, VLU, VEU] is [LSU-LDR, VEU-ADD, LSU-STR, VLU-AND, VEU-MUL].

[0077] By using the technical solution, through the engine and mode matching constraints, it can be ensured that each generated target operator conforms to the hardware execution logic of the specified processor, avoiding the generation of invalid test instructions based on the operators subsequently, and reducing the invalid verification cost. Moreover, through the mode uniqueness constraint and the random allocation of modes, the diversified operation capabilities of each execution engine can be covered, and different operation combination scenarios that the processor may encounter in actual work can be simulated through randomness, thereby the difference between the verification environment and the actual working environment of the chip can be reduced.

[0078] In some embodiments, the above step S103 can be implemented through step S1031 and step S1032: Step S1031, obtaining the data constraint corresponding to each computing operation mode from the hardware constraint information.

[0079] The hardware constraint information refers to the content defined by the custom SIMD Core architecture document, which describes the input and output format, data type, memory access mode, and other limitation conditions supported by different computing operation modes. The hardware constraint information usually includes hard regulations on tensor shape, memory alignment, register usage, data width, etc. For example, the computing operation mode can only support fixed-size tensor input, or require a specific data arrangement order, in order to improve the execution efficiency of the SIMD Core.

[0080] The data constraint represents the specific parameter range and structure requirement of the data that can be processed by a specific computing operation mode under a specific computing operation mode. For example, the computing operation mode can require that the input tensor must be 4-dimensional, and the length of the first dimension must be a multiple of 8, or require that the output tensor must have the same memory layout as the input tensor. The data constraint ensures that the generated instructions conform to the hardware design specification, so as to prevent illegal instructions from being generated, thereby avoiding the occurrence of verification failure or hardware exception.

[0081] In some embodiments, the data constraints can include, but are not limited to, data interaction type constraints, resource usage type constraints, and structure type constraints. Among them, the data interaction type constraints can be used to represent input / output format (such as dimension arrangement of tensors, data bit width matching rules), data type (such as only supporting int8 / int16 / float32, not supporting float64), memory access mode (such as only supporting aligned access, prohibiting non-aligned address read / write) and the like; the resource usage type constraints can be used to represent register usage restrictions (such as a specific calculation operation mode can only use a certain group of vector registers, register read / write sequence), data width matching (such as the input data bit width needs to be a multiple of the number of SIMD lanes, such as 8Lane SIMD Core needs int8 data length to be a multiple of 8) and the like; the structure type constraints can be used to represent tensor shape restrictions (such as only supporting 4-dimensional tensors, the first dimension length needs to be a fixed multiple of 8 / 16), memory layout requirements (such as the output tensor needs to maintain the same row-major / column-major layout as the input tensor) and the like.

[0082] In this step, first, a mapping relationship between the calculation operation mode and the hardware constraint information can be established. In the architecture document of the customized SIMD Core, the hardware constraint information is usually described by calculation operation mode, wherein the hardware implementation logic of different calculation operation modes is different, and the supported data range and structure requirements also differ, and there is no case that all modes share the same set of data constraints. Therefore, first, the constraint chapter corresponding to each calculation operation mode can be located in the document to establish an explicit mapping relationship.

[0083] The specific parameters of the data constraints are extracted from the corresponding constraint chapter. After locating the hardware constraint chapter corresponding to a calculation operation mode, the specific restrictions related to data in the chapter are further extracted to form data constraints exclusive to the mode. For example, if the constraint description of the 4-dimensional tensor input mode in the document is “the input tensor must be 4-dimensional, and the length of the first dimension is a multiple of 8”, the extracted data constraints are “tensor dimension = 4, the length of the first dimension ∈ {8, 16, 24,...} (positive integer multiples of 8)”.

[0084] The extracted data constraints can be stored in the form of “parameter list” or “rule set” as the basis for judgment in subsequent steps (such as checking address alignment when allocating operand addresses, confirming tensor dimensions when generating data).

[0085] Step S1032, determining the test instruction stream of the thread according to the data constraints corresponding to each target operator in the target operator queue and the address space corresponding to the thread.

[0086] In this step, the target operator in the target operator queue can be iterated in a loop, and for each target operator, the test instruction corresponding to the target operator can be determined according to the data constraint corresponding to the target operator and the address space corresponding to the thread. Then, the test instruction stream can be obtained based on the plurality of test instructions.

[0087] In some embodiments, the hardware constraint information further includes instruction specification information corresponding to the processor architecture. Therefore, the test instruction stream of the thread can be determined by the following steps: S1, in the address space corresponding to the thread, the address information of the first target operator is generated according to the data constraint corresponding to the first target operator.

[0088] The address information includes an input start address and an output start address.

[0089] In this step, the data constraint of the load operator can be obtained first, and a memory region that satisfies all constraints and has not been occupied can be found in the memory address range of the thread, and the start position of the region can be taken as the input start address. For example, the data constraint of the load operator can be "the address must be 16-byte aligned" and "the data block size is 256 bytes", and then a 256-byte free region starting from 0x0000 and aligned to 16 bytes can be found in the memory address range of the thread. The input start address is 0x0000. The region from 0x0000 to 0x00FF can be marked as "occupied", so as to prevent data conflict caused by repeated use of subsequent instructions.

[0090] If the first operator is a calculation type, the data constraint of the calculation operator can be obtained, such as "the input must be a vector register" and "special-purpose registers R0-R7 are not allowed to be used". Then the register file can be scanned to find free general-purpose vector registers in the register file of the thread according to the constraint. The register number found is taken as the "input start address". For example, free registers R8 and R9 are found, which are the two input start addresses of the addition operator. Finally, R8 and R9 can be marked as "occupied" to prevent data conflict caused by repeated use of subsequent instructions.

[0091] S2, based on the pre-set instruction dependency relationship, the address information of the subsequent target operator having a dependency relationship with the first target operator is generated.

[0092] In some embodiments, the output start address of the current target operator can be sequentially taken as the input start address of the adjacent next target operator in the order of the target operator queue, until the next target operator is the last target operator.

[0093] S3, according to the instruction specification information, randomly generating the rest bit segment of each target operator in the target operator queue to obtain each test instruction in the test instruction stream of the thread.

[0094] The rest bit segment is a rest bit segment of the target operator in the test instruction.

[0095] In this step, the rest bit segment of each target operator in the target operator queue can be randomly generated according to the instruction template to translate the target operator into a test instruction conforming to the specified processor architecture specification.

[0096] The instruction template can be generated based on the hardware constraint information of the specified processor architecture, different operator types can correspond to different instruction templates, and the instruction template can include multiple instruction bit segments, each instruction bit segment can correspond to different encoding information.

[0097] The instruction bit segment can include but is not limited to an operation code bit segment, a source operand address bit segment, a destination operand address bit segment, a data type bit segment, a vector length bit segment, and a condition bit segment.

[0098] After obtaining the address information, the corresponding instruction template can be selected from the pre-defined template library according to the type of the target operator, and then the multiple instruction bit segments of the target operator can be filled according to the operand address. For example, the operation type of the operator can be mapped to the operation code, the corresponding operation code bit segment can be filled, the allocated input address can be encoded as the value of the source operand bit segment, the output address can be encoded as the value of the destination operand bit segment, and the rest bit segments can be filled according to the data type (such as int8), vector length (such as 8 elements) and other information of the operator, and the first test instruction can be obtained.

[0099] Optionally, for the rest of the operators in the target operator queue, when allocating the input address, the output address of the previous instruction can be forced to be at least one input address of the current instruction, and a new output address (which can be used as the input of the next instruction) is allocated for the current instruction, and so on to form a data dependency chain. For example, if the second operator is an int8 vector multiplication, the input address 1 is constrained to be the output address (0x0200~0x02FF) of the first instruction, the input address 2 can be allocated a new address (0x0300~0x03FF), and the output address can be allocated 0x0400~0x04FF. Then the second operator can be converted into the instruction: VMUL.Int80x0400, 0x0200, 0x0300 (dependent on the result of the first instruction). If the third operator is an int8 vector subtraction, the input address 1 can be constrained to be the output address (0x0400~0x04FF) of the second instruction, so as to form a longer dependency chain.

[0100] After obtaining the address information of the remaining operators in the target operator queue, the same steps as for the first target operator can be used to translate the remaining operators into other test instructions that conform to the specified processor architecture specifications according to the instruction template.

[0101] S4. The test instruction stream corresponding to the thread can be determined based on the test instructions corresponding to each target operator.

[0102] By adopting the above technical solution, the generation of illegal instructions can be eliminated and the consumption of invalid verification can be significantly reduced by using data constraint-driven address generation and instruction specification constraint bit field filling. Furthermore, by forcing the input address of subsequent test instructions to be associated with the output address of the preceding instructions, continuous data flow can be simulated to verify the stability of composite computing. This can narrow the difference between the verification environment and the actual working environment of the chip, making the verification results more reflective of the correctness of the chip in real business scenarios and greatly improving the credibility of the verification results.

[0103] In some embodiments, step S104 can be implemented by steps S1041 and S1042: Step S1041: Generate a return instruction at the end of the test instruction stream for each thread.

[0104] The return instruction is an instruction used to indicate that each thread has completed its task and exited the current execution flow after all its operations have been executed. Return instructions typically include an end flag, status code, and other information to ensure that the specified processor architecture can correctly identify the end point of each thread's execution and perform subsequent processing or resource release.

[0105] In practical applications, return instructions can be implemented in various ways, such as the RET (Return) instruction, the HALT instruction, or other custom termination instructions. Different instruction types are suitable for specific processor architectures, so when generating return instructions, they can be adapted according to the requirements of the target processor architecture. This method of adapting return instructions to different processor architectures not only improves the standardization and readability of the instruction flow but also facilitates error localization during debugging and verification.

[0106] By adding return instructions to the test instruction stream for each thread, the system can clearly distinguish the execution boundaries of each thread, thereby improving the stability and reliability of multi-threaded testing environments. Furthermore, return instructions can also serve as part of a synchronization mechanism, helping to coordinate the execution order among multiple threads.

[0107] Step S1042: Output the test instruction streams of all returned threads according to the preset format to obtain the output test instruction file.

[0108] The preset format refers to a standardized data structure and organization method followed when generating the test instruction file. The preset format generally includes a file header, a thread identifier, an instruction sequence, a parameter field, a check bit, and the like. This design ensures that the generated test instruction file is universal between different tool chains and platforms. The design of the preset format is based on the instruction set description document of the target specified processor architecture, and is optimized in combination with test requirements to improve test coverage and instruction compatibility.

[0109] In actual applications, the preset format can adopt various data exchange formats, such as YAML, JSON, or binary format, and the like. The YAML format is often used for input configuration of test scripts due to its good readability and structural characteristics. The JSON format is relatively common in automated testing environments due to its wide support and parsing efficiency. Selecting a suitable preset format helps to improve the parsing efficiency and cross-platform compatibility of the test instruction file corresponding to the preset format.

[0110] By uniformly outputting the test instruction streams of all threads in the preset format, the system can generate standardized test cases, which facilitates subsequent simulation, verification, and debugging work. At the same time, the preset format provides convenience for version management and team collaboration of the test instruction file, and improves the overall development efficiency and test quality.

[0111] By generating a return instruction at the end of the test instruction stream of each thread and outputting the test instruction streams of all threads in the preset format, the method can ensure the integrity and consistency of the test instruction stream, and thus improve the test coverage and verification efficiency of the SIMD Core in the specified processor architecture.

[0112] Figure 2 is another optional flowchart of the test instruction generation method provided by the embodiment of the present application. The following will be described in combination with the steps shown in Figure 2 As shown in Figure 2 , the method includes the following steps S105 and S106: Step S105, randomly determine a to-be-synchronized thread in a plurality of threads.

[0113] In this step, random determination refers to randomly selecting a plurality of threads as to-be-synchronized threads in the plurality of threads according to a certain probability distribution or algorithm. The plurality of to-be-synchronized threads will be inserted with synchronization instructions in the subsequent test instruction stream to simulate the synchronization behavior between multiple threads. The selection of the synchronization thread can be implemented based on a uniform distribution, a normal distribution, or other probability models suitable for the current test scenario.

[0114] The operation of randomly selecting multiple threads to be synchronized can help the test tool to improve the diversity and coverage of the test, and avoid the test blind area caused by using a fixed mode. The behavior of the test tool inserting synchronization instructions on different threads can more realistically simulate the thread competition and cooperation that may occur in the actual running environment, thereby improving the robustness verification effect of the test platform on the SIMD Core in a concurrent environment.

[0115] In step S106, a synchronization instruction is randomly inserted in the test instruction stream corresponding to each thread to be synchronized, to obtain a test instruction stream corresponding to each thread to be synchronized.

[0116] The synchronization instruction is a control instruction used to coordinate the execution order of multiple threads, such as barrier, fence, etc. Before the synchronization instruction is executed, it will wait for other specified threads to complete to a certain stage before continuing to execute.

[0117] In this step, random insertion means that the synchronization instruction is inserted at an appropriate position in the generated test instruction stream according to a certain probability rule. In this way, the position and frequency of the synchronization operation have uncertainty, so as to cover more execution paths and timing combinations.

[0118] The insertion mode of the synchronization instruction can include fixed interval insertion, random position insertion, dynamic insertion based on thread state, etc. By randomly inserting the synchronization instruction, the dependence relationship and synchronization behavior between threads under different loads and concurrency conditions can be effectively simulated, so as to comprehensively evaluate the performance and stability of the SIMD Core under complex concurrent scenarios. In addition, the random insertion of the synchronization instruction can help to discover potential data competition, deadlock, etc. problems, and improve the completeness and accuracy of chip verification.

[0119] By using the above technical solution, the threads to be synchronized are randomly determined in multiple threads, and the synchronization instruction is randomly inserted in the corresponding test instruction stream. This method can enhance the diversity and coverage of the test case, so as to more comprehensively verify the behavior characteristics of the SIMD Core in a multi-thread environment, and thus improve the efficiency and reliability of chip verification.

[0120] The test instruction generation method provided by the embodiment of the application can be executed by the test instruction generation device. In the embodiment of the application, the test instruction generation method executed by the test instruction generation device is taken as an example to illustrate the test instruction generation device provided by the embodiment of the application.

[0121] Figure 3 is a block diagram of a test instruction generation device provided by the embodiment of the application, as shown in Figure 3 The device 300 includes: The acquisition module 301 is configured to acquire hardware constraint information of a specified processor architecture, wherein the hardware constraint information comprises a plurality of threads supported by the specified processor architecture, a number of operators to be executed by each thread, and an address space corresponding to each thread. The first generation module 302 is configured to generate, for each thread, a target operator queue corresponding to the thread by calling different operators by each execution engine according to the number of operators to be executed by the thread. The determination module 303 is configured to determine a test instruction stream corresponding to the target operator queue of the thread according to the address space corresponding to the thread, wherein each target operator in the target operator queue corresponds to a test instruction in the test instruction stream, and an output address of at least one test instruction in the test instruction stream is an input address of a subsequent test instruction. The second generation module 304 is configured to generate a test instruction file of the specified processor architecture according to the test instruction stream corresponding to each thread.

[0122] In some embodiments, the first generation module 302 comprises: The first allocation sub-module is configured to obtain an execution engine queue by randomly allocating a calling number to each execution engine, wherein each execution engine calls a different operator each time, and the length of the execution engine queue matches the number of operators. The second allocation sub-module is configured to randomly allocate a computing operation mode to each operator called by each execution engine in sequence according to the order of the execution engine queue to obtain a target operator queue, wherein each target operator is used to execute a different computing operation mode.

[0123] Optionally, the determination module 303 comprises: The acquisition sub-module is configured to acquire, from the hardware constraint information, data constraints corresponding to each computing operation mode. The determination sub-module is configured to determine the test instruction stream of the thread according to the data constraints corresponding to each target operator in the target operator queue and the address space corresponding to the thread.

[0124] In some embodiments, the determination sub-module is configured to generate, in the address space corresponding to the thread, address information of a first target operator according to data constraints corresponding to the first target operator, the address information comprising an input start address and an output start address; generate address information of a subsequent target operator having a dependency relationship with the first target operator based on a pre-set instruction dependency relationship; randomly generate a remaining bit segment of each target operator in the target operator queue according to instruction specification information to obtain each test instruction in the test instruction stream of the thread; the remaining bit segment is a remaining bit segment of the test instruction corresponding to the target operator except for an address bit segment; and determine the test instruction stream corresponding to the thread according to the test instruction corresponding to each target operator.

[0125] In some embodiments, the determining sub-module is configured to sequentially set the output start address of a current target operator as the input start address of a next target operator in sequence of the target operator queue until the next target operator is the last target operator.

[0126] In some embodiments, the second generating module 304 is configured to include: The generating sub-module is configured to generate a return instruction at the end of the test instruction stream of each thread; The output sub-module is configured to output the returned test instruction streams of all threads in a preset format to obtain an output test instruction file.

[0127] In some embodiments, the apparatus further includes: The to-be-synchronized module is configured to randomly determine to-be-synchronized threads in the plurality of threads; The inserting module is configured to randomly insert a synchronization instruction into the test instruction stream corresponding to each to-be-synchronized thread to obtain the test instruction stream corresponding to each to-be-synchronized thread.

[0128] With the above apparatus, the test instruction can be generated for the specified processor architecture by taking the hardware constraint information of the specified processor architecture as the basis, so that the test instruction generated can conform to the hardware specification of the specified processor architecture, and the computing resources for screening invalid test cases can be saved. The output address of at least one test instruction in the test instruction stream is constrained to be the input address of a subsequent test instruction, so as to automatically construct an instruction sequence with a chain-like dependency relationship to simulate a continuous scene in a real computing scene, so that the difference between the verification environment and the actual working environment of the chip can be reduced, and the reliability of the verification result can be improved. Moreover, the test instruction stream corresponding to each thread can be independently generated, which can be used to verify the use scenario of multi-thread cooperative work, can expand the verification scenario of the test instruction, and can enhance the verification intensity of the concurrent processing capability and stability of the chip.

[0129] The above description of the apparatus side embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the apparatus embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0130] The following describes the application of the test instruction generation in actual scenarios provided by the embodiments of the present application, mainly involving a method for generating test instructions based on a customized SIMD Core random instruction generator.

[0131] The customized SIMD Core instruction architecture is a special instruction architecture, each domain segment of the instruction has its own unique meaning and constraint, and a lot of efforts and work are needed to generate a test instruction conforming to the specification. The random instruction generator can be used to randomly generate all instructions conforming to the constraints of the SIMD Core instruction architecture and possible cooperation between the instructions, so as to accelerate the convergence speed of the SIMD Core verification and improve the completeness of the chip verification.

[0132] By adopting the steps in the above embodiments, the verification progress of the chip can be accelerated, and human resources can be saved; and the generated test instruction can comprehensively cover the running scene of the SIMD Core, and the completeness is improved.

[0133] The main features of the technical solutions provided in the embodiments of the present application are as follows: first, the generated test instruction is based on the customized SIMD Core, and has higher pertinence; second, the instruction architecture of the generated test instruction is generated based on the instruction description of the SIMD Core instruction architecture, and has higher accuracy, avoiding generating invalid instructions; third, the generated test instruction is generated for each thread, which can improve the diversity of the test scene, and can verify the working conditions of multiple different execution units of the processor in a real concurrent state at one time; fourth, the test instruction is generated based on the address as the primary constraint through the inter-thread and intra-thread constraints, so that the instruction flow close to the real instruction flow can be constructed through the chain-like dependency of the address, and the verification depth is improved; fifth, the synchronization instruction and the return instruction inserted in the generated test instruction flow are randomly generated independently of other instructions, so that the control flow and the data flow can be decoupled, and the cycle of the real computing task can be simulated more realistically.

[0134] In the embodiments of the present application, the test instruction flow can be generated by the stimulus generator.

[0135] Figure 4 is another optional flowchart of the test instruction generation method provided in the embodiments of the present application, which will be described below in combination with the steps shown in Figure 4 As shown in Figure 4 The method includes the following steps S401 to S411. Step S401, based on the instruction description document given by the architecture, an instruction description file is generated.

[0136] In this step, based on the instruction set structure table file given by the customized SIMD Core architecture, the python script is used to extract the instruction related information, and the yaml file of the instruction description is generated, which is used as the input file of the random instruction generation, that is, the instruction description file corresponding to the hardware constraint information of the specified processor architecture.

[0137] The instruction description document provided by the architecture is the original data source of the hardware constraint information in the above embodiment, and the generated instruction description yaml file is the hardware constraint information in the above embodiment.

[0138] In step S402, the required number of threads is generated according to the instruction description.

[0139] In this step, the number of threads supported by the hardware can be obtained, and the threads are constrained within a suitable range, and the number of instructions of each thread is also constrained.

[0140] The number of threads supported by the hardware is the number of threads supported by the specified processor architecture in the above embodiment, which can be obtained from the hardware constraint information of the specified processor architecture. The number of instructions in the number of instructions of each thread is the number of operators to be executed by each thread in the above embodiment. The number of instructions can be the number of generated instructions prepared for each thread, and the upper limit and generation strategy of this number are constrained by the specified processor architecture itself (i.e. processing capability).

[0141] In step S403, the address space required for each thread calculation is generated according to the number of instruction threads.

[0142] The address space required for each thread calculation is the address space corresponding to each thread in the above embodiment, which can be obtained from the hardware constraint information of the specified processor architecture, and is used to define the memory address range that each thread can access.

[0143] Generating the address space required for each thread calculation means that according to the obtained hardware constraints (such as the address space base address and size of each thread), the unique and protected memory address region of each thread in this test is specifically divided and initialized. This ensures that there is no address conflict when the thread is executed, so as to meet the memory management constraints of the hardware.

[0144] In step S404, the number of operator calculations and the number of threads are randomly generated.

[0145] In this step, the number of instructions can be used to randomly determine the number and order of each execution engine. The total number of instructions is equal to the number of instructions of the current thread, and each execution engine has a special field in the instruction description file. In this step, a queue of each execution engine in order can be generated, and then the current ordered operator calculation mode can be further randomly generated according to the queue order of the execution engine in order.

[0146] Wherein, each thread computation flow is the target operator queue in the above embodiment, used to define the execution order and type of the thread instruction; the number of operators is the number of operators to be executed by the thread in the above embodiment, and can be the execution engine queue length in the above embodiment; the scheduling number and order of each execution engine is the random allocation of the number of calls for each execution engine in the above embodiment, obtaining the execution engine queue, and generating the queue of each execution engine arranged in sequence is the execution engine queue in the above embodiment; randomly outputting the current ordered operator computation mode is the random allocation of the computation operation mode for each execution engine called in sequence in the above embodiment.

[0147] Step S405, for the first operator of the computation flow, the required tensor size and shape are randomly outputted.

[0148] In this step, the required input tensor constraint can be obtained according to the operator computation mode and the instruction description file.

[0149] Wherein, the first operator of the computation flow is the first target operator in the finally generated target operator queue in the above embodiment; the operator computation mode is the computation operation mode in the above embodiment, which is the operation mode randomly allocated for each operator in the above step (S404).

[0150] The input tensor constraint and the tensor size and shape are the data constraints in the above embodiment. They can be used to define the type, number, size (such as the dimension and shape of the tensor), data alignment mode, etc. of the operands required to execute a specific computation operation mode.

[0151] Step S406, then the starting address of the input tensor and the starting address of the output tensor are randomly outputted.

[0152] In this step, the address and tensor shape of the current operator can be generated according to the address range of the current thread and the tensor constraint.

[0153] Wherein, the address range of the current thread is the address space corresponding to the thread in the above embodiment, which is the range constraint of address generation; the tensor constraint is also the data constraint in the above embodiment, which is concretized as the “tensor size and shape” in step S405. This is the number and spacing constraint of address generation, for example, a 4x4 FP32 tensor requires 4x4x4=64 bytes of continuous address space.

[0154] The starting address of the input tensor and the starting address of the output tensor are the address information in the above embodiment, specifically including the input starting address and the output starting address.

[0155] Step S407, according to the instruction description, a complete instruction meeting the requirements is packaged out.

[0156] In this step, various parameters required by the instruction can be generated according to the tensor shape and the instruction description file, and then a complete instruction of the current operator can be packaged according to the various parameters and the instruction description file.

[0157] The instruction description is the instruction specification information of the hardware constraint information in the above embodiment, which can be used to define the encoding format of the test instruction, the meaning and legal value of each bit segment (such as operation code, function code, register address domain, etc.); the complete instruction is the test instruction finally generated in the above embodiment; the tensor shape is determined in the previous step (S405) and can be part of the data constraint, which can be used to determine the bit segment related to the data size in the instruction (for example, the field for specifying the vector length or the field for controlling the number of loops).

[0158] The various parameters are the remaining bit segments in the above embodiment, which include but are not limited to operation code, function code, calculation operation mode, register address, and control field related to "tensor shape".

[0159] In step S408, the calculation result of the previous operator is used as the input for each operator in the subsequent calculation process, and the tensor of the current operator is randomly generated.

[0160] In this step, the next operator in the list is sequentially randomized, the destination address of the previous instruction is constrained to the start address of the current operator, and the remaining steps are the same as the steps of generating the operator constraint before, until the randomization of all operators in the list is completed. The above operation can be performed on the list of each thread to complete the random generation of the business operator instruction of all threads.

[0161] The calculation result of the previous operator is the output start address of the current test instruction in the above embodiment, that is, the "output tensor start address" generated for the previous operator.

[0162] The destination address of the previous instruction is constrained to the start address of the current operator, that is, the output start address of the current test instruction is sequentially used as the input start address of the next test instruction, the destination address is the output start address, and the start address of the current operator is the input start address of the next test instruction.

[0163] The tensor of the current operator is randomly generated, that is, the data constraint (tensor shape) of the current operator is randomized in the above embodiment, but the input address is no longer completely random, but is "constrained" to the output address of the previous operator.

[0164] Step S409, according to the number of threads, randomly generate a number of synchronization instructions, and insert the randomly generated instructions into the middle of the instruction stream, to complete the generation of the entire random instruction.

[0165] In this step, after the completion of the list operator, the synchronization instruction needs to be randomly inserted to simulate the synchronization scene. First, the number of synchronization times needs to be randomly generated, and the number of synchronization instructions has no upper limit. Then, for each synchronization, the number of threads and thread IDs that need to be synchronized are randomly generated. According to the thread ID, the synchronization instruction is packaged for each thread that needs to be synchronized. Then, for each thread operator sequence, the synchronization instruction is randomly inserted from top to bottom.

[0166] Among them, the synchronization instruction is the synchronization instruction in the above embodiment. It is a special instruction used to control the execution order and data consistency between multiple threads (such as memory barriers, barrier instructions, semaphore operations, etc.). The instruction stream is the test instruction stream corresponding to each thread generated by steps S407 and S408.

[0167] The number of threads and thread IDs that need to be synchronized are the set of threads to be synchronized in the above embodiment, wherein the thread ID is used to uniquely identify each thread to be synchronized.

[0168] Step S410, after the random end of the entire operator flow, the return instructions of each thread are randomly generated, and returned to the end of the instruction.

[0169] In this step, the entire operator flow refers to the complete test instruction stream generated for each thread in the previous steps (S404 to S409), which includes the randomly inserted synchronization instructions.

[0170] Step S411, the randomly generated instructions are output in a fixed format and provided to each team for calling.

[0171] In this step, the test instruction file output can be obtained by outputting the test instruction stream of all threads returned in a predetermined format.

[0172] According to the technical scheme, the test instruction is generated according to the hardware constraint information of the specified processor architecture, so that the customized test instruction is generated for the specified processor architecture, the generated test instruction can conform to the hardware specification of the specified processor architecture, and the computing resources for screening invalid test cases can be saved; the output address of at least one test instruction in the test instruction stream is constrained to be the input address of a subsequent test instruction, so that the instruction sequence with the chained dependency relationship is automatically constructed, the continuous scene in the real computing scene is simulated, the difference between the verification environment and the actual working environment of the chip is reduced, and the reliability of the verification result is improved; and the test instruction stream corresponding to each thread is independently generated, which can be used for verifying the use scene of the multi-thread cooperative work, the verification scene of the test instruction is expanded, and the verification strength of the concurrent processing capability and stability of the chip is improved.

[0173] The application further provides an electronic device including a memory and a processor, the memory storing a computer program capable of running on the processor, and the processor implements the method according to any one of the above embodiments when executing the computer program.

[0174] The application further provides a computer readable storage medium storing executable instructions, and the computer program is executed by the processor to implement the method.

[0175] The application further provides a computer program product including a computer program or instructions, and the computer program or instructions are executed by the processor to implement part or all steps of the method according to any one of the above embodiments. The computer program product can be specifically implemented by hardware, software or a combination thereof. In an optional embodiment, the computer program product is specifically embodied as a computer storage medium, and in another optional embodiment, the computer program product is specifically embodied as a software product, such as a software development kit (SDK) and the like.

[0176] Figure 5 is a hardware entity schematic diagram of a computer device provided by the embodiment of the application, as shown in the figure, the hardware entity of the computer device 500 includes a processor 501 and a memory 502, wherein the memory 502 stores a computer program capable of running on the processor 501, and the processor 501 implements the steps in the method according to any one of the above embodiments when executing the program. Figure 5

[0177] ​The memory 502 stores computer programs executable on the processor, and is configured to store instructions and applications executable by the processor 501, and can also cache data (for example, image data, audio data, voice communication data and video communication data) to be processed by the processor 501 and modules in the computer device 500. The memory 502 can be implemented by a FLASH or a Random Access Memory (RAM).

[0178] The processor 501 implements the steps of the task execution method described above when executing the program. The processor 501 generally controls the overall operation of the computer device 500.

[0179] It should be noted here that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of the present application, please refer to the description of the method embodiments for understanding.

[0180] The processor described above can be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, or a microprocessor. It can be understood that the electronic device that implements the functions of the processor described above can also be other electronic devices, and the embodiments of the present application are not limited specifically.

[0181] The computer storage medium / memory can be a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Ferromagnetic Random Access Memory (FRAM), a Flash Memory, a magnetic surface storage, an optical disc, a Compact Disc Read-Only Memory (CD-ROM), or the like memory; or can be various terminals including one or any combination of the above memories, such as a mobile phone, a computer, a tablet device, a personal digital assistant, and the like.

[0182] It should be understood that every monetary term referred to throughout the specification, such as "one embodiment" or "an embodiment", means that a certain feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the application. Therefore, appearances of the phrases "in one embodiment" or "in an embodiment" throughout the specification are not necessarily referring to the same embodiment. Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that the sequence of steps / processes described in various embodiments of the application does not mean the order of execution, and the execution order of the steps / processes should be determined according to their functions and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the application. The above sequence number of the embodiments of the application is only for description, and does not represent the advantages or disadvantages of the embodiments.

[0183] It should be noted that, in this document, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not only include those elements, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more limitations, an element defined by the statement "comprising a" does not exclude the existence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0184] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other manners. The described device embodiments are merely schematic. For example, the division of the units is only a logical function division. There can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed coupling, or direct coupling or communication connection between the components can be indirect coupling or communication connection through some interfaces, devices, or units, and can be electrical, mechanical, or in other forms.

[0185] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units; they can be located in one place, or distributed on multiple network units; and some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0186] In addition, each functional unit in each embodiment of the present application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be realized in the form of hardware, or in the form of hardware plus software functional units. Those skilled in the art can understand that all or part of the steps of the above-mentioned method embodiments can be completed by program instruction related hardware, and the foregoing program can be stored in a computer readable storage medium, and the program is executed to perform the steps of the above-mentioned method embodiments; and the foregoing storage medium includes mobile storage devices, read-only memories (ROM), magnetic discs or optical discs, and various storage media that can store program codes.

[0187] Alternatively, the integrated units of the present application, if implemented in the form of software functional modules and sold or used as independent products, can also be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application can be embodied in the form of software products, and the computer software products are stored in a storage medium, including a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in the embodiments of the present application. The foregoing storage medium includes mobile storage devices, ROM, magnetic discs or optical discs, and various storage media that can store program codes.

[0188] The above merely provides the implementation of the present application, but the protection scope of the present application is not limited thereto, any person skilled in the art can easily think of the change or replacement within the technical range disclosed by the present application, which should be covered in the protection scope of the present application.

Claims

1. A method for generating test instructions, characterized in that, The method includes: Obtain hardware constraint information for a specified processor architecture, wherein the hardware constraint information includes multiple threads supported by the specified processor architecture, the number of operators to be executed for each thread, and the address space corresponding to each thread; For each thread, based on the number of operators to be executed by the thread, different operators are called by each execution engine to generate a target operator queue corresponding to the thread; Based on the address space corresponding to the thread, the test instruction stream corresponding to the target operator queue of the thread is determined; wherein, each target operator in the target operator queue corresponds to a test instruction in the test instruction stream, and the output address of at least one test instruction in the test instruction stream is the input address of a subsequent test instruction; Based on the test instruction stream corresponding to each thread, a test instruction file for the specified processor architecture is generated.

2. The method according to claim 1, characterized in that, For each thread, based on the number of operators to be executed by the thread, different operators are invoked through each execution engine to generate a target operator queue corresponding to the thread, including: An execution engine queue is obtained by randomly assigning a number of calls to each execution engine; wherein each execution engine calls a different operator each time, and the length of the execution engine queue matches the number of operators; According to the order of the execution engine queue, the calculation operation mode is randomly assigned to the operator called by each execution engine in turn to obtain the target operator queue; wherein, each target operator is used to execute different calculation operation modes.

3. The method according to claim 2, characterized in that, The step of determining the test instruction stream corresponding to the target operator queue of the thread based on the address space corresponding to the thread includes: Obtain the data constraints corresponding to each computing operation mode from the hardware constraint information; The test instruction stream of the thread is determined based on the data constraints corresponding to each target operator in the target operator queue and the address space corresponding to the thread.

4. The method according to claim 3, characterized in that, The hardware constraint information also includes instruction specification information corresponding to the specified processor architecture; determining the test instruction stream of the thread based on the data constraints corresponding to each target operator in the target operator queue and the address space corresponding to the thread includes: In the address space corresponding to the thread, the address information of the first target operator is generated according to the data constraints corresponding to the first target operator. The address information includes the input start address and the output start address. Based on the pre-set instruction dependency relationship, the address information of subsequent target operators that are dependent on the first target operator is generated; According to the instruction specification information, the remaining bit fields of each target operator in the target operator queue are randomly generated to obtain each test instruction in the test instruction stream of the thread; the remaining bit fields are the remaining bit fields in the test instruction corresponding to the target operator, excluding the address bit fields. The test instruction stream corresponding to the thread is determined based on the test instruction corresponding to each target operator.

5. The method according to claim 4, characterized in that, The step of generating address information for subsequent target operators that are dependent on the first target operator based on pre-set instruction dependencies includes: According to the order of the target operator queue, the output start address of the current target operator is used as the input start address of the next adjacent target operator in turn, until the next target operator is the last target operator.

6. The method according to any one of claims 1-5, characterized in that, The step of generating a test instruction file for the specified processor architecture based on the test instruction stream corresponding to each thread includes: A return instruction is generated at the end of the test instruction stream for each thread; The test instruction streams of all returned threads are output according to a preset format to obtain the output test instruction file.

7. The method according to any one of claims 1-5, characterized in that, The method further includes: Randomly select the thread to be synchronized from among the multiple threads; A synchronization instruction is randomly inserted into the test instruction stream corresponding to each thread to be synchronized, thereby obtaining the test instruction stream corresponding to each thread to be synchronized.

8. A test instruction generation device, characterized in that, The device includes: The acquisition module is used to acquire hardware constraint information of a specified processor architecture, wherein the hardware constraint information includes multiple threads supported by the specified processor architecture, the number of operators to be executed by each thread, and the address space corresponding to each thread. The first generation module is used to generate a target operator queue for each thread by calling different operators through each execution engine, based on the number of operators to be executed by the thread. The determination module is used to determine the test instruction stream corresponding to the target operator queue of the thread based on the address space corresponding to the thread; wherein, each target operator in the target operator queue corresponds to a test instruction in the test instruction stream, and the output address of at least one test instruction in the test instruction stream is the input address of a subsequent test instruction; The second generation module is used to generate a test instruction file for the specified processor architecture based on the test instruction stream corresponding to each thread.

9. An electronic device, comprising: The method includes a memory and a processor, the memory storing a computer program that runs on the processor, characterized in that the processor, when executing the program, implements the method according to any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The processor stores executable instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the method described in any one of claims 1 to 7.

Images