Test excitation generation method and device, equipment, storage medium and product

Abstract

The invention discloses a test incentive generation method and device, equipment, a storage medium and a product, and belongs to the technical field of artificial intelligence chips, the method comprises the steps that a test case is acquired, the test case comprises multiple pairs of equipment identifiers, and each pair of equipment identifiers comprises an equipment identifier of one piece of master equipment and an equipment identifier of one piece of slave equipment; selecting a first excitation constraint set matched with the master device from the master device constraint set according to the device identifier of the master device in each pair of device identifiers, and selecting a second excitation constraint set matched with the slave device from the slave device constraint set according to the device identifier of the slave device in each pair of device identifiers; and according to the first excitation constraint set and the second excitation constraint set corresponding to each pair of device identifiers, generating a test excitation, the test excitation being used for testing a communication path from one master device to one slave device. According to the invention, a single test case can test a plurality of communication paths, and the number of the test cases is obviously reduced.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence chip technology, and in particular to a test stimulus generation method, apparatus, device, storage medium, and product. Background Technology

[0002] As integrated circuit scale continues to increase, the number of master and slave devices integrated in a System on Chip (SoC) has increased significantly, and their interconnection structure has become increasingly complex. To ensure that data can be correctly routed and transmitted among numerous master and slave devices, thorough verification of the interconnection network has become a key step in chip functional verification.

[0003] In existing technologies, the verification of interconnection paths in such multi-master, multi-slave systems commonly employs a "one-to-one path traversal" method based on targeted testing. This method develops a separate test case for each specific Master→Slave communication path and runs a test sequence specifically configured for that path within that test to verify the functional correctness of that single path. This is achieved by executing all possible Master→Slave paths one by one. N (M is the number of master devices, N is the number of slave devices) test cases are superimposed to achieve coverage of all routing paths in the entire system.

[0004] Therefore, as chip size increases, there is a problem that the number of test cases in existing technologies grows exponentially. Summary of the Invention

[0005] This application provides a test stimulus generation method, apparatus, device, storage medium, and product to reduce the number of test cases.

[0006] In a first aspect, embodiments of this application provide a test stimulus generation method, including: Obtain test cases, which include multiple pairs of device identifiers, each pair of device identifiers including a device identifier of a master device and a device identifier of a slave device; Based on the device identifier of the master device in each pair of device identifiers, a first set of incentive constraints matching the master device is selected from the master device constraint set, and based on the device identifier of the slave device in each pair of device identifiers, a second set of incentive constraints matching the slave device is selected from the slave device constraint set. Test stimuli are generated based on the first set of incentive constraints and the second set of incentive constraints corresponding to each pair of device identifiers. These test stimuli are used to test the communication path from a master device to a slave device.

[0007] In some embodiments, for each pair of device identifiers, the device identifier is used to characterize the device type and device characteristics of the device, and the set of incentive constraints matched by the device is determined according to the following steps: From the set of device constraints corresponding to the device type of any device, select a set of incentive constraints that matches the device characteristics of any device.

[0008] In some embodiments, generating test stimuli based on the first set of stimuli constraints and the second set of stimuli constraints corresponding to each pair of device identifiers includes: The first set of incentive constraints, the second set of incentive constraints, and the preset set of general incentive constraints are merged to obtain the effective set of incentive constraints. Based on the set of effective incentive constraints, the incentive generation function is invoked to generate the test incentives.

[0009] In some embodiments, the method further includes: For each target incentive constraint in the first incentive constraint set and the second incentive constraint set, if there is a general incentive constraint in the general incentive constraint set that has the same constraint type as the target incentive constraint, then a constraint conflict analysis is performed on the constraint content of the device incentive constraint and the general incentive constraint. Based on the conflict analysis results, determine the effective incentive constraints among the target incentive constraints and the general incentive constraints.

[0010] In some embodiments, determining the effective incentive constraints among the target incentive constraints and the general incentive constraints based on the conflict analysis results includes: If the conflict analysis result is that there is no conflict, then both the target incentive constraint and the general incentive constraint are determined to be effective incentive constraints. If the conflict analysis results indicate that a conflict exists, then based on the target incentive constraint and the general incentive constraint, a decision incentive constraint is determined, and the decision incentive constraint is identified as an effective incentive constraint.

[0011] In some embodiments, determining the decision incentive constraints based on the target incentive constraints and the general incentive constraints includes: Obtain the constraint strength of the target incentive constraint and the general incentive constraint, wherein the constraint strength includes mandatory constraints and suggested constraints; If the target incentive constraint and the general incentive constraint have different constraint strengths, then the incentive constraint with a mandatory constraint strength among the target incentive constraint and the general incentive constraint shall be determined as the decision incentive constraint. If both the target incentive constraint and the general incentive constraint are mandatory constraints, then the constraint merging is determined to have failed, and an alarm message is generated. If the constraint strength of both the target incentive constraint and the general incentive constraint is a suggestion constraint, then the target incentive constraint and the general incentive constraint are merged, and the merged incentive constraint is determined as the decision incentive constraint.

[0012] Secondly, embodiments of this application provide a test stimulus generation apparatus, comprising: The acquisition module is used to acquire test cases, which include multiple pairs of device identifiers, each pair of device identifiers including a device identifier of a master device and a device identifier of a slave device. The selection module is used to select a first set of incentive constraints that matches the master device from the master device constraint set based on the master device's device identifier in each pair of device identifiers, and to select a second set of incentive constraints that matches the slave device from the slave device constraint set based on the slave device's device identifier in each pair of device identifiers; The generation module is used to generate test stimuli based on the first set of incentive constraints and the second set of incentive constraints corresponding to each pair of device identifiers. The test stimuli are used to test the communication path from a master device to a slave device.

[0013] Thirdly, embodiments of this application provide an electronic device, including: at least one processor, and a memory communicatively connected to the at least one processor, wherein: The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform any of the above-described test stimulus generation methods.

[0014] Fourthly, embodiments of this application provide a storage medium in which, when a computer program in the storage medium is executed by a processor of an electronic device, the electronic device is capable of executing any of the above-described test stimulus generation methods.

[0015] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements any of the above-described test stimulus generation methods.

[0016] In this embodiment, test cases are obtained, each including multiple pairs of device identifiers, with each pair including a master device identifier and a slave device identifier. Based on the master device identifier in each pair, a first set of incentive constraints matching the master device is selected from the master device constraint set, and based on the slave device identifier in each pair, a second set of incentive constraints matching the slave device is selected from the slave device constraint set. Test stimuli are generated based on the first and second incentive constraint sets corresponding to each pair of device identifiers. These test stimuli are used to test a communication path from one master device to one slave device. In traditional methods, each master-to-slave communication path requires a separate test case, resulting in the development of M×N test cases in a system with M master devices and N slave devices. This application addresses this by designing a single test case containing multiple pairs of master and slave device identifiers, each pair representing a communication path under test. Based on predefined master and slave device constraint sets, a corresponding incentive constraint set is independently matched and generated for each pair of devices, thereby generating multiple test stimuli in parallel. This approach eliminates the need for a single test case to be bound to a single communication path. Instead, it defines a set of "master-slave device pairs," with each pair independently matching its stimulus constraint set and generating corresponding test stimuli in parallel. This achieves the technical effect of testing multiple communication paths simultaneously with a single test case, significantly reducing the total number of test cases.

[0017] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This application scenario diagram illustrates a test stimulus generation method provided in an embodiment of this application. Figure 2 A flowchart illustrating a test stimulus generation method provided in this application embodiment; Figure 3 A schematic diagram of a test stimulus generation method provided in this application embodiment; Figure 4 This is a schematic diagram of a test stimulus generation device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device for generating test stimuli, provided as an embodiment of this application. Detailed Implementation

[0019] To reduce the number of test cases, embodiments of this application provide a test stimulus generation method, apparatus, device, storage medium, and product.

[0020] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0021] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0022] Before introducing the test stimulus generation method provided in the embodiments of this application, for ease of understanding, the technical background of the embodiments of this application will be described in detail below.

[0023] As integrated circuit scale continues to increase, the number of master and slave devices integrated in a System on Chip (SoC) has increased significantly, and their interconnection structure has become increasingly complex. To ensure that data can be correctly routed and transmitted among numerous master and slave devices, thorough verification of the interconnection network has become a key step in chip functional verification.

[0024] In existing technologies, the verification of interconnection paths in such multi-master, multi-slave systems commonly employs a "one-to-one path traversal" method based on targeted testing. This method develops a separate test case for each specific Master→Slave communication path and runs a test sequence specifically configured for that path within that test to verify the functional correctness of that single path. This is achieved by executing all possible Master→Slave paths one by one. N (M is the number of master devices, N is the number of slave devices) test cases are superimposed to achieve coverage of all routing paths in the entire system.

[0025] Therefore, as chip size increases, there is a problem that the number of test cases in existing technologies grows exponentially.

[0026] To address this, this application provides a novel test stimulus generation scheme. By setting multiple pairs of device identifiers in a single test case and generating multiple test stimuli through parallel matching of the stimulus constraint sets of the master and slave devices, a single test case can test multiple communication paths, significantly reducing the number of test cases.

[0027] To more clearly illustrate the methods of the embodiments of this application, the application scenarios of the embodiments of this application will be introduced below.

[0028] See Figure 1 , Figure 1 This application scenario illustrates a test stimulus generation method provided in an embodiment of this application. The application scenario diagram includes a terminal device 110 and a server 120.

[0029] In this embodiment of the application, the terminal device 110 is used for verification engineers or planners to configure test cases and view test results, including but not limited to devices such as tablet computers, laptop computers, and desktop computers.

[0030] Server 120 is used for generating test stimuli. It can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0031] It should be noted that the test stimulus generation method in each embodiment of this application can be executed by an electronic device, which can be a server 120. The specific method includes: the server 120 obtaining test cases sent by the terminal device 110. Each test case includes multiple pairs of device identifiers, each pair including a master device identifier and a slave device identifier; based on the master device identifier in each pair, selecting a first stimulus constraint set matching the master device from the master device constraint set, and based on the slave device identifier in each pair, selecting a second stimulus constraint set matching the slave device from the slave device constraint set; generating test stimuli based on the first and second stimulus constraint sets corresponding to each pair of device identifiers. These test stimuli are used to test a communication path from a master device to a slave device. Finally, the test results of the master-slave communication path tested using the test stimuli can be sent to the terminal device 110. The master device constraint set and the slave device constraint set can be stored in the database of the server 120.

[0032] In one alternative implementation, the terminal device 110 and the server 120 can communicate via a communication network.

[0033] In one alternative implementation, the communication network is a wired network or a wireless network.

[0034] It should be noted that, Figure 1 The examples shown are merely illustrative; in reality, the number of terminal devices and servers is unlimited and is not specifically limited in the embodiments of this application.

[0035] See Figure 2 , Figure 2 A flowchart of a test stimulus generation method provided in this application embodiment, the method being applied to Figure 1 In server 120, the method includes the following steps.

[0036] In step 201, test cases are obtained. Each test case includes multiple pairs of device identifiers, and each pair of device identifiers includes a device identifier of a master device and a device identifier of a slave device.

[0037] The System on Chip (SoC) integrates multiple master and slave devices, and enables inter-module communication via a high-speed bus or Network-on-Chip (NoC). The SoC includes, but is not limited to, the following master devices: video decoder, video encoder, stream processor cluster (SPC) with its master port denoted as SPC_M, transfer control unit (TCU), level 2 cache master port (L2_M), die-to-die controller (D2D), peer-to-peer master port (P2P_M), system controller (System_ctrl), UCIe-based I / O Ultra Chip Interconnect Express (IO_ucie), host endpoint (HOST_ep), and system direct memory access (SDMA) controller.

[0038] The SoC includes, but is not limited to, the following slave devices: Stream Processor Cluster Slave Port (SPC_S), High Bandwidth Memory (HBM) controller or address space, Level 2 Cache Slave Port (L2_S), Peer-to-Peer Slave Port (P2P_S), and PCIe Slave interface or address space (PCIe_S).

[0039] Each master device connects to one or more slave devices through an interconnect network to achieve data transmission and control access. For example, SPC_M can access HBM and L2_S for large-scale parallel computing data reading and writing; SDMA can initiate data transfer to PCIe_S through NoC to achieve peripheral communication; D2D controller can access HBM for remote die memory access in Chiplet architecture.

[0040] For each pair of device identifiers, the device identifier is used to characterize the device type and characteristics of that device. The device type refers to the functional role of the device in the on-chip system, such as a Central Processing Unit (CPU), Direct Memory Access Controller (DMA), Graphics Processing Unit (GPU), Artificial Intelligence Accelerator (NPU), etc. The device characteristics include, but are not limited to: interface protocol type (such as AXI4, AHB-Lite), communication bandwidth capability, maximum transmission latency, supported packet size, power domain affiliation, clock frequency range, address space distribution, etc.

[0041] Based on the device type and characteristics of any given device, a device identifier is pre-configured for each device. For example, the device type and characteristics can be directly encoded into the device identifier; for instance, SDMA_0_AXI4_BW12G represents an AXI4 interface SDMA controller with a bandwidth of 12GB / s. Alternatively, a concise number can be used to name the device identifier, such as MST00_0 representing the 0th interface of the 0th master device. The system pre-configures a device registry, establishing a mapping relationship between each device identifier and its device type (e.g., SDMA, SPC_M, D2D, etc.) and device characteristics (e.g., interface protocol AXI4, bandwidth 12GB / s, maximum latency 50ns, etc.).

[0042] In practice, after predefining the device identifiers of each master device and each slave device, test cases can be obtained in the following ways: manually created by verification engineers through the configuration interface; generated by automated test generation tools based on SoC architecture information; or dynamically generated by the coverage analysis system based on uncovered paths. Each test case includes multiple pairs of device identifiers, each pair consisting of a master device identifier and a slave device identifier, representing a "master device → slave device" communication path to be verified.

[0043] For example, the content of test case A is shown in Table 1: Table 1

[0044] As shown in Table 1 above: Test case A indicates that the access of the stream processor cluster to HBM, the system DMA to PCIe, and the inter-die interconnect to remote memory need to be verified simultaneously.

[0045] In practice, the number of device identifier pairs in each test case can be determined based on simulation resources and simulation time, and this application does not impose any restrictions on this.

[0046] In step 202, based on the device identifier of the master device in each pair of device identifiers, a first set of excitation constraints matching the master device is selected from the master device constraint set, and based on the device identifier of the slave device in each pair of device identifiers, a second set of excitation constraints matching the slave device is selected from the slave device constraint set.

[0047] Among them, incentive constraints refer to a set of pre-configured rules used to limit the range of test incentive generation so that it conforms to the interface protocol, performance capabilities, functional characteristics and system environment requirements of a specific hardware module.

[0048] In practical implementation, the incentive constraint set of the master device may include request type (such as read operation, write operation), request size (such as 4 bytes, 8 bytes), request length (such as 256 times), address type (such as physical address, virtual address), user signals (user-defined additional information, such as security attributes, thread ID, QoS level), etc.; the incentive constraint set of the slave device may include address range (such as 0x8000_0000 ~ 0x8FFF_FFFF), maximum supported latency (such as response time ≤ 50ns), bypass control signals, cache control signals, etc.

[0049] In practice, an incentive constraint mapping table corresponding to each master device identifier can be maintained in advance, and then the first incentive constraint set corresponding to the master device identifier can be found in the mapping table. Similarly, an incentive constraint set mapping table corresponding to each slave device identifier can be maintained in advance, and then the second incentive constraint set corresponding to the slave device identifier can be found in the mapping table.

[0050] For example, the contents of the master device incentive constraint mapping table are {(master device 1: incentive constraint 1, incentive constraint 2, incentive constraint 3); (master device 2: incentive constraint 4, incentive constraint 5, incentive constraint 6); (master device 3: incentive constraint 7, incentive constraint 8, incentive constraint 9)...}. Assuming that the device identifier of the master device is 1, then the first incentive constraint set found is (incentive constraint 1, incentive constraint 2, incentive constraint 3).

[0051] For example, if the contents of the device incentive constraint mapping table are {(device 1: incentive constraint 11, incentive constraint 21, incentive constraint 31); (device 2: incentive constraint 41, incentive constraint 51, incentive constraint 61); (device 3: incentive constraint 71, incentive constraint 81, incentive constraint 91)...}, and assuming the device identifier of the device is 2, then the second incentive constraint set found is (incentive constraint 41, incentive constraint 51, incentive constraint 61).

[0052] In practice, for each device, based on the device type and characteristics represented in the device identifier, an incentive constraint set that matches the device characteristics of any device can be selected from the device constraint set corresponding to the device type of any device.

[0053] For example, a library of device incentive and constraint templates can be maintained in advance, where multiple constraint templates are organized according to device type (such as stream processor cluster SPC_M, high bandwidth memory HBM). Each template contains multiple predefined incentive and constraint configurations, each corresponding to different combinations of device characteristics.

[0054] The equipment constraint set template library can be shown in Table 2: Table 2

[0055] When a device identifier of a master device is obtained (e.g., "SPC_M_0_AXI5_BW16G"), the system first parses out its device type (SPC_M) and device characteristics (interface protocol is AXI5, bandwidth is 16GB / s); then, based on the device type, it loads the corresponding master device constraint set (set 1 and set 2) from the device constraint set template library; then, in set 1 and set 2, it filters out the configuration items that match the device characteristics, that is, set 2 is used as the first excitation constraint set of the master device.

[0056] Similarly, for a slave device identifier (such as "HBM_0_AXI4_LAT35ns"), the system parses its device type (HBM) and characteristics (protocol AXI4, maximum delay 35ns). Then, based on the device type, it loads the corresponding slave device constraint set (set 11 and set 21) from the device constraint set template library. Based on the device characteristics, it filters from set 11 and set 21 those that conform to protocol AXI4 and have a maximum delay of less than or equal to 35ns, thus using set 21 as the second excitation constraint set for the slave device.

[0057] In this way, this application achieves dynamic and refined matching of incentive constraints, eliminating the need to configure constraints separately for each device instance, thus improving the scalability and automation of the system.

[0058] In step 203, test stimuli are generated based on the first set of stimuli constraints and the second set of stimuli constraints corresponding to each pair of device identifiers. The test stimuli are used to test the communication path from a master device to a slave device.

[0059] Among them, test stimulus refers to the simulation stimulus signal or transaction-level data packet injected into the input terminal of the system under test during the communication path verification process. It is used to simulate communication behavior in real scenarios, trigger system response, and thus verify its functional correctness.

[0060] In practical implementation, the first incentive constraint set corresponding to the master device is used to constrain the response rules of the master device, while the second incentive constraint set corresponding to the slave device is used to constrain the application rules of the slave device. To further enhance system-level policy control, this application also sets a general incentive constraint set. The general incentive constraint set is a set of preset system-level rules applicable to all communication paths between master and slave devices, including but not limited to the constraint sets of master devices, slave devices, and system-level constraint sets (such as illegal address ranges, maximum number of concurrent master devices, global timeout thresholds, data integrity verification enable flags, power domain access rules, etc.). The general incentive constraint set is used to ensure that all communication behaviors comply with the overall SoC operating environment, security policies, and verification objectives, avoiding the generation of test stimuli that may be "syntactically correct but semantically incorrect," leading to false alarms, false negatives, simulation crashes, or security vulnerabilities.

[0061] Therefore, the first set of incentive constraints, the second set of incentive constraints, and the preset general set of incentive constraints can be merged to obtain the effective set of incentive constraints; then, the incentive generation function is called according to the effective set of incentive constraints to generate test incentives.

[0062] In practice, the process of merging the first set of incentive constraints, the second set of incentive constraints, and the preset general set of incentive constraints is not a simple splicing, but a constraint fusion process with clear rules, execution, and verifiability. Since the general set of incentive constraints includes, but is not limited to, the constraint sets of master devices, slave devices, and system-level constraint sets, and can be set differently based on the device types of master and slave devices (e.g., a master device of device type 1 and a slave device of device type 2 correspond to general set of incentive constraints 1, a master device of device type 2 and a slave device of device type 3 correspond to general set of incentive constraints 2, etc.), during the merging process, each target incentive constraint in the first and second sets may conflict with the incentive constraints in the general set of incentive constraints. For example, when the first set of incentive constraints and the general set of incentive constraints impose incompatible and unsatisfactory requirements on the same resource (such as address space), a "constraint conflict" occurs. For instance, the address range in the first set of incentive constraints is... The address range is "0x7000_0000~0x9FFF_FFFF", while the address range in the general excitation constraint set is "0x8000_0000~0x8FFF_FFFF", meaning that there is a conflict between the effective address of the master device and the effective address of the system.

[0063] In this situation, the effective incentive constraints can be determined according to the following steps.

[0064] Step 1: For each target incentive constraint in the first incentive constraint set and the second incentive constraint set, if there is a general incentive constraint in the general incentive constraint set that has the same constraint type as the target incentive constraint, then perform constraint conflict analysis on the constraint content of the equipment incentive constraint and the general incentive constraint.

[0065] For example: the target incentive constraint is interface protocol: AXI5, and there is a general incentive constraint in the general incentive constraint set that has the same constraint type (interface protocol) as the target incentive constraint: interface protocol: AXI4.

[0066] For example: the target stimulus constraint is in the address range of 0x7000_0000 ~ 0xFFFF_FFFF, and there is a general stimulus constraint in the general stimulus constraint set with the same constraint type (address range) as the target stimulus constraint: address range of 0x8000_0000 ~ 0x8FFF_FFFF.

[0067] Step 2: Based on the conflict analysis results, determine the effective incentive constraints among the target incentive constraints and general incentive constraints.

[0068] In practice, if the conflict analysis result is that there is no conflict, then both the target incentive constraint and the general incentive constraint are determined to be effective incentive constraints. Here, no conflict means that the target incentive constraint and the general incentive constraint can simultaneously satisfy the requirements of the same constraint type, and the merged constraint set is not empty, legal, and executable.

[0069] For example, if the target incentive constraint has an interface protocol of AXI5, and there is a general incentive constraint with the same constraint type (interface protocol) as the target incentive constraint in the general incentive constraint set: interface protocol of AXI4, then if the system topology supports protocol downgrading or protocol conversion between the AXI5 master device and the AXI4 slave device, it is determined to be conflict-free; at this time, both the target incentive constraint interface protocol of AXI5 and the general incentive constraint interface protocol of AXI4 are effective incentive constraints.

[0070] In practice, if the conflict analysis results show that there is a conflict, then the decision incentive constraint is determined based on the objective incentive constraint and the general incentive constraint, and the decision incentive constraint is determined as the effective incentive constraint.

[0071] In practical implementation, the constraint strengths of the target incentive constraints and general incentive constraints can be obtained. The constraint strength includes mandatory constraints and suggested constraints. Mandatory constraints are system-level rules that must be met, while suggested constraints are optimization objectives that are recommended to be met. For example, mandatory constraints may include prohibiting access to illegal addresses, requiring ECC to be enabled, and ensuring protocol version compatibility; suggested constraints may include burst length, QoS range, and maximum concurrency. If the constraint strengths of the target incentive constraints and general incentive constraints are different, the incentive constraint with a mandatory constraint strength among the target incentive constraints and general incentive constraints is determined as the decision incentive constraint.

[0072] For example, if the target incentive constraint has an interface protocol of AXI5, and there is a general incentive constraint in the general incentive constraint set with the same constraint type (interface protocol) as the target incentive constraint (interface protocol: AXI3), then if AXI5 and AXI3 are incompatible, then the conflict analysis result will be that there is a conflict.

[0073] At this point, assuming that the interface protocol in the target incentive constraint is a mandatory constraint and the interface protocol in the general incentive constraint set is a suggested constraint, then the interface protocol AXI5 in the target incentive constraint can be determined as the decision incentive constraint.

[0074] In practice, if both the target incentive constraint and the general incentive constraint are mandatory constraints, then the constraint merging is determined to have failed and an alarm message is generated. For example, if the target stimulus constraint is an address range of 0x1000_0000~0x1FFF_FFFF and is a mandatory constraint, and the general stimulus constraint is an address range of 0x8000_0000~0x8FFF_FFFF and is also a mandatory constraint, then constraint merging will fail and an alarm message will be generated.

[0075] If both the target incentive constraint and the general incentive constraint have the strength of suggestion constraints, then the target incentive constraint and the general incentive constraint will be merged, and the merged incentive constraint will be determined as the decision incentive constraint.

[0076] For example, if the target incentive constraint is a QoS range of [0, 15] and is a suggestion constraint, and the general incentive constraint is a QoS range of [0, 7] and is also a suggestion constraint, then the target incentive constraint and the general incentive constraint are merged. For example, the intersection of the two is taken as [0, 7], and the merged incentive constraint [0, 7] is determined as the decision incentive constraint.

[0077] For example, if the target incentive constraint is a QoS range of [0, 7] and is a suggestion constraint, and the general incentive constraint is a QoS range of [8, 15] and is also a suggestion constraint, then the target incentive constraint and the general incentive constraint are merged. Since there is no intersection, the default value can be taken, such as determining QoS=0 as the decision incentive constraint.

[0078] In practice, assuming the set of effective incentive constraints is given, the incentive generation function can be called to generate test incentives. For example, the incentive generation function can be called to randomize each effective incentive constraint in the set of effective incentive constraints. The randomization process refers to assigning a definite value to the variable corresponding to all effective incentive constraints. For example, if the effective incentive constraint has a QoS range of [8, 15], then the QoS range obtained after randomization can be QoS=10.

[0079] This application obtains test cases, each consisting of multiple pairs of device identifiers. Each pair includes a master device identifier and a slave device identifier. Based on the master device identifier in each pair, a first set of incentive constraints matching the master device is selected from the master device constraint set. Similarly, based on the slave device identifier in each pair, a second set of incentive constraints matching the slave device is selected from the slave device constraint set. Test stimuli are generated based on the first and second incentive constraint sets corresponding to each pair of device identifiers. These test stimuli are used to test a communication path from one master device to one slave device. In contrast, traditional methods require developing M×N test cases to test the path in a system with M master devices and N slave devices. This application, however, uses multiple pairs of device identifiers in a single test case and generates multiple test stimuli by matching the incentive constraint sets of the master and slave devices in parallel. This allows a single test case to test multiple communication paths, significantly reducing the number of test cases.

[0080] The solutions of this application embodiment are described below with specific examples.

[0081] See Figure 3 , Figure 3 The system architecture diagram of a test incentive generation method provided in this application embodiment includes three parts: determining the communication path under test in each test case, determining the master device incentive constraints and slave device incentive constraints in each communication path under test, and merging the master device incentive constraints and slave device incentive constraints with the general incentive constraints to obtain the effective incentive constraints.

[0082] The following sections will provide a detailed introduction to these three parts.

[0083] Part 1: Identify the communication path to be tested in each test case.

[0084] First, analyze the number and characteristics of the master devices in the system under test, and define a string corresponding to each master's name to distinguish the access options of different masters. For example, use MST00_0 to represent the layer 0 interface of master 0. In this way, the target path to be tested can be identified by the string in the test case, and it can also be easily identified by the subsequent string parsing function. Following the naming method of the master devices, define a string corresponding to each slave device's name to distinguish the access options of different slaves; for example, SLV00_0 represents slave 0.

[0085] Then, based on simulation resources and simulation time, reasonably allocate the number of Master-Slave access paths for each test case, such as 10 or 12.

[0086] Finally, under different test cases, add the following simulation parameters: Master path selection, Slave path selection; and support passing in multiple Master and multiple Slave paths; where multiple Master / Slave strings can be separated by a delimiter, such as ".".

[0087] For example, the system under test has 4 Masters and 4 Slaves. The Masters are the zeroth, first, second and third layers of the SPC, and the Slaves are l2c0, l2c1, l2c2 and l2c3, respectively. Each Master can access each Slave.

[0088] First, based on the device type and characteristics of the Master and Slave, each Master and Slave can be named as follows: Master: SPC00_0, SPC00_1, SPC00_2, SPC00_3; Slave: L2000_0, L2000_1, L2000_2, L2000_3.

[0089] Then, assuming that based on simulation resources and simulation time, each test case can test 4 communication paths.

[0090] Test case 1 can then be as follows: “test1” “+ Master _name=” “SPC00_0.SPC00_0.SPC00_1.SPC00_1” “+ Slave _name=” “L2000_0.L2000_1.L2000_2.L2000_3” Since the device identifiers in the test cases appear in pairs, test1 is used to test the four communication paths: SPC00_0 to L2000_0, SPC00_0 to L2000_1, SPC00_1 to L2000_2, and SPC00_1 to L2000_3.

[0091] Part Two: Determine the master device excitation constraints and slave device excitation constraints in each communication path under test.

[0092] First, `test1` is obtained. Then, the base test module (which executes the actual stimulus generation module) calls the parse function to parse the communication path under test in `test1`. After parsing, the data can be stored in the corresponding Master and Slave queues. Optionally, `base test` can be written in a system-level verification language or System Verilog (SV).

[0093] For example, the Master queue is: SPC00_0 SPC00_0 SPC00_1 SPC00_1; The Slave queues are: L2000_0 L2000_1 L2000_2 L2000_3; Then, based on the Master queue and Slave queue, each Master in the Master queue and each Slave in the Slave queue are traversed to determine the communication paths to be tested, namely, SPC00_0 to L2000_0, SPC00_0 to L2000_1, SPC00_1 to L2000_2, and SPC00_1 to L2000_3. For each communication path, basetest selects the excitation constraint sequence constraint matching the identifier of each Master (first excitation constraint set) from the pre-set master constraint set (mst select) and the excitation constraint sequence constraint matching the identifier of each Slave (second excitation constraint set) from the pre-set slave constraint set (slv select), and passes the selected constraints to the base sequence.

[0094] The first set of incentive constraints may include, for example, some or all of the following: request type, request size, request length, address type, and user signals; the second set of incentive constraints may include, for example, some or all of the following: address range, maximum supported latency, bypass control signals, and cache control signals.

[0095] Part Three: Merge the master device incentive constraints (first incentive constraint set) and slave device incentive constraints (second incentive constraint set) with the common sequence (common incentive constraints) to obtain the effective incentive constraints.

[0096] For example, the first set of incentive constraints is {Incentive Constraint 1, Incentive Constraint 2, Incentive Constraint 3}, the second set of incentive constraints is {Incentive Constraint 4, Incentive Constraint 5, Incentive Constraint 6}, and the general set of incentive constraints is a set of preset system-level rules applicable to all communication paths between master and slave devices, including but not limited to the constraint sets of master devices, the constraint sets of slave devices, and system-level constraint sets (such as illegal address range, maximum number of concurrent master devices, global timeout threshold, data integrity verification enable flag, power domain access rules, etc.). For example, the general set of incentive constraints is {Incentive Constraint 6, Incentive Constraint 7, Incentive Constraint 8}. The base sequence calls the incentive generation function to generate test incentives based on the effective set of incentive constraints (the first set of incentive constraints and the second set of incentive constraints) and the general set of incentive constraints.

[0097] Optionally, applying the first and second sets of incentive constraints to a unified universal set of incentive constraints can be achieved through the constraint application mechanism in the Universal Verification Methodology (UVM), including using the apply_constraints() function or the uvm_do_with macro. Furthermore, the above test stimulus generation method can be executed in the UVM verification environment, where the base sequence is a basic sequence, such as a UVM sequence.

[0098] Specifically, each incentive constraint can be randomized. If there are conflicts between the incentive constraints inherent in the first set of incentive constraints, the second set of incentive constraints, and the general set of incentive constraints, randomization may fail. Therefore, incentive constraints that may cause conflicts can be set as suggested constraints (soft constraints). In this way, when merging, if conflicts exist, the soft constraints will be overridden by the higher-priority mandatory constraints (hard constraints). Finally, the test incentives are sent to the system under test.

[0099] This application, by maintaining a set of incentive constraints corresponding to master and slave device identifiers, can quickly obtain incentive constraints for different combinations of master and slave devices, and then combine them with pre-defined general incentive constraints to generate target test incentives for testing communication paths. This method only requires changing the configuration or constraints in the test cases to quickly generate new test incentives, improving the efficiency of test preparation and the flexibility of test scenarios.

[0100] Meanwhile, this application establishes a hierarchical testing architecture by combining parameterized configuration information, modular constraint sets, and general incentive constraints. When the system topology or device behavior changes, only the configuration information needs to be updated or the corresponding constraint set needs to be modified, transforming maintenance work from complex code-level modifications to simple configuration-level adjustments, significantly reducing maintenance costs and related error risks.

[0101] In addition, the general incentive constraints in this application are independent of specific system topologies and have strong reusability; at the same time, the constraint sets of master and slave devices adopt a modular design, which can also be ported and reused in different projects.

[0102] Figure 4 A schematic diagram of a test stimulus generation device provided in this application embodiment includes: The acquisition module 401 is used to acquire test cases, wherein the test cases include multiple pairs of device identifiers, and each pair of device identifiers includes a device identifier of a master device and a device identifier of a slave device. Selection module 402 is used to select a first set of incentive constraints that matches the master device from the master device constraint set according to the master device device identifier in each pair of device identifiers, and to select a second set of incentive constraints that matches the slave device from the slave device constraint set according to the slave device device identifier in each pair of device identifiers; The generation module 403 is used to generate test incentives based on the first incentive constraint set and the second incentive constraint set corresponding to each pair of device identifiers. The test incentives are used to test the communication path from a master device to a slave device.

[0103] In some embodiments, for any device in each pair of device identifiers, the device identifier is used to characterize the device type and device characteristics of that device; The selection module 402 is specifically used to determine the set of excitation constraints that match any of the devices according to the following steps: From the set of device constraints corresponding to the device type of any device, select a set of incentive constraints that matches the device characteristics of any device.

[0104] In some embodiments, the generation module 403 is specifically used for: The first set of incentive constraints, the second set of incentive constraints, and the preset set of general incentive constraints are merged to obtain the effective set of incentive constraints. Based on the set of effective incentive constraints, the incentive generation function is invoked to generate the test incentives.

[0105] In some embodiments, it also includes: The analysis module 404 is used to perform constraint conflict analysis on the constraint content of the device incentive constraint and the general incentive constraint for each target incentive constraint in the first incentive constraint set and the second incentive constraint set, if there is a general incentive constraint in the general incentive constraint set with the same constraint type as the target incentive constraint. Based on the conflict analysis results, determine the effective incentive constraints among the target incentive constraints and the general incentive constraints.

[0106] In some embodiments, the analysis module 404 is specifically used for: If the conflict analysis result is that there is no conflict, then both the target incentive constraint and the general incentive constraint are determined to be effective incentive constraints. If the conflict analysis results indicate that a conflict exists, then based on the target incentive constraint and the general incentive constraint, a decision incentive constraint is determined, and the decision incentive constraint is identified as an effective incentive constraint.

[0107] In some embodiments, the analysis module 404 is specifically used for: Obtain the constraint strength of the target incentive constraint and the general incentive constraint, wherein the constraint strength includes mandatory constraints and suggested constraints; If the target incentive constraint and the general incentive constraint have different constraint strengths, then the incentive constraint with a mandatory constraint strength among the target incentive constraint and the general incentive constraint shall be determined as the decision incentive constraint. If both the target incentive constraint and the general incentive constraint are mandatory constraints, then the constraint merging is determined to have failed, and an alarm message is generated. If the constraint strength of both the target incentive constraint and the general incentive constraint is a suggestion constraint, then the target incentive constraint and the general incentive constraint are merged, and the merged incentive constraint is determined as the decision incentive constraint.

[0108] The module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, other division methods are possible. Furthermore, the functional modules in each embodiment of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. Coupling between modules can be achieved through interfaces, typically electrical communication interfaces, but mechanical interfaces or other types of interfaces are also possible. Therefore, modules described as separate components may or may not be physically separate; they can be located in one place or distributed across different locations on the same or different devices. The integrated modules described above can be implemented in hardware or as software functional modules.

[0109] Having introduced the test stimulus generation method and apparatus according to exemplary embodiments of this application, we will now introduce an electronic device according to another exemplary embodiment of this application.

[0110] The following reference Figure 5 To describe an electronic device 130 implemented according to this embodiment of the present application. Figure 5 The electronic device 130 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0111] like Figure 5 As shown, the electronic device 130 is presented in the form of a general electronic device. The components of the electronic device 130 may include, but are not limited to: at least one processor 131, at least one memory 132, and a bus 133 connecting different system components (including memory 132 and processor 131).

[0112] Bus 133 represents one or more of several bus structures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus structures.

[0113] The memory 132 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 1321 and / or cache memory 1322, and may further include read-only memory (ROM) 1323.

[0114] The memory 132 may also include a program / utility 1325 having a set (at least one) of program modules 1324, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0115] Electronic device 130 can also communicate with one or more external devices 134 (e.g., keyboard, pointing device, etc.), and with one or more devices that enable a user to interact with electronic device 130, and / or with any device that enables electronic device 130 to communicate with one or more other electronic devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 135. Furthermore, electronic device 130 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 136. As shown, network adapter 136 communicates with other modules used in electronic device 130 via bus 133. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0116] In an exemplary embodiment, the electronic device of this application may include at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores a computer program executable by the at least one processor, and when the computer program is executed by the at least one processor, it enables the at least one processor to perform the steps of any test stimulus generation method provided in the embodiments of this application.

[0117] In an exemplary embodiment, a storage medium is also provided, which, when executed by a processor of an electronic device, enables the electronic device to perform any of the test stimulus generation methods described above. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0118] In an exemplary embodiment, a computer program product is also provided, which implements any of the test stimulus generation methods provided in this application when the computer program is executed by a processor.

[0119] It should be noted that although several modules or sub-modules of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more modules described above can be embodied in one module. Conversely, the features and functions of one module described above can be further divided and embodied by multiple modules.

[0120] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0121] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0122] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0123] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, then this application also includes such modifications and variations.

Claims

1. A test stimulus generation method, characterized by, The method comprises the following steps: acquiring test cases, the test cases comprising a plurality of pairs of device identifiers, each pair of device identifiers comprising a device identifier of a master device and a device identifier of a slave device; selecting, according to the device identifier of the master device in each pair of device identifiers, a first set of excitation constraints matched with the master device from a set of master device constraints, and selecting, according to the device identifier of the slave device in each pair of device identifiers, a second set of excitation constraints matched with the slave device from a set of slave device constraints; generating, according to the first set of excitation constraints and the second set of excitation constraints corresponding to each pair of device identifiers, a test excitation used for testing a communication path from a master device to a slave device.

2. The method of claim 1, wherein, For a device identifier of any device in each pair of device identifiers, the device identifier is used to represent a device type and a device feature of the any device, and a set of excitation constraints matched with the any device is determined according to the following steps: selecting, from a set of device constraints corresponding to the device type of the any device, a set of excitation constraints matched with the device feature of the any device.

3. The method of claim 1, wherein, The step of generating, according to the first set of excitation constraints and the second set of excitation constraints corresponding to each pair of device identifiers, a test excitation comprises the following steps: merging the first set of excitation constraints, the second set of excitation constraints, and a preset universal set of excitation constraints to obtain an effective set of excitation constraints; calling an excitation generation function according to the effective set of excitation constraints to generate the test excitation.

4. The method of claim 3, wherein, The method further comprises the following steps: For each target excitation constraint in the first set of excitation constraints and the second set of excitation constraints, if the universal set of excitation constraints has a universal excitation constraint of the same constraint type as the target excitation constraint, performing constraint conflict analysis on constraint contents of the target excitation constraint and the universal excitation constraint; determining, according to a conflict analysis result, an effective excitation constraint from the target excitation constraint and the universal excitation constraint.

5. The method of claim 4, wherein, The step of determining, according to a conflict analysis result, an effective excitation constraint from the target excitation constraint and the universal excitation constraint comprises the following steps: if the conflict analysis result is no conflict, determining that both the target excitation constraint and the universal excitation constraint are effective excitation constraints; if the conflict analysis result is conflict, determining a decision excitation constraint based on the target excitation constraint and the universal excitation constraint, and determining the decision excitation constraint as the effective excitation constraint.

6. The method of claim 5, wherein, The step of determining a decision excitation constraint based on the target excitation constraint and the universal excitation constraint comprises the following steps: acquiring constraint strengths of the target excitation constraint and the universal excitation constraint, wherein the constraint strengths comprise mandatory constraints and suggested constraints; if the constraint strengths of the target excitation constraint and the universal excitation constraint are different, determining, as the decision excitation constraint, an excitation constraint with a mandatory constraint strength from the target excitation constraint and the universal excitation constraint; if the constraint strengths of the target excitation constraint and the universal excitation constraint are both mandatory constraints, determining constraint merging failure and generating an alarm information; If the constraint strength of the target incentive constraint and the constraint strength of the general incentive constraint are both suggested constraints, the target incentive constraint is fused with the general incentive constraint, and the fused incentive constraint is determined as a decision incentive constraint.

7. A test stimulus generation apparatus, characterized by, The method comprises the steps of: An acquisition module is configured to acquire a test case, the test case comprising a plurality of pairs of device identifiers, each pair of device identifiers comprising a device identifier of a master device and a device identifier of a slave device; A selection module is configured to select, according to the device identifier of the master device in each pair of device identifiers, a first set of incentive constraints matched with the master device from a master device constraint set, and select, according to the device identifier of the slave device in each pair of device identifiers, a second set of incentive constraints matched with the slave device from a slave device constraint set; A generation module is configured to generate, according to the first set of incentive constraints and the second set of incentive constraints corresponding to each pair of device identifiers, a test incentive, the test incentive being used to test a communication path from a master device to a slave device.

8. An electronic device, comprising: The method comprises the steps of: At least one processor, and a memory connected with the at least one processor in communication, wherein: The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A storage medium, characterized by When the computer program in the storage medium is executed by the processor of the electronic device, the electronic device can perform the method of any one of claims 1-6.

10. A computer program product, characterised in that, The computer program is executed by the processor to implement the method of any one of claims 1-6.

Images