Artificial intelligence accelerator chip simulation method, device, equipment, medium and product

Abstract

The application provides an artificial intelligence accelerator chip simulation method, device, equipment, medium and product, and relates to the technical field of artificial intelligence accelerator chip simulation. The method comprises the following steps: reading a chip behavior contract file defining hardware numerical behavior; based on the file, instantiating a pure integer operation simulation context that prohibits calling a floating point instruction on a general processor; in the simulation context, driving a data flow according to an execution topology sequence, performing a bit-level arithmetic operation on an integer type data structure, and saving an intermediate bit vector of each stage; finally, when there is a bit-level difference between a simulation result and a hardware reference output, the stage identifier and the intermediate bit vector of the stage that cause the difference can be output to backtrack and locate a hardware design defect. The application can realize bit-by-bit accurate deterministic simulation of low-precision matrix operation of an AI chip, and has the advantages of high precision, high flexibility and efficient defect positioning.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence accelerator chip simulation technology, and in particular to an artificial intelligence accelerator chip simulation method, apparatus, equipment, medium and product. Background Technology

[0002] Artificial intelligence (AI) accelerator chips, such as Tensor Cores in graphics processing units (GPUs), widely adopt low-precision data formats for matrix operations in pursuit of higher computing throughput and energy efficiency, such as FP16, BF16, FP8, FP6, FP4, and various block floating-point (MX) formats.

[0003] However, these low-precision formats exhibit significant differences in their specific numerical behaviors across different hardware architectures, product generations, and chip manufacturers. These differences manifest in various aspects, including data encoding methods, rounding strategies, subnormal number processing, propagation of special values ​​(such as NaN and Inf), saturation mechanisms, and accumulation models (such as truncated accumulation and grouped reduction accumulation). During the chip design and verification phases, accurate simulation of these complex numerical behaviors is necessary to ensure the functional correctness of the hardware design.

[0004] Existing simulation methods mainly suffer from two types of problems. The first type of method uses the standard floating-point arithmetic unit built into a general-purpose processor (such as a CPU) for approximate simulation. However, the floating-point operations of general-purpose processors follow standards such as IEEE 754, and their arithmetic logic, rounding modes, and precision often cannot accurately match the unique, non-standard low-precision numerical paths within the target AI accelerator chip. This often results in bit-level differences between the simulation results and the output of the real hardware, making this simulation method unsuitable for rigorous verification of hardware numerical behavior.

[0005] The second approach involves writing a dedicated, hard-coded simulation model for each specific hardware design. While this method can achieve high simulation accuracy, its development and maintenance costs are extremely high. Whenever the hardware design iterates, introducing new data formats, scaling rules, or adjusting pipeline stages, the simulation model needs to be extensively modified or even rewritten. This approach lacks flexibility and scalability, making it unable to adapt to the rapidly evolving needs of AI chip designs.

[0006] Therefore, existing simulation methods have the following shortcomings when simulating low-precision matrix operations of AI accelerator chips: First, the simulation accuracy is insufficient, failing to achieve deterministic simulation that is consistent with hardware behavior bit by bit, resulting in frequent bit-level differences between simulation results and actual hardware measurements. Second, when these bit-level differences occur, existing simulation methods lack effective diagnostic mechanisms, making it difficult to trace the specific computational steps and hardware modules that caused the differences, and failing to provide effective debugging information for locating hardware design defects, leading to low verification efficiency before chip tape-out. Furthermore, the simulation process of existing methods is rigid, lacking flexibility and scalability, making it difficult to adapt to AI accelerator chips with different architectures. These shortcomings make it difficult for existing simulation methods to meet the accuracy and efficiency requirements of AI chip design verification. Summary of the Invention

[0007] This invention provides a method and apparatus for simulating artificial intelligence accelerator chips. It addresses the problem that related technologies, when simulating artificial intelligence accelerator chips, struggle to reproduce the bit-by-bit deterministic numerical behavior of different hardware designs in a configurable and scalable manner on general-purpose processors. This leads to discrepancies between simulation results and actual hardware behavior, making it difficult to trace and locate design defects. The technical solution is as follows: On the one hand, a method for simulating an artificial intelligence accelerator chip is provided, the method comprising: Read the behavior contract file corresponding to the chip hardware description. The behavior contract file records the configuration parameter set in the form of structured data. The configuration parameter set defines at least the matrix shape, operand bit width, bit storage mapping of logical elements, numerical scaling rules, and execution topology order of each stage of the data path pipeline. Based on the behavior contract file, a simulation context for pure integer operations is instantiated on a general-purpose processor. This simulation context prohibits the invocation of floating-point operation instructions of the general-purpose processor, and all matrix elements are represented by an integer data structure containing explicit decimal information. In the simulation context, the data flow is driven through each stage step by step according to the execution topology order. When each stage is executed, bit-level arithmetic operations are performed on the integer data structure according to the operation type of the current stage and the parameters in the behavior contract file to generate an intermediate bit vector consistent with the behavior of the hardware registers in that stage, and the intermediate bit vector is saved to the simulation register buffer corresponding to each stage. Store the output bit vector of the final stage of the pipeline into the result buffer; In response to a bit-level difference between the hardware reference output and the output bit vector in the result buffer, the stage identifier corresponding to the bit-level difference and the intermediate bit vector in the simulation register buffer of that stage are output to trace back and locate hardware design defects in the chip. On the other hand, an artificial intelligence accelerator chip simulation device is provided, the device comprising: The contract file reading module is used to read the behavior contract file corresponding to the chip hardware description. The behavior contract file records the configuration parameter set in the form of structured data. The configuration parameter set defines at least the matrix shape, operand bit width, bit storage mapping of logical elements, numerical scaling rules, and execution topology order of each stage of the data path pipeline. The simulation context instantiation module is used to instantiate a simulation context for pure integer operations on a general-purpose processor based on the behavior contract file. This simulation context prohibits the calling of floating-point operation instructions of the general-purpose processor, and all matrix elements are represented by an integer data structure containing explicit decimal information. The pipeline execution module is used to drive the data flow through each stage step by step in the execution topology order in the simulation context. When each stage is executed, it performs bit-level arithmetic operations on the integer data structure according to the operation type of the current stage and the parameters in the behavior contract file to generate an intermediate bit vector consistent with the behavior of the hardware registers in that stage. An intermediate state storage module is used to save the intermediate bit vector to the simulation register buffer corresponding to each stage; The result output module is used to store the output bit vector of the final stage of the pipeline into the result buffer. The difference backtracking module is used to respond to a bit-level difference between the hardware reference output and the output bit vector in the result buffer, and outputs the stage identifier corresponding to the bit-level difference and the intermediate bit vector in the simulation register buffer of that stage, for backtracking and locating the hardware design defects of the chip.

[0008] On the other hand, a computer device is provided, the computer device including a memory and a processor, the memory for storing computer programs, and the processor for executing the computer programs stored in the memory to implement the steps of the artificial intelligence accelerator chip simulation method described above.

[0009] On the other hand, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the steps of the artificial intelligence accelerator chip simulation method described above.

[0010] On the other hand, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the artificial intelligence accelerator chip simulation method described above.

[0011] The technical solution provided by this invention offers at least the following beneficial effects: By instantiating a simulation context for pure integer operations and performing bit-level arithmetic, this invention eliminates dependence on the floating-point unit of the host platform (general-purpose processor). This eliminates the uncertainty in simulation results caused by different platforms, compilers, or floating-point implementations, enabling the generation of bit-by-bit accurate simulation results consistent with the target hardware behavior, providing a reliable reference for hardware verification. Furthermore, by introducing a behavior contract file to abstract and parameterize the numerical behavior of the hardware, including data format, pipeline topology order, scaling rules, etc., users only need to modify this configuration file to simulate the numerical behavior of AI chips from different manufacturers and generations without altering the simulator's core code. This design makes the method highly flexible and scalable, enabling rapid adaptation to new hardware architectures and numerical formats. During the simulation process, this invention saves the intermediate bit vectors of each stage in the data path pipeline. When the final output differs from the hardware reference output at the bit level, it can output the stage identifier that caused the difference and the complete input / output state of that stage. This allows hardware designers to quickly trace back and pinpoint the specific aspects of design flaws, helping to shorten the debugging and verification cycle of chip design. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of an artificial intelligence accelerator chip simulation method provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of the overall data flow according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the state transition of a staged numerical path according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the MX quantization process according to an embodiment of the present invention; Figure 5 This is a schematic diagram of bit packing in a non-byte aligned format according to an embodiment of the present invention; Figure 6 This is a schematic diagram of numerical data transformation according to a specific embodiment of the present invention; Figure 7 This is a structural diagram of an artificial intelligence accelerator chip simulation device provided in an embodiment of the present invention; Figure 8 This is a hardware architecture diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0015] As mentioned above, the embodiments of this application aim to provide a simulation method for artificial intelligence accelerator chips to solve the problem of bit-level deviation between simulation results and actual hardware behavior caused by reliance on general-purpose floating-point arithmetic units in the prior art.

[0016] The specific implementation of the above concept is described below.

[0017] Please refer to Figure 1 The artificial intelligence accelerator chip simulation method provided in this embodiment of the invention includes: Step 100: Read the behavior contract file corresponding to the chip hardware description. The behavior contract file records the configuration parameter set in the form of structured data. The configuration parameter set defines at least the matrix shape, operand bit width, bit storage mapping of logical elements, numerical scaling rules, and execution topology order of each stage of the data path pipeline. Step 101: Based on the behavior contract file, instantiate a simulation context for pure integer operations on a general-purpose processor. This simulation context prohibits the calling of floating-point operation instructions of the general-purpose processor, and all matrix elements are represented by an integer data structure containing explicit decimal information. Step 102: In the simulation context, the data flow is driven through each stage step by step according to the execution topology order. When each stage is executed, bit-level arithmetic operations are performed on the integer data structure according to the operation type of the current stage and the parameters in the behavior contract file to generate an intermediate bit vector consistent with the behavior of the hardware registers in that stage, and the intermediate bit vector is saved to the simulation register buffer corresponding to each stage. Step 103: Store the output bit vector of the final stage of the pipeline into the result buffer. Step 104: In response to a bit-level difference between the hardware reference output and the output bit vector in the result buffer, the stage identifier corresponding to the bit-level difference and the intermediate bit vector in the simulation register buffer of that stage are output to backtrack and locate the hardware design defect of the chip.

[0018] In this embodiment of the invention, a deterministic and traceable simulation of the chip's numerical behavior is achieved by constructing a simulation environment entirely based on integer operations and driven by a detailed behavioral contract file. Based on this simulation architecture, the simulation output is compared bit-by-bit with the hardware reference output. In response to bit-level differences, the stage identifier of the bit-level difference and the intermediate bit vector of that stage are output, thereby achieving full interpretability and traceability of the simulation process from input to bit-level difference output.

[0019] The following description Figure 1 and Figure 2 The execution method for each step is shown.

[0020] Step 100: Read the behavior contract file corresponding to the chip hardware description. The behavior contract file records the configuration parameter set in the form of structured data. The configuration parameter set defines at least the matrix shape, operand bit width, bit storage mapping of logical elements, numerical scaling rules, and execution topology order of each stage of the data path pipeline. The behavior contract file in this embodiment refers to a structured data file used to record the complete numerical behavior specification for matrix multiplication and addition operations of an artificial intelligence accelerator chip. Its content includes at least a set of configuration parameters, which defines the matrix shape, operand bit width, bit storage mapping of logical elements, numerical scaling rules, and the execution topology order of each stage of the data path pipeline. This file serves as a common language connecting hardware design, simulation models, and the software stack, ensuring that all parties have a consistent understanding and implementation of the numerical behavior. In some implementations, it can be generated from a more high-level declarative specification file.

[0021] The method provided in this application's embodiments is based on the core principle of first reading the behavior contract file corresponding to the chip hardware description. This behavior contract file defines the logical constraints and expected behavior specifications for the chip's numerical operations. It precisely records all key simulation parameters in a structured data format, such as JSON, YAML, or a custom binary format. These parameters constitute a configuration parameter set that delves into the micro-level of hardware implementation, defining at least the logical shape of the matrix (e.g., M, N, K dimensions), the numerical format and bit width of the operands (e.g., FP8, FP4), the bit storage mapping method of logical elements in physical memory, complex numerical scaling rules, etc. (logical constraints), and the execution topology order of each computational stage in the data path pipeline (expected behavior specifications). The purpose of this step is to extract all numerically related specifications of the hardware design from scattered design documents, RTL code, and engineers' experience, forming a single, machine-readable source, thereby laying a solid foundation for subsequent deterministic simulation. Step 101: Based on the behavior contract file, instantiate a simulation context for pure integer operations on a general-purpose processor. This simulation context prohibits the calling of floating-point operation instructions of the general-purpose processor, and all matrix elements are represented by an integer data structure containing explicit decimal information. In this embodiment, the simulation context refers to a software environment instantiated on a general-purpose processor and dedicated to performing bit-level precise simulation. Its core feature is that it prohibits calling the host processor's floating-point arithmetic instructions, and all values ​​are represented in an integer data structure containing explicit decimal information, thereby avoiding the uncertainty of simulation results caused by differences in floating-point implementations across different platforms and ensuring the bit-level reproducibility of the simulation process.

[0022] Specifically, based on the aforementioned read behavior contract file, the next step is to instantiate a simulation context for pure integer arithmetic on a general-purpose processor. Pure integer arithmetic means that throughout the simulation process, calling floating-point arithmetic instructions built into the general-purpose processor (CPU) (such as floating-point addition and multiplication in the SSE / AVX instruction set of the x86 architecture) is strictly prohibited. The design principle is that different CPU architectures, different compiler versions, and even different compilation optimization options can lead to slight differences in floating-point arithmetic results (Least Significant Bit, LSB difference). These slight differences can be amplified in long chains of accumulation operations, ultimately causing unexplained deviations between the simulation results and hardware RTL simulations or post-silicon measured results. By forcing all operations to be performed in the integer domain, this scheme fundamentally eliminates this uncertainty. To express floating-point or fixed-point numbers in the integer domain, all matrix elements are represented as a special integer data structure that, in addition to storing the integer part of the value, explicitly includes information about the number of decimal places (e.g., recording the position of the decimal point through an additional field), or directly uses fixed-point representation to scale all values ​​to integers for calculation. In this way, even decimal operations are transformed into precise, unambiguous integer shifts and arithmetic operations, thus solving the problem of bit-level consistency that cannot be guaranteed due to the uncertainty of floating-point operations in traditional simulation methods.

[0023] Step 102: In the simulation context, the data flow is driven through each stage step by step according to the execution topology order. When each stage is executed, bit-level arithmetic operations are performed on the integer data structure according to the operation type of the current stage and the parameters in the behavior contract file to generate an intermediate bit vector consistent with the behavior of the hardware registers in that stage, and the intermediate bit vector is saved to the simulation register buffer corresponding to each stage. The execution topology order in this embodiment refers to an ordered list that defines the sequential order of the various computational stages in the data path pipeline. This invention decomposes the complex matrix multiplication and addition process into a series of configurable and reorderable atomic stages (such as exact multiplication, scaling, reduction, etc.), and this order itself constitutes part of the semantics of numerical behavior; different orders represent different hardware accumulation models.

[0024] Bit-level arithmetic operations in this embodiment refer to arithmetic operations performed directly on the binary representation of integers or fixed-point numbers, such as bit shifting, bitwise AND / OR / XOR, integer addition / multiplication, etc. These operations can accurately simulate numerical transformations at the register level within the hardware, including decoding, rounding, saturation, and handling of special values ​​for non-standard data formats, forming the basis for achieving precise bit-by-bit simulation.

[0025] Specifically, within the constructed simulation context, the data flow is driven step-by-step through each stage of the pipeline according to the execution topology sequence defined in the behavior contract file. This simulates the flow of data between different computing units in real hardware. At each stage, the simulator performs bit-level arithmetic operations on the integer data structure passed in from the previous stage, based on the operation type of the current stage (e.g., multiplication, scaling, or accumulation) and the parameters configured for that stage in the behavior contract file (e.g., bit width, rounding mode, scaling factor, group size, etc.). These operations include, but are not limited to, integer multiplication, integer addition, logical shifts (used to scale and align fixed-point numbers), and bitmasking operations (used to handle special values ​​or packed data). An intermediate bit vector consistent with the behavior of the hardware registers at that stage is generated. Generating an intermediate bit vector consistent with the behavior of the hardware registers at that stage means that, under the same input bit mode and the same configuration parameters (including but not limited to bit width, rounding mode, scaling factor, group size), the value (0 or 1) of each bit in the intermediate output bit vector calculated by the simulation system is exactly the same as the value stored in the register of the corresponding hardware module in the real AI accelerator chip after executing the same stage. This consistent behavior is not a functional or numerical approximation, but rather a deterministic result of bit-identical equivalence. This ensures that the simulation process accurately reflects the bit-level semantics of the hardware in low-precision computation, providing a precise reference for subsequent backtracking. This intermediate bit vector is then stored in the simulation register buffer corresponding to that stage. Through this staged execution and state-saving mechanism, not only is the final computation result of the hardware simulated, but more importantly, the evolution of data at each step of the pipeline is reproduced. This helps solve the problem that existing simulation methods often focus only on the final output while ignoring intermediate states, leading to debugging difficulties.

[0026] Step 103: Store the output bit vector of the final stage of the pipeline into the result buffer. Specifically, after the data stream completes computations across all pipeline stages, the output bit vector generated in the final stage is stored in a dedicated result buffer. The data in this result buffer should, in theory, be completely identical to the output produced by the target hardware under the same input. This step provides direct, bit-level accurate simulation output for subsequent verification and comparison.

[0027] Step 104: In response to a bit-level difference between the hardware reference output and the output bit vector in the result buffer, the stage identifier corresponding to the bit-level difference and the intermediate bit vector in the simulation register buffer of that stage are output to backtrack and locate the hardware design defect of the chip.

[0028] Finally, a core aspect of this method lies in its effective debugging and backtracking capabilities. After the simulation process concludes, the system initiates a backtracking mechanism in response to a trigger condition: any bit-level difference exists between the hardware reference output (e.g., from RTL simulation, FPGA prototype, or measured results from a fabricated chip) and the output bit vector in the aforementioned result buffer. Once a mismatch is detected, the system not only reports a result error but also outputs detailed contextual information leading to the difference. Specifically, it outputs the identifier of the pipeline stage where the bit-level difference first occurred, along with the intermediate bit vector stored in the simulation register buffer of that stage that caused the erroneous output. By recording the intermediate bit vectors and their respective stage identifiers during the simulation process, and outputting the stage identifier and input / output bit vectors corresponding to the difference when there is a bit-level difference between the output result and the hardware reference output, chip design engineers can locate the specific processing stage in the hardware design that causes numerical deviations based on the precise bit-level information of the simulation intermediate state. This enables rapid diagnosis and correction of logical errors, rounding strategy errors, scaling parameter errors, or stage sequence errors in RTL code, effectively shortening the chip verification cycle and improving the tape-out success rate.

[0029] Furthermore, in a preferred embodiment, to support the diverse AI computing needs of the industry, the operand bit-width format recorded in the configuration parameter set in the aforementioned behavior contract file includes at least one of the following: single-precision floating-point format (FP32), half-precision floating-point format (FP16), bfloat16 floating-point format (BF16), 8-bit floating-point format (FP8), 6-bit floating-point format (FP6), 4-bit floating-point format (FP4), 8-bit mixed integer format (MXINT8), 8-bit unsigned exponent zero-bit mantissa floating-point format (UE8M0), and 4-bit unsigned exponent three-bit mantissa floating-point format (UE4M3). For some of these non-byte-aligned formats (such as FP4 and FP6), their physical storage method is particularly critical. Therefore, the bit storage mapping in the behavior contract file is configured such that, for non-byte-aligned low-precision formats, the bit offset start position and bit field length of each logical element are defined in a byte-level storage buffer, and the bit field of each logical element is entirely within a single byte and does not cross byte boundaries. Based on this bit storage mapping, the simulation system extracts the bit patterns of each logical element from the original byte stream bit by bit, thereby achieving deterministic decoding of non-byte-aligned low-precision formats such as FP4 and FP6. This mechanism avoids decoding errors caused by byte alignment assumptions in traditional simulation tools, significantly improving the reproducibility and verification accuracy of low-precision formats across different platforms.

[0030] In another preferred embodiment, the bit storage mapping rules can be specified for the aforementioned FP4 and FP6 formats. For example, when the operand bit width format is FP4, i.e., each logical element occupies 4 bits, one byte (8 bits) can store two logical elements. In this case, the bit storage mapping can be specified as follows: the lower 4 bits of the byte (bits 0-3) are mapped to logical elements with even indices, while the higher 4 bits of the byte (bits 4-7) are mapped to logical elements with odd indices. Please refer to [reference needed]. Figure 5 The diagram clearly illustrates this packing method. For the operand bit-width format FP6, the bit storage mapping specifies that the bit fields of every two consecutive logical elements are compressed and stored in a byte-a-half, and filled in high-order priority within that byte-a-half. Specifically, each FP6 logical element occupies 6 bits, and two consecutive logical elements constitute a 12-bit byte-a-half; this byte-a-half is distributed across two consecutive bytes in the physical storage medium: the 6 bits of the first logical element are stored in the high 6 bits (bits 7–2) of the first byte, and the 6 bits of the second logical element are stored in the low 6 bits (bits 5–0) of the second byte. Within each byte, the element bits are filled sequentially from the most significant bit (bit 7) to the least significant bit (bit 0), forming a uniform high-order priority bit order. This explicit bit-level packing rule enables the simulator to accurately simulate how the hardware reads and interprets memory, ensuring bit-level consistency from the input data source.

[0031] In one alternative implementation, to accurately simulate the block floating-point or mixed precision technologies widely used in modern AI chips, the configuration parameter set in the behavioral contract file contains detailed numerical scaling rules. These rules typically include local scaling factors and global scaling factors. A local scaling factor is a scaling value shared by all elements within a data block (e.g., an 8x8 submatrix), aiming to maintain the highest possible dynamic range and precision within a finite bit width. The behavioral contract file records how this local scaling factor is generated; two common methods exist: the first is the shared exponent method, which determines a common power of 2 as the local scaling factor based on the maximum exponent value among all elements in the block; the second is the maximum value method, which determines the scaling factor based on the ratio between the maximum absolute value of all elements in the block and the maximum representable finite value determined by the current operand bit width format. These two methods each have their advantages and disadvantages, and their hardware implementations differ. This solution achieves accurate simulation by explicitly specifying these values ​​in the contract file. Corresponding to the local scaling factor is the global scaling factor, which is a uniform scaling value spanning all data blocks. The behavioral contract file records its specific numerical value (as a fixed constant) or its calculation rules (e.g., dynamically calculated based on the absolute maximum value of the entire input matrix). Furthermore, the global scaling factor can be independently applied to the first and second matrix paths in the data path pipeline. By modeling these complex scaling rules, this method can accurately reproduce the quantization error introduced by scaling, a crucial step in ensuring the accuracy of numerical simulations. Further, as... Figure 2 and Figure 3 As shown, the data path pipeline defined by the aforementioned execution topology sequence can be decomposed into a series of specific, sequentially executable stages. Specifically, Figure 2 The core data flow of this method is shown from the overall architecture perspective: the behavior contract file serves as the specification input, which, after being parsed by the unified rule representation layer, provides input to bit-level reading and numerical interpretation and the staged numerical path execution order; the output of bit-level reading and numerical interpretation serves as the input to the staged numerical path execution order, and after being processed by the staged numerical path execution order, it is output to the bit-level output result buffer; local / global scaling data, after being processed by the scaling and quantization description layer, is directly output to the bit-level output result buffer.

[0032] Figure 3The state transitions and data update processes between the stages of the pipeline are further illustrated at the state machine level: the stage control specification includes stage order, rounding and merging strategies, which are used to control the execution order of each stage of the pipeline; the pipeline starts execution from the initial state (product term is empty). In the initial state, the product term is empty and the group index initialization is completed. After the initial state, the stage control specification enters the precise product stage to generate a set of product terms. Each uncrunted full-precision integer bit vector generated in the precise product stage is defined as a product term. That is, a product item is an intermediate value of the unreduced product generated by the multiplication operation of a single matrix element, corresponding to the smallest data unit output in the precise product stage; multiple product items constitute a product item set, which serves as the input for the subsequent item-by-item scaling stage; the product item set is updated to the scaled product in the item-by-item scaling stage, the scaled product is updated to the in-group result in the group reduction stage, the in-group result is updated to the grouped scaling result in the grouped scaling stage, the grouped scaling result is updated to the current result in the alignment, rounding, and summation stage, the current result is updated to the merged result in the accumulation and merging stage, and the merged result is updated to the output bit mode in the output encoding stage; intermediate data is passed between stages through a shared state vector, which includes product items, current result, accumulated items, group index, target precision, and special value markers. A typical implementation includes at least the following three stages: First, the precise product stage, in which fixed-point integer multiplication is performed on the elements of the two input matrices (or their sub-blocks), generating an untruncated, unrounded, full-precision integer bit vector that retains all information from the multiplication operation. The second stage is the item-by-item scaling stage. This stage, based on the aforementioned numerical scaling rules (including local and global scaling factors), performs fixed-point shifting (for power-of-2 scaling) or fixed-point multiplication (for non-power-of-2 scaling) on ​​the product bit vectors generated in the previous step to complete the scaling operation. Finally, the grouping reduction stage performs fixed-point accumulation within each group on the scaled product bit vectors according to the grouping granularity recorded in the behavior contract file. The grouping granularity can be a fixed number of consecutive elements (e.g., every four elements) or grouping by parity index. By decomposing the complex matrix multiplication into such a series of well-defined and configurable stages, this method can flexibly simulate the numerical behavior of different hardware architectures (such as truncated accumulation, grouped scaling accumulation, etc.), greatly improving the versatility and accuracy of the simulation.

[0033] In a more specific implementation, the data path pipeline can include more refined stages to simulate more complex hardware behavior. For example, after group reduction, a post-group scaling stage can be added, whereby the post-group scaling stage applies a block-level scaling factor to the result of the intra-group reduction again, which is common in some multi-level scaling hardware designs. Subsequently, the alignment and rounding summation stage proceeds, which is the core control point for numerical accuracy. It aligns multiple bit vectors from different product terms to a unified decimal reference using fixed-point shift operations based on a target number of decimal places, and then performs a multi-operand fusion summation according to the rounding mode recorded in the behavior contract file (e.g., rounding to zero, rounding to the nearest even number, rounding up, or rounding down). Afterward, there may be an accumulation and merging stage, which performs fixed-point addition to merge the bit vectors of the summation result with the bit vectors of corresponding elements in the accumulation matrix (usually the accumulated result from the previous round of calculation). For more complex reduction strategies, there may also be an inter-group merging stage for secondary aggregation of the results of multiple group reductions. In addition, a special value processing stage is included to handle abnormal values. This stage processes bit vectors in the input, intermediate, or final results that conform to the NaN (Not a Number), Inf (Infinity), or subnormal number encoding patterns, performing the processing operations specified in the behavior contract file. Finally, the output encoding stage encodes the final fixed-point result into the original bit pattern according to the output bit width format requirements recorded in the behavior contract file (such as exponent bit width, mantissa bit width, saturation threshold, and final rounding mode), and writes it to the simulation register buffer. This detailed series of stages allows this simulation method to reproduce every minute operation within the hardware with extremely high fidelity. In a preferred implementation of the alignment, rounding, and summation stage, a specific integer arithmetic strategy is adopted by the simulation context to accurately simulate the impact of the limited effective bit width of the chip's internal accumulator. Specifically, it converts multiple fixed-point product bit vectors to be summed into signed integer forms. Then, based on the target number of decimal places recorded for this stage in the behavior contract file, a logical left shift operation is performed on these signed integers to achieve decimal point alignment. The key is that the aligned integers will undergo a single multi-operand integer addition (instead of pairwise addition), and after the entire addition operation is completed, a uniform rounding operation is performed on the final summation result exactly once. This "accumulate first, then round" strategy is highly consistent with the behavior of the commonly used fused multiply-add (FMA) unit in hardware, and can accurately simulate numerical differences caused by different accumulation order and intermediate rounding times, thereby capturing numerical deviations related to accumulator bit width limitations that are easily ignored in traditional simulations.

[0034] Furthermore, in a preferred embodiment, to decouple the stored data format from the computed data format, the configuration parameter set in the behavior contract file also includes an MX quantization description field independent of the execution topology order. The MX format is a block floating-point representation method popular in the AI ​​chip field in recent years. This field specifically records parameters related to MX quantization, such as: element format type (e.g., MXFP8, MXFP4), block size (e.g., 32 elements per group), axial block layout (whether the block is divided along rows or columns), local scaling factor generation method (shared exponent method or maximum value method), global scaling strategy, subnormal number processing strategy (whether to retain or flush to zero), saturation strategy, and mapping rules for special values ​​(e.g., NaN / Inf). After reading the original bit string of the input matrix, the simulation context will first perform quantization operations on the input data according to this MX quantization description, such as... Figure 4 As shown; correspondingly, before the pipeline computation is completed and the final output encoding is performed, the fixed-point result is dequantized according to this MX quantization description. By introducing this independent MX quantization description layer, the data format used during storage / transmission (usually a highly compressed MX format) is separated from the data format used during pipeline computation (potentially a higher-precision fixed-point format), which greatly enhances the flexibility and modularity of the design.

[0035] The decoupling of the MX quantization description from the execution topology order, as described above, brings significant technical advantages. Specifically, the MX quantization description field recorded in the behavior contract file is independent of the stage definition in the execution topology order. This means that while the values ​​of the MX quantization description field (i.e., the quantization parameters) remain unchanged, the simulator can flexibly switch the implementation of its core computational pipeline; that is, the execution topology order can be configured to multiple modes such as truncated accumulation pipeline, grouped scaling accumulation pipeline, or precise accumulation pipeline. This orthogonal design allows the same set of quantization parameters to be easily applied to various different accumulation value paths for testing and verification. For example, designers can quickly evaluate the impact on the final model accuracy when using lower-cost truncated accumulation hardware versus higher-cost precise accumulation hardware for the same MXFP4 quantization scheme. This capability is of great significance for architecture exploration and performance-cost trade-offs in the early stages of chip design, solving the problem of tightly coupled quantization schemes and computational paths in traditional simulation methods, making independent changes difficult.

[0036] In one alternative implementation, to enhance usability and automation, the behavior contract file itself can be generated from a declarative specification file. This declarative specification file can have two formats: a compact specification format or a full specification format. The compact specification format is designed for experienced users or common scenarios, recording only the most critical parameters, such as the model category identifier (e.g., a tensor core representing a particular generation of GPUs from a specific manufacturer), segment length parameters, internal significant bits parameters, and output rounding strategy parameters. Upon receiving this compact specification, the simulation context automatically derives and generates a default, complete execution topology order matching the model category, based on a built-in rule base or model library. The full specification format, on the other hand, provides flexibility and control, allowing users to explicitly record detailed information for each stage of the execution topology order, including operation type, group size parameters, block size parameters, internal significant bits parameters, rounding mode parameters, and a flag indicating whether the stage needs to be merged with the accumulation matrix. This hierarchical specification design balances the needs for rapid configuration and fine-grained control.

[0037] To further improve simulation performance, especially for large-scale regression testing scenarios, the aforementioned declarative specification file can be pre-compiled into an executable specification object before the simulation context starts running. This compilation process transforms the high-level, descriptive specification text into a low-level, more efficient form. This executable specification object can be a structured data object with an optimized memory layout for fast random access; or it can be a further optimized sequence of bytecode instructions, similar to a miniature virtual machine instruction set customized for this simulation task. This executable specification object, embedded in memory, allows the simulation context to directly read and execute these efficient instructions or data when performing staged numerical operations, completely independent of the potentially time-consuming configuration interpreter initially used to generate it. Through this compile-once, run-multiple-times model, the simulation context can independently complete all stages of computation without relying on the configuration interpreter when performing staged numerical operations, significantly reducing the configuration parsing overhead of each simulation run and improving the overall simulation throughput.

[0038] During pipelined execution, handling special values ​​(such as NaN, Inf, and subnormal numbers) is a crucial but complex step in ensuring numerical consistency. In a preferred embodiment of this application, the aforementioned special value handling stage provides detailed specifications for this. For input matrix elements, any intermediate operation results, or the final output result whose bit vectors conform to the NaN, Inf, or subnormal number encoding rules, the simulation context strictly operates according to the special value handling strategy recorded in the behavior contract file. These strategies are highly flexible and can perform at least one or more of the following: One strategy is "zeroing," which replaces the bit vector of the special value with a bit vector of all zeros, used in some hardware to suppress error propagation. Another strategy is "clamping," which replaces the bit vector with a bit vector representing the largest or smallest finite value that the current data format can represent. A third strategy is "preservation and marking," which preserves the bit vector of the special value, allowing it to continue propagating in the pipeline, while simultaneously recording a special value marker in the corresponding bit of a parallel status register for use in subsequent stages or final analysis. The fourth strategy is "mapping transformation," which precisely maps the special value bit vector of the current format to the corresponding special value bit vector in the target format based on the special value encoding bit pattern of the target output format (e.g., converting one representation of NaN to another). By finely modeling these processing strategies, this method can capture the differences in the final result caused by different hardware handling methods for special values.

[0039] The ultimate goal of this simulation method is to serve chip verification and debugging. Therefore, in a specific implementation, the output bit vector in the result buffer of the simulation context is used for bit-by-bit consistency comparison with one or more reference bit vectors. These reference bit vectors can come from various sources, including: the corresponding matrix multiplication and addition result bit vector output by the chip's hardware RTL (Register Transfer Level) simulation model under the same stimulus; the corresponding matrix multiplication and addition result bit vector measured on a test platform after chip manufacturing (post-siliconization); the corresponding matrix multiplication and addition result bit vector pre-calculated from a mathematically absolutely accurate golden reference sample that does not consider any hardware limitations; or even the corresponding matrix multiplication and addition result bit vector output in a separate simulation context, possibly implemented by a different team, based on the same behavior contract file, for cross-validation. Once any bit-level difference appears in the comparison results, the system will output the location information of the difference bit and the stage identifier of the stage in which the difference bit is located. Based on this location information and stage identifier, combined with the pattern of the difference, the system will determine and output the possible numerical behavior deviation type corresponding to the difference.

[0040] In one specific embodiment, based on the bit-level differences in the comparison results, a stage-level intermediate state log is maintained for each output logic element during simulation execution to accurately record the position information of the difference bit in the output matrix (including row index m, column index n, and bit offset bit_idx within the element). Then, according to the execution sequence of the staged numerical path, the stage identifier (such as STAGE_GROUP_REDUCE, STAGE_POST_SCALE, or STAGE_OUTPUT_CONVERT) of the first occurrence of the difference is traced back. Subsequently, the pattern characteristics of the numerical field containing the difference bit are parsed (such as sign bit flipping, overflow of +1 or -1 in the mantissa, abnormal exponent jump, or special values ​​(Inf / NaN / Zero) being incorrectly truncated to normal values). Based on a preset mapping rule base of "stage identifier, difference pattern, and deviation type," the above triples (position information, stage identifier, and difference pattern) are matched to predefined numerical behavior deviation types. For example: when the stage identifier is STAGE_ROUND_SUM and the difference mode is overflow of the last digit + 1, it is determined as "insufficient intermediate precision during alignment rounding and summation leads to incorrect rounding direction"; When the stage identifier is STAGE_POST_SCALE and the difference mode is sign bit flip, it is determined as "post-group scaling does not properly handle negative saturation". Finally, the numerical behavior deviation type corresponding to the difference is output in a structured format, realizing end-to-end automatic diagnosis from bit-level inconsistency to semantic-level error root cause.

[0041] These types of deviations include, but are not limited to: rounding boundary deviations (e.g., the hardware's rounding direction is different from the expected direction for a value exactly between two representable values), block scaling quantization errors (precision loss due to local or global scaling), stage execution order semantic deviations (e.g., the hardware actually accumulates first and then scales, while the model thinks it scales first and then accumulates), special value propagation deviations (the hardware handles NaN or Inf differently than expected), and output truncation deviations (errors that occur when converting the final result to the output format). In this way, this method can not only detect defects but also identify the type of defect with a high probability, providing strong support for locating and fixing these critical numerical behavior deviations before chip fabrication.

[0042] To support efficient simulation of large-scale matrix multiplication and addition operations and accurately reproduce the tiling strategy commonly used in hardware, the simulation context of this invention performs block processing on the input matrix before executing the staged numerical path. Specifically, along the inner product dimension of the matrix multiplication operation, i.e., the K dimension, the K dimension is divided into several continuous sub-blocks according to the segment length parameter recorded in the behavior contract file. The length of each sub-block is equal to the parameter, except for the last sub-block. For each sub-block, the simulation context independently reads the row vector sub-block of the first matrix A within the corresponding K range of the sub-block, and the column vector sub-block of the second matrix B within the corresponding K range of the sub-block, and converts them into a unified fixed-point representation using bit-level decoding. Subsequently, it drives the data flow of the sub-block to strictly follow all stages defined by the execution topology order in the behavior contract file, including exact multiplication, item-by-item scaling, etc. The process involves sequentially performing operations such as sorting, grouping and reduction, post-grouping scaling, alignment and rounding summation, and merging of accumulated terms to generate an intermediate bit vector corresponding to the sub-block. This vector consists of fixed-point integer intermediate values ​​encoded in the target output format but not yet merged. After entering the accumulation and merging stage, all intermediate bit vectors generated by the sub-blocks are merged element-by-element using fixed-point integer addition based on their row and column positions (m, n) in the output matrix to form the final bit vector. When the total length of the K-dimensional dimension cannot be divided evenly by the segment length parameter, the last sub-block uses its actual remaining length as the effective K range and still performs all stages of operations completely to ensure that no computational contribution is lost. Furthermore, its internal bit-level decoding, scaling application, and rounding operations strictly follow the format and precision rules defined in the behavior contract file, thereby maintaining the determinism, integrity, and hardware behavior consistency of the computation under any matrix shape.

[0043] Please see Figure 6 This figure illustrates a complete numerical data transformation process from input to output in a specific embodiment of this application, used to simulate a matrix multiplication-addition operation using FP4 input format and FP32 output format. The entire process begins with input 500, which contains input matrix A (FP4) 510 and input matrix B (FP4) 520. The elements of these two matrices are stored as bit strings in FP4 format. First, in step 530, the simulation context decodes the input bit strings into an internally used integer data structure containing explicit decimal information according to the FP4 bit storage mapping rules defined in the behavior contract file. This step is the first step in decoupling floating-point operations from the host platform.

[0044] The decoded integer data structure enters the data path pipeline 590. The first stage of the pipeline is precise product 540, which performs pure integer multiplication on corresponding elements from matrix A and matrix B, generating an untruncated, full-precision integer intermediate result 542. Subsequently, the data flow enters stage two: scaling 550. In this stage, fixed-point shifting or integer multiplication is performed on the intermediate result 542 according to the numerical scaling rules in the behavior contract file (e.g., a local scaling factor calculated from the block data), resulting in a scaled integer intermediate result 552. Next is stage three: fusion summation 560. This stage aligns and accumulates multiple scaled intermediate results 552, performing a unified rounding after all additions according to the rounding pattern defined in the behavior contract file, ultimately generating a fixed-point integer summation result 562. This process precisely simulates the behavior of a hardware accumulator.

[0045] Finally, the data stream leaves the data path pipeline and enters the output stage 595. In the encoding and output step 570, the summation result 562 is encoded into a standard FP32 bit pattern according to the encoding rules (such as exponent bias, mantissa bit width, special value representation, etc.) defined in the behavior contract file for the output format (FP32 in this example). Ultimately, the encoded output matrix C(FP32) 580 is stored in the result buffer and can be used for bit-level comparison with the hardware reference value. The entire process is performed entirely within the framework of integer and fixed-point arithmetic, ensuring that each transformation from input 500 to output 595 is deterministic and reproducible.

[0046] Please refer to Figure 7 This invention provides an artificial intelligence accelerator chip simulation device, which includes: The contract file reading module 61 is used to read the behavior contract file corresponding to the chip hardware description. The behavior contract file records the configuration parameter set in the form of structured data. The configuration parameter set defines at least the matrix shape, operand bit width, bit storage mapping of logical elements, numerical scaling rules, and execution topology order of each stage of the data path pipeline. The simulation context instantiation module 62 is used to instantiate a simulation context for pure integer operations on a general-purpose processor based on the behavior contract file. This simulation context prohibits the calling of floating-point operation instructions of the general-purpose processor, and all matrix elements are represented by an integer data structure containing explicit decimal information. The pipeline execution module 63 is used to drive the data flow through each stage step by step in the execution topology order in the simulation context. When each stage is executed, it performs bit-level arithmetic operations on the integer data structure according to the operation type of the current stage and the parameters in the behavior contract file to generate an intermediate bit vector consistent with the behavior of the hardware registers of that stage. Intermediate state storage module 64 is used to save the intermediate bit vector to the simulation register buffer area corresponding to each stage; The result output module 65 is used to store the output bit vector of the final stage of the pipeline into the result buffer. The difference backtracking module 66 is used to respond to a bit-level difference between the hardware reference output and the output bit vector in the result buffer, and output the stage identifier corresponding to the bit-level difference and the intermediate bit vector in the simulation register buffer of that stage, for backtracking and locating the hardware design defects of the chip.

[0047] It should be noted that the artificial intelligence accelerator chip simulation device provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the artificial intelligence accelerator chip simulation device and the artificial intelligence accelerator chip simulation method embodiment provided in the above embodiments belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0048] Embodiments of this application also provide a computer device, please refer to... Figure 8 The computer device includes a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, at least one program, code set or instruction set being loaded and executed by the processor to implement the artificial intelligence accelerator chip simulation method provided in the above-described method embodiments.

[0049] Embodiments of this application also provide a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the artificial intelligence accelerator chip simulation method provided in the above-described method embodiments.

[0050] Embodiments of this application also provide a computer program product, which includes a computer program. A processor of a computer device reads the computer program from a computer-readable storage medium and executes the computer program, causing the computer device to perform any of the artificial intelligence accelerator chip simulation methods described in the above embodiments.

[0051] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0052] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0053] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0054] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A simulation method for an artificial intelligence accelerator chip, characterized in that, The method includes: Read the behavior contract file corresponding to the chip hardware description. The behavior contract file records the configuration parameter set in the form of structured data. The configuration parameter set defines at least the matrix shape, operand bit width, bit storage mapping of logical elements, numerical scaling rules, and execution topology order of each stage of the data path pipeline. Based on the behavior contract file, a simulation context for pure integer operations is instantiated on a general-purpose processor. This simulation context prohibits the invocation of floating-point operation instructions of the general-purpose processor, and all matrix elements are represented by an integer data structure containing explicit decimal information. In the simulation context, the data flow is driven through each stage step by step according to the execution topology order. When each stage is executed, bit-level arithmetic operations are performed on the integer data structure according to the operation type of the current stage and the parameters in the behavior contract file to generate an intermediate bit vector consistent with the behavior of the hardware registers in that stage, and the intermediate bit vector is saved to the simulation register buffer corresponding to each stage. Store the output bit vector of the final stage of the pipeline into the result buffer; In response to a bit-level difference between the hardware reference output and the output bit vector in the result buffer, the stage identifier corresponding to the bit-level difference and the intermediate bit vector in the simulation register buffer of that stage are output to achieve full interpretability traceability of the simulation process from input to bit-level difference output.

2. The method according to claim 1, characterized in that, The operand bit width format recorded in the configuration parameter set includes at least one of the following: 8-bit floating-point format, single-precision floating-point format, half-precision floating-point format, bfloat16 floating-point format, 8-bit floating-point format, 6-bit floating-point format, 4-bit floating-point format, 8-bit mixed integer format, 8-bit unsigned exponent zero-bit mantissa floating-point format, and 4-bit unsigned exponent three-bit mantissa floating-point format. For non-byte aligned low-precision formats, the bit storage mapping is in a byte-level storage buffer, defining the bit offset start position and bit field length for each logical unit, and the bit field of each logical element is completely located within a single byte and does not cross byte boundaries. Based on the bit storage mapping, the bit pattern of each logical element is extracted bit by bit from the original byte stream to achieve deterministic decoding of non-byte aligned formats.

3. The method according to claim 2, characterized in that, When the operand bit width format is 4-bit floating-point format, the bit storage mapping is specified as follows: the lower 4 bits of the byte are mapped to logical elements with even indices, and the higher 4 bits are mapped to logical elements with odd indices; when the operand bit width format is 6-bit floating-point format, the bit storage mapping is specified as follows: the bit fields of every two consecutive logical elements are compressed and stored in one byte, and the byte half is filled in high-order priority.

4. The method according to claim 1, characterized in that, The numerical scaling rules in the configuration parameter set include local scaling factors and global scaling factors, wherein: The local scaling factor is a scaling factor shared within the block, and the behavior contract file records its generation method. The generation method includes a first method of determining a common scaling benchmark based on the numerical distribution characteristics within the block, and a second method of determining the scaling coefficient based on the ratio of the extreme value within the block to the range of representable numerical values. The global scaling factor is a unified scaling factor across all data blocks, and the behavior contract file records its value as a fixed constant or a rule for dynamically calculating based on the global characteristics of the input data. The global scaling factor is independently applied to the first matrix path and the second matrix path in the data path pipeline.

5. The method according to claim 1, characterized in that, The data path pipeline defined by the execution topology order includes at least three stages executed according to the execution topology order: Precise product stage: Fixed-point integer multiplication is performed on the elements of the input matrix to generate an untruncated full-precision integer bit vector; Item-by-item scaling stage: Perform fixed-point displacement or fixed-point multiplication scaling on the product bit vector according to the numerical scaling rules; Grouping and Reduction Phase: Based on the grouping granularity recorded in the behavior contract file, perform intra-group fixed-point accumulation on the scaled product bit vector. The grouping granularity is either a fixed number of consecutive element groups or grouping by parity index. Post-group scaling stage: After grouping and reducing is completed, a block-level scaling factor is applied to the reduction result; Alignment and rounding summation stage: Based on the target number of decimal places, align multiple fixed-point product vectors to a unified number of decimal places, and then perform multi-operand fusion summation according to the rounding mode recorded in the behavior contract file. The rounding mode includes rounding to zero, rounding to the nearest even number, rounding up, or rounding down. Accumulation and merging stage: The bit vector of the summation result is merged with the bit vector of the corresponding element in the accumulation matrix by fixed-point addition; Inter-group merging phase: Perform secondary aggregation on the bit vectors resulting from multiple group reductions; Special value processing stage: For bit vectors in input elements, intermediate results, or final results that conform to the encoding patterns of non-Number NaN, Infinity Inf, or subnormal numbers, perform the processing operations specified in the behavior contract file; Output encoding stage: The final fixed-point result is encoded into the original bit mode according to the exponent bit width, mantissa bit width, saturation threshold and rounding mode of the output bit width format recorded in the behavior contract file, and written into the simulation register buffer area.

6. The method according to claim 5, characterized in that, In the alignment, rounding, and summation stage, the simulation context converts multiple fixed-point product bit vectors into signed integers, then performs a left shift alignment operation on the signed integers according to the target number of decimal places recorded in the behavior contract file, performs multi-operand integer addition on the aligned integers, and performs a unified rounding operation on the summation result after the addition is completed to simulate the effective bit width limit of the accumulator inside the chip.

7. The method according to claim 1, characterized in that, The configuration parameter set in the behavior contract file also includes an MX quantization description field independent of the execution topology order. The MX quantization description field records the following quantization parameters: element format type, block size, axial block layout, local scaling factor generation method, global scaling strategy, subnormal number processing strategy, saturation strategy, and special value mapping rules. After reading the original bit string of the input matrix, the simulation context performs quantization on the input data according to the MX quantization description, and performs dequantization on the fixed-point results according to the MX quantization description before output encoding, so as to achieve decoupling between the stored data format and the calculated data format.

8. The method according to claim 7, characterized in that, The MX quantization description field recorded in the behavior contract file is independent of the stage definition of the execution topology order. While the value of the MX quantization description field remains unchanged, the execution topology order can be switched to a truncated accumulation pipeline, a grouped scaling accumulation pipeline, or a precise accumulation pipeline, so that the same set of quantization parameters can be applied to multiple accumulation value paths.

9. The method according to claim 1, characterized in that, The behavioral contract document is generated from a declarative specification document, which can be either a compact specification format or a full specification format. The compact specification format records the model category identifier, segment length parameter, internal significant digits parameter, and output rounding strategy parameter. The simulation context automatically derives and generates the default execution topology order based on the compact specification format. The complete specification format displays the operation type, group size parameter, block size parameter, internal significant digits parameter, rounding mode parameter, and flag bit indicating whether to merge with the accumulation matrix for each stage in the execution topology sequence.

10. The method according to claim 9, characterized in that, The declarative specification file is compiled into an executable specification object before the simulation context starts running. The executable specification object is stored in memory in the form of a structured data object or a sequence of bytecode instructions. When the simulation context performs staged numerical operations, it directly reads the executable specification object and completes all stage operations independently without the configuration interpreter that generated the declarative specification file.

11. The method according to claim 5, characterized in that, In the special value processing stage, if the bit vectors of the input matrix elements, intermediate operation results, or final output results conform to the NaN, Inf, or subnormal number encoding rules, the simulation context performs at least one of the following operations based on the special value processing strategy recorded in the behavior contract file: Replace the bit vector with an all-zero bit vector; Replace the bit vector with a bit vector representing the maximum or minimum finite value that the current format can represent; The bit vector is kept unchanged, and a special value marker is recorded in the corresponding status register bit; Based on the special value encoding bit pattern of the target output format, the bit vector is mapped and converted into the corresponding special value bit vector of the target format.

12. The method according to claim 1, characterized in that, The output bit vector in the result buffer of the simulation context is used to perform a bitwise consistency comparison with at least one of the following reference bit vectors: The bit vector of the corresponding matrix multiplication and addition result output by the hardware RTL simulation model of the chip; The bit vector of the corresponding matrix multiplication and addition result output by the actual silicon back-end of the chip; The bit vector of the matrix multiplication and addition result output from the pre-calculated gold reference sample; The corresponding matrix multiplication and addition result bit vector is output from another simulation context independently instantiated based on the behavior contract file; Based on the bit-level differences in the comparison results, the position information of the difference bits and the stage identifier of the stage in which the difference bits are located are output. Based on the position information and stage identifier, combined with the difference pattern, the numerical behavior deviation type corresponding to the difference is determined and output. The numerical behavior deviation includes at least one of rounding boundary deviation, block scaling quantization error, stage execution order semantic deviation, special value propagation deviation, and output truncation deviation.

13. The method according to claim 1, characterized in that, The simulation context performs block processing on the input matrix: Along the K-dimensional direction of matrix multiplication, based on the segment length parameter recorded in the behavior contract file, the K-dimensional direction is divided into several continuous sub-blocks, the length of each sub-block being equal to the segment length parameter, except for the last sub-block; For each sub-block, the simulation context independently reads the row vector sub-block of the first matrix A within the corresponding K range of the sub-block, and the column vector sub-block of the second matrix B within the corresponding K range of the sub-block, and converts them into a unified fixed-point representation using bit-level decoding. Then, it drives the data flow of the sub-block to execute all stages in strict accordance with the execution topology order defined in the behavior contract file, generating the intermediate result bit vector corresponding to the sub-block. After entering the accumulation and merging stage, the intermediate result bit vectors generated by all sub-blocks are merged element by element using fixed-point integer addition based on their row and column positions in the output matrix to form the final result bit vector. When the total length of the K dimension cannot be divided by the segment length parameter, the last sub-block uses its actual remaining length as the effective K range, and still performs all stage operations completely. Moreover, its internal bit-level decoding, scaling application, and rounding operations strictly follow the format and precision rules defined in the behavior contract file.

14. An artificial intelligence accelerator chip simulation device, characterized in that, The device includes: The contract file reading module is used to read the behavior contract file corresponding to the chip hardware description. The behavior contract file records the configuration parameter set in the form of structured data. The configuration parameter set defines at least the matrix shape, operand bit width, bit storage mapping of logical elements, numerical scaling rules, and execution topology order of each stage of the data path pipeline. The simulation context instantiation module is used to instantiate a simulation context for pure integer operations on a general-purpose processor based on the behavior contract file. This simulation context prohibits the calling of floating-point operation instructions of the general-purpose processor, and all matrix elements are represented by an integer data structure containing explicit decimal information. The pipeline execution module is used to drive the data flow through each stage step by step in the execution topology order in the simulation context. When each stage is executed, it performs bit-level arithmetic operations on the integer data structure according to the operation type of the current stage and the parameters in the behavior contract file to generate an intermediate bit vector consistent with the behavior of the hardware registers in that stage. An intermediate state storage module is used to save the intermediate bit vector to the simulation register buffer corresponding to each stage; The result output module is used to store the output bit vector of the final stage of the pipeline into the result buffer. The difference backtracking module is used to respond to a bit-level difference between the hardware reference output and the output bit vector in the result buffer, and outputs the stage identifier corresponding to the bit-level difference and the intermediate bit vector in the simulation register buffer of that stage, for backtracking and locating the hardware design defects of the chip.

15. A computer device, characterized in that, The computer device includes a memory and a processor. The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory to implement the steps of the method according to any one of claims 1-13.

16. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method described in any one of claims 1-13.

17. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1-13.

Images