An interrupt verification method, device, and equipment of a system on chip and a storage medium

Abstract

The application discloses a kind of interrupt verification method, device, equipment and storage medium of system on chip, comprising: obtaining the global topology description information of system on chip, global topology description information is analyzed, and structured information configuration file is obtained;Information configuration file is input into configuration template engine, and verification file associated with interrupt verification is generated by configuration template engine, and verification environment is constructed according to verification file;According to the configuration interrupt source of verification environment, and the excitation signal of the interrupt source configured is applied to the interrupt trigger port corresponding to source IP module, then the message data of target IP module is collected;Message data is compared with pre-set standard data, and the interrupt verification result corresponding to system on chip is determined according to comparison result.The technical scheme of the embodiment of the application can improve the interrupt verification efficiency of system on chip and the accuracy of verification result.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an interrupt verification method, apparatus, device, and storage medium for a system-on-a-chip. Background Technology

[0002] Currently, System-on-Chip (SOC) chips typically integrate a large number of functional modules, which communicate and collaborate with each other through interrupt mechanisms. As SOC scales up, the number of interrupt sources increases significantly, interrupt types and routing relationships become increasingly complex, and the complexity of interrupt verification rises dramatically.

[0003] Existing technologies for interrupt verification of SOC chips primarily rely on manually writing test cases. Due to the massive scale of verification scenarios, numerous parameter combinations, and the exponentially increasing relationships between different interrupt types, interrupt source modules, and interrupt target modules, manually constructing verification scenarios is inefficient and struggles to systematically cover all combinations, impacting the completeness and reliability of the verification. Furthermore, the sheer volume of verification cases in regression scenarios can strain limited machine resources, affecting overall verification efficiency. Additionally, the verification scenarios involve numerous signal paths and a wide range of files, requiring significant manual maintenance of related signal paths and configuration files, resulting in poor portability of the verification method across different platforms. Summary of the Invention

[0004] This invention provides an interrupt verification method, apparatus, device, and storage medium for a system-on-a-chip (SoC), which can improve the efficiency of interrupt verification and the accuracy of verification results.

[0005] According to one aspect of the present invention, an interrupt verification method for an on-chip system is provided, comprising: Obtain the global topology description information of the on-chip system, parse the global topology description information, and obtain a structured information configuration file; The information configuration file is input into the configuration template engine, which generates a verification file associated with the interruption verification and builds a verification environment based on the verification file. Configure the interrupt source according to the verification environment, apply the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source intellectual property (IP) module, and then collect the message data of the target IP module; The message data is compared with preset standard data, and the interrupt verification result corresponding to the on-chip system is determined based on the comparison result.

[0006] According to another aspect of the present invention, an interrupt verification apparatus for a system-on-a-chip is provided, comprising: The information acquisition module is used to acquire the global topology description information of the on-chip system, parse the global topology description information, and obtain a structured information configuration file. The environment building module is used to input the information configuration file into the configuration template engine, generate the verification file associated with the interruption verification through the configuration template engine, and build the verification environment based on the verification file. The excitation application module is used to configure an interrupt source according to the verification environment, apply the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source IP module, and then collect message data from the target IP module. The result comparison module is used to compare the message data with preset standard data and determine the interrupt verification result of the on-chip system based on the comparison result.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: 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, which enables the at least one processor to perform the interrupt verification method for a system-on-a-chip according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the interrupt verification method of the on-chip system according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the interrupt verification method for a system-on-a-chip according to any embodiment of the present invention.

[0010] The technical solution provided by this invention obtains the global topology description information of the on-chip system, parses the global topology description information to obtain a structured information configuration file, inputs the information configuration file into a configuration template engine, generates an interrupt verification-related verification file through the configuration template engine, constructs a verification environment based on the verification file, configures interrupt sources according to the verification environment, applies the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source IP module, and then collects message data from the target IP module, compares the message data with preset standard data, and determines the interrupt verification result corresponding to the on-chip system based on the comparison result. Compared with the existing technology that relies on manually writing test cases one by one, manually maintaining signal paths, and manually analyzing verification results, this method can automatically generate the verification file required for interrupt verification, quickly build the verification environment, and eliminate the need for verification personnel to write verification logic separately for each IP module combination. This reduces the workload of manually maintaining related signal paths and configuration files, thereby improving the interrupt verification efficiency of the on-chip chip and the scalability of the verification method, and shortening the on-chip chip development cycle and regression preparation cycle.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0013] Figure 1 This is a flowchart of an interrupt verification method for a system-on-a-chip according to an embodiment of the present invention; Figure 2 This is a flowchart of another interrupt verification method for a system-on-a-chip according to an embodiment of the present invention; Figure 3a This is a flowchart of another interrupt verification method for a system-on-a-chip according to an embodiment of the present invention; Figure 3b This is a schematic diagram illustrating a scenario applicable to another interrupt verification method for a system-on-a-chip provided by an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an interrupt verification device for a system-on-a-chip according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device that implements the interrupt verification method of the system-on-chip according to an embodiment of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Figure 1 This is a flowchart illustrating an interrupt verification method for a system-on-a-chip (SoC) according to an embodiment of the present invention. This embodiment is applicable to interrupt verification of SoC chips. The method can be executed by an interrupt verification device for the SoC, which can be implemented in hardware and / or software and configured in an electronic device, such as... Figure 1 As shown, the method includes: Step 110: Obtain the global topology description information of the on-chip system, parse the global topology description information, and obtain a structured information configuration file.

[0017] In this embodiment, the global topology description information can be the description information corresponding to the IP modules in the on-chip system, such as the basic attribute information and topology connection information of the IP modules. After obtaining the global topology description information, it can be converted into structured data by a parsing engine, and a structured information configuration file can be generated according to the structured data and a preset standard file format.

[0018] Step 120: Input the information configuration file into the configuration template engine, generate the verification file associated with the interruption verification through the configuration template engine, and build the verification environment based on the verification file.

[0019] In this embodiment, the configuration template engine can pre-integrate generation templates corresponding to various verification files. After the above information configuration file is input into the configuration template engine, the verification files required for interruption verification can be automatically generated through the generation templates corresponding to various verification files in the configuration template engine, such as application programming interface (API) configuration files, test files, and test case sets.

[0020] Optionally, the configuration template engine can abstract key variables in interrupt verification into dimensions such as "interruption type, source IP group, target IP group, and reporting method," and combine and expand these dimensions to generate a set of verification scenarios covering different interruption paths and reporting modes. Specifically, the configuration template engine can read the corresponding source IP group and target IP group based on the interrupt verification type and interrupt reporting method, and expand them using a Cartesian product to generate a set of verification scenarios in the form of "interruption type × source IP group × target IP group × reporting method." After the set of verification scenarios is determined, API configuration files, test files, test lists, and test case sets are automatically generated through template filling, thus forming a complete automated verification scenario matrix.

[0021] In one embodiment of this example, within a single verification scenario, the configuration template engine can traverse the Cartesian product of the source IP list and the target IP list within the group, and automatically eliminate unsupported combination scenarios, such as scenarios where the source IP and target IP are the same, scenarios where a certain IP does not support the specified interrupt type, and scenarios where the specified reporting method is not supported.

[0022] For example, if the information configuration file defines error interrupt verification using source IP group SRC_IP={IPa, IPb} and target IP group DES_IP={IPm, IPn}, and simultaneously supports three reporting methods: traditional interrupt INTx, message signaled interrupts (MSI), and extended message signaled interrupts (MSIx), then the configuration template engine can automatically generate the following test cases: SRC_IP->ERROR INT->IPm->INTx; SRC_IP->ERROR INT->IPm->MSI; SRC_IP->ERROR INT->IPm->MSIx; SRC_IP->ERROR INT->IPn->INTx; SRC_IP->ERROR INT->IPn->MSI; SRC_IP->ERROR INT->IPn->MSIx.

[0023] If normal interrupts are only supported by IPA, then the following test cases are generated: IPa->NORMAL INT->IPm->INTx; IPa->NORMAL INT->IPm->MSI; IPa->NORMAL INT->IPm->MSIx; IPa->NORMAL INT->IPn->INTx; IPa->NORMAL INT->IPn->MSI; IPa->NORMAL INT->IPn->MSIx.

[0024] The advantage of this setup is that by generating a structured information configuration file and inputting it into the configuration template engine, a complete verification scenario matrix can be automatically generated. This ensures coverage while reducing the number of redundant verifications, thereby improving the efficiency of interrupted verification and reducing regression overhead.

[0025] Step 130: Configure the interrupt source according to the verification environment, apply the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source IP module, and then collect the message data of the target IP module.

[0026] Optionally, in this step, the source IP group and the target IP group can be polled according to the verification environment to generate an interrupt stimulus signal that meets the requirements. At the same time, standard data is automatically generated for the interrupt stimulus signal. Then, the interrupt source stimulus signal is applied to the interrupt trigger port corresponding to the source IP module. After receiving the interrupt source stimulus signal, the source IP module can route the interrupt stimulus signal to the corresponding target IP module. Finally, message data is collected from the cache unit corresponding to the target IP module.

[0027] Step 140: Compare the message data with the preset standard data, and determine the interrupt verification result corresponding to the on-chip system based on the comparison result.

[0028] In this step, the collected message data can be compared byte by byte with the preset standard data. Based on the comparison results, it can be determined whether the interruption and transmission between the source IP module and the target IP module are correct, and a final interruption verification report can be generated based on the judgment results.

[0029] The technical solution provided by this invention obtains the global topology description information of the on-chip system, parses the global topology description information to obtain a structured information configuration file, inputs the information configuration file into a configuration template engine, generates an interrupt verification-related verification file through the configuration template engine, constructs a verification environment based on the verification file, configures interrupt sources according to the verification environment, applies the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source IP module, and then collects message data from the target IP module, compares the message data with preset standard data, and determines the interrupt verification result corresponding to the on-chip system based on the comparison result. Compared with the existing technology that relies on manually writing test cases one by one, manually maintaining signal paths, and manually analyzing verification results, this method can automatically generate the verification file required for interrupt verification, quickly build the verification environment, and eliminate the need for verification personnel to write verification logic separately for each IP module combination. This reduces the workload of manually maintaining related signal paths and configuration files, thereby improving the interrupt verification efficiency of the on-chip chip and the scalability of the verification method, and shortening the on-chip chip development cycle and regression preparation cycle.

[0030] Figure 2 A flowchart of another interrupt verification method for a system-on-chip provided in an embodiment of the present invention is shown below. Figure 2 As shown, the method includes: Step 210: Obtain the IP attribute information and IP packet topology information of the on-chip system, and construct the IP attribute information database and IP packet topology database.

[0031] In this embodiment, the IP attribute information database stores the mapping relationship between each IP module name and its attribute information. The IP packet topology database stores the mapping relationship between IP packet names and each IP module name, as well as the mapping relationship between authentication types and IP packet names.

[0032] Specifically, for the source IP module, the IP attribute information database can be as shown in Table 1. The attribute information corresponding to the source IP module may include the base address, hierarchical subpath, excitation port, interrupt type, and interrupt reporting method, etc. For the target IP module, the IP attribute information database can be as shown in Table 2. The attribute information corresponding to the target IP module may include the base address, hierarchical subpath, and memory address used to receive interrupt messages, etc.

[0033] In addition, the IP attribute information database can predefine common hierarchical path information, such as the top-level common path of the verification platform, the package number and the chip number, so that the complete hardware hierarchical path can be automatically assembled later.

[0034] Table 1 Table 2 In this embodiment, the IP packet topology library stores the mapping relationship between IP packet names and the names of each IP module (as shown in Table 3), and the mapping relationship between authentication types and IP packet names (as shown in Table 4). Specifically, the number of IP packets and the number of IP modules within a group can be flexibly configured as needed.

[0035] Table 3 Table 4 Step 220: Parse the IP attribute information and IP packet topology information to obtain a structured information configuration file, and input the information configuration file into the configuration template engine.

[0036] Optionally, in this step, the IP attribute information can be parsed using the first parsing engine to obtain configuration items such as the name, base address, hierarchical subpath, excitation port, common path, interrupt type, and interrupt reporting method of each IP module, and these configuration items can be converted into a structured IP attribute configuration file. For example, the following structured configuration file can be generated for the source IP: src_ip_name -> {base_addr, path, intr_port, intr_type, report_mode,...}; The following structured configuration file is generated for the target IP module: des_ip_name -> {base_addr, path, mem_addr, ...}. At the same time, the public path information is organized into a unified configuration item for subsequent concatenation to form a complete instance access path, for example: { IPa { u_IPa_top.u_interrupt_send_module, IPa_BASE_ADDR, i_int_trigger_0~8, { Normal, Error}, { MSI, MSIx}; IPB { …} } { IPm { IPm_BASE_ADDR, u_IPm_top.u_interrupt_module, IPm_BUFFER_ADDR} IPn { …} } Common_path -> { tb_top.u_package_top_0.u_chip_top_0}. Then, the IP packet topology information is parsed by the second parsing engine. Based on the predefined interruption type and interruption reporting method, the interruption topology routing relationship between the source IP group and the target IP group is automatically established. The verification type, test case name and IP group expansion rules are associated to generate the corresponding information configuration file.

[0037] In one embodiment of this example, during the parsing of IP attribute information and IP packet topology information, a consistency check can also be performed on the parsing results, including at least one of the following: checking whether the IP module name exists in the attribute information database; checking whether the members listed in the IP group are valid; checking whether the combination between the verification type, interruption type, and reporting method is legal; and checking whether the mapping relationship between the source IP group and the target IP group meets preset rules. The advantage of this setting is that it ensures the correctness and executability of the subsequently automatically generated verification environment.

[0038] In this embodiment, the configuration template engine integrates API configuration templates, test file templates, and test case templates. The API configuration template contains general environment configuration information and reserves placeholders for variable parameters such as macro definitions, IP module names, IP module paths, and IP addresses. The test file template contains general configuration information for the test scenario and reserves placeholders for parameters such as source IP groups, target IP groups, and corresponding IP lists. The test case template contains test case configuration information and reserves placeholders for fields such as test type, test list, test file, and test case name.

[0039] In practical applications, multiple IP modules in a system-on-a-chip often have similar attributes in terms of interrupt behavior, reporting methods, or connection relationships. If an exhaustive approach of enumerating each IP module, each path, and each combination is used to construct verification scenarios, a large number of test cases with high repetition and similar verification value will be generated.

[0040] To this end, this embodiment groups multiple IP modules into source IP groups and target IP groups based on their functional attributes, interrupt type support capabilities, reporting method support capabilities, and routing relationships. During the test scenario generation phase, scenarios are preferentially expanded based on these groups, and controlled combination traversal is performed on specific source IP modules and target IP modules within each group. This avoids unnecessary exhaustive searching while ensuring coverage of key combinations. Simultaneously, by automatically identifying and eliminating invalid or unsupported scenarios, such as scenarios where the source and target IP modules are identical, scenarios that do not support specified interrupt types, and scenarios that do not support specified reporting methods, the number of verification scenarios can be significantly reduced, lowering the computational resources and runtime required for simulation regression.

[0041] Meanwhile, this embodiment parses IP attribute information and IP packet topology information to obtain a structured information configuration file, enabling the separation and management of on-chip system description information and verification execution logic. By extracting information such as IP module name, instance level path, register base address, interrupt routing relationship, and verification grouping rules from the verification code and centrally maintaining them in the configuration file, when the on-chip system adds a new IP module, modifies interrupt routing, adjusts the level path, adds a new interrupt type, or expands to a new reporting method, verification personnel only need to update the corresponding IP attribute information library and IP packet topology library to re-parse the configuration data and generate new verification scenarios, without requiring large-scale modifications to the existing verification code. This allows the interrupt verification method to quickly adapt to changes brought about by chip version evolution, architecture adjustments, and module expansion, reducing the maintenance cost of the verification method and improving the platform's reusability.

[0042] Step 230: Use the information configuration file to populate the API configuration template, test file template, and test case template respectively, to obtain the API configuration file, test file, and test case set associated with the interruption verification.

[0043] Step 240: Build a verification environment based on the API configuration file, test files, and test case set, and initialize the verification environment.

[0044] In this step, specifically during the initialization of the verification environment, the complete hardware hierarchy path, register configuration address, and interrupt delivery method of the corresponding IP module can be automatically obtained based on the attribute information of the source IP module. The global parameters of the interrupt management module are then initialized based on this information. The complete hardware hierarchy path is typically obtained by automatically concatenating a common path with local sub-paths of the source IP module.

[0045] For example, the common path tb_top.u_package_top_0.u_chip_top_0 and the sub-paths u_IPa_top.u_interrupt_send_module.i_int_trigger_0~8 of IPA can be concatenated to obtain the complete set of paths for each interrupt trigger port of IPA: IPa:path { tb_top.u_package_top_0.u_chip_top_0.u_IPa_top.u_interrupt_send_module.i_int_trigger_0, …, tb_top.u_package_top_0.u_chip_top_0.u_IPa_top.u_interrupt_ end_module.i_int_trigger_8}. In practical applications, for large-scale on-chip systems, the source IP module excitation port path, target IP module buffer path, register address and status signal path are usually numerous and deeply hierarchical. If they are maintained manually, configuration errors are likely to occur and it is not conducive to cross-project reuse.

[0046] This embodiment records information such as common paths, local IP sub-paths, port names, register base addresses, and buffer addresses in a unified configuration file. During the execution phase, it automatically completes path concatenation and target location. Specifically, it first reads the common path information, then concatenates it with the local sub-paths of the source IP module or target IP module to obtain the complete hardware-level path. Then, it combines the interrupt trigger port name or target buffer address to automatically locate the Register-Transfer Level (RTL) signal that needs to be driven or the storage area that needs to be observed. This can effectively reduce the risk of errors caused by manual path maintenance and improve the adaptability of the verification platform under different chip-level structures.

[0047] Step 250: Based on the verification environment, poll each IP module corresponding to the source IP packet and the target IP packet in the IP packet topology library. Configure the interrupt source parameters of the source IP module according to the polling results, and configure the cache address of the target IP module.

[0048] The interrupt source parameters include at least one of the following: interrupt source identifier, interrupt type, excitation port number, cache address of the target IP module, timestamp, interrupt message content, and interrupt delivery method.

[0049] Step 260: Apply the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source IP module, read the message data received by the target IP module according to the cache address of the target IP module, and compare the message data with the preset standard data item by item.

[0050] In this embodiment, for the configured interrupt source stimulus signal, the corresponding expected result data (i.e., the standard data) can be generated synchronously. For example, when the verification scenario is "IPa->Error Interrupt->IPm->MSI", the control registers of the IPa module and the IPm module can be configured, and the path can be automatically located: tb_top.u_package_top_0.u_chip_top_0.u_IPa_top.u_interrupt_send_module.i_int_trigger_5, Then, an interrupt source stimulus signal is injected into the interrupt trigger port corresponding to the IPA module to prepare to drive the IPA module to generate the corresponding type of interrupt event: Forcetb_top.u_package_top_0.u_chip_top_0.u_IPa_top.u_interrupt_send_module.i_int_trigger_5=Golden_value; The advantage of this setup is that by applying trigger values ​​conforming to preset rules to the excitation port of the source IP module, interrupt initiation behavior in a real hardware system can be simulated. The existing interrupt handling logic within the system under test (SUTP) can then be used to complete event identification, encoding, routing, and delivery, thereby verifying the correctness of the real interrupt chain. Specifically, after receiving the interrupt source excitation signal, the source IP module can identify, encode, route, and deliver the interrupt event according to its internal interrupt handling process, and transmit the interrupt message to the corresponding target IP module based on the current interrupt type and reporting method. Upon receiving the interrupt message, the target IP module can encapsulate and buffer the message, and write it to a preset circular buffer or message buffer. Furthermore, since the generation of the excitation signal's result data and the generation of the expected standard result are both based on the same scenario configuration, the final verification result is traceable.

[0051] After the interruption message is written to the buffer by the target IP module, the message data in the buffer can be read to obtain the actual result data to be compared. Optionally, the message data includes at least one of the following: interruption message content, status field, message identifier, and time data.

[0052] The advantage of this setup is that it can automatically extract the structured results received by the target IP module without requiring manual viewing of the on-chip system signal waveforms, thereby improving the interrupt verification efficiency of the on-chip system.

[0053] In one specific embodiment, the message data received by the target IP module can be compared field by field with preset standard data. This can verify not only whether the interruption has arrived, but also whether the interruption source, type, delivery method, message content, and write location are correct, thereby achieving integrity verification of the interruption behavior. Optionally, the field-by-field comparison includes at least one of the following: comparing whether the interruption type is consistent; comparing whether the interruption source identifier is consistent; comparing whether the interruption delivery method is consistent; comparing whether the interruption message content is consistent; comparing whether the interruption write target address or buffer location is consistent; and comparing whether other fields related to the protocol definition are consistent.

[0054] Step 270: Determine the interrupt verification result corresponding to the on-chip system based on the comparison results.

[0055] In this embodiment, if the message data received by the target IP module is consistent with the preset standard data, the current verification scenario can be marked as successful; if the message data is inconsistent with the preset standard data, it is determined that the on-chip system interrupt verification has failed, and the error information during the interrupt verification process is recorded. Based on the error information, an interrupt verification report corresponding to the on-chip system is generated.

[0056] Specifically, the error information may include a failure field, source IP module name, target IP module name, verification type, reporting method, actual result data and standard data, etc. The interrupted verification report may include the number of IP modules that were successfully verified, the number of IP modules that failed verification, the classification of failure reasons, and a detailed description of the verification scenario, etc.

[0057] The technical solution provided in this invention obtains IP attribute information and IP packet topology information of the on-chip system, constructs an IP attribute information library and an IP packet topology library, parses the IP attribute information and IP packet topology information to obtain a structured information configuration file, and inputs the information configuration file into a configuration template engine. Using the information configuration file, API configuration templates, test file templates, and test case templates are populated to obtain the API configuration file, test file, and test case set associated with interrupt verification. A verification environment is constructed based on the API configuration file, test file, and test case set, and the verification environment is initialized. Based on the verification environment, the source IP packets and target IP packets in the IP packet topology library are compared. The process involves polling each IP module corresponding to the P group, configuring the interrupt source parameters of the source IP module based on the polling results, configuring the cache address of the target IP module, applying the configured interrupt source stimulus signal to the interrupt trigger port corresponding to the source IP module, reading the message data received by the target IP module based on the cache address of the target IP module, and comparing the message data with preset standard data item by item. The technical method of determining the interrupt verification result of the on-chip system based on the comparison results can effectively improve the interrupt verification efficiency of large-scale on-chip systems, reduce the size of test cases, improve the coverage and completeness of verification scenarios, and enhance the maintainability, scalability, and adaptability of the verification platform to complex interrupt scenarios.

[0058] Based on the above implementation methods, in order to better explain the technical solution of this embodiment, the interrupt verification method of the on-chip system can be referred to as follows: Figure 3a The flowchart shown and as Figure 3b The illustrated scenario shows that the method includes the following steps: Obtain IP attribute information and IP packet topology information of the on-chip system, and construct an IP attribute information database and an IP packet topology database; The IP attribute information is parsed by the first parsing engine, and the IP packet topology information is parsed by the second parsing engine to obtain structured configuration data; Based on the structured configuration data, a test scenario matrix is ​​generated, including the interrupt topology routing relationship between the source IP group and the target IP group, the interrupt type, and the reporting method, etc. Based on the test scenario matrix, API configuration template, test file template, and test case template, generate the API configuration file, test file, and test case set associated with the interruption verification. Initialize the verification environment and configure the interrupt source parameters of the source IP module; The interrupt source excitation signal configured by the excitation generation module is applied to the interrupt trigger port corresponding to the source IP module, and the preset standard data corresponding to the interrupt source excitation signal is generated by the expected data generation module. The interrupt data is processed based on RTL, and the actual message data of the target IP module is collected through the data acquisition module. The standard data is compared with the actual message data by the data comparison module; a verification report is generated based on the comparison results by the result reporting module. If the results are consistent, the verification of the current source IP module and the target IP module is considered successful; if the results are inconsistent, the verification of the current source IP module and the target IP module is considered unsuccessful. The process of traversing and performing interrupted verification on other IP modules continues until the verification process for all IP modules is completed.

[0059] Figure 4 This is a schematic diagram of the structure of an interrupt verification device for a system-on-a-chip provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the device includes: an information acquisition module 310, an environment construction module 320, an excitation application module 330, and a result comparison module 340.

[0060] The information acquisition module 310 is used to acquire global topology description information of the on-chip system, parse the global topology description information, and obtain a structured information configuration file. The environment building module 320 is used to input the information configuration file into the configuration template engine, generate a verification file associated with the interruption verification through the configuration template engine, and build a verification environment based on the verification file. The excitation application module 330 is used to configure an interrupt source according to the verification environment, apply the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source IP module, and then collect message data from the target IP module. The result comparison module 340 is used to compare the message data with preset standard data and determine the interrupt verification result corresponding to the on-chip system based on the comparison result.

[0061] The technical solution provided by this invention obtains the global topology description information of the on-chip system, parses the global topology description information to obtain a structured information configuration file, inputs the information configuration file into a configuration template engine, generates an interrupt verification-related verification file through the configuration template engine, constructs a verification environment based on the verification file, configures interrupt sources according to the verification environment, applies the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source IP module, and then collects message data from the target IP module, compares the message data with preset standard data, and determines the interrupt verification result corresponding to the on-chip system based on the comparison result. Compared with the existing technology that relies on manually writing test cases one by one, manually maintaining signal paths, and manually analyzing verification results, this method can automatically generate the verification file required for interrupt verification, quickly build the verification environment, and eliminate the need for verification personnel to write verification logic separately for each IP module combination. This reduces the workload of manually maintaining related signal paths and configuration files, thereby improving the interrupt verification efficiency of the on-chip chip and the scalability of the verification method, and shortening the on-chip chip development cycle and regression preparation cycle.

[0062] Based on the above embodiments, the configuration template engine integrates application programming interface (API) configuration templates, test file templates, and test case templates.

[0063] The information acquisition module 310 includes: The IP information acquisition unit is used to acquire IP attribute information and IP packet topology information of the on-chip system, and to construct an IP attribute information database and an IP packet topology database. The IP attribute information database stores the mapping relationship between each IP module name and attribute information. The IP packet topology database stores the mapping relationship between IP packet names and each IP module name, as well as the mapping relationship between authentication type and IP packet name.

[0064] Environment building module 320 includes: The template filling unit is used to fill the API configuration template, test file template and test case template with the information configuration file to obtain the API configuration file, test file and test case set associated with the interruption verification. The environment initialization unit is used to build a verification environment based on the API configuration file, test file and test case set, and to initialize the verification environment.

[0065] The excitation application module 330 includes: The interrupt configuration unit is used to poll each IP module corresponding to the source IP packet and the target IP packet in the IP packet topology library according to the verification environment, configure the interrupt source parameters of the source IP module according to the polling results, and configure the cache address of the target IP module. The interrupt source parameters include at least one of the following: interrupt source identifier, interrupt type, excitation port number, cache address of the target IP module, timestamp, interrupt message content, and interrupt delivery method; The message reading unit is used to read message data received by the target IP module according to the cache address of the target IP module; the message data includes at least one of the following: interrupt message content, status field, message identifier, and time data.

[0066] The results comparison module 340 includes: The item-by-item comparison unit is used to compare the message data with preset standard data item by item; if the message data is inconsistent with the preset standard data, it is determined that the on-chip system interrupt verification has failed, and the error information in the interrupt verification process is recorded. Then, an interrupt verification report corresponding to the on-chip system is generated based on the error information.

[0067] The above-described apparatus can execute the methods provided in all the foregoing embodiments of the present invention, and has the corresponding functional modules and beneficial effects for executing the above methods. Technical details not described in detail in the embodiments of the present invention can be found in the methods provided in all the foregoing embodiments of the present invention.

[0068] Figure 5 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0069] like Figure 5As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) or a random access memory (RAM), communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 12 or loaded from the storage unit 18 into the random access memory 13. The random access memory 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, the read-only memory 12, and the random access memory 13 are interconnected via a bus 14. Input / output (I / O) interfaces are also connected to the bus 14.

[0070] Multiple components in electronic device 10 are connected to input / output interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0071] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processing (DSP) processors, and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the interrupt verification method of the system-on-chip.

[0072] In some embodiments, the system-on-chip interrupt verification method can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via read-only memory 12 and / or communication unit 19. When the computer program is loaded into random access memory 13 and executed by processor 11, one or more steps of the system-on-chip interrupt verification method described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the system-on-chip interrupt verification method by any other suitable means (e.g., by means of firmware).

[0073] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0074] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0075] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0076] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a cathode ray tube (CRT) or a liquid crystal display (LCD)) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0077] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0078] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) in terms of management difficulty and weak business scalability.

[0079] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0080] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An interrupt verification method for a system-on-a-chip, characterized in that, The method includes: Obtain the global topology description information of the on-chip system, parse the global topology description information, and obtain a structured information configuration file; The information configuration file is input into the configuration template engine, which generates a verification file associated with the interruption verification and builds a verification environment based on the verification file. Configure the interrupt source according to the verification environment, apply the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source intellectual property IP module, and then collect the message data of the target IP module; The message data is compared with preset standard data, and the interrupt verification result corresponding to the on-chip system is determined based on the comparison result.

2. The method according to claim 1, characterized in that, Obtain the global topology description information of the on-chip system, including: Obtain IP attribute information and IP packet topology information of the on-chip system, and construct an IP attribute information database and an IP packet topology database; The IP attribute information database stores the mapping relationship between each IP module name and attribute information; the IP packet topology database stores the mapping relationship between IP packet names and each IP module name, as well as the mapping relationship between authentication type and IP packet name.

3. The method according to claim 1, characterized in that, The configuration template engine integrates application programming interface (API) configuration templates, test file templates, and test case templates. The configuration template engine generates a verification file associated with the interrupted verification, including: Using the aforementioned information configuration file, the API configuration template, test file template, and test case template are populated respectively to obtain the API configuration file, test file, and test case set associated with the interruption verification.

4. The method according to claim 3, characterized in that, Constructing a verification environment based on the verification file includes: The verification environment is constructed based on the API configuration file, test files, and test case set, and the verification environment is initialized.

5. The method according to claim 2, characterized in that, Configure interrupt sources according to the verification environment, including: Based on the verification environment, each IP module corresponding to the source IP packet and the target IP packet in the IP packet topology library is polled in rounds. Based on the polling results, the interrupt source parameters of the source IP module are configured, and the cache address of the target IP module is configured. The interrupt source parameters include at least one of the following: interrupt source identifier, interrupt type, excitation port number, cache address of the target IP module, timestamp, interrupt message content, and interrupt delivery method.

6. The method according to claim 5, characterized in that, Collect message data from the target IP module and compare the message data with preset standard data, including: Based on the cache address of the target IP module, read the message data received by the target IP module, and compare the message data with preset standard data item by item; The message data includes at least one of the following: interruption message content, status field, message identifier, and time data.

7. The method according to claim 1, characterized in that, Based on the comparison results, the interrupt verification results corresponding to the on-chip system are determined, including: If the message data is inconsistent with the preset standard data, the on-chip system interrupt verification is determined to have failed, and the error information during the interrupt verification process is recorded. An interrupt verification report corresponding to the system-on-chip is generated based on the error information.

8. An interrupt verification device for a system-on-a-chip, characterized in that, The device includes: The information acquisition module is used to acquire the global topology description information of the on-chip system, parse the global topology description information, and obtain a structured information configuration file. The environment building module is used to input the information configuration file into the configuration template engine, generate the verification file associated with the interruption verification through the configuration template engine, and build the verification environment based on the verification file. The excitation application module is used to configure an interrupt source according to the verification environment, apply the configured interrupt source excitation signal to the interrupt trigger port corresponding to the source IP module, and then collect message data from the target IP module. The result comparison module is used to compare the message data with preset standard data and determine the interrupt verification result of the on-chip system based on the comparison result.

9. An electronic device, characterized in that, The electronic device includes: 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 the interrupt verification method of the system-on-chip according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the interrupt verification method of the system-on-chip according to any one of claims 1-7.

Images