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

Abstract

Embodiments of the present application disclose a test instruction generation method and device, electronic equipment, medium and product. The method 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 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; 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 independent of each other in logic, which can only test the execution function of a single instruction and cannot verify the correctness and stability of processing continuous and 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:

[0006] In one aspect, the embodiments of the present application provide a test instruction generation method, which comprises:

[0007] 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;

[0008] For each thread, a target operator queue corresponding to the thread is generated by calling different operators through each execution engine according to the number of operators to be executed by the thread;

[0009] 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;

[0010] generating a test instruction file of the specified processor architecture according to the test instruction stream corresponding to each thread.

[0011] In some embodiments, the generating, 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, comprises:

[0012] obtaining an execution engine queue by randomly allocating 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;

[0013] sequentially randomly allocating a calculation operation mode to each operator called by each execution engine in the order of the execution engine queue to obtain a target operator queue; wherein each target operator is used to execute a different calculation operation mode.

[0014] In some embodiments, the determining, according to the address space corresponding to the thread, a test instruction stream corresponding to the target operator queue of the thread, comprises:

[0015] obtaining data constraints corresponding to each calculation operation mode from the hardware constraint information;

[0016] 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.

[0017] 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 target operator in the target operator queue and the address space corresponding to the thread, the test instruction stream of the thread, comprises:

[0018] generating address information of the first target operator in the address space corresponding to the thread according to the data constraints corresponding to the first target operator, the address information comprising an input start address and an output start address;

[0019] 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;

[0020] randomly generating the remaining bit segments of each target operator in the target operator queue according to the instruction specification information to obtain each test instruction in the test instruction stream of the thread; the remaining bit segments being the remaining bit segments of the test instruction corresponding to the target operator except for the address bit segments;

[0021] determine the test instruction stream corresponding to the thread according to the test instruction corresponding to each target operator.

[0022] In some embodiments, the address information of the subsequent target operator having a dependency relationship with the first target operator is generated based on the preset instruction dependency relationship, including:

[0023] In the order of the target operator queue, the output start address of the current target operator is sequentially taken as the input start address of the adjacent next target operator until the next target operator is the last target operator.

[0024] In some embodiments, the test instruction file of the specified processor architecture is generated according to the test instruction stream corresponding to each thread, including:

[0025] A return instruction is generated at the end of the test instruction stream of each thread;

[0026] The test instruction stream of all the threads returned is output in a preset format to obtain the output test instruction file.

[0027] In some embodiments, the method further includes:

[0028] Randomly determine the threads to be synchronized in the plurality of threads;

[0029] Randomly insert a synchronization instruction in the test instruction stream corresponding to each thread to be synchronized to obtain the test instruction stream corresponding to each thread to be synchronized.

[0030] In another aspect, the embodiments of the present application provide a test instruction generation device, the device includes:

[0031] An acquisition module is configured to acquire hardware constraint information of a specified processor architecture, wherein the hardware constraint information includes 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.

[0032] A first generation module is 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.

[0033] A determination module 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 the output address of at least one test instruction in the test instruction stream is the input address of a subsequent test instruction.

[0034] a second generation module, configured to generate a test instruction file of the specified processor architecture according to the test instruction stream corresponding to each thread.

[0035] In another aspect, an electronic device is provided, including a memory and a processor, the memory storing 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.

[0036] In another aspect, a computer storage medium is provided, storing executable instructions, and the processor executes the method provided in any of the embodiments of the present application when executing the executable instructions.

[0037] In another aspect, a computer program product is provided, including a computer program or instructions, and the processor implements any of the methods provided in the embodiments of the present application when executing the computer program or instructions.

[0038] In the embodiments 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 includes 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 calling 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; 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; and 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 the subsequent test instruction, an instruction sequence with a chained dependency relationship is 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; and 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 can enhance the verification intensity of the concurrent processing capability and stability of the chip.

[0039] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, but not limiting the technical solutions of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0040] The drawings incorporated in the specification and constituting a part of the specification illustrate embodiments consistent with the present application and, together with the specification, serve to explain the technical solutions of the present application.

[0041] Figure 1 is a flowchart of a test instruction generation method provided by an embodiment of the present application;

[0042] Figure 2 is another flowchart of a test instruction generation method provided by an embodiment of the present application;

[0043] Figure 3 is a block diagram of a test instruction generation device provided by an embodiment of the present application;

[0044] Figure 4 is another flowchart of a test instruction generation method provided by an embodiment of the present application;

[0045] Figure 5 is a hardware entity diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0046] In order to make the purposes, 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. The described embodiments should not be regarded as limiting the present application, and all other embodiments obtained by those of ordinary skill in the art without making creative efforts fall within the scope of protection of the present application.

[0047] 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.

[0048] 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.

[0049] In the following description, the terms thread, operator, test instruction stream, etc. are core concepts in the invention. To facilitate understanding, these terms are first explained:

[0050] 1) Thread: In processor architecture, a thread refers to an independent execution unit that can execute instructions concurrently. In this invention, 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.

[0051] 2) Operator: In this application, an operator refers to a functional module or computing pattern in the execution engine that performs a specific computing 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.

[0052] 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 constraints to meet the dependency relationship and data flow requirements between threads.

[0053] 4) Address space: In this application, 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.

[0054] 5) Synchronization instruction: In a multi-threaded environment, synchronization instructions are used to coordinate the execution order of different threads, ensuring that certain operations start only after other operations are completed, thus simulating the concurrent control mechanism in real scenarios.

[0055] 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.

[0056] 7) SIMD Core (Single Instruction, Multiple Data Core): the core of the Single Instruction, Multiple Data architecture, which is a processor architecture that can handle multiple data items simultaneously, suitable for image processing, deep learning, etc. 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 a proprietary specification, therefore strict constraint verification is required.

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

[0058] 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 and multi-step composite computing tasks, thereby failing 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, and seriously reducing the credibility of the verification result.

[0059] To solve the above problems, the present application provides a test instruction generation method, which generates test instructions according to the hardware constraint information of a specified processor architecture, generates customized test instructions for the specified processor architecture, ensures that the generated test instructions conform to the hardware specifications of the specified processor architecture, saves computing resources for screening invalid test cases, constrains the output address of at least one test instruction in the test instruction stream to be the input address of the subsequent test instruction, automatically constructs an instruction sequence with a chained dependency relationship, simulates continuous scenarios in real computing scenarios, reduces the difference between the verification environment and the actual working environment of the chip, and improves the credibility 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, expand the verification scenario of the test instruction, and enhance the verification of the concurrent processing capability and stability of the chip.

[0060] The test instruction generation method provided by the embodiments of the present 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 present application can 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.

[0061] Figure 1 is a flowchart of the test instruction generation method provided by the embodiments of the present application. The following will be described in combination with the steps shown in Figure 1 As shown in Figure 1 , the method includes the following steps S101 to S104:

[0062] Step S101, obtain hardware constraint information of the specified processor architecture.

[0063] The hardware constraint information can be basic data for guiding the generation of subsequent test instructions. The hardware constraint information can include, but is not limited to, 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 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.

[0064] In the case of a multi-threaded architecture of the specified processor architecture, 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 within this range.

[0065] 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 fields such as the number of threads, the number of operators and the address space. 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.

[0066] 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.

[0067] The execution engine can be a virtual machine environment, a compiler front end, or a simulator, and can be responsible for performing specific types of computations in the processor, such as a vector computation engine, a scalar computation engine, a load / store engine, a special function engine, and the like. Each engine can perform one or more specific operators. An operator represents an atomic, indivisible computation or operation instruction type that can be instantiated as an instruction after being assigned specific parameters.

[0068] Real-world computing tasks, such as image processing and scientific computing, are almost never completed by a single instruction, but rather by a series of associated computation steps. By generating a queue, rather than just random isolated instructions, the working state of the processor under the driving of a real application can be highly simulated, and thus deeper design flaws can be discovered.

[0069] 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 satisfy the operator quantity constraint to be executed by the thread. By randomly scheduling different execution engines, the probability that all computing units are called can be ensured, which can avoid verification vulnerabilities.

[0070] 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 / store engine.

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

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

[0073] In step S103, the test instruction stream corresponding to the target operator queue of the thread is determined according to the address space corresponding to the thread.

[0074] In the target operator queue, each target operator 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.

[0075] 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, so as to avoid resource conflicts between threads.

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

[0077] In some embodiments, for the first operator in the target operator queue, an unoccupied address can be randomly selected according to the operation requirement, 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 be allocated in the same way. The output address needs to meet the memory alignment requirement, address range limitation and other hardware constraints of the processor. For example, if the first operator is an int8 vector addition, according to the operation requirement corresponding to the vector addition, it can be determined that it needs 2 input vectors and 1 output vector, and therefore 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.

[0078] 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.

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

[0080] In some embodiments, the instruction bit segments can include, but are 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.

[0081] After obtaining the operand addresses, a corresponding instruction template can be selected from a predefined template library according to the type of the target operator, and then multiple instruction bit segments of the target operator can be filled according to the operand addresses. 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; the allocated input address can be encoded as a value of a source operand bit segment, and the source operand address bit segment can be filled; the output address can be encoded as a value of a destination operand bit segment, and the destination operand address bit segment can be filled; and according to the data type (such as int8) and vector length (such as 8 elements) of the operator, the corresponding remaining bit segments can be filled, and thus a first test instruction can be obtained.

[0082] In some embodiments, for the remaining operators in the target operator queue, when allocating the input addresses thereof, the output address of a previous instruction can be forced to be at least one input address of a current instruction, and a new output address can be allocated for the current instruction (which can be used as an input of a next 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 can be 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 an 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.

[0083] 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 remaining test instructions in accordance with the instruction template.

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

[0085] In this way, the instruction is generated based on the thread-specific address space, address conflicts during multi-thread testing can be avoided, and through the association of the output address of the current instruction and the input address of the subsequent instruction, the instruction flow is no longer an isolated instruction set, but a continuous flow simulating the multi-step processing of data in a real task. Compared with independent instructions that can only test the correctness of a single function, the instruction flow with chain dependency can verify the correctness of the processor when processing composite calculations.

[0086] In step S104, a test instruction file of a specified processor architecture is generated according to the test instruction flow corresponding to each thread.

[0087] The final output test instruction file can contain the test instruction flow 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.

[0088] 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 packages the test instruction flow 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.

[0089] By using the above technical solution, the test instruction is generated based on the hardware constraint information of the specified processor architecture, the customized test instruction can be 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. By constraining the output address of at least one test instruction in the test instruction flow to be the input address of the subsequent test instruction, an instruction sequence with chain dependency is automatically constructed to simulate the continuous scenario in the real computing scenario, the difference between the verification environment and the actual working environment of the chip is reduced, and the credibility of the verification result is improved. Moreover, the test instruction flow corresponding to each thread is independently generated, which can be used to verify the use scenario of multi-thread cooperation, expand the verification scenario of the test instruction, and enhance the verification of the concurrent processing capability and stability of the chip.

[0090] In some embodiments, the above step S102 can be implemented through steps S1021 and S1022:

[0091] In step S1021, the execution engine queue is obtained by randomly assigning the number of calls to each execution engine.

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

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

[0094] For example, the execution engines supported by the specified processor architecture can include but are not limited to VEC_ENGINE (vector engine), LDST_ENGINE (load store engine), and SCL_ENGINE (scalar engine). VEC_ENGINE can be allocated 3 calls, LDST_ENGINE can be allocated 2 calls, and SCL_ENGINE (scalar engine) can be allocated 1 call. 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 generate 3 vector instructions, then 2 load store instructions, and finally 1 scalar instruction. In this way, the random call frequency allocation can force the test generator to use all types of engines, avoiding test vulnerabilities.

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

[0096] It should be noted that in the execution engine queue, each execution engine calls a different operator each time.

[0097] Step S1022, randomly allocate a calculation operation mode to each operator called by each execution engine in the order of the execution engine queue to obtain a target operator queue.

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

[0099] In this step, the execution engine queue can include multiple entries, each entry can correspond to a call 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 allocated to the operator.

[0100] An operator refers to a basic operation that the execution engine can perform. 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 the like. An operator refers to any one of the various operation operations that the VEU can perform, and the specific operation is not limited here.

[0101] A computation operation mode refers to a specific operation type of the same operator. For example, for a vector arithmetic engine (VEU), the computation operation mode refers to ADD vector addition, SUB vector subtraction, MUL vector multiplication, and the like.

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

[0103] The entries in the current execution engine queue to be processed can be extracted in the order of the execution engine queue, and the current extracted entry is 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 constraints, all computation operation modes supported by the current entry (which can be marked as "initial available mode set") can be filtered out. For example, when the current engine is LSU, the initial available mode set is {LDR, STR, ALDR}. The execution engine of the entry is queried for "previous call records" in the queue. If there are already allocated computation operation modes, these used modes are excluded from the initial available mode set to obtain the "final available mode set". For example, when the current engine is the second call of LSU in the queue, and the first call has allocated the "LDR" mode, the final available mode set is {STR, ALDR}. If the execution engine is the first call (without previous records), the final available mode set is consistent with the initial available mode set.

[0104] After obtaining the available computation operation modes of the current engine, a computation operation mode can be randomly allocated. An algorithm that meets the test randomness requirement (such as a uniform random sampling algorithm) is used to randomly select a computation 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}.

[0105] After the operators in the execution engine queue are assigned with corresponding computing operation modes, the 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 the operator of the LSU execution memory storage operation), 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 of "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].

[0106] 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.

[0107] In some embodiments, the above step S103 can be implemented through step S1031 and step S1032:

[0108] Step S1031, obtaining the data constraint corresponding to each computing operation mode from the hardware constraint information.

[0109] 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.

[0110] 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 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.

[0111] 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.

[0112] 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.

[0113] 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 constraint is “tensor dimension = 4, the length of the first dimension ∈ {8, 16, 24,...} (positive integer multiples of 8)”.

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

[0115] 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.

[0116] 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.

[0117] 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:

[0118] 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.

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

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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.

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

[0126] 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.

[0127] The instruction template can be generated based on the hardware constraint information of the 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.

[0128] 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.

[0129] 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, and 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, and the source operand address bit segment can be filled; 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; and according to the data type (such as int8) of the operator, the vector length (such as 8 elements) and other information, the corresponding rest bit segment can be filled, and the first test instruction can be obtained.

[0130] 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). And 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.

[0131] 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.

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

[0133] 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.

[0134] In some embodiments, step S104 can be implemented by steps S1041 and S1042:

[0135] Step S1041: Generate a return instruction at the end of the test instruction stream for each thread.

[0136] 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.

[0137] 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.

[0138] 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.

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

[0140] 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.

[0141] In actual applications, the preset format can adopt various data exchange formats, such as YAML, JSON, or binary format. YAML format is often used for input configuration of test scripts due to its good readability and structural characteristics. JSON is more 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.

[0142] By uniformly outputting the test instruction streams of all threads in the preset format, the system can generate standardized test cases, facilitating 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, improving overall development efficiency and test quality.

[0143] 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, thereby improving the test coverage and verification efficiency of the SIMD Core in the specified processor architecture.

[0144] 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:

[0145] Step S105, randomly determine the threads to be synchronized in the plurality of threads.

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

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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.

[0152] 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.

[0153] 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.

[0154] 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:

[0155] 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.

[0156] The first generation module 302 is configured to, for each thread, generate 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.

[0157] 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.

[0158] 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.

[0159] In some embodiments, the first generation module 302 comprises:

[0160] The first allocation sub-module is configured to obtain an execution engine queue by randomly allocating 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.

[0161] The second allocation sub-module is configured to randomly allocate a calculation 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 calculation operation mode.

[0162] Optionally, the determination module 303 comprises:

[0163] The acquisition sub-module is configured to acquire data constraints corresponding to each calculation operation mode from the hardware constraint information.

[0164] 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.

[0165] In some embodiments, the determining submodule is configured to generate address information of the first target operator in the address space corresponding to the thread according to the data constraint corresponding to the first target operator, the address information including 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; and generate a remaining bit segment of each target operator in the target operator queue according to the instruction specification information to obtain each test instruction in the test instruction stream of the thread; the remaining bit segment being 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.

[0166] In some embodiments, the determining submodule is configured to sequentially set the output start address of a current target operator as an input start address of a next target operator adjacent to the current target operator according to the order of the target operator queue until the next target operator is the last target operator.

[0167] In some embodiments, the second generating module 304 is configured to:

[0168] The generating submodule is configured to generate a return instruction at the end of the test instruction stream of each thread.

[0169] The output submodule is configured to output the returned test instruction streams of all threads according to a pre-set format to obtain an output test instruction file.

[0170] In some embodiments, the apparatus further includes:

[0171] The to-be-synchronized module is configured to randomly determine to-be-synchronized threads in the plurality of threads.

[0172] 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.

[0173] By using the above apparatus, the test instruction can be generated according to the hardware constraint information of the specified processor architecture, the customized test instruction can be generated for the specified processor architecture, the generated test instruction can conform to the hardware specification of the specified processor architecture, the computing resources for screening invalid test cases can be saved, at least one output address of the test instruction in the test instruction stream is constrained to be an input address of a subsequent test instruction, the instruction sequence having a chained dependency relationship can be automatically constructed to simulate the continuous scene in the real computing scene, the difference between the verification environment and the actual working environment of the chip can be reduced, and the credibility of the verification result can be improved, and by independently generating the test instruction stream corresponding to each thread, the use scene of the multi-thread cooperative work can be verified, the verification scene of the test instruction can be expanded, and the verification intensity of the concurrent processing capability and stability of the chip can be enhanced.

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

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

[0176] The customized SIMD Core instruction architecture is a proprietary instruction architecture, and each domain segment of the instruction has its own unique meaning and constraints. A lot of effort and work is needed to generate test instructions that meet the specifications. The random instruction generator can be used to randomly generate all instructions that meet the constraints of the SIMD Core instruction architecture and the possible cooperation between instructions, which can accelerate the convergence speed of SIMD Core verification and improve the completeness of chip verification.

[0177] 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 instructions can comprehensively cover the SIMD Core running scenarios, and the completeness can be improved.

[0178] The main features of the technical solutions provided in the embodiments of the present application are as follows: first, the generated test instructions are based on the customized SIMD Core, which has higher pertinence; second, the instruction architecture of the generated test instructions is generated based on the instruction description of the SIMD Core instruction architecture, which has higher accuracy and avoids generating invalid instructions; third, the generated test instructions are generated for each thread, which can improve the diversity of the test scenarios and verify the working conditions of multiple different execution units of the processor in a real concurrent state at a time; fourth, the test instructions are generated based on the address as the primary constraint through inter-thread and intra-thread constraints, which can construct a real instruction stream through the chain dependency of the address and improve the verification depth; fifth, the synchronization instructions and return instructions inserted in the generated test instruction stream are randomly generated independently of other instructions, which can decouple the control flow and the data flow and can more realistically simulate the cycle of real computing tasks.

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

[0180] Figure 4 is another optional flowchart of the test instruction generation method provided by 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:

[0181] Step S401, based on the instruction description document given by the architecture, an instruction description file is generated.

[0182] In this step, based on the instruction set architecture 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 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.

[0183] Among them, the instruction description document given by the architecture is the original data source of the hardware constraint information in the above embodiment, and the yaml file of the instruction description is the hardware constraint information in the above embodiment.

[0184] Step S402, the number of threads required is generated according to the instruction description.

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

[0186] Among them, 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, wherein 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).

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

[0188] Among them, 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.

[0189] 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.

[0190] Step S404, the number of operators and the calculation flow of each thread are randomly generated.

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

[0192] Wherein, each thread computing 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 number of scheduling and the 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 arranged in order of each execution engine is the execution engine queue in the above embodiment; the current ordered operator calculation mode is randomly generated for each execution engine in the above embodiment.

[0193] Step S405, for the first operator of the computing flow, the required tensor size and shape are randomly generated.

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

[0195] Wherein, the first operator of the computing flow is the first target operator in the finally generated target operator queue in the above embodiment; the operator calculation mode is the calculation operation mode in the above embodiment, which is randomly allocated to each operator in the previous step (S404).

[0196] The input tensor constraint, the tensor size and the shape are the data constraints in the above embodiment. It can be used to define the type, number, size (such as the dimension and shape of the tensor), data alignment mode and the like of the operation number required for executing a specific calculation operation mode.

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

[0198] 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.

[0199] 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 embodied as "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.

[0200] The input and the starting address of the output tensor are the address information in the above embodiment, which specifically includes the input starting address and the output starting address.

[0201] In step S407, a complete instruction that meets the requirements is packaged according to the instruction description.

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

[0203] 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).

[0204] 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".

[0205] 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 operator is randomly generated.

[0206] In this step, the next operator in the list is sequentially randomized, and the destination address of the previous instruction is constrained as the starting address of the current operator, and the remaining steps are the same as the steps of generating operator constraints before, until all operators in the list are randomly 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.

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

[0208] The destination address of the previous instruction is constrained to the start address of the current operator, which is the output start address of the current test instruction in the above embodiment, and 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.

[0209] The tensor of the random output is the way of randomizing the data constraint (tensor shape) of the current operator in the above embodiment, but the input address is no longer completely random, but is "constrained" to the output address of the previous operator.

[0210] Step S409, according to the number of threads, a plurality of synchronization instructions are randomly generated and inserted into the middle of the randomly generated instruction stream, to complete the generation of the entire random instruction.

[0211] In this step, after the list operator is completed, a synchronization instruction needs to be randomly inserted to simulate a synchronization scenario. First, the number of synchronizations 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, a 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.

[0212] 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 generated by steps S407 and S408 for each thread.

[0213] 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.

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

[0215] 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.

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

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

[0218] 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.

[0219] The present application also provides an electronic device, including a memory and a processor, the memory stores a computer program capable of running on the processor, and the processor implements the method of any one of the above when executing the computer program.

[0220] The present application also provides a computer readable storage medium, which stores executable instructions, and the computer program is executed by the processor to implement the above method. The computer readable storage medium can be transitory or non-transitory.

[0221] The present application also provides a computer program product, which includes a computer program or instructions, and the computer program or instructions are executed by the processor to implement part or all steps of any one of the above methods. 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 (Software Development Kit, SDK) and the like.

[0222] Figure 5 is a hardware entity schematic diagram of a computer device provided by the present application, as shown in Figure 5 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 of any one of the above embodiments when executing the program.

[0223] 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, and can be implemented by a FLASH or a Random Access Memory (RAM).

[0224] 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.

[0225] 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.

[0226] The above processor 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, and a microprocessor. It can be understood that the electronic device realizing the function of the above processor can also be other, and the embodiments of the present application are not limited specifically.

[0227] 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.

[0228] It should be understood that all the terms “one embodiment” or “an embodiment” as used herein means that a particular feature, structure, or characteristic described is included in at least one embodiment of the application. Therefore, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily referring to the same embodiment. Furthermore, the particular 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.

[0229] 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, the element defined by the sentence “comprises a…” does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0230] 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.

[0231] 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.

[0232] 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 implemented 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.

[0233] 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.

[0234] 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 test instruction generation method characterized by comprising: The method 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 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; generating a test instruction file of the specified processor architecture according to the test instruction stream corresponding to each thread.

2. The method of claim 1, wherein, The method comprises: allocating a call number to each execution engine randomly to obtain an execution engine queue; wherein each execution engine calls a different operator each time, and the length of the execution engine queue matches the number of operators; allocating a calculation operation mode to each operator called by each execution engine 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 calculation operation mode.

3. The method of claim 2, wherein, The method comprises: obtaining data constraints corresponding to each calculation operation mode from the hardware constraint information; 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.

4. The method of claim 3, wherein, The hardware constraint information further comprises instruction specification information corresponding to the specified processor architecture; and the method 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; 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 each test instruction in the test instruction stream of the thread according to the instruction specification information and the remaining bit segments of each target operator in the target operator queue; the remaining bit segments are remaining bit segments other than address bit segments in the test instruction corresponding to the target operator; determining the test instruction stream corresponding to the thread according to the test instruction corresponding to each target operator.

5. The method of claim 4, wherein, The method comprises: 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. In order, according to the order of the target operator queue, the output start address of the current target operator is taken as the input start address of the adjacent next target operator 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 generating the test instruction file of the specified processor architecture according to the test instruction flow corresponding to each thread comprises: generating a return instruction at the end of the test instruction flow of each thread; outputting the returned test instruction flow of all threads in 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 comprises: randomly determining threads to be synchronized in the plurality of threads; inserting a synchronization instruction into the test instruction flow corresponding to each thread to be synchronized to obtain the test instruction flow corresponding to each thread to be synchronized.

8. A test instruction generation apparatus characterized by comprising: The apparatus comprises: an acquisition module 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, the number of operators to be executed by each thread, and an address space corresponding to each thread; a first generation 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 determination module configured to determine a test instruction flow 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 flow, and the output address of at least one test instruction in the test instruction flow is the input address of a subsequent test instruction; a second generation module configured to generate a test instruction file of the specified processor architecture according to the test instruction flow corresponding to each thread.

9. An electronic device comprising: A memory and a processor, the memory stores a computer program running on the processor, and the processor implements the method of any one of claims 1 to 7 when executing the program.

10. A computer storage medium, characterized in that, Executable instructions are stored, and when the executable instructions are executed by a processor, the processor executes the method of any one of claims 1 to 7.

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

Images