Tensor memory access verification method and device, electronic equipment and storage medium

Abstract

The application provides a tensor memory access verification method and device, electronic equipment and storage medium, relates to the chip design and manufacturing technical field, and includes the following steps: randomly generating test parameters; based on the test parameters, controlling a tensor memory access unit in a first processor to perform an actual data carrying operation to obtain an actual result of storing source data in a second memory associated with the first processor; based on the test parameters, controlling a second processor to perform behavior-level simulation to obtain an expected result of carrying the source data from a first memory to the second memory; comparing the actual result with the expected result to determine the functional correctness of the tensor memory access unit under the test parameters. The method and device provided by the application can automatically and comprehensively and efficiently verify the functional correctness of the tensor memory access unit, solve the technical problems of insufficient coverage and poor pertinence of the verification method in the related art, and significantly improve the verification efficiency and quality of the tensor memory access unit.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of chip design manufacturing, and particularly relates to a tensor memory access verification method and device, electronic equipment and a storage medium. BACKGROUND

[0002] A tensor memory access (TMA) unit is a hardware acceleration unit used to transfer tensor data between a global memory (GMEM) and a shared memory (SMEM) of a graphics processing unit (GPU), or between multiple concurrent thread arrays (CTAs) within a thread block cluster.

[0003] The related art does not have a special test verification for the tensor memory access unit, but only tests and verifies it as part of a larger test range, and the verification is not strong in pertinence. In the test and verification process, the transfer address, the stride or the tensor size is relatively regular, and the test scene is fixed, which cannot effectively cover the complex scene formed by the random combination of a large number of parameters.

[0004] Therefore, how to comprehensively and efficiently verify the functional correctness of the tensor memory access has become a technical problem to be solved in the industry. SUMMARY

[0005] The present application provides a tensor memory access verification method and device, electronic equipment and a storage medium, which are used to solve the technical problem of how to comprehensively and efficiently verify the functional correctness of the tensor memory access.

[0006] The present application provides a tensor memory access verification method, comprising:

[0007] Randomly generating test parameters, the test parameters comprising a tensor descriptor used to define the layout of source data in a first memory associated with a first processor, and an instruction modifier used to define a data transfer rule;

[0008] Based on the test parameters, controlling a tensor memory access unit in the first processor to perform an actual data transfer operation to obtain an actual result of storing the source data in a second memory associated with the first processor;

[0009] Based on the test parameters, controlling a second processor to perform a behavior-level simulation to obtain an expected result of transferring the source data from the first memory to the second memory;

[0010] The actual result is compared with the expected result to determine the functional correctness of the tensor memory access unit under the test parameters.

[0011] In some embodiments, based on the test parameters, the tensor memory access unit in the first processor is controlled to perform an actual data movement operation to obtain an actual result of storing the source data in a second memory associated with the first processor, including:

[0012] Based on the test parameters, an assembly instruction is dynamically generated to control the tensor memory access unit to perform an actual data movement operation;

[0013] The assembly instruction is loaded and executed in the first processor to control the tensor memory access unit to move the source data from the first memory to the second memory to obtain the actual result.

[0014] In some embodiments, based on the test parameters, a second processor is controlled to perform a behavior-level simulation to obtain an expected result of moving the source data from the first memory to the second memory, including:

[0015] Based on the tensor descriptor, the second processor is controlled to generate a source data model; the source data model is used to simulate the layout of the source data in the first memory;

[0016] Based on the instruction modifier, the second processor is controlled to simulate the data movement behavior of the tensor memory access unit to process the source data model to obtain the expected result.

[0017] In some embodiments, the control of the second processor to simulate the data movement behavior of the tensor memory access unit includes simulating at least one of:

[0018] Resolving multi-dimensional memory addresses;

[0019] Performing stride movement;

[0020] Performing boundary checks;

[0021] Performing out-of-bound zero padding.

[0022] In some embodiments, the comparison of the actual result with the expected result to determine the functional correctness of the tensor memory access unit under the test parameters includes:

[0023] The actual result is compared with the expected result byte by byte;

[0024] In the case where each byte in the actual result matches the corresponding byte in the expected result, it is determined that the tensor memory access unit is functionally correct.

[0025] In some embodiments, the first processor is a graphics processor or a silicon- before- validation model corresponding to the graphics processor; the second processor is a central processing unit; the first memory is a global memory associated with the graphics processor or a silicon-before-validation model corresponding to the global memory; and the second memory is a shared memory in the graphics processor.

[0026] The application provides a tensor memory access verification device, comprising:

[0027] A parameter generation module is configured to randomly generate test parameters, wherein the test parameters comprise a tensor descriptor used to define a layout of source data in a first memory associated with a first processor, and an instruction modifier used to define a data transfer rule.

[0028] A data transfer module is configured to control a tensor memory access unit in the first processor to perform an actual data transfer operation based on the test parameters, so as to obtain an actual result of storing the source data in a second memory associated with the first processor.

[0029] An analog transfer module is configured to control a second processor to perform a behavior-level simulation based on the test parameters, so as to obtain an expected result of transferring the source data from the first memory to the second memory.

[0030] A result verification module is configured to compare the actual result with the expected result, and determine a functional correctness of the tensor memory access unit under the test parameters.

[0031] The application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the tensor memory access verification method when executing the computer program.

[0032] The application provides a non-transitory computer-readable storage medium, which stores a computer program, wherein the computer program is executable on a processor to implement the tensor memory access verification method.

[0033] The application provides a computer program product, comprising a computer program, wherein the computer program is executable on a processor to implement the tensor memory access verification method.

[0034] The tensor memory access verification method, device, electronic equipment and storage medium provided by the application, by randomly generating test parameters containing a tensor descriptor and an instruction modifier, controlling a tensor memory access unit in a first processor to perform an actual data carrying operation to obtain an actual result, controlling a second processor to perform behavior level simulation to obtain an expected result, comparing the actual result with the expected result, and determining the functional correctness of the tensor memory access unit under the test parameters, the random parameter generation and the processor behavior level simulation can automatically and comprehensively and efficiently verify the functional correctness of the tensor memory access unit in the special processor, effectively solve the technical problems of insufficient coverage and weak pertinence of the verification method in the related art, and significantly improve the verification efficiency and quality of the tensor memory access unit. BRIEF DESCRIPTION OF DRAWINGS

[0035] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the application and, together with the description, serve to explain the principles of the application.

[0036] In order to more clearly illustrate the technical solutions in the application or the prior art, the accompanying drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the accompanying drawings in the following description are some embodiments of the application, and other accompanying drawings can be obtained by those skilled in the art without creative labor.

[0037] Figure 1 is a flowchart of the tensor memory access verification method provided by the application.

[0038] Figure 2 is a process diagram of the tensor memory access verification provided by the application.

[0039] Figure 3 is a schematic diagram of the data carrying operation provided by the application.

[0040] Figure 4 is a structural diagram of the tensor memory access verification device provided by the application.

[0041] Figure 5 is a structural diagram of the electronic equipment provided by the application.

[0042] Reference signs:

[0043] 410: parameter generation module; 420: data carrying module;

[0044] 430: simulation carrying module; 440: result verification module;

[0045] 510: processor; 520: communication interface; 530: memory; 540: communication bus. DETAILED DESCRIPTION

[0046] In order to make the person skilled in the art better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be clearly and completely described below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by the person skilled in the art without creative labor should belong to the scope of protection of the present application.

[0047] It should be noted that the terms "first", "second" and the like in the present application are used to distinguish similar objects, and do not necessarily have to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units or modules does not have to be limited to those steps or units or modules clearly listed, but can include other steps or units or modules that are not clearly listed or inherent to these processes, methods, products or devices.

[0048] In order to solve the deficiencies of the related art, Figure 1 is a flowchart of the tensor memory access verification method provided by the present application, as Figure 1 shown, the method comprises steps 110, 120, 130 and 140.

[0049] Step 110, randomly generate test parameters, the test parameters include a tensor descriptor for defining the layout of the source data in the first memory associated with the first processor, and an instruction modifier for defining the data transfer rule.

[0050] Specifically, the execution subject of the tensor memory access verification method provided by the embodiments of the present application is a tensor memory access verification device or system. The device can be implemented by software, such as a tensor memory access verification program running in a computer; it can also be implemented by hardware, such as an artificial intelligence chip, a computer or a server executing the tensor memory access verification method.

[0051] The first processor can refer to any processor containing a dedicated hardware unit for processing tensor memory access. In a specific embodiment, the first processor is a graphics processing unit (GPU), a tensor processing unit (TPU), or other types of application-specific integrated circuit (ASIC) specially designed for artificial intelligence computing tasks.

[0052] Correspondingly, the first memory is a storage space associated with the first processor for storing source data, which can be a global memory (GMEM) or a video memory of a graphics processing unit, for example; and the second memory is a storage space associated with the first processor as a data carrying target, which can be a high-speed shared memory (SMEM) inside the graphics processing unit, for example.

[0053] The tensor memory access verification method provided by the embodiments of the present application can verify the first processor in the form of an actual physical chip (hardware) or in the form of a pre-silicon verification model (software).

[0054] When the first processor is a graphics processing unit, it is an actual physical chip that has completed physical manufacturing, packaging, and deployment in a test system; when the first processor is a pre-silicon verification model corresponding to the graphics processing unit, it refers to a software model used to simulate hardware behavior in a simulation environment before the chip is actually manufactured. The model is usually composed of register transfer level (RTL) code written in a hardware description language.

[0055] Correspondingly, the first memory can refer to a physical video memory particle on a graphics processing unit board as a global memory, or to a pre-silicon verification model simulating the read-write behavior of a large-capacity memory in a simulator, which interacts with the pre-silicon verification model of the graphics processing unit and responds to read-write requests.

[0056] In a specific embodiment, the method of the embodiments of the present application is used for pre-silicon verification. The entire verification environment runs on a simulation server. The object being tested is a pre-silicon verification model corresponding to a graphics processing unit. In pre-silicon verification, any mismatch found directly corresponds to a logical defect in the design code. Repairing the defect only requires modifying the code and re-simulating, with extremely low cost, thereby avoiding bringing errors into the expensive chip manufacturing process.

[0057] In another specific embodiment, the method of the present application is used for silicon post- validation. The whole validation environment runs on a real hardware platform containing physical chips. The object under test is an actually existing graphic processor. The validation verifies the functional correctness of the final physical chip, and captures errors that can be introduced by physical implementation, timing problems or manufacturing process deviation, which are not exposed in pre-silicon validation.

[0058] In yet another specific embodiment, pre-silicon validation and post-silicon validation can be combined to build a unified, reusable and life-cycle validation method that runs through the whole chip from design to product. Test parameters can be reused in different stages, greatly improving the efficiency and consistency of the validation work, and ensuring the high quality and reliability of the final chip product.

[0059] Test parameters are a set of configuration data used to define a complete validation test scenario. Its random generation is the key to achieving high-coverage automated testing. Test parameters mainly include two types of parameters: tensor descriptor and instruction modifier.

[0060] Tensor descriptor (Usharp) is a data structure used to accurately describe the physical layout of source data in the first memory. Due to the need for performance optimization, source data is usually not stored continuously in memory. Tensor descriptor defines the shape, format and layout of the source data to be moved, which can include but is not limited to the following information: (1) dimensions of the tensor, such as batch, depth, height, width and channel, etc.; (2) stride, i.e. the number of bytes to skip in memory to move from one element of a dimension to the next element; (3) memory layout, such as row-major order, column-major order, or more complex interleaved or block layout; (4) data format, such as FP32 (32-bit floating point), FP16 (16-bit floating point) and INT8 (8-bit integer), etc. Through tensor descriptor, up to 2048 or even more complex memory layouts can be combined.

[0061] The instruction modifier is a set of rules defining the specific behavior of the tensor memory access unit when performing data transfer. It controls how data is read from the source address and written to the target address. The instruction modifier can include but is not limited to the following information: (1) the starting coordinates of the data transfer; (2) the amount of data to be transferred; (3) the stride of the transfer, i.e. the increment of the address after each transfer operation on the source data; (4) the transfer mode, whether it is continuous transfer (memory intensive) or jump transfer; (5) the boundary handling rule, for example, when the transfer operation reaches the boundary of a dimension, whether to continue from the start of the dimension or stop; (6) the multicast rule, i.e. copying a copy of the source data to multiple shared memories. Through the tensor descriptor, up to 120 or even more data transfer rules can be combined.

[0062] The random generation of test parameters can be generated by a pseudo-random number algorithm, randomly selected from a set of massive preset values, or generated according to historical test coverage data to explore unexplored function points.

[0063] Step 120, based on the test parameters, controlling the tensor memory access unit in the first processor to perform actual data transfer operation, and obtaining the actual result of the source data stored in the second memory associated with the first processor.

[0064] Specifically, the tensor memory access unit refers to the hardware logic circuit integrated inside the first processor, which is specially used to efficiently perform complex data transfer operations defined by the tensor descriptor and the instruction modifier.

[0065] There are several ways to control the first processor to perform actual data transfer operations. For example, you can pass the test parameters to the driver program of the first processor through a high-level programming interface call, and then the driver program parses and configures the hardware to execute. Alternatively, you can also dynamically generate program code (such as assembly code or intermediate representation code) containing specific instructions, and load the program onto the first processor for execution.

[0066] The execution process of the data transfer operation is as follows: the first processor drives its internal tensor memory access unit according to the received control instructions. The unit reads and parses the tensor descriptor and instruction modifier in the test parameters, accurately grabs the source data from the first memory, and writes it to the second memory according to the rules. After the operation is completed, the data content stored in the second memory is the actual result of this test.

[0067] Step 130, based on the test parameters, controlling the second processor to perform behavior-level simulation, and obtaining the expected result of the source data transferred from the first memory to the second memory.

[0068] In particular, the second processor can be a general-purpose processor, such as a Central Processing Unit (CPU), which has strong programmable flexibility.

[0069] Controlling the second processor to perform the behavior-level simulation means running a software program on the second processor, which completely reproduces the behavior of the tensor memory access unit in the first processor in terms of logical functions. The simulation is functionally equivalent, rather than a timing simulation at the hardware circuit level, and thus is more efficient in execution. The simulation program running on the second processor is also referred to as a reference model.

[0070] The process of performing the behavior-level simulation is as follows: the second processor obtains exactly the same test parameters (including the tensor descriptor and the instruction modifier) as used by the first processor. Then, the simulation program starts execution. For example, the access to a multi-dimensional tensor can be simulated by a multi-layer nested loop, in each iteration of which the address of the current data element to be moved in the source data and the address to be written into the second memory are accurately calculated. This calculation process strictly follows all the rules defined by the instruction modifier. When all the data is simulated to be moved, the source data copy constructed in the memory of the second processor is the expected result of this test.

[0071] Step 140, compare the actual result with the expected result to determine the functional correctness of the tensor memory access unit under the test parameters.

[0072] In particular, after obtaining the actual result and the expected result, consistency verification is performed thereon. The actual result data stored in the second memory associated with the first processor can be copied out first so as to be accessed by an entity (usually the second processor) capable of performing the comparison operation. The comparison can be performed in various ways, such as element-by-element or byte-by-byte data comparison.

[0073] If the actual result is completely consistent with the expected result, it indicates that the tensor memory access unit of the first processor performs correctly under the combination of the randomly generated test parameters. If there is any difference between the actual result and the expected result, it indicates that the hardware can have defects. At this time, the system records the specific test parameter combination leading to the failure, for subsequent debugging and repair by hardware design and verification engineers. Through thousands of times of automated random testing, this method can efficiently discover hidden defects in the hardware design which are exposed only under specific conditions.

[0074] The tensor memory access verification method provided in this application randomly generates test parameters containing tensor descriptors and instruction modifiers. It then controls the tensor memory access unit in the first processor to perform actual data transfer operations to obtain actual results, and controls the second processor to perform behavioral-level simulations to obtain expected results. By comparing the actual results with the expected results, the functional correctness of the tensor memory access unit under the test parameters is determined. Through random parameter generation and processor behavioral-level simulation, a comprehensive and efficient functional correctness verification of the tensor memory access unit in a dedicated processor can be automatically performed. This effectively solves the technical problems of insufficient coverage and lack of specificity in related technologies, significantly improving the verification efficiency and quality of tensor memory access units.

[0075] It should be noted that each implementation method of this application can be freely combined, rearranged, or executed individually, and does not need to rely on or depend on a fixed execution order.

[0076] In some embodiments, based on test parameters, the tensor memory access unit in the first processor is controlled to perform actual data transfer operations to obtain the actual result of the source data being stored in the second memory associated with the first processor, including:

[0077] Based on test parameters, dynamically generate assembly instructions to control the tensor memory access unit to perform actual data transfer operations;

[0078] The assembly instructions are loaded and executed in the first processor, which controls the tensor memory access unit to move the source data from the first memory to the second memory to obtain the actual result.

[0079] Specifically, assembly instructions refer to low-level machine instructions that a primary processor can directly recognize and execute, or after minimal conversion. Compared to application programming interfaces (APIs) using high-level programming languages, directly manipulating assembly instructions bypasses the optimizations or abstractions of higher-level compilers and drivers, thereby achieving the most direct and precise control over hardware behavior.

[0080] Dynamic generation refers to the fact that assembly instructions are not pre-written fixed programs, but are constructed in memory on the fly based on randomly generated test parameters (i.e., tensor descriptors and instruction modifiers) during the runtime of the verification program.

[0081] In one specific embodiment, assembly instructions can be randomly generated according to the following steps:

[0082] Step 1: Define the assembly code template. This template contains the basic structure of a core kernel, but the critical tensor memory access instructions and their operands are left as placeholders.

[0083] Step 2: Parse test parameters. The program reads the parameter values ​​from the currently randomly generated tensor descriptor and instruction modifier;

[0084] Step three, fill the template to generate an instruction string. The parsed parameter values are formatted and filled into the placeholders of the template according to the syntax rules of the first processor assembly language, thereby generating a complete and executable assembly code. The assembly code can include bulk move instructions, core move instructions, synchronization instructions, and bulk write-back instructions, etc.

[0085] The process of loading and executing the assembly instructions usually relies on the just-in-time compilation function provided by the driver program of the first processor, and the specific process can include:

[0086] Step one, pass the code. The generated assembly code string is passed to the first processor;

[0087] Step two, just-in-time compilation. The driver program calls its built-in compiler to compile the assembly code string into hardware executable binary machine code and load it into the instruction cache of the first processor to form an executable kernel;

[0088] Step three, bind resources and start the kernel. Before executing the kernel, the tensor descriptor in the test parameters needs to be bound with the identification (ID) of a specific resource in the hardware. In this way, when the tensor memory access instruction is executed, the hardware knows how to parse the memory layout information of the source data. At the same time, the address of the first memory where the source data is located and other information are passed as parameters to the kernel;

[0089] Step four, hardware execution. After starting the kernel, the first processor schedules its computing units for execution. When the tensor memory access instruction is executed, the tensor memory access unit is activated, which automatically completes the complex data move from the first memory to the second memory according to the bound tensor descriptor and the modifier encoded in the instruction.

[0090] After the operation is completed, the data stored in the second memory is the actual result.

[0091] The tensor memory access verification method provided by the embodiments of the present application can avoid all intermediate software layers that may introduce interference, directly detect the instruction-level behavior of the hardware, and more deeply and reliably find potential deep-seated defects in the hardware design, thereby greatly improving the completeness and accuracy of the verification.

[0092] In some embodiments, based on the test parameters, the second processor is controlled to perform behavior-level simulation to obtain an expected result of the source data moved from the first memory to the second memory, including:

[0093] Based on the tensor descriptor, the second processor is controlled to generate a source data model; the source data model is used to simulate the layout of the source data in the first memory;

[0094] Based on the instruction modifier, the second processor is controlled to simulate the data movement behavior of the tensor memory access unit, process the source data model, and obtain the expected result.

[0095] Specifically, the second processor can be a central processing unit (CPU), and the source data model is a data structure or array created in the memory of the second processor. The purpose of this data model is not to simply copy the values of the source data, but to accurately reproduce the physical address layout of the source data in the first memory.

[0096] The process of controlling the second processor to generate the source data model is as follows:

[0097] Step one, allocate linear memory. The second processor first allocates a large enough, continuous linear memory region in the memory space, which will be used to simulate the storage space of the first processor;

[0098] Step two, parse the tensor descriptor. The program will parse the tensor descriptor in the current test parameters in detail. The descriptor defines key information such as the dimensions, size, span, and memory arrangement pattern of the source data;

[0099] Step three, fill data. The program will place the initialized source data (such as all 1s, incremental sequences, or random numbers) into the simulated linear memory region according to the complex layout defined by the tensor descriptor. This placement process is critical to the simulation. For example, if the tensor descriptor defines a two-dimensional tensor with a large span between rows (i.e., memory discontinuity), the program will skip the corresponding number of bytes at the end of each row before starting to fill the data of the next row. If the layout is a more complex interleaved or block pattern, the program will perform the corresponding address calculation to ensure that each data element is placed in exactly the same relative position as in the first memory.

[0100] Through the above process, a model that is exactly the same as the physical layout of the source data in the first memory, i.e., the source data model, is created in the memory of the second processor.

[0101] After the source data model is constructed, the simulation program on the second processor begins to simulate the actual data movement process. Simulating the data movement behavior of the tensor memory access unit means reproducing the internal data processing flow of the hardware through software logic. This software logic is designed to be functionally equivalent to the behavior of the hardware.

[0102] The process of controlling the second processor to simulate the data movement behavior of the tensor memory access unit is as follows:

[0103] Step one, initialize the target storage area: additionally allocate a block of area in the memory of the second processor, which is used to simulate the second memory associated with the first processor, and initialize it;

[0104] Step two, parse the instruction modifier: the program parses the instruction modifier in the current test parameter in detail to determine the specific rules of this time of data moving, such as the step length of moving, the data extraction mode, the boundary processing rule, etc.

[0105] Step three, iterate the data moving: the program enters one or more nested loops to simulate the hardware to grab data from the source data model and write it to the target storage area one time after another.

[0106] In each iteration: (1) calculate the source address: according to the current loop variable and the instruction modifier (such as the stride value), the program will calculate the exact address of the data element to be grabbed in the source data model (i.e. the simulated linear memory) this time; (2) calculate the target address: similarly, the program will calculate the address where the data element should be written to the target storage area; (3) execute data copying: the program reads data from the calculated source address and writes it to the calculated target address.

[0107] When all the data to be moved are processed according to the above logic, the data stored in the target storage area simulated in the memory of the second processor constitutes the expected result of this test.

[0108] The tensor memory access verification method provided by the embodiment of the application controls the second processor to generate a source data model through a tensor descriptor, and controls the second processor to simulate the data moving behavior of the tensor memory access unit through an instruction modifier to process the source data model; the behavior level simulation of the first processor is realized, all behavior details of the tensor memory access unit can be reproduced with high fidelity, and the reliability of the expected result is ensured.

[0109] In some embodiments, controlling the second processor to simulate the data moving behavior of the tensor memory access unit includes simulating at least one of the following:

[0110] Parsing a multi-dimensional memory address;

[0111] Performing stride moving;

[0112] Performing boundary checking;

[0113] Performing out-of-bound zero padding.

[0114] Specifically, the data moving behavior simulated by the second processor includes parsing a multi-dimensional memory address, performing stride moving, performing boundary checking, and performing out-of-bound zero padding.

[0115] Resolving a multi-dimensional memory address refers to a calculation process of converting a multi-dimensional coordinate into a one-dimensional linear memory address according to the dimensions, sizes and strides defined in the tensor descriptor.

[0116] Performing stride transfer refers to accessing and copying the source data in a non-continuous and fixed step. The size of the stride is defined in the instruction modifier. The second processor needs to accurately reproduce this jump access mode.

[0117] When the transfer operation approaches or reaches the boundary of a certain dimension of the tensor, the hardware will adopt different strategies according to the settings of the instruction modifier. Performing boundary check refers to judging whether the current access address exceeds the dimension boundary defined by the tensor descriptor.

[0118] When the hardware is configured not to wrap around when it goes out of bounds, it may be required to return zero values for all out-of-bound read requests instead of accessing invalid memory. Performing out-of-bound zero padding refers to, when a read request is found by the boundary check to have an address that falls outside the valid range defined by the source data model, not actually reading the memory at that address (because it may be invalid data or belong to other objects). Instead, the simulation program directly fills in zero values at the location to be written into the target storage area. This ensures that the expected results correctly reflect the safe behavior of the hardware when an out-of-bound read occurs, which is crucial for verifying robustness.

[0119] The tensor memory access verification method provided by the embodiments of the present application accurately implements the above data transfer behavior in behavior-level simulation, so that the second processor can accurately predict the output of the tensor memory access unit under various complex and edge cases.

[0120] In some embodiments, comparing the actual result with the expected result to determine the functional correctness of the tensor memory access unit under the test parameters comprises:

[0121] Comparing the actual result with the expected result byte by byte;

[0122] In the case where each byte in the actual result matches the corresponding byte in the expected result, it is determined that the function of the tensor memory access unit is correct.

[0123] Specifically, the actual result refers to the data block stored in the second memory after the actual transfer operation is performed by the tensor memory access unit of the first processor. The expected result refers to the data block stored in the memory of the second processor calculated by the behavior-level simulation of the second processor.

[0124] Before comparison, the actual result data stored on the first processor side needs to be transmitted to the memory on the second processor side so that the second processor can access both data blocks simultaneously.

[0125] The process of comparing actual results with expected results byte by byte includes:

[0126] Step 1: Treat the actual result data block and the expected result data block as two byte arrays. The lengths of the two arrays should be exactly the same because they are generated based on the same test parameters;

[0127] Step 2: Set a pointer or index starting from the first byte of the two byte arrays (the position with an address offset of 0); in a loop, compare whether the byte value from the actual result pointed to by the current pointer is equal to the corresponding byte value from the expected result. Regardless of the comparison result, move the pointer one byte back and continue comparing the next pair of bytes until all bytes of the two data blocks are compared.

[0128] Only when every byte in the actual result from the first byte to the last byte is exactly equal to the byte at its corresponding position in the expected result, the comparison process is considered successful. In this case, it can be concluded that the function of the tensor memory access unit under this specific set of random test parameters is exactly as designed, i.e., it functions correctly.

[0129] In the process of byte-by-byte comparison, as soon as any byte at a position is found to be mismatched, the comparison process will immediately terminate and report a failure. At this time, it can be determined that the tensor memory access unit has a functional defect or error under this test parameter.

[0130] The tensor memory access verification method provided by the embodiments of the present application adopts the byte-by-byte comparison method, which eliminates any risk of missing errors due to data coincidence, ensuring the certainty of the verification conclusion.

[0131] Figure 2 is a process diagram of the tensor memory access verification provided by the present application, as Figure 2 shown, the first processor is a graphics processor; the second processor is a central processor; the first memory is a global memory associated with the graphics processor; and the second memory is a shared memory in the graphics processor.

[0132] For the graphics processor: assemble instructions for dynamically performing actual data transfer operations according to test parameters; load the assembly instructions into the graphics processor to control the tensor memory access unit to transfer source data from the global memory to the shared memory to obtain actual results.

[0133] For the central processor: control the central processor to generate a source data model according to the tensor descriptor in the test parameters; and control the central processor to simulate the data transfer behavior of the tensor memory access unit to process the source data model to obtain expected results according to the instruction modifier.

[0134] Figure 3 is a schematic diagram of data movement operation provided by the present application, as shown in Figure 3 The dashed arrow in the figure represents the data movement operation, and the solid arrow represents the data movement process. Data blocks 1, 2, 3, and 4 need to be moved from global memory to shared memory.

[0135] According to the tensor descriptor, the data is stored in the form of a tensor in the global memory.

[0136] According to the instruction modifier, the data movement amount is 4, and the stride is 2.

[0137] The moved data is stored in the form of a tensor in the shared memory. The graphics processor performs the actual data movement operation through the tensor memory access unit to obtain the actual result. The central processor simulates the data movement operation through the program to obtain the expected result.

[0138] Finally, the actual result and the expected result are compared to verify the correctness of the function of the tensor memory access unit in the graphics processor.

[0139] The device provided by the embodiments of the present application is described below. The device described below can be referred to the method described above.

[0140]

[0141] is a structural schematic diagram of the tensor memory access verification device provided by the present application, as shown in Figure 4 The device comprises: Figure 4 The parameter generation module 410 is configured to randomly generate test parameters, the test parameters comprising a tensor descriptor used to define the layout of the source data in the first memory associated with the first processor, and an instruction modifier used to define the data movement rule.

[0142] The data movement module 420 is configured to control the tensor memory access unit in the first processor to perform the actual data movement operation based on the test parameters, and obtain the actual result of the source data stored in the second memory associated with the first processor.

[0143] The simulation movement module 430 is configured to control the second processor to perform the behavior-level simulation based on the test parameters, and obtain the expected result of the source data moved from the first memory to the second memory.

[0144] The result verification module 440 is configured to compare the actual result with the expected result, and determine the functional correctness of the tensor memory access unit under the test parameters.

[0145]

[0146] ​​The tensor memory access verification device provided in the embodiments of the present application can generate test parameters including a tensor descriptor and an instruction modifier randomly, control a tensor memory access unit in a first processor to perform an actual data carrying operation to obtain an actual result, control a second processor to perform behavior level simulation to obtain an expected result, compare the actual result with the expected result, and determine the functional correctness of the tensor memory access unit under the test parameters. The random parameter generation and the processor behavior level simulation can automatically and comprehensively and efficiently verify the functional correctness of the tensor memory access unit in the special processor, effectively solve the technical problems of insufficient coverage and weak pertinence of the verification method in the related art, and significantly improve the verification efficiency and quality of the tensor memory access unit.

[0147] Figure 5 is a structural schematic diagram of an electronic device provided in the present application, as shown in Figure 5 The electronic device can include a processor 510, a communication interface 520, a memory 530 and a communication bus 540, wherein the processor 510, the communication interface 520 and the memory 530 can complete mutual communication through the communication bus 540. The processor 510 can call a logical command in the memory 530 to execute the method described in the above embodiments, for example:

[0148] The test parameters are generated randomly, and the test parameters include a tensor descriptor used to define the layout of the source data in a first memory associated with the first processor and an instruction modifier used to define a data carrying rule; based on the test parameters, the tensor memory access unit in the first processor is controlled to perform an actual data carrying operation to obtain an actual result of storing the source data in a second memory associated with the first processor; based on the test parameters, the second processor is controlled to perform behavior level simulation to obtain an expected result of carrying the source data from the first memory to the second memory; and the actual result is compared with the expected result to determine the functional correctness of the tensor memory access unit under the test parameters.

[0149] In addition, the logic commands in the memory described above can be implemented in the form of a software function unit and sold or used as a separate product, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a plurality of commands to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0150] The processor in the electronic device provided by the embodiments of the present application can call the logic instructions in the memory to implement the above method, and the specific implementation manners are consistent with the above method implementation manners, and the same beneficial effects can be achieved, which will not be described here.

[0151] The embodiments of the present application also provide a computer-readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the method provided by each of the above embodiments.

[0152] The specific implementation manners are consistent with the above method implementation manners, and the same beneficial effects can be achieved, which will not be described here.

[0153] The embodiments of the present application provide a computer program product, which includes a computer program. The computer program is executed by a processor to implement the above method.

[0154] The device embodiments described above are only schematic, and the units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or distributed on multiple network units. Part or all of the modules can be selected to achieve the purpose of the present embodiment scheme according to actual needs. Those skilled in the art can understand and implement it without creative labor.

[0155] Those skilled in the art can clearly understand the implementation of the various embodiments by means of software and the necessary general hardware platform from the above description of the embodiments, and of course, the embodiments can also be implemented by hardware. Based on such understanding, the above technical solutions, essentially or in other words, the part of the prior art that contributes to the technical solutions can be embodied in the form of a software product. The computer software product can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, and the like, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0156] Finally, it should be noted that: the above examples are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing examples, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing examples, or make equivalent replacement for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A tensor memory access verification method, characterized in that, include: Randomly generated test parameters include a tensor descriptor for defining the layout of source data in a first memory associated with the first processor, and an instruction modifier for defining data movement rules. Based on the test parameters, the tensor memory access unit in the first processor is controlled to perform actual data transfer operations to obtain the actual result that the source data is stored in the second memory associated with the first processor. Based on the test parameters, the second processor is controlled to perform behavioral-level simulation to obtain the expected result of the source data being moved from the first memory to the second memory; By comparing the actual results with the expected results, the functional correctness of the tensor memory access unit under the test parameters is determined.

2. The tensor memory access verification method according to claim 1, characterized in that, The step of controlling the tensor memory access unit in the first processor to perform actual data transfer operations based on the test parameters, and obtaining the actual result that the source data is stored in the second memory associated with the first processor, includes: Based on the test parameters, assembly instructions are dynamically generated to control the tensor memory access unit to perform actual data transfer operations; The assembly instructions are loaded and executed in the first processor to control the tensor memory access unit to move the source data from the first memory to the second memory, thereby obtaining the actual result.

3. The tensor memory access verification method according to claim 1, characterized in that, The step of controlling the second processor to perform behavioral-level simulation based on the test parameters to obtain the expected result of the source data being moved from the first memory to the second memory includes: Based on the tensor descriptor, the second processor is controlled to generate a source data model; the source data model is used to simulate the layout of the source data in the first memory. Based on the instruction modifier, the second processor is controlled to simulate the data movement behavior of the tensor memory access unit, process the source data model, and obtain the expected result.

4. The tensor memory access verification method according to claim 3, characterized in that, The control of the second processor to simulate the data movement behavior of the tensor memory access unit includes simulating at least one of the following: Resolving multidimensional memory addresses; Perform step-by-step transport; Perform boundary checks; Perform out-of-bounds zero padding.

5. The tensor memory access verification method according to claim 1, characterized in that, The step of comparing the actual results with the expected results to determine the functional correctness of the tensor memory access unit under the test parameters includes: The actual results are compared byte by byte with the expected results; If each byte in the actual result matches the byte corresponding to the expected result, the function of the tensor memory access unit is determined to be correct.

6. The tensor memory access verification method according to any one of claims 1 to 5, characterized in that, The first processor is a graphics processor or a pre-silicon verification model corresponding to the graphics processor; the second processor is a central processing unit; the first memory is the global memory associated with the graphics processor or the pre-silicon verification model corresponding to the global memory; the second memory is the shared memory in the graphics processor.

7. A tensor memory access verification device, characterized in that, include: The parameter generation module is used to randomly generate test parameters, which include tensor descriptors for defining the layout of source data in the first memory associated with the first processor, and instruction modifiers for defining data handling rules. The data transfer module is used to control the tensor memory access unit in the first processor to perform actual data transfer operations based on the test parameters, so as to obtain the actual result that the source data is stored in the second memory associated with the first processor; The simulation transfer module is used to control the second processor to perform behavioral-level simulation based on the test parameters, so as to obtain the expected result of the source data being transferred from the first memory to the second memory; The result verification module is used to compare the actual results with the expected results to determine the functional correctness of the tensor memory access unit under the test parameters.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the tensor memory access verification method according to any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the tensor memory access verification method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the tensor memory access verification method according to any one of claims 1 to 6.

Images