Method, device, computer device, medium and product for generating instructions for verifying engine accelerator

Abstract

The present disclosure provides a generation method and device for instructions for verifying an engine accelerator, a computer device and a medium, relating to the technical field of hardware verification, the method comprising: allocating a globally continuous memory address space; constructing a calculation pipeline; initializing at least one intermediate calculation layer layer by layer to generate at least one hardware acceleration engine node in each intermediate calculation layer; obtaining hardware constraint conditions for each hardware acceleration engine node; allocating input data space and output data space satisfying the hardware constraint conditions in the memory address space; extracting directed graph data dependency relationships between the hardware acceleration engine nodes; inserting hardware synchronization instructions between the hardware acceleration engine nodes that interact; and generating an instruction stream for verifying the engine accelerator according to a preset operator template, the input data space and the output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions.

Description

Technical Field

[0001] This disclosure relates to the field of hardware verification technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for generating instructions for verifying engine accelerators. Background Technology

[0002] With the rapid development of artificial intelligence and high-performance computing, the microarchitectures of hardware accelerators, such as multi-engine parallel computing systems, are becoming increasingly large and complex. Before hardware chip tape-out or during the architecture design phase, it is necessary to rely on architecture-level verification systems for functional correctness verification and performance evaluation. During the verification process, it is usually necessary to generate a large number of test instructions to drive the engine accelerator to simulate data processing, memory access, and underlying resource scheduling under real workloads.

[0003] Therefore, generating verification instruction streams for engine accelerators is a crucial aspect of hardware verification and electronic design automation. Summary of the Invention

[0004] This disclosure provides a method, apparatus, computer device, computer-readable storage medium, and computer program product for generating instructions for verifying an engine accelerator.

[0005] According to one aspect of this disclosure, a method for generating instructions for verifying an engine accelerator is provided, comprising: allocating a globally contiguous memory address space; constructing a computational pipeline, wherein the computational pipeline includes an input layer, at least one intermediate computational layer connected in sequence, and an output layer, wherein the input layer is used to transfer data from external storage to the globally contiguous memory address space, and the output layer is used to transfer the computation result of the last intermediate computational layer to the external storage; initializing the at least one intermediate computational layer layer by layer to generate at least one hardware acceleration engine node in each intermediate computational layer, wherein the hardware acceleration engine node is used to simulate the data processing and memory access behavior of a physics engine; and for each For each hardware acceleration engine node in the intermediate computing layer, the hardware constraints of that hardware acceleration engine node are obtained; input data space and output data space satisfying the hardware constraints are allocated for that hardware acceleration engine node in the globally contiguous memory address space; based on the input data space and output data space of each hardware acceleration engine node, directed graph data dependencies between hardware acceleration engine nodes are extracted; according to the directed graph data dependencies, hardware synchronization instructions are inserted between hardware acceleration engine nodes that generate interactions; and according to the preset operator template, the input data space and output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions, an instruction stream for verifying the engine accelerator is generated.

[0006] In some embodiments, the engine accelerator includes multiple physical engines of different types, and wherein the step of initializing the at least one intermediate computing layer layer by layer to generate at least one hardware acceleration engine node in each intermediate computing layer includes: generating multiple hardware acceleration engine nodes in each intermediate computing layer; and specifying a corresponding physical engine type for each of the multiple hardware acceleration engine nodes to simulate concurrent computing tasks of the multiple physical engines of different types.

[0007] In some embodiments, the method further includes: using a dictionary structure to record allocated space in the globally contiguous memory address space as occupied space, and recording unallocated space in the globally contiguous memory address space as free space.

[0008] In some embodiments, obtaining the hardware constraints of each hardware acceleration engine node in each intermediate computing layer includes: determining the physical engine type corresponding to each hardware acceleration engine node in each intermediate computing layer according to a preset list of available engines; and obtaining the input data constraints, output data constraints, and address alignment granularity corresponding to the physical engine type, and using the input data constraints, output data constraints, and address alignment granularity as the hardware constraints of the hardware acceleration engine node.

[0009] In some embodiments, allocating input data space and output data space for the hardware acceleration engine node in the globally contiguous memory address space that satisfy the hardware constraints includes: allocating the input data space for the hardware acceleration engine node in the occupied space based on the input data constraints and the address alignment granularity; and allocating the output data space for the hardware acceleration engine node in the free space based on the output data constraints and the address alignment granularity.

[0010] In some embodiments, extracting the directed graph data dependency relationship between hardware acceleration engine nodes based on the input data space and output data space of each hardware acceleration engine node includes: for each hardware acceleration engine node, comparing the memory address corresponding to the input data space of the hardware acceleration engine node with the memory address corresponding to the output data space of each hardware acceleration engine node in the preceding intermediate computing layer; determining the hardware acceleration engine node whose memory address corresponding to the output data space matches the memory address corresponding to the input data space of the hardware acceleration engine node as the target node that the hardware acceleration engine node depends on; and generating the directed graph data dependency relationship based on the pointing relationship between each hardware acceleration engine node and the target node it depends on.

[0011] In some embodiments, inserting hardware synchronization instructions between the hardware acceleration engine nodes that generate the interaction based on the directed graph data dependency relationship includes: determining the hardware acceleration engine nodes that generate the interaction based on the directed graph data dependency relationship, wherein the hardware acceleration engine node that is depended upon is a producer engine node, and the hardware acceleration engine node that generates the dependency is a consumer engine node; inserting a waiting instruction before the execution instruction sequence of the consumer engine node; and inserting a notification instruction after the execution instruction sequence of the producer engine node.

[0012] In some embodiments, generating an instruction stream for verifying the engine accelerator based on a preset operator template, the input data space and output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions includes: extracting the space address parameters and data specification parameters of the input data space and output data space of the corresponding hardware acceleration engine node according to the instruction field structure defined by the preset operator template; filling the space address parameters, the data specification parameters, and the synchronization instructions into the instruction field structure to generate an operator instruction sequence corresponding to each hardware acceleration engine node; and converting the operator instruction sequence corresponding to each hardware acceleration engine node into machine instruction code to generate an instruction stream for verifying the engine accelerator.

[0013] According to one aspect of this disclosure, an apparatus for generating instructions for verifying an engine accelerator is provided. The apparatus includes: a first allocation module configured to allocate a globally contiguous memory address space; a construction module configured to construct a computational pipeline, wherein the computational pipeline includes an input layer, at least one intermediate computational layer connected sequentially, and an output layer, wherein the input layer is used to transfer data from external storage to the globally contiguous memory address space, and the output layer is used to transfer the computation results of the last intermediate computational layer to the external storage; an initialization module configured to initialize the at least one intermediate computational layer layer by layer to generate at least one hardware acceleration engine node in each intermediate computational layer, wherein the hardware acceleration engine node is used to simulate the data processing and memory access behavior of a physics engine; and an acquisition module configured to target... For each hardware acceleration engine node in each intermediate computing layer, the hardware constraints of that hardware acceleration engine node are obtained; a second allocation module is configured to allocate input data space and output data space that satisfy the hardware constraints for that hardware acceleration engine node in the globally contiguous memory address space; an extraction module is configured to extract directed graph data dependencies between hardware acceleration engine nodes based on the input data space and output data space of each hardware acceleration engine node; an insertion module is configured to insert hardware synchronization instructions between hardware acceleration engine nodes that generate interactions based on the directed graph data dependencies; and a generation module is configured to generate an instruction stream for verifying the engine accelerator based on a preset operator template, the input data space and output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions.

[0014] According to another aspect of this disclosure, a computer device is provided, comprising: at least one processor; and a memory having a computer program stored thereon, wherein the computer program, when executed by the at least one processor, causes the at least one processor to perform the methods provided above in this disclosure.

[0015] According to another aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to perform the methods provided above in this disclosure.

[0016] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, causes the processor to perform the methods provided above in this disclosure.

[0017] According to one or more embodiments of this disclosure, a method for generating instructions for a verification engine accelerator is provided. This method involves allocating a globally contiguous memory address space and constructing a computational pipeline comprising an input layer, an intermediate computation layer, and an output layer. Hardware acceleration engine nodes are generated during the layer-by-layer initialization of the intermediate computation layer, and input and output data spaces are allocated to them in the memory address space based on the obtained hardware constraints. Then, the directed graph data dependencies between the hardware acceleration engine nodes are automatically extracted based on the allocation results, and hardware synchronization instructions are inserted between nodes that interact. Finally, a verification instruction stream is generated by combining preset operator templates. This method automates the construction of a multi-level computational pipeline. By combining data space allocation with physical hardware constraints, it recreates the actual memory access behavior of the underlying hardware. Simultaneously, it accurately extracts data dependencies based on the memory space allocation results to insert synchronization instructions, thereby achieving automated and reliable generation of complex hardware instruction streams.

[0018] These and other aspects of this disclosure will be apparent from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description

[0019] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of this disclosure. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0020] Figure 1 This is a flowchart illustrating a method for generating instructions for verifying an engine accelerator according to an exemplary embodiment.

[0021] Figure 2 This diagram illustrates the nested relationship of the system hierarchy architecture for generating verification instructions according to an exemplary embodiment.

[0022] Figure 3A and Figure 3B This is a topology diagram illustrating the data dependency relationships between hardware acceleration engine nodes according to an exemplary embodiment.

[0023] Figure 4 This is a schematic block diagram illustrating an apparatus for generating instructions for verifying an engine accelerator according to an exemplary embodiment.

[0024] Figure 5 This is a block diagram illustrating an exemplary computer device that can be applied to an exemplary embodiment. Detailed Implementation

[0025] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0026] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.

[0027] The terminology used in the description of the various examples described in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. As used herein, the term "multiple" means two or more, and the term "based on" should be interpreted as "at least partially based on". Furthermore, the terms "and / or" and "at least one of..." cover any one of the listed items and all possible combinations thereof.

[0028] In existing technologies, the verification of hardware accelerators such as multi-engine parallel computing systems typically employs methods based on fixed test cases or simple random stimuli. These methods often rely on verification engineers manually writing or generating limited, preset test scenarios through scripts, which have several significant drawbacks. For example, the concurrent state coverage is low; existing scenario constructions struggle to exhaustively cover the complex dynamic interaction states in multi-engine systems, easily overlooking errors such as data races under high concurrency. Secondly, memory simulation is overly idealized or static, failing to realistically reflect the fragmentation of the limited on-chip shared cache during dynamic scheduling and the timing issues of allocation and release. Finally, the dependencies and synchronization mechanisms between engines usually rely on explicit manual specification, resulting in a heavy workload and a high risk of omissions in edge scenarios, leading to low automation.

[0029] To address the aforementioned issues, this disclosure proposes a method for generating instructions for a verification engine accelerator. By allocating a globally contiguous memory address space and constructing a computational pipeline comprising an input layer, intermediate computation layer, and output layer, hardware acceleration engine nodes are generated during the layer-by-layer initialization of the intermediate computation layer. Input and output data spaces are allocated to these nodes in the memory address space based on the acquired hardware constraints. Furthermore, the directed graph data dependencies between the hardware acceleration engine nodes are automatically extracted based on the allocation results, and hardware synchronization instructions are inserted between interacting nodes. Finally, a verification instruction stream is generated by combining preset operator templates. This method automates the construction of a multi-level computational pipeline. By deeply integrating data space allocation with physical hardware constraints, it recreates the actual memory access behavior of the underlying hardware. Simultaneously, it accurately extracts data dependencies based on the memory space allocation results to insert synchronization instructions, thereby achieving automated and reliable generation of complex hardware instruction streams.

[0030] Figure 1 This is a flowchart illustrating a method for generating instructions for verifying an engine accelerator according to an exemplary embodiment.

[0031] like Figure 1 As shown, the method 100 for generating instructions to verify the engine accelerator includes: Step S101: Allocate a globally contiguous memory address space; Step S102: Construct a computation pipeline, wherein the computation pipeline includes an input layer, at least one intermediate computation layer connected in sequence, and an output layer, wherein the input layer is used to transfer data from external storage to the globally contiguous memory address space, and the output layer is used to transfer the computation results of the last intermediate computation layer to the external storage. Step S103: Initialize the at least one intermediate computing layer layer by layer to generate at least one hardware acceleration engine node in each intermediate computing layer, wherein the hardware acceleration engine node is used to simulate the data processing and memory access behavior of the physics engine. Step S104: For each hardware acceleration engine node in each intermediate computing layer, obtain the hardware constraints of that hardware acceleration engine node. Step S105: Allocate input data space and output data space that satisfy the hardware constraints for the hardware acceleration engine node in the globally contiguous memory address space; Step S106: Based on the input data space and output data space of each hardware acceleration engine node, extract the directed graph data dependency relationship between hardware acceleration engine nodes. Step S107: Based on the directed graph data dependencies, insert hardware synchronization instructions between the hardware acceleration engine nodes that generate the interaction; and Step S108: Generate an instruction stream for verifying the engine accelerator based on the preset operator template, the input data space and output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions.

[0032] In step S101, a globally contiguous memory address space is allocated. This operation is primarily to establish a logical storage model in the verification environment that corresponds to the physical memory of the target hardware (e.g., shared cache or global cache), simulating the limited on-chip storage resources within the target engine accelerator that are shared by multiple processing units. By allocating such an address space, a unified addressing range can be provided, dynamically providing a place to store raw data and computation results for subsequent computation tasks, thereby restoring the memory layout characteristics of the physical hardware at the basic resource level.

[0033] In step S102, a computational pipeline comprising an input layer, an intermediate computation layer, and an output layer is constructed. Specifically, step S102 establishes the data transmission path from entering the hardware to completing processing and finally writing back to external storage. The input layer is responsible for modeling the transfer of data from external storage to internal contiguous memory, while the output layer is responsible for writing back the final computation results. This defines the overall data flow boundary and hierarchical processing structure of the verification task, thereby reflecting the end-to-end data transmission and processing pipeline of the engine accelerator, making the generated verification scenario more closely resemble the state of a real chip handling a workload.

[0034] In step S103, intermediate computing layers are initialized layer by layer to generate hardware acceleration engine nodes. Specifically, within the pre-constructed computing pipeline architecture, specific execution units are instantiated hierarchically to simulate the data processing and memory access behavior of the underlying physical engine at different pipeline stages. This transforms the abstract pipeline hierarchy into node models capable of executing specific processing tasks, serving as execution entities for the physical hardware in the verification environment. By generating these hardware acceleration engine nodes, the computing architecture of the target accelerator can be replicated, ensuring that the generated behavioral model reflects the operational logic of the physical engine.

[0035] In step S104, the corresponding hardware constraints are obtained for each generated hardware acceleration engine node. Real engine accelerators are typically constrained by various specifications when processing data. By obtaining pre-set hardware design parameters, the rules that the current node must follow are determined, clarifying the range of conditions that the current node can support when performing data access and computation. This introduces the actual design boundaries of the physical hardware into the simulation process, ensuring that the behavior of the current node conforms to the capabilities of the real hardware, thereby avoiding the generation of invalid test instructions that the hardware cannot parse or execute.

[0036] In step S105, input and output data spaces that meet hardware constraints are allocated to the hardware acceleration engine nodes within a globally contiguous memory address space. Based on the hardware limitations obtained in the preceding steps, address segments for storing read data and computation results are designated for the nodes in the memory model established in step S101. This establishes a connection between computational tasks and underlying storage resources, simulating the memory allocation and occupancy process of a real engine accelerator during task processing. This constraint-based allocation method can reproduce the hardware resource scheduling within a limited storage range, helping to reveal potential memory access conflicts during the verification process.

[0037] In step S106, directed graph data dependencies between hardware acceleration engine nodes are extracted based on the input and output data spaces of each node. Since different nodes have overlapping read and write operations on memory space, the pre- and post-processing relationships between various computational tasks are analyzed by tracking the usage of memory addresses. This clarifies the interaction topology when multiple nodes work together, and further determines the execution waiting conditions of each node. Thus, automated extraction of data dependencies is achieved, replacing the tedious process of manually specifying dependencies and improving the accuracy of topology construction in concurrent scenarios.

[0038] In step S107, hardware synchronization instructions are inserted between the hardware acceleration engine nodes that generate interactions, based on the data dependencies in the directed graph. Based on the extracted node topology, a control mechanism for coordinating timing is added to the instruction sequence corresponding to nodes with data dependencies to address the problem of data being read before it is ready or being abnormally overwritten when multiple execution units operate asynchronously. By inserting hardware synchronization instructions, the execution order between nodes that generate data interactions can be coordinated, preventing concurrency errors such as deadlocks, thereby ensuring the correctness of the generated verification scenario in terms of timing relationships.

[0039] In step S108, an instruction stream for verifying the engine accelerator is generated based on the preset operator template, input / output data space allocation, and inserted synchronization instructions. After integrating the previously determined node behaviors, memory address allocation results, and timing synchronization rules, step S108 compiles and converts the instruction format template recognized by the target hardware to output the previously constructed logical verification model and data topology relationships as low-level machine instructions capable of driving the actual operation of the engine accelerator. This establishes a complete process from pipeline modeling, resource allocation, dependency extraction to instruction output, effectively improving the automation level of hardware instruction stream generation.

[0040] In summary, the instruction generation method for verifying engine accelerators provided in this disclosure allocates a globally contiguous memory address space and constructs a computational pipeline containing an input layer, intermediate computation layer, and output layer. Hardware acceleration engine nodes are generated during the layer-by-layer initialization of the intermediate computation layer. Input and output data spaces are allocated in the memory address space based on hardware constraints. Then, the directed graph data dependencies between hardware acceleration engine nodes are automatically extracted based on the data space allocation results, and hardware synchronization instructions are inserted between interacting nodes. Finally, an instruction stream for verification is generated by combining operator templates. This method automates the construction of multi-level computational pipelines. By combining dynamic allocation of data space with physical hardware constraints, it recreates the actual memory access behavior of the underlying hardware. Simultaneously, it accurately extracts data dependencies based on space allocation and inserts hardware synchronization mechanisms, achieving automated and reliable generation of complex hardware verification instruction streams.

[0041] To illustrate how the foundation of the above data processing architecture is established, the specific construction process of the computation pipeline in step S102 is described in detail below.

[0042] Figure 2 This diagram illustrates the nested hierarchical architecture of a system for generating verification instructions according to an exemplary embodiment. For ease of description, the following will be combined with... Figure 2 Let's elaborate.

[0043] In some embodiments, building a computational pipeline mainly includes the sequential creation of an input layer, at least one intermediate computation layer, and an output layer. Specifically, the construction and management of the aforementioned pipeline can be primarily achieved through the management of objects at the top-level engine tree, such as... Figure 2 The initialization logic of the EngineTree architecture layer shown in the diagram drives the creation of a complete execution flow from data input, multi-layer computation to data output.

[0044] First, create the input layer as the data source, such as... Figure 2 This is defined as a Layer 0 structure. At this stage, an input layer object responsible for data interaction is instantiated within the EngineTree architecture to simulate the transfer of initial test data from external storage hardware, such as external DDR, to a globally contiguous memory address space via a Direct Memory Access (DMA) engine. Simultaneously, the backward connections of this input layer are recorded, thus completing the data preparation work at the input end of the computation pipeline.

[0045] Secondly, create at least one intermediate computing layer in sequence, such as Figure 2 Defined as Layer 1 ( Figure 2The structure from Layer N (not shown) to Layer N can be implemented. Specifically, a specified number of intermediate computation layer objects (e.g., layer_num) can be instantiated iteratively based on a preset pipeline depth parameter (e.g., the number of computation layers parameter layer_num). Figure 2 (The EngineLayer module in the architecture). These intermediate computation layers are nested under the top-level architecture, forming the processing backbone of the entire pipeline. Each time a layer is created, the connection method between that layer and the previous layer is recorded to establish the internal data flow topology, thereby providing the basic support structure for the subsequent nesting of specific hardware acceleration engine nodes within each layer.

[0046] Finally, create an output layer to receive the final data, such as Layer N+1 ( Figure 2 (Not shown in the image). After all intermediate computation layers are established, the memory address of the computation result corresponding to the last intermediate computation layer is extracted. Based on this, an output layer object responsible for data export is instantiated to simulate writing the final computation result, which is stored in a globally contiguous memory address space, back to the external storage hardware through the DMA engine, so as to realize the process of only retaining the computation result of the last layer for output.

[0047] To more clearly illustrate the mapping relationship between the above computational pipeline in specific software implementations and system architectures, the following will combine... Figure 2 The system hierarchy diagram shown illustrates the nested relationships within the architecture, illustrating the specific implementation of this architecture. In some embodiments, the aforementioned pipeline architecture can be implemented by constructing different class objects and their hierarchical calling relationships.

[0048] Engine tree management class (such as) Figure 2 The EngineTree class shown corresponds to Figure 2 The top-level architecture of this class is responsible for coordinating the entire lifecycle of the computational pipeline. Its attributes primarily include the total number of pipeline layers defining pipeline depth, the maximum number of layers to retain for controlling memory release strategies, a layer dictionary for recording information about each layer, and a layer instruction dictionary. Its methods mainly include initialization methods for building a complete computational pipeline, methods for generating inter-layer dependencies and adding synchronization instructions, methods for releasing memory space before a specified layer, methods for extracting input source connection information, methods for printing engine tree structure information, methods for drawing the engine tree structure diagram, methods for decoding layer labels, and methods for dumping the final generated instructions. The attributes of this class and... Figure 2 The system inputs, macroscopic boundaries, and data flow associated with this mainly include: the configuration structure `config` used to configure the overall initialization parameters for verification; and the external storage model used to simulate the external data interaction source of the accelerator chip. Figure 2The DDR model shown in the figure), and the shared memory model used to simulate the on-chip shared memory access behavior inside the accelerator chip ( Figure 2 The SM model shown in the figure represents a hierarchical topology encompassing the entire range of intermediate computational layers from input to output. Figure 2 The diagram shows Layer 0-Layer N, and the storage of the final calculation results used for temporary storage and dumping of the final verification test sequence. Figure 2 (The result is shown in the image). This class not only drives the initialization process of each layer of the architecture, but also triggers the generation of directed graph data dependencies between layers, executes the sliding window memory release strategy, and finally dumps the generated verification instructions. The EngineTree class forms the macroscopic architectural skeleton by instantiating subsequent layer objects through hierarchical nesting.

[0049] Data interaction layer classes (e.g., EngineInOutLayer class, Figure 2 (Not shown in the image) This data interaction layer class is specifically designed to handle data interaction between the computing accelerator and external storage. During the initialization phase, the EngineTree class instantiates this data interaction layer class to generate... Figure 2 The class consists of an input layer (e.g., Layer 0) and an output layer (e.g., Layer N+1). Internally, this class encapsulates the logic for calling the DMA engine, simulating the actual movement of data between external storage hardware (e.g., DDR) and a globally contiguous memory address space (e.g., GLB).

[0050] Intermediate computation layer classes (such as) Figure 2 The EngineLayer class shown corresponds to Figure 2 At least one intermediate computation layer (e.g., Layer 1 to Layer N) is sequentially connected. The `EngineLayer` class, as the parent or peer logical class of the data interaction layer class, is responsible for managing all concurrent tasks within its layer at a specific pipeline depth. The main attributes of this class include the current pipeline depth index and the collection of all engine node objects contained within this layer. These attributes primarily include the current layer index, the number of engines contained, and the collection of node objects within this layer. Figure 2 The internal structure of the `<engineLayer>` class is uniformly mapped to the variable fields `idx`, `num`, and `list` (where `idx` represents the layer index, `num` represents the number of engine nodes, and `list` represents the list of engine node objects). During initialization or runtime, each instantiation of an `EngineLayer` class object will receive the corresponding physical engine configuration information. Figure 2The diagram shows Engine 0 to Engine N (i.e., engines 0 to N), used for batch assignment and maintenance of topological connections and concurrent tasks within the layer. Its methods primarily include initialization methods for managing the lifecycle of concurrent tasks within the layer, methods for assisting in releasing layer memory space, and methods for assisting in generating dependencies within the layer. Each instantiation of an EngineLayer object represents the creation of a pipeline depth; this object maintains the set of nodes within the layer and records the topological connections with preceding or succeeding layers.

[0051] Engine node classes (such as) Figure 2 The EngineNode class shown corresponds to Figure 2 The specific hardware acceleration engine nodes (such as VPU, SPU, SE, etc.) are distributed across various intermediate computing layers. Each instantiated EngineNode object represents a physical engine model executing a specific computing task. The attributes of this class mainly include a physical engine type identifier, a list of input data packet objects, a list of output data packet objects, a list of synchronization signals to wait for from preceding nodes, and a list of synchronization signals to be notified from following nodes. Specifically, this class object encapsulates and maintains a random engine instance `random_engine` for generating high-randomness test scenarios, and receives and temporarily stores its corresponding node-specific configuration information `config` during the construction phase. This node performs address comparison and parameter translation by running its internal methods, ultimately deriving and generating the specific control instruction sequence `instruction` corresponding to the node. Its methods mainly include methods for calling the underlying memory space management class to allocate physical space, methods for extracting data dependencies with associated nodes through address comparison, and methods for generating the specific machine instruction sequence corresponding to the node based on its own parameters. In the aforementioned EngineLayer object, multiple EngineNode objects can be instantiated in parallel, thus accurately mapping the physical engine at the software level. Figure 2 A physical architecture for multiple physics engines to work concurrently at the same pipeline depth.

[0052] Data encapsulation classes (such as) Figure 2 The DataPackage class shown is used to transfer and represent data specifications between various EngineNode objects, concretizing abstract data flows into data blocks with physical attributes. The main attributes of this class include the tensor shape parameter TensorShape, which represents the geometry of the multidimensional data space, and the starting address of the dynamically allocated space in physical memory. Figure 2 The st_addr shown in the figure) and the data type identifier that identifies the underlying data element type ( Figure 2(as shown in the dtype diagram). Its methods primarily include those that automatically calculate and update the required storage capacity based on the input shape and format parameters. This class ensures that data exchanged between nodes strictly meets the read / write constraints of the hardware bus in terms of spatial size and format.

[0053] Memory space management classes (such as) Figure 2 The `MemAddrSpace` class shown corresponds to the global contiguous memory address space management and scheduling module, responsible for executing a dictionary-based space allocation and dynamic reclamation mechanism. This class contains and maintains in real-time an occupied memory space dictionary (`occupied_space`) for recording the status of allocated address ranges, and a free memory space dictionary (`vacant_space`) for dynamically recording currently available contiguous physical addresses. During runtime, this class receives basic configuration parameters `config` from external sources, such as the total global memory capacity and address alignment granularity, and uses this information to find and define compliant contiguous address segments in the free space to calculate and return the corresponding starting physical address. Figure 2 The st_addr shown in the figure provides underlying protection against overlap and fragmentation for high-concurrency memory access across multiple engines.

[0054] Instruction set (e.g.) Figure 2 The `Instr` and `EngineInstr` classes shown are used to construct, arrange, and manage the final output hardware instruction stream. The `Instr` class, as the most basic instruction unit class, represents a single low-level machine instruction or control microcode. Its attributes mainly include opcode and operand or physical address parameters. This class object can call its internally encapsulated formatter or bit-concatenation function `converter` to parse and shift the low-level basic configuration parameters `config`, such as opcode and operands, directly converting and outputting a hexadecimal machine instruction code stream that can be seamlessly read and executed by the hardware physical bus. Its methods mainly include formatting the current instruction parameters into hardware-recognizable low-level code according to preset operator template rules. The `EngineInstr` class, as an instruction set container class for a specific `EngineNode` object, typically contains multiple nested `Instr` objects. Its attributes mainly include the engine node identifier, the basic data computation instruction set for this node, and the hardware handshake synchronization instruction set. Its methods mainly include inserting wait instructions and notification instructions into the execution sequence according to dependencies, and arranging and dumping all instructions of this node in chronological order.

[0055] By nesting and hierarchically instantiating the aforementioned objects, the macroscopic pipeline construction steps are effectively transformed into a highly cohesive and loosely coupled system model, further enhancing the flexibility and scalability of the verification platform in the face of different testing scenarios.

[0056] After completing the skeleton construction of each layer in the aforementioned computational pipeline, it is necessary to further configure specific processing nodes within the intermediate computation layer. The following will provide a detailed explanation of how to initialize the intermediate computation layer and generate hardware acceleration engine nodes.

[0057] When building a deep computational pipeline, in order to avoid exhausting limited memory resources, the above-mentioned step of initializing intermediate computational layers can also introduce a memory sliding window-based space management mechanism.

[0058] According to some embodiments, the step-by-step initialization of the at least one intermediate computing layer includes: setting a maximum number of reserved layers; when initializing a new intermediate computing layer, determining whether the total number of currently constructed intermediate computing layers exceeds the maximum number of reserved layers; if not, directly generating the hardware acceleration engine node in the current intermediate computing layer; if exceeding, automatically releasing the memory space occupied by the earliest historical intermediate computing layer that exceeds the maximum number of reserved layers, and re-recording the released memory space to the free space for reuse, before generating the hardware acceleration engine node in the current intermediate computing layer.

[0059] In practice, this sliding window mechanism controls the number of logical layers that can simultaneously reside in the computation pipeline by using a preset maximum retention layer parameter. As new intermediate computation layers are continuously created and initialized, automatic cleanup logic is triggered once the current accumulated number of layers reaches a set threshold. At this point, since the data of the earliest historical intermediate computation layers has usually been read by subsequent nodes with data dependencies, there is no longer a need for retention. Therefore, the physical address ranges occupied by these historical layers can be remarked as free by updating the space record status. Through this timely release and space reuse, deeper computation pipeline architectures can be generated within the constraints of limited global memory address space, thereby meeting the simulation requirements for long-sequence computation processes in complex verification scenarios.

[0060] Based on the memory management mechanism described above, which ensures that the pipeline hierarchy can extend smoothly downwards, for each specific intermediate computing layer, it is also necessary to instantiate each engine node that actually undertakes the computing tasks within the layer.

[0061] According to some embodiments, the engine accelerator includes multiple physical engines of different types, and step S103 includes: generating multiple hardware acceleration engine nodes in each intermediate computing layer; and specifying corresponding physical engine types for the multiple hardware acceleration engine nodes to simulate concurrent computing tasks of the multiple physical engines of different types.

[0062] Target engine accelerators typically integrate multiple physical engines for performing different computational tasks, such as Vector Processing Units (VPUs), Scalar Processing Units (SPUs), or Sparse Engines (SEs). To recreate this complex hardware architecture during the verification phase, multiple hardware acceleration engine nodes can be generated in parallel within the current intermediate computation layer during layer-by-layer initialization. Subsequently, each hardware acceleration engine node within the same layer is assigned a corresponding physical engine type identifier. By setting multiple different types of engine nodes within the same computational depth, the concurrent mechanism of multiple physical engines operating simultaneously in the target accelerator can be objectively reflected in the logical structure. This method of generating nodes by assigning engine types can establish a concurrent computation topology that conforms to the underlying physical distribution, thus providing a basic model for subsequent analysis of the data interaction state of multiple physical engines under shared memory conditions. This helps to reveal potential concurrency conflicts and deadlocks during the verification process, improving the coverage of the verification scenario.

[0063] After configuring the corresponding hardware acceleration engine nodes for each intermediate computing layer, dynamic management of the underlying hardware's memory resources is needed to support the data read and write requirements of these nodes when executing concurrent computing tasks. Based on the above embodiments, a corresponding space recording mechanism can be introduced.

[0064] According to some embodiments, the method further includes: using a dictionary structure to record the allocated space in the globally contiguous memory address space as occupied space, and recording the unallocated space in the globally contiguous memory address space as free space.

[0065] As the various layers of the computing pipeline are built sequentially, the allocation status of the memory address space is constantly changing. To address this, a space mapping relationship based on a dictionary structure can be established. The dictionary uses key-value pairs to record the current usage attributes of each address segment in memory. When space is allocated to a hardware acceleration engine node for storing input or output data, the starting address and length of that space are registered in the dictionary structure, and its status is marked as occupied. Conversely, physical address ranges that have not yet been requested are marked as free space in the dictionary structure. Based on this dictionary-based recording method, when allocating data space for newly established nodes, a contiguous free space meeting the size requirements can be located by searching the dictionary structure. This reduces the risk of overlapping read / write addresses between different engine nodes and ensures the logical correctness of concurrent memory access by multiple physical engines.

[0066] Furthermore, to improve the utilization of the limited memory address space, the method also includes a dynamic reclamation process for the memory address space. During the flow of verification instruction generation, when a hardware acceleration engine node in a certain intermediate computing layer completes its corresponding computation task, and its intermediate computation results have been read by all subsequent engine nodes with data dependencies, the data retention requirement for that part of the data space ends. At this time, the state of the corresponding address range can be changed from occupied space to free space by updating the dictionary structure, thereby realizing the reclamation of memory resources. This dynamic reclamation mechanism can release idle address resources for subsequent engine nodes at other levels to reuse cyclically, which better simulates the real data lifecycle management of the underlying hardware. This allows for the generation of deeper computational pipelines and more complex verification instruction flows under limited memory capacity constraints, reducing the possibility of memory overflow in long-sequence verification scenarios.

[0067] Having established the foundation for memory flow through the aforementioned space recording and dynamic reclamation mechanisms, the next step is to set specific execution limits for each hardware acceleration engine node. The following will explain how to obtain and assign corresponding physical attribute characteristics to these nodes as the basis for subsequent space allocation and instruction generation.

[0068] According to some embodiments, step S104 includes: for each hardware acceleration engine node in each intermediate computing layer, determining the physical engine type corresponding to the hardware acceleration engine node according to a preset list of available engines; and obtaining the input data constraints, output data constraints, and address alignment granularity corresponding to the physical engine type, and using the input data constraints, the output data constraints, and the address alignment granularity as hardware constraint conditions for the hardware acceleration engine node.

[0069] Specifically, for each hardware acceleration engine node within the intermediate computing layer, a random sampling mechanism can be used to determine its physical engine type. Specifically, a random allocation algorithm can be used to randomly select from a pre-defined list of available engines, and the selected type can be assigned to the currently processing node. This type determination method based on random selection can establish diverse engine distribution topologies during multiple executions of the verification and generation process, thereby expanding the coverage of various complex concurrent scenarios for the target accelerator.

[0070] After determining the physical engine type, the associated hardware constraints are further obtained. These constraints primarily include the data format and data size range followed by the physical engine when reading and writing memory. The data format relates to the element type of the processed data, such as floating-point or integer types with specific widths; the data size range defines the upper and lower limits of the data size supported by the engine in a single computation. Combining the constraints of data format and size dimensions with the underlying address alignment granularity as comprehensive hardware constraints ensures that the subsequently divided memory address ranges conform to the physical hardware's read / write specifications, helping to guarantee the executableness of the final generated verification instructions in the actual chip.

[0071] After obtaining the specific hardware constraints of each hardware acceleration engine node, it is necessary to further combine these physical limitations and allocate actual physical storage areas for each node in a globally contiguous memory address space. To accurately reflect the data flow mechanism and lifecycle in the computing pipeline, differentiated space allocation logic is required based on the storage needs of input and output data.

[0072] According to some embodiments, step S105 includes: allocating the input data space for the hardware acceleration engine node in the occupied space based on the input data constraints and the address alignment granularity; and allocating the output data space for the hardware acceleration engine node in the free space based on the output data constraints and the address alignment granularity.

[0073] Since the input data of the current processing node typically originates from the results calculated and stored in memory by the preceding node, the allocation of input data space essentially involves matching and addressing within the already occupied space recorded in the dictionary structure. Simultaneously, it's crucial to ensure that the selected address range strictly adheres to the input format, data size, and bus address alignment granularity requirements for this engine type. Conversely, new data generated by the current node needs to be written to previously unused physical locations. Therefore, the allocation of output data space involves delineating a new, contiguous address range within the free space recorded in the dictionary structure, conforming to output data constraints and address alignment specifications. This physical allocation logic, which distinguishes between input sources and output destinations, objectively replicates the actual data flow of the preceding node's write and the current node's read operations at the underlying memory level, forcing effective data continuity between different engines.

[0074] Furthermore, when simulating complex high-concurrency computing scenarios, the continuous allocation and dynamic reclamation of memory space may lead to memory resource shortages or space fragmentation. To address this challenge, an adaptive matching adjustment mechanism can be introduced during space allocation. Specifically, during the allocation of physical space for hardware acceleration engine nodes, if the retrieved candidate space is insufficient to accommodate the original requested data size, and if a forced matching mode is enabled, the shape dimension of the data can be automatically reduced to fit the current candidate space based on its actual capacity. This allows the allocation of input and output data spaces to continue under constrained conditions. This dynamic dimensionality reduction matching mechanism can maximize the success rate of data connections between engine nodes in the pipeline under limited shared memory conditions, avoiding interruptions in the entire computing topology construction due to insufficient local physical space, thereby improving the robustness of automatically generating complex verification scenarios.

[0075] After the physical memory space allocation for each hardware acceleration engine node in the entire computing pipeline is completed, the data flow paths between nodes are objectively defined by the underlying shared memory addresses. To further generate accurate hardware synchronization control instructions, this implicit interaction relationship in the physical addresses needs to be extracted as an explicit logical dependency topology. The following will detail how to automatically extract directed graph data dependencies based on the memory space allocation results.

[0076] According to some embodiments, step S106 includes: for each hardware acceleration engine node, comparing the memory address corresponding to the input data space of the hardware acceleration engine node with the memory address corresponding to the output data space of each hardware acceleration engine node in the preceding intermediate computing layer; determining the hardware acceleration engine node whose memory address corresponding to the output data space matches the memory address corresponding to the input data space of the hardware acceleration engine node as the target node on which the hardware acceleration engine node depends; and generating the directed graph data dependency relationship based on the pointing relationship between each hardware acceleration engine node and the target node on which it depends.

[0077] Specifically, for the currently processed hardware acceleration engine node, its allocated input memory address for reading data is obtained, and the process reverses the computation pipeline by traversing each intermediate computation layer preceding it. During this process, the input memory address of the current node is compared one by one with the output memory address of each engine node in each preceding layer. If an overlap or match is found between the output memory address range of a preceding node and the input memory address range of the current node, it objectively indicates that the current node needs to read the result data calculated and written to that address by the preceding node. Based on this objective physical address collision, the data transfer logic between the two can be clearly established, thus identifying the matching preceding node as the target node upon which the current node depends.

[0078] With the traversal and comparison of all nodes in the pipeline completed, a clear forward-backward relationship can be established between each node and its corresponding target node. By aggregating these relationships, the true topology covering the entire multi-engine architecture can be objectively and completely deduced in reverse, i.e., a directed graph data dependency relationship can be generated. This method of concretizing abstract logical connections into the extraction of underlying memory address collision comparisons can effectively characterize the intricate concurrent interaction states, ensuring that the automatically constructed computational dependency graph strictly matches the underlying real data flow, thus laying a solid data topology foundation for the subsequent insertion of precise hardware handshake communication mechanisms.

[0079] Figure 3A and Figure 3B This is a topology diagram illustrating the data dependency relationships between hardware acceleration engine nodes according to an exemplary embodiment.

[0080] like Figure 3A and Figure 3B As shown, the data dependency topology diagram visually illustrates the complete data flow path of the computing pipeline from top to bottom.

[0081] It should be noted that, Figure 3A and Figure 3BThe English words and accompanying numbers / letters marked in the figure are all data structure names, parameter names, or unique variable identifiers defined at the code level in this embodiment. Their specific meanings are explained as follows: In the figure, "layer" means a computation layer or pipeline level. The numbers following it (e.g., layer 0 to layer 9) represent the specific layer index number in the pipeline, i.e., layers 0 to 9. "tensor" in the figure represents a tensor data block, used to represent a multidimensional data array. The letter and number combination following it (e.g., bf16x(16,4) 0x55c8) represents the specific specifications of this tensor data block in the underlying physical space. "weight" in the figure represents a weight data block, representing the network weight parameters required by the computation node when performing operators such as convolution. The letter and number combination following it also represents the specific specifications of this weight data block in the underlying physical space. "vector" in the figure represents vector data, used to represent computational data or bias parameters. The letter and number combination following it represents the specific specifications of this vector data block in the underlying physical space. In the diagram, din is an abbreviation for Data In, which means input data or input data packet. It represents that the calculation results output by the preceding calculation layer are passed as specific input data to the target node of the last layer (such as the output layer node responsible for writing back to external storage).

[0082] like Figure 3A and Figure 3B As shown, at the source of the topology diagram, there is an input layer responsible for data preparation, which performs the action of moving initial test data from external storage (e.g., DDR) to a globally contiguous memory address space (e.g., GLB). Below the input layer, multiple intermediate computation layers are arranged sequentially, such as layer 1, layer 2, up to layer N. Within each intermediate computation layer, one or more concrete instantiated hardware acceleration engine nodes are distributed, such as the vector processing unit node (VPU), scalar processing unit node (SPU), and sparse engine node (SE) shown in the diagram. These nodes are distributed side by side within the same layer, objectively presenting the architectural characteristics of the target engine accelerator where multiple types of physics engines work concurrently within the same pipeline depth.

[0083] Further observation Figure 3A and Figure 3B The directed arrows connecting layers and between layers and nodes represent the data dependencies objectively extracted in the preceding steps based on memory input / output space address matching. The starting end of the arrow connects to the preceding layer node (the data producer), and the pointing end connects to the current layer node (the data consumer). For example, for an engine node in layer 2 to perform computation, it must read... Figure 3AThe forward arrow points to the result data calculated and written to shared memory by the preceding node in layer 1. This cross-layer mesh topology, derived from the reverse deduction of underlying physical address collisions, accurately depicts the intricate shared memory interaction logic and concurrent state.

[0084] Understandably, an output layer responsible for data export can be set at the end of the topology graph to write back the computation results that finally reside in the global contiguous memory address space to external storage, thereby forming a complete closed loop of the data flow lifecycle.

[0085] Therefore, based on Figure 3A and Figure 3B The tight directed graph data dependencies shown here lay the foundation for accurately inserting the corresponding hardware synchronization control instructions between specific producer and consumer nodes that generate data interactions.

[0086] After generating the directed graph data dependencies through the above process and clarifying the data interaction topology between various hardware acceleration engine nodes in the multi-level structure, to ensure that each physical node strictly follows the dependency logic during low-level concurrent execution and avoids data competition or blocking caused by read / write timing errors, a precise low-level hardware synchronization control mechanism can be further configured between the interacting nodes. The following section will provide a detailed explanation of how to insert hardware synchronization instructions based on the data dependencies.

[0087] According to some embodiments, step S107 includes: determining the hardware acceleration engine node that generates the interaction based on the directed graph data dependency relationship, wherein the hardware acceleration engine node that is depended upon is the producer engine node, and the hardware acceleration engine node that generates the dependency is the consumer engine node; inserting a waiting instruction before the execution instruction sequence of the consumer engine node; and inserting a notification instruction after the execution instruction sequence of the producer engine node.

[0088] For example, the directed graph data dependencies extracted earlier can be used to traverse the entire computational dependency topology and explicitly define the roles of the nodes that generate interactions. Specifically, for each pair of nodes with data pointing relationships, the dependent node providing source data is marked as the producer engine node, and the dependent node reading the source data for subsequent operations is marked as the consumer engine node. After clarifying the role division, the targeted insertion phase of synchronization instructions begins. For the consumer engine node, a wait instruction is inserted before the start of its own data processing execution instruction sequence, thereby forcibly blocking the premature execution of the node at the hardware control level, so that the consumer engine node remains in a suspended state, truly waiting for the corresponding producer engine node to complete all the preceding computation tasks. At the same time, for the producer engine node, a notification instruction is inserted after the end of its data processing execution instruction sequence, so that after the producer engine node completes the computation and safely writes the result back to the corresponding physical memory space, it sends a handshake signal to notify and wake up the waiting consumer engine node to start subsequent work. This instruction-level handshake communication mechanism based on the producer-consumer model imposes strict timing constraints on the final verification flow, realistically simulating the concurrent control logic when multiple engines work together inside the target chip. This helps to effectively expose and reproduce potential timing defects such as deadlocks during the verification process.

[0089] In some embodiments, the inserted hardware synchronization instructions can support multiple underlying hardware-related synchronization types. For example, synchronization instructions may include event synchronization for event notification, request synchronization for request waiting, and at least one of self synchronization, processor unit synchronization (PE), or vector processor synchronization (RVV) specific to a particular processor architecture. By supporting these multiple synchronization types, the high-concurrency communication model of real hardware can be accurately reproduced, avoiding deadlocks.

[0090] After completing the allocation of physical memory space and constructing the hardware synchronization mechanism through the above steps, the computational tasks, data read / write paths, and concurrent coordination control timings of each node in the computing pipeline have been established. To enable this configuration information to actually run in a real chip or hardware simulation platform, the above architecture topology needs to be converted into an instruction format that the underlying hardware can directly recognize and execute. The following section will explain in detail how to generate the final instruction stream used for verification.

[0091] According to some embodiments, step S108 includes: extracting the space address parameters and data specification parameters of the input data space and output data space of the corresponding hardware acceleration engine node according to the instruction field structure defined by the preset operator template; filling the space address parameters, the data specification parameters and the synchronization instructions into the instruction field structure to generate an operator instruction sequence corresponding to each hardware acceleration engine node; and converting the operator instruction sequence corresponding to each hardware acceleration engine node into machine instruction code to generate an instruction stream for verifying the engine accelerator.

[0092] For each type of physics engine, a corresponding operator template is typically pre-configured. This template defines the instruction encoding format and underlying field composition specifications required for that type of engine to perform computational tasks. During the instruction generation phase, for each hardware acceleration engine node in the pipeline, the required memory start address, step size, and other spatial address parameters, as well as the corresponding data dimension and type, are precisely extracted from the pre-allocated input and output data spaces based on its associated operator template. Subsequently, these extracted physical memory parameters, along with the handshake synchronization instructions inserted for that node in the previous steps, are filled and integrated according to the field arrangement rules specified in the operator template. Through this parameter filling process, the abstract computational nodes and dependencies are concretized into a sequence of operator instructions carrying real physical addresses and timing control information. Finally, the integrated operator instruction sequence is parsed and translated, converting it into machine instruction code natively supported by the target engine accelerator. This template-filling and machine code-converting processing method establishes a mapping link between the upper-layer logic topology and the lower-layer actual chip execution file, ensuring that the generated verification instruction stream conforms to the instruction set architecture specifications of the target hardware. This completes the closed-loop process of end-to-end automated verification instruction generation, providing reliable test incentives for chip verification in complex concurrent scenarios.

[0093] To fully reflect the heterogeneous characteristics of various engine architectures, in some embodiments, the preset operator templates are predefined templates specifically associated with each engine node. The operator templates not only define specific instruction formats but also define parameter ranges and input / output constraints. For example, the Direct Memory Access (DMA) engine can be associated with the LDT / STT template, the Tensor Engine (TE) with the GEMM template, the Sparse Engine (SE) with the SORT template, and the Vector Processing Unit (VPU) with the ACT template. When generating the instruction stream, the parameters of each node are uniformly aggregated and generated according to their respective operator templates, thereby supporting the verification of hybrid architectures with multiple different engines.

[0094] In the final verification application, the instruction stream generated by this disclosure supports a rich set of Design Verification (DV) verification modes. In some embodiments, the method supports layer-by-layer checking and end-to-end checking. For example, in layer-by-layer checking, verification is performed immediately after each layer's instruction is executed (e.g., sending an RVV command); while in end-to-end checking, all layers' computational tasks are automatically completed, and the results are compared uniformly at the end. This flexible mode support improves the debugging efficiency and scenario coverage for verification personnel.

[0095] In summary, the verification instruction generation method provided in this disclosure establishes an end-to-end automated test stimulus generation mechanism. By constructing a multi-level computing pipeline and realistically simulating the allocation, flow, and dynamic recycling of data in the underlying contiguous memory space, this scheme can objectively and accurately map the concurrent interaction state of multiple types of physical engines working collaboratively in the target accelerator. Compared to the limitations of traditional manual design of test scenarios, this scheme reverse-engineers data dependencies based on physical address matching and automatically constructs a rigorous handshake synchronization mechanism in the generated code accordingly. This processing logic, which integrates dynamic space management with physical hardware constraints, not only improves the efficiency of automated construction of complex verification instruction streams but also systematically triggers and exposes deep-seated hardware defects such as data contention and deadlock hidden in high-concurrency shared memory scenarios. This effectively expands the boundaries and coverage of verification scenarios, providing solid technical support for the completeness and reliability of complex multi-engine chip verification.

[0096] According to one aspect of this disclosure, an apparatus for generating instructions for verifying an engine accelerator is also provided.

[0097] like Figure 4As shown, the instruction generation apparatus 400 for verifying the engine accelerator includes: a first allocation module 401 configured to allocate a globally contiguous memory address space; a construction module 402 configured to construct a computational pipeline, wherein the computational pipeline includes an input layer, at least one intermediate computational layer connected in sequence, and an output layer, wherein the input layer is used to transfer data from external storage to the globally contiguous memory address space, and the output layer is used to transfer the computation results of the last intermediate computational layer to the external storage; an initialization module 403 configured to initialize the at least one intermediate computational layer layer by layer to generate at least one hardware acceleration engine node in each intermediate computational layer, wherein the hardware acceleration engine node is used to simulate the data processing and memory access behavior of the physics engine; and an acquisition module 404 configured to acquire data from each intermediate computational layer. Each hardware acceleration engine node in the layer obtains its hardware constraints; a second allocation module 405 is configured to allocate input data space and output data space that satisfy the hardware constraints for the hardware acceleration engine node in the globally contiguous memory address space; an extraction module 406 is configured to extract the directed graph data dependencies between hardware acceleration engine nodes based on the input data space and output data space of each hardware acceleration engine node; an insertion module 407 is configured to insert hardware synchronization instructions between the interacting hardware acceleration engine nodes according to the directed graph data dependencies; and a generation module 408 is configured to generate an instruction stream for verifying the engine accelerator based on a preset operator template, the input data space and output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions.

[0098] The first allocation module 401 is configured to allocate a globally contiguous memory address space. This operation primarily aims to establish a logical storage model in the verification environment that corresponds to the physical memory of the target hardware (e.g., shared cache or global cache), simulating the limited on-chip storage resources shared by multiple processing units within the target engine accelerator. By allocating such an address space, a unified addressing range can be provided, dynamically offering a place to store raw data and computation results for subsequent computation tasks, thereby restoring the memory layout characteristics of the physical hardware at the basic resource level.

[0099] The construction module 402 is configured to build a computational pipeline comprising an input layer, an intermediate computation layer, and an output layer. Specifically, the construction module 402 is used to establish the data transmission path from entering the hardware to completing processing and finally writing back to external storage. The input layer is responsible for modeling the transfer of data from external storage to internal contiguous memory, while the output layer is responsible for writing back the final computation results. This defines the overall data flow boundary and hierarchical processing structure of the verification task, thereby reflecting the end-to-end data transmission and processing pipeline of the engine accelerator, making the generated verification scenario more closely resemble the state of a real chip when processing workloads.

[0100] Initialization module 403 is configured to initialize intermediate computing layers layer by layer to generate hardware acceleration engine nodes. Specifically, within the pre-built computing pipeline architecture, specific execution units are instantiated hierarchically to simulate the data processing and memory access behavior of the underlying physical engine at different pipeline stages. This transforms the abstract pipeline hierarchy into node models capable of executing specific processing tasks, acting as execution entities of the physical hardware in the verification environment. By generating these hardware acceleration engine nodes, the computing architecture of the target accelerator can be replicated, ensuring that the generated behavioral model reflects the operating logic of the physical engine.

[0101] The acquisition module 404 is configured to acquire the corresponding hardware constraints for each generated hardware acceleration engine node. Real engine accelerators are typically constrained by various specifications when processing data. By acquiring pre-set hardware design parameters, the various rules that the current node must follow are determined, thus clarifying the range of conditions that the current node can support when performing data access and computation. This introduces the actual design boundaries of the physical hardware into the simulation process, ensuring that the behavior of the current node conforms to the capabilities of the real hardware, thereby avoiding the generation of invalid test instructions that the hardware cannot parse or execute.

[0102] The second allocation module 405 is configured to allocate input and output data spaces that meet hardware constraints for hardware acceleration engine nodes within a globally contiguous memory address space. Combined with the hardware constraints acquired by the acquisition module 404, address segments for storing read data and computation results are designated for the nodes within the memory model established by the first allocation module 401. This establishes a connection between computational tasks and underlying storage resources, simulating the memory allocation and occupancy process of a real engine accelerator during task processing. This constraint-based allocation method can reproduce the hardware resource scheduling within a limited storage range, helping to reveal potential memory access conflicts during verification.

[0103] The extraction module 406 extracts the directed graph data dependencies between hardware acceleration engine nodes based on the input and output data spaces of each node. Since different nodes have overlapping read and write operations on memory space, the module tracks address usage to analyze the pre- and post-processing relationships between various computational tasks, clarifying the interaction topology when multiple nodes work together, and thus determining the execution waiting conditions of each node. This achieves automated extraction of data dependencies, replacing the tedious process of manually specifying dependencies and improving the accuracy of topology construction in concurrent scenarios.

[0104] The insertion module 407 inserts hardware synchronization instructions between the hardware acceleration engine nodes that generate interactions, based on the data dependencies in the directed graph. Based on the extracted node topology, a control mechanism for coordinating timing is added to the instruction sequences corresponding to nodes with data dependencies. This addresses the issue of data being read before it is ready or being abnormally overwritten when multiple execution units operate asynchronously. By inserting hardware synchronization instructions, the execution order between nodes that generate data interactions can be coordinated, preventing concurrency errors such as deadlocks, thereby ensuring the correctness of the timing relationships in the generated verification scenario.

[0105] The generation module 408 generates an instruction stream for verifying the engine accelerator based on preset operator templates, input / output data space allocation, and inserted synchronization instructions. After integrating the previously determined node behaviors, memory address allocation results, and timing synchronization rules, the generation module 408 compiles and converts the instruction format templates recognized by the target hardware to output the previously constructed logical verification model and data topology relationships as low-level machine instructions capable of driving the actual operation of the engine accelerator. This streamlines the entire process from pipeline modeling, resource allocation, dependency extraction to instruction output, effectively improving the automation level of hardware instruction stream generation.

[0106] In summary, the instruction generation apparatus for verifying the engine accelerator provided in this disclosure allocates a globally contiguous memory address space and constructs a computational pipeline containing an input layer, intermediate computation layer, and output layer. During the layer-by-layer initialization of the intermediate computation layer, hardware acceleration engine nodes are generated, and input and output data spaces are allocated in the memory address space based on hardware constraints. Then, based on the data space allocation results, directed graph data dependencies between hardware acceleration engine nodes are automatically extracted, and hardware synchronization instructions are inserted between interacting nodes. Finally, an instruction stream for verification is generated by combining operator templates. This apparatus achieves automated construction of a multi-level computational pipeline. By combining dynamic allocation of data space with physical hardware constraints, it recreates the actual memory access behavior of the underlying hardware. Simultaneously, it accurately extracts data dependencies based on space allocation and inserts hardware synchronization mechanisms, achieving automated and reliable generation of complex hardware verification instruction streams.

[0107] It is understood that each module of the instruction generation device 400 for verifying the engine accelerator can be configured to execute the various method steps defined in method 100 to generate instructions for verifying the engine accelerator, which the applicant will not elaborate on here.

[0108] According to one aspect of this disclosure, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory. The processor is configured to execute the computer program to implement the steps of any of the method embodiments described above.

[0109] According to one aspect of this disclosure, a non-transitory computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the method embodiments described above.

[0110] According to one aspect of this disclosure, a computer program product is also provided, which includes a computer program that, when executed by a processor, implements the steps of any of the method embodiments described above.

[0111] In the following text, combined with Figure 5 Illustrative examples describing such computer devices, non-transitory computer-readable storage media, and computer program products.

[0112] Figure 5 An example computer device 500 is shown in which any of the embodiments described herein may be implemented. The computer device 500 may be used to implement one or more components of the systems and methods described above. The computer device 500 may include a bus 502 or other communication mechanism for communicating information, and one or more processors 504 coupled to the bus 502 for processing information. The processor 504 may be, for example, one or more general-purpose microprocessors.

[0113] Computer device 500 may also include main memory 506, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 502, for storing information and instructions to be executed by processor 504. Main memory 506 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 504. Such instructions, when stored in a storage medium accessible to processor 504, can make computer device 500 a special-purpose machine customized to perform the operations specified in the instructions. Main memory 506 may include non-volatile media and / or volatile media. Non-volatile media may include, for example, optical discs or magnetic disks. Volatile media may include dynamic memory. Common media formats may include, for example, floppy disks, collapsible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs (read-only optical disc drives), any other optical data storage media, any physical media with a perforated arrangement, RAM (random access memory), DRAM (dynamic random access memory), PROM (programmable read-only memory) and EPROM (erasable programmable read-only memory), FLASH-EPROM (fast erase programmable read-only memory), NVRAM (non-volatile random access memory), any other memory chips or tape cartridges, or network versions of the above.

[0114] Computer device 500 may implement the techniques described herein using custom hardwired logic, one or more ASICs (Application-Specific Integrated Circuits) or FPGAs (Field-Programmable Gate Arrays), firmware, and / or program logic, which, when combined with computer device 500, enable computer device 500 to become a special-purpose machine or to be programmed therein. According to one embodiment, the techniques described herein are executed by computer device 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions may be read into main memory 506 from another storage medium, such as storage device 508. Executing the sequence of instructions contained in main memory 506 causes processor 504 to perform the processing steps described herein. For example, the processes / methods disclosed herein may be implemented by computer program instructions stored in main memory 506. When these instructions are executed by processor 504, they may perform the steps shown in the corresponding figures and as described above. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0115] Computer device 500 also includes a network interface 510 coupled to bus 502. Network interface 510 can provide bidirectional data communication coupled to one or more network links connected to one or more networks. As another example, network interface 510 can be a local area network (LAN) card to provide data communication connectivity with a compatible LAN (or a WAN component communicating with a WAN (wide area network)). Wireless links can also be implemented.

[0116] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across many machines. In some exemplary embodiments, the processor or the processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other exemplary embodiments, the processor or the processor-implemented engine may be distributed across many geographic locations.

[0117] Each process, method, and algorithm described in the preceding sections can be embodied in a code module executed by one or more computer systems or computer processors including computer hardware, and can be fully or partially automated by them. These processes and algorithms can be implemented, in part or in whole, in a specific application circuit.

[0118] When the functions disclosed herein are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Specific technical solutions (all or part) disclosed herein, or aspects contributing to the prior art, can be embodied in the form of a software product. This software product can be stored in a storage medium and includes instructions to cause a computer device (which may be a personal computer, server, network device, etc.) to perform all or part of the steps of the methods described in the embodiments of this application. The storage medium may include a flash drive, a portable hard drive, ROM, RAM, a magnetic disk, an optical disk, another medium suitable for storing program code, or any combination thereof.

[0119] The embodiments disclosed herein can be implemented via a cloud platform, server, or group of servers that interact with a client. The client can be a terminal device or a client registered by a user on the platform, wherein the terminal device can be a mobile terminal, a personal computer (PC), or any device that can install platform applications.

[0120] The various features and processes described above can be used independently or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. Furthermore, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and associated blocks or states may be executed in other suitable orders. For example, described blocks or states may be executed in a non-specifically disclosed order, or multiple blocks or states may be combined in a single block or state. Exemplary blocks or states may be executed serially, in parallel, or otherwise. Blocks or states may be added to or removed from the disclosed exemplary embodiments. The exemplary systems and components described herein may be configured differently from those described. For example, elements may be added, removed, or rearranged compared to the disclosed exemplary embodiments.

[0121] The various operations of the exemplary methods described herein can be performed at least in part by an algorithm. An algorithm may consist of program code or instructions stored in memory (such as the non-transitory computer-readable storage medium described above). Such an algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not be explicitly programmed into the computer to perform the function, but may learn from training data to obtain a predictive model for performing that function.

[0122] The various operations of the exemplary methods described herein can be performed at least in part by one or more processors, which are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute the engine of a processor implementation whose operation is to perform one or more of the operations or functions described herein.

[0123] Similarly, the methods described herein can be implemented at least partially by a processor, where a specific processor or one or more processors are examples of hardware. For example, at least some operations of the methods can be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors can also run in a “cloud computing” environment or as “Software as a Service” (SaaS) to support the execution of the relevant operations. For example, at least some operations can be performed by a group of computers (as an example of a machine including processors), which can be accessed via a network (e.g., the Internet) and through one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0124] The performance of certain operations can be distributed across processors, not just residing within a single machine, but deployed across many machines. In some exemplary embodiments, the processor or the processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other exemplary embodiments, the processor or the processor-implemented engine may be distributed across many geographic locations.

[0125] In this specification, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are described and illustrated as independent operations, one or more individual operations may be performed concurrently, and these operations are not required to be performed in the order shown. Structures and functionalities presented as independent components in the example configuration may be implemented as combined structures or components. Similarly, structures and functionalities presented as individual components may be implemented as independent components. These and other variations, modifications, additions, and improvements are all within the scope of this document.

[0126] As used herein, “or” is inclusive rather than exclusive unless explicitly stated or indicated by context. Furthermore, “and” is both common and individual unless explicitly stated or indicated by context. Moreover, multiple instances may be provided for the resources, operations, or structures described herein as a single example. Furthermore, the boundaries between various resources, operations, engines, and data stores are somewhat arbitrary, and specific operations are illustrated within the context of a particular illustrative configuration. The allocation of other functionalities is conceivable and may fall within the scope of various embodiments of this disclosure. Generally, structures and functionalities presented as independent resources in example configurations may be implemented as combined structures or resources. Similarly, structures and functionalities presented as individual resources may be implemented as independent resources. These and other variations, modifications, additions, and improvements are all within the scope of embodiments of this disclosure. Therefore, this specification and accompanying drawings should be viewed in an illustrative rather than restrictive sense.

[0127] The terms “comprising” or “including” are used to indicate the presence of a subsequently stated feature, but do not preclude the addition of other features. Conditional language, in particular, such as “may,” “can,” or “may,” unless specifically stated or otherwise understood in the context of use, is generally intended to express that certain embodiments include certain features, elements, and / or steps, while other embodiments do not. Therefore, such conditional language generally does not imply that a feature, element, and / or step is necessary in any way for one or more embodiments, or that one or more embodiments must include logic that, with or without user input or prompting, determines whether such features, elements, and / or steps are included in any particular embodiment, or whether they are to be performed in any particular embodiment.

Claims

1. A method for generating instructions for verifying an engine accelerator, characterized in that, The method includes: Allocate a globally contiguous memory address space; A computational pipeline is constructed, comprising an input layer, at least one intermediate computation layer connected in sequence, and an output layer, wherein the input layer is used to transfer data from external storage to the globally contiguous memory address space, and the output layer is used to transfer the computation results of the last intermediate computation layer to the external storage. The at least one intermediate computing layer is initialized layer by layer to generate at least one hardware acceleration engine node in each intermediate computing layer, wherein the hardware acceleration engine node is used to simulate the data processing and memory access behavior of the physics engine; For each hardware acceleration engine node in each intermediate computing layer, obtain the hardware constraints for that hardware acceleration engine node, including: For each hardware acceleration engine node in each intermediate computing layer, the physical engine type corresponding to that hardware acceleration engine node is determined based on a pre-defined list of available engines; and Obtain the input data constraints, output data constraints, and address alignment granularity corresponding to the physical engine type, and use the input data constraints, output data constraints, and address alignment granularity as hardware constraint conditions for the hardware acceleration engine node. In the globally contiguous memory address space, an input data space and an output data space that satisfy the hardware constraints are allocated for the hardware acceleration engine node; Based on the input and output data spaces of each hardware acceleration engine node, the directed graph data dependencies between hardware acceleration engine nodes are extracted. Based on the directed graph data dependencies, hardware synchronization instructions are inserted between the hardware acceleration engine nodes that generate interactions; and Based on the preset operator template, the input data space and output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions, an instruction stream for verifying the engine accelerator is generated.

2. The method according to claim 1, characterized in that, in, The engine accelerator includes multiple physical engines of different types, and wherein the step-by-step initialization of the at least one intermediate computing layer to generate at least one hardware acceleration engine node in each intermediate computing layer includes: Multiple hardware acceleration engine nodes are generated in each intermediate computing layer; Each of the multiple hardware acceleration engine nodes is assigned a corresponding physical engine type to simulate concurrent computing tasks of the multiple physical engines of different types.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The dictionary structure is used to record the allocated space in the global contiguous memory address space as occupied space, and the unallocated space in the global contiguous memory address space as free space.

4. The method according to claim 3, characterized in that, in, The allocation of input and output data spaces that satisfy the hardware constraints for the hardware acceleration engine node in the globally contiguous memory address space includes: Based on the input data constraints and the address alignment granularity, allocate the input data space for the hardware acceleration engine node within the already occupied space; and Based on the output data constraints and the address alignment granularity, the output data space is allocated to the hardware acceleration engine node in the free space.

5. The method according to claim 1 or 2, characterized in that, in, The extraction of directed graph data dependencies between hardware acceleration engine nodes based on the input and output data spaces of each hardware acceleration engine node includes: For each hardware acceleration engine node, the memory address corresponding to the input data space of the hardware acceleration engine node is compared with the memory address corresponding to the output data space of the hardware acceleration engine node in each preceding intermediate computing layer. The hardware acceleration engine node whose memory address matches the memory address of its input data space is identified as the target node on which the hardware acceleration engine node depends; and The directed graph data dependency relationship is generated based on the pointing relationship between each hardware acceleration engine node and the target node it depends on.

6. The method according to claim 1 or 2, characterized in that, in, The step of inserting hardware synchronization instructions between the hardware acceleration engine nodes that generate the interaction, based on the directed graph data dependencies, includes: Based on the directed graph data dependency relationship, the hardware acceleration engine node that generates the interaction is determined, wherein the hardware acceleration engine node that is depended on is the producer engine node, and the hardware acceleration engine node that generates the dependency is the consumer engine node. Insert a wait instruction before the execution instruction sequence of the consumer engine node; A notification instruction is inserted after the sequence of execution instructions of the producer engine node.

7. The method according to claim 1 or 2, characterized in that, in, The step of generating an instruction stream for verifying the engine accelerator based on a preset operator template, the input data space and output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions includes: Based on the instruction field structure defined by the preset operator template, extract the space address parameters and data specification parameters of the input data space and output data space of the corresponding hardware acceleration engine node; The spatial address parameters, the data specification parameters, and the synchronization instructions are respectively filled into the instruction field structure to generate the operator instruction sequence corresponding to each hardware acceleration engine node; The operator instruction sequence corresponding to each hardware acceleration engine node is converted into machine instruction code to generate an instruction stream for verifying the engine accelerator.

8. An apparatus for generating instructions for verifying an engine accelerator, characterized in that, The device includes: The first allocation module is configured to allocate a globally contiguous memory address space; A building module is configured to build a computing pipeline, wherein the computing pipeline includes an input layer, at least one intermediate computing layer connected in sequence, and an output layer, wherein the input layer is used to transfer data from external storage to the globally contiguous memory address space, and the output layer is used to transfer the computation results of the last intermediate computing layer to the external storage; An initialization module is configured to initialize the at least one intermediate computing layer layer by layer to generate at least one hardware acceleration engine node in each intermediate computing layer, wherein the hardware acceleration engine node is used to simulate the data processing and memory access behavior of the physics engine. The acquisition module is configured to acquire the hardware constraints of each hardware acceleration engine node in each intermediate computing layer, wherein the acquisition module is further configured to: For each hardware acceleration engine node in each intermediate computing layer, the physical engine type corresponding to that hardware acceleration engine node is determined based on a pre-defined list of available engines; and Obtain the input data constraints, output data constraints, and address alignment granularity corresponding to the physical engine type, and use the input data constraints, output data constraints, and address alignment granularity as hardware constraint conditions for the hardware acceleration engine node. The second allocation module is configured to allocate input data space and output data space that satisfy the hardware constraints for the hardware acceleration engine node in the globally contiguous memory address space. The extraction module is configured to extract the directed graph data dependencies between hardware acceleration engine nodes based on the input data space and output data space of each hardware acceleration engine node. The insertion module is configured to insert hardware synchronization instructions between the hardware acceleration engine nodes that generate the interaction, based on the directed graph data dependencies; and The generation module is configured to generate an instruction stream for verifying the engine accelerator based on a preset operator template, the input data space and output data space corresponding to each hardware acceleration engine node, and the inserted synchronization instructions.

9. A computer device, characterized in that, The computer device includes: At least one processor; A memory having a computer program stored thereon, wherein, when executed by the at least one processor, the computer program causes the at least one processor to perform the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1-7.

Images