Method and system for verifying a hole address

Abstract

The application discloses a verification method and system of a hollow address, relates to the technical field of data processing, and reversely deduces all unoccupied hollow address intervals in an address space by acquiring address boundary information of each register module, so that the verification content is expanded to an address decoding blind area. Meanwhile, the detection address is automatically selected based on the hollow address interval and a type label is marked, so that the generation of the detection point does not depend on manual calculation and hard coding. When the address mapping is changed, the boundary information only needs to be reacquired to automatically update, thereby avoiding the problems that manual maintenance is high in cost and is easy to be out of synchronization with the simulation mapping. Further, the detection address and the label are generated into a verification constant table and are subjected to differential verification according to the label type, so that batch detection of the read-write behavior of the hollow address is realized, and boundary omission caused by the manual listing mode is eliminated.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for verifying void addresses. Background Technology

[0002] During the integration and verification phase of a System-on-Chip (SOC) chip, multiple Intellectual Property (IP) modules are mapped to a unified address space. Between the address decoding ranges of each module are address regions that are not declared by any slave device and do not correspond to any valid register read / write operations—these are known as "hole addresses." Verifying the read / write behavior of these hole addresses is a crucial step in ensuring the correctness of the SOC chip's address decoding logic.

[0003] Currently, the verification methods in related technologies are based on the register abstraction layer model in the general verification methodology. However, the register abstraction layer model only describes the effective registers after address allocation and does not contain information between register modules. Therefore, it lacks the ability to detect errors in empty addresses. At the same time, if empty addresses are manually listed for verification, when the address mapping relationship changes, the hard-coded addresses in the test cases need to be manually corrected one by one. This results in high maintenance costs and difficulty in keeping up with the register backdoor simulation mapping in a timely manner. It is also easy to cause data omissions due to manual processing.

[0004] Therefore, how to identify empty address ranges in the address space and systematically verify them is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a method and system for verifying void addresses. Its main purpose is to solve the problem of how to identify void address ranges in the address space and systematically verify them.

[0006] According to a first aspect of this application, a method for verifying void addresses is provided, comprising: Obtain the address boundary information of multiple register modules in the chip within a unified address space. The address boundary information includes at least the start and end addresses of each register module. Determine the empty address range in the unified address space that is not occupied by any register module based on the address boundary information; At least one probe address is selected based on the void address range, and the probe address is labeled with an address type label. The address type label includes a first type label for indicating that the probe address is a void address and / or a second type label for indicating that the probe address is a valid address. Based on the probe address and address type label, a verification constant table is generated. The verification constant table contains at least one address value and address type label corresponding to the probe address. Perform read and write operations on each probe address in the verification constant table, and verify the read and write operation results of the probe addresses based on the verification method corresponding to the address type label to obtain the verification results.

[0007] According to a second aspect of this application, a system for verifying void addresses is provided, comprising: The address boundary extraction module is used to obtain the address boundary information of multiple register modules in the chip in a unified address space. The address boundary information includes at least the start address and end address of each register module. The hole detection point generation module is used to determine the hole address range in the unified address space that is not occupied by any register module based on the address boundary information; The cavity detection point generation module is also used to select at least one detection address based on the cavity address range and to label the detection address with an address type label. The address type label includes a first type label for indicating that the detection address is a cavity address and / or a second type label for indicating that the detection address is a valid address. The verification constant packet generation module is used to generate a verification constant table based on the probe address and address type label. The verification constant table contains at least one address value and address type label corresponding to the probe address. The verification execution module is used to perform read and write operations on each probe address in the verification constant table, and verify the read and write operation results of the probe addresses based on the verification method corresponding to the address type label, so as to obtain the verification result.

[0008] According to a third aspect of this application, an electronic device is provided, comprising: At least one processor; and A memory that is communicatively connected to at least one processor; wherein, The memory stores instructions that can be executed by at least one processor, such that the at least one processor is able to perform the method described in the first aspect above.

[0009] According to a fourth aspect of this application, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the method of the first aspect described above.

[0010] According to a fifth aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method as described in the first aspect above.

[0011] The method and system for verifying void addresses provided in this application deduce all unoccupied void address ranges in the address space by obtaining the address boundary information of each register module, thus extending the verification scope to address decoding blind zones. Simultaneously, by automatically selecting probe addresses based on void address ranges and labeling them with type tags, the generation of probe points does not rely on manual calculation or hard coding. When the address mapping changes, it only needs to re-acquire boundary information to automatically update, avoiding the problems of high manual maintenance costs and potential synchronization issues with simulation mapping. Furthermore, by generating a verification constant table of probe addresses and tags and performing differentiated verification based on tag types, batch detection of void address read / write behavior is achieved, eliminating boundary omissions that are easily caused by manual listing methods.

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

[0013] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of this application. Wherein: Figure 1 A flowchart illustrating a method for verifying a void address provided in an embodiment of this application; Figure 2 A diagram illustrating a system architecture for verifying void addresses provided in an embodiment of this application; Figure 3 A flowchart illustrating the verification of a void address provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of a hole address verification system provided in an embodiment of this application; Figure 5 This is a schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0015] During the System-on-Chip (SOC) integration and verification phase, after multiple Intellectual Property Core (IP) modules are mapped to a unified Advanced Dextensible Interface (AXI) address space, address ranges exist between the decoding intervals of each module that are not declared by any slave device and should not generate valid register reads or writes. These address ranges are called reserved holes. The reason for these reserved holes is that when register modules in the SOC system allocate addresses within the unified address space, each module occupies a continuous address range based on its base address and address depth. Since the functional complexity and register depth of each module are different, during address allocation, there are unallocated gaps between the end address of one module and the start address of the next; these gaps are the reserved address ranges. If these reserved addresses are incorrectly decoded to adjacent modules or generate abnormal read / write behavior, it will lead to problems such as incorrect address mapping and corrupted register data after SOC integration. Therefore, the hole address must be fully verified to ensure the reliability and correctness of the chip in actual operation.

[0016] In existing technologies, standard register verification methods based on the Register Abstraction Layer (RAL) model are typically used to perform read and write tests on defined registers. However, the RAL model only describes the allocated register addresses and does not include empty address ranges between modules. Therefore, it cannot detect the decoding behavior of unmodeled addresses, nor can it detect address boundary errors after SOC integration. Another technical solution involves manually listing empty addresses based on the register model or address specifications and hard-coding AXI read and write tasks for address-by-address testing on the test platform. However, this method has high maintenance costs, and test cases need to be manually recalculated and modified after each address mapping change, which is prone to missing boundary points and makes it difficult to guarantee the completeness and consistency of verification.

[0017] To address the shortcomings of the existing technology, this application provides a method for verifying void addresses, which can achieve automated identification and verification of void addresses, thereby improving verification coverage and efficiency.

[0018] The following describes a method and system for verifying the void address according to embodiments of this application, with reference to the accompanying drawings.

[0019] Figure 1 This is a flowchart illustrating a method for verifying a void address provided in an embodiment of this application.

[0020] like Figure 1 As shown, the method includes the following steps: Step 101: Obtain the address boundary information of each of the multiple register modules in the chip in a unified address space. The address boundary information includes at least the start address and end address of each of the multiple register modules.

[0021] In the embodiments of this application, a chip refers to a system-on-a-chip (SoC) chip that integrates multiple functional modules. A unified address space refers to a single address space shared by all master and slave devices in the SoC. A register module refers to a logic module in the SoC responsible for implementing specific function control and status registers. Each register module occupies a contiguous address range in the unified address space, used to map its internal control registers, status registers, and configuration registers, etc.

[0022] Address boundary information is used to characterize the address range occupied by each register module in the unified address space. This address boundary information includes at least a start address and an end address. The start address refers to the first address of the address range occupied by the register module, that is, the base address of the register module in the unified address space, which is also the lowest address of the address range occupied by the register module. The end address refers to the last address in the address range occupied by the register module. However, the address range occupied by the register module does not include this end address; that is, the address boundary information is a half-open interval represented as [start address, end address]. Therefore, the actual highest address in the address range occupied by the register module is end_addr - 'h1', where end_addr is the end address.

[0023] Step 102: Determine the empty address ranges in the unified address space that are not occupied by any register module based on the address boundary information.

[0024] In the embodiments of this application, the entire address range of the unified address space is analyzed, the address intervals occupied by each register module are taken as the effective address intervals, and then the remaining part of the unified address space other than all the effective address intervals is determined as the empty address intervals.

[0025] Since the address ranges of each register module are discretely distributed in a unified address space, there may be continuous gaps between the address ranges of adjacent register modules that have not been assigned to any module. These gaps constitute empty address ranges.

[0026] A hole address range is an address segment consisting of consecutive hole addresses. No address in this range has been assigned to any register module and is not within the decoding range of any register module. Performing read or write operations on any address in this range is considered accessing an unmapped address.

[0027] Step 103: Select at least one probe address based on the void address range, and label the probe address with an address type label. The address type label includes a first type label for indicating that the probe address is a void address and / or a second type label for indicating that the probe address is a valid address.

[0028] In the embodiments of this application, the probe address is an address point selected from the void address range and used to actually perform read and write verification operations. Since the void address range may contain a large number of consecutive addresses, it is necessary to select a representative address from each void address range as the probe address, rather than verifying each address in the void address range one by one, thereby controlling the verification time cost while ensuring the validity of the verification.

[0029] After selecting the probe address, each probe address is labeled with an address type label. The address type label is used to identify the attribute category of the probe address, that is, whether the probe address is a hole address or a valid address. The first type label is used to indicate that the probe address is a hole address, that is, the probe address is located in a hole address range that is not occupied by any register module, and reading and writing operations on it should produce behavior that conforms to the hole address specification.

[0030] Step 104: Generate a verification constant table based on the probe address and address type label. The verification constant table contains at least one address value and address type label corresponding to the probe address.

[0031] In the embodiments of this application, the verification constant table is a structured data table that contains all the probe addresses and their attribute information required for this verification. The verification constant table is provided to the verification platform in the form of constant data.

[0032] The address value refers to the specific numerical value of the probe address within a unified address space, used as the target address in read and write transactions. In the verification constant table, the address value of each probe address corresponds to its address type label, forming an address-attribute mapping relationship.

[0033] Since the verification constant table is automatically generated based on address boundary information before verification starts, the read and write operation sequence during the verification process does not need to be hardcoded with specific address values ​​in the code. Instead, the probe address is dynamically obtained by referencing the verification constant table, thereby achieving decoupling between verification data and verification logic.

[0034] Organizing probe addresses and address type labels into a constant table allows the verification constant table to be determined at compile time, eliminating the need for address calculations during simulation runtime. This helps improve the efficiency of verification execution and avoids the additional overhead and potential errors caused by dynamic runtime calculations.

[0035] Step 105: Perform read and write operations on each probe address in the verification constant table, and verify the read and write operation results of the probe addresses based on the verification method corresponding to the address type label to obtain the verification results.

[0036] In the embodiments of this application, read and write operations refer to bus read transactions and bus write transactions performed on the target address, wherein the bus read transaction is used to read data from the target address, and the bus write transaction is used to write test data to the target address.

[0037] Since different types of probe addresses have different expected behaviors, it is necessary to select the appropriate verification method for result comparison based on the address type label of the probe address. The verification method refers to the expected result comparison rules and judgment criteria adopted for a specific type of probe address. Different types of probe addresses correspond to different verification methods.

[0038] For probe addresses labeled with Type I tags, i.e., hole addresses, their expected read and write behavior differs from that of valid addresses: when reading data from a hole address, the expected return value is the preset default value; after writing data to a hole address, it is expected that it will not have any effect on adjacent valid registers. Therefore, for hole addresses, the verification method used should include checking the correctness of the read return value and checking the impact of the write operation.

[0039] For probe addresses labeled with the second type of tag, such as valid addresses, the verification method should include confirmation of successful read operation and checking the correctness of the written data.

[0040] By selecting the corresponding verification method based on address type labels, differentiated verification logic can be implemented, ensuring that different types of address ranges are appropriately verified. The verification platform compares the actual read / write operation results with the expected results specified by the corresponding verification method to determine whether each probe address has passed verification.

[0041] This application automatically identifies void address ranges and selects probe addresses by acquiring address boundary information from register modules. A single data source ensures consistency between the verification address and the chip design, avoiding errors from manual transcription. By generating a verification constant table containing address type labels, verification data and verification logic are decoupled. After address mapping changes, only the verification constant table needs to be regenerated to complete the verification update, without modifying the verification sequence code, thus reducing maintenance costs. By performing read and write operations on probe addresses and selecting the corresponding verification method based on address type labels, the application can automatically cover the detection of read and write behaviors at void addresses, overcoming the shortcomings of traditional register verification methods that cannot detect void addresses, and improving the coverage and efficiency of SOC integrated verification.

[0042] To facilitate understanding of the implementation process of the embodiments of this application, this application provides a system architecture diagram for verifying void addresses, such as... Figure 2 As shown, and a flowchart for verifying a void address, as follows. Figure 3 As shown, this application automatically extracts module boundaries from register backdoor address mapping files or CSV files, dynamically generates a hole detection point table, and drives the UVM Frontdoor sequence to complete the Reserved Hole boundary verification, thereby realizing automated, configurable, and regressive verification of the reserved space address boundaries after SOC integration.

[0043] In one possible implementation of this application embodiment, when obtaining the address boundary information of multiple register modules in a unified address space, the following methods can be used, but are not limited to: parsing a register backdoor address mapping file, which at least records the mapping relationship between the register paths and address ranges of multiple register modules; performing regular expression matching on each mapping relationship in the register backdoor address mapping file to obtain the register path, start address, and end address corresponding to each of the multiple register modules; and constructing address boundary information using the register path, start address, and end address.

[0044] In the embodiments of this application, the register backdoor address mapping file is a path mapping description file used for register backdoor access. This file records the mapping relationship between the relative paths of each register in the chip simulation hierarchy and their corresponding address ranges. The register backdoor address mapping file is usually generated by the verification engineer according to the register specifications when the chip verification environment is set up. Its function is to provide an accurate correspondence between hierarchical paths and addresses for backdoor access.

[0045] A register path refers to the complete hierarchical path identifier of a register module within the top-level structure of chip simulation. This path allows for the unique location of a specific register instance during simulation. An address range refers to the contiguous address range occupied by a register module within a unified address space, defined by a start address and an end address. In the register backdoor address mapping file, each register module's register path corresponds one-to-one with its address range, forming a mapping relationship. This mapping relationship allows for both finding the corresponding register path by address to achieve backdoor access and finding the corresponding address range by register path.

[0046] Regular expression matching refers to the process of using regular expressions to match and extract patterns from text content. Regular expressions are syntax rules used to describe string matching patterns. By writing specific regular expression patterns, target information that conforms to a specific format can be extracted from unstructured text.

[0047] In this application, the register backdoor address mapping file typically records the mapping relationships using a specific text format, for example, each line records the mapping information of a register module. By writing a regular expression pattern adapted to this file format, the start address, end address, and register path can be extracted from each line. Specifically, for the representation format of the address range (e.g., using "start address:end address" or "start address ~end address"), the capturing group function in the regular expression can extract the matched address values ​​and path strings separately, thereby obtaining structured data.

[0048] Address boundary information is specifically composed of register path, start address, and end address. The register path serves as the identifier for this address boundary information, used to distinguish the address boundaries of different register modules. The start address and end address are used to define the address range occupied by the register module.

[0049] In practical applications, the extraction of address boundary information can be illustrated through, but is not limited to, the following methods: parsing the simulation register txt file sys_reg_backdoor.txt or the register csv file, and extracting the (start_addr, end_addr, reg_path) triples using regular expressions. The information for each line in the register backdoor address mapping file can be formatted as a case entry of get_hdl_relative_path in the register txt file sys_reg_backdoor.txt, as shown below: ['ha060:'ha094-'h1]: reg_path = "tb_top...u_sys_paxi1_edf_abs"; Where ha060 is the starting address (start_addr), ha094 is the ending address (end_addr), reg_path is the register path, and end_addr-'h1 represents a half-open interval [start, end), that is, the address interval can be represented in a half-open interval manner (the starting address is included in the interval, and the ending address is not included in the interval).

[0050] This application automatically extracts address boundary information programmatically, effectively eliminating errors caused by manual intervention and improving the accuracy and reliability of verification data. Furthermore, when the chip design undergoes address mapping changes, only the extraction process needs to be re-executed to obtain the updated address boundary information, without requiring any modifications to the verification code, significantly improving the maintainability of the verification environment.

[0051] In one possible implementation of this application embodiment, when determining the empty address intervals in a unified address space that are not occupied by any register module based on address boundary information, the following methods can be used, but are not limited to: determining the address intervals between the start and end addresses of each of the multiple register modules as valid address intervals; sorting the multiple valid address intervals in the unified address space according to the order of the start addresses from smallest to largest to obtain sorted valid address intervals; determining the address interval between the end address of the target valid address interval and the start address of the next valid address interval as an empty address interval, wherein the target valid address interval is any valid address interval in the sorted valid address intervals; and determining the interval between the end address of the last valid address interval in the sorted valid address intervals and the upper limit of the preset address window as an empty address interval.

[0052] In the embodiments of this application, the effective address range refers to the address range in the unified address space that has been actually occupied by a certain register module and can be decoded normally and respond to bus transactions.

[0053] Since the allocation of each register module in the unified address space is independent, the effective address ranges of different register modules are discretely distributed in the address space according to their base addresses. To identify gaps between all effective address ranges, they need to be arranged in ascending order of their starting addresses. Sorting refers to arranging multiple effective address ranges from low to high numerical values ​​of their starting addresses.

[0054] In the sorted sequence of valid address intervals, there are two possible positional relationships between any two adjacent valid address intervals: The first relationship is that the two valid address intervals are consecutive, in which case the end address of the first interval is equal to the start address of the second interval, indicating that the address allocation of the two modules is consecutive; the second relationship is that there is a gap between the two valid address intervals, in which case the end address of the first interval is less than the start address of the second interval, indicating that there is an unoccupied address gap between the address allocation of the two modules, and this gap is called the empty address interval.

[0055] In the second scenario, all addresses between the end address of the previous valid address interval and the address preceding the start address of the next valid address interval are considered empty addresses. The target valid address interval refers to any valid address interval currently being probed, i.e., any valid address interval in the sorted sequence of valid address intervals.

[0056] In the actual address allocation of a unified address space, the end address of the last register module is usually not equal to the highest address of the entire address space. There may be a high-order address region that is not occupied by any register module after the end address of the last valid address interval; this region also belongs to the empty address interval. The preset address window upper limit refers to the highest address of the address window set for this verification.

[0057] In this application, the verification process can be performed within a preset verification address window, which is defined by the lower limit and the upper limit of the preset address window.

[0058] Similarly, for the address region before the starting address of the first valid address region in the sorted valid address range, if the region is located between the lower limit of the preset address window and the starting address of the first valid address range, then the region is also not occupied by any register module and should also be identified as an empty address range.

[0059] This application addresses the gaps between adjacent valid address ranges by sorting the effective address ranges of each register module according to their starting addresses. All gaps are identified through a systematic comparison process, eliminating the need for manual intervention and avoiding omissions and errors introduced by manual calculation and labeling. When the chip address mapping changes, only the address boundary information needs to be re-acquired and the sorting and comparison performed to automatically update the identification results of gaps, improving the maintainability and scalability of the verification environment.

[0060] In one possible implementation of this application embodiment, when selecting at least one probe address based on a hole address range, the following methods can be used, but are not limited to: obtaining the lower limit address and upper limit address of the target hole address range, where the target hole address range can be any hole address range; selecting probe addresses at the lower limit address, the lower limit address plus a first offset, the upper limit address minus a second offset, and the upper limit address minus a first offset, respectively, wherein the first offset is less than the second offset; if the length of the target hole address range is less than the address length corresponding to the maximum data bit width of a single bus transmission, not selecting a probe address within the target hole address range; obtaining the target start address and target end address of the target register module, and selecting probe addresses at the target start address and target end address minus a first offset, respectively, where the target register module can be any register module.

[0061] In the embodiments of this application, the target cavity address range refers to a cavity address range currently being selected for detection. The lower limit address refers to the address with the smallest address value within the target cavity address range, i.e., the starting boundary of the target cavity address range; the upper limit address refers to the address with the largest address value within the target cavity address range, i.e., the ending boundary of the target cavity address range.

[0062] Both the first offset and the second offset are preset address offset values ​​used to select multiple representative sampling points as probe addresses within the hole address range. The first offset is less than the second offset. Selecting a probe address at the lower limit address of the hole address range can cover the critical address at the boundary between the hole address range and the previous valid address range. Selecting a probe address at the lower limit address plus the first offset can cover the inner address immediately adjacent to the starting boundary of the hole.

[0063] Similarly, selecting a probe address at the upper limit address minus the second offset can cover addresses within the hole address range that are close to the inner edge of the end boundary, and can be used to verify the behavior of the hole address at the second offset from the end boundary. Selecting a probe address at the upper limit address minus the first offset can cover the critical address at the boundary between the hole address range and the next valid address range.

[0064] The specific values ​​of the first offset and the second offset can be determined based on the data bit width of the bus protocol. In some implementations, the first offset can be set to the number of bytes corresponding to the maximum data bit width of a single bus transmission. For example, for a bus system with a 32-bit data bit width, the first offset can be 4 bytes. The second offset can be set to a value greater than the first offset, such as 8 bytes, thereby enabling the probe address to form a sampling distribution at different distances near the boundary of the hole address range.

[0065] In this application, the address length corresponding to the maximum data bit width of a single bus transmission refers to the address space length corresponding to the maximum data width that a single transmission transaction supported by the bus protocol can access. When the length of the empty address interval is less than this address length, it means that the empty address interval is too small and may not be able to accommodate a complete bus transmission operation. In this case, if a probe address is selected within the empty address interval and a bus read / write operation is performed, the bus transaction may cross the boundary of the empty address interval and access an adjacent valid address interval, thereby producing unexpected verification results and interfering with the correct judgment of the empty address behavior. Therefore, when the length of the target empty address interval is less than the address length corresponding to the maximum data bit width of a single bus transmission, a probe address is not selected within the target empty address interval, that is, the empty address interval is skipped and not included in the subsequent verification scope.

[0066] Furthermore, in this application, the target register module refers to a register module currently being processed to select a probe address, the target start address is the start address of the target register module, and the target end address is the end address of the target register module. In addition to verifying the empty address range, in some embodiments, it is also necessary to verify the boundary addresses within the valid address range to confirm that the read and write functions of the legitimate addresses are normal.

[0067] Specifically, a probe address is selected at the target start address of the target register module to verify whether the start address of the register module can be correctly decoded and the bus read / write operation can be successfully completed. A probe address is selected at the target end address minus the first offset, that is, near the end of the address range occupied by the target register module, to verify whether the address near the end address of the register module can be correctly decoded.

[0068] This application achieves comprehensive sampling of the boundaries of each address interval in a unified address space by simultaneously selecting probe addresses at key boundary locations of both the empty address interval and the valid address interval. The selected probe addresses cover all intersections between the empty address interval and the valid address interval, effectively detecting address overlaps or omissions caused by unmet address decoding boundary conditions. Furthermore, filtering out excessively small empty address intervals avoids invalid probes, thus improving verification efficiency and reliability.

[0069] In one possible implementation, the selection of the probe address can be achieved through, but is not limited to, the following examples: Within the preset address window [win_lo, win_hi), sort the clipped region (address range) list (i.e., the address range of the register module) by start (starting address) and execute: 1. VALID probe points (probe addresses of valid address ranges): selected at the start and end-4 (last word alignment boundary) of each region, used for sanity checks to confirm that the legitimate address is readable; 2. HOLE probe point (probe address of hole address range): the gap (address range) between adjacent regions [cur, next.start) and the tail gap from the last region to win_hi (preset address window upper limit); take 4 boundary sampling addresses (lo, lo+4, hi-8, hi-4) in each gap, which are the probe addresses; 3. Deduplication strategy: If the same address contains both VALID and HOLE, HOLE will be retained first.

[0070] The final extracted probe addresses can be illustrated using examples, but are not limited to, Table 1: Table 1

[0071] In one possible implementation of this application embodiment, when generating a verification constant table based on the probe address and address type label, it can be implemented in the following way, but is not limited to: compiling the address value, address type label and debugging label information corresponding to at least one probe address into a verification constant package file according to a preset data structure; wherein, the verification constant package file includes a verification constant table, and in the verification constant package file, the address value is stored in the form of compile-time constants, and the address type label is stored in an enumeration type.

[0072] In the embodiments of this application, the verification constant package file is a file containing constant data required for verification. This file can be organized using the syntax of a hardware description language (e.g., SystemVerilog). Debug label information is auxiliary information used to describe and identify probe addresses, enhancing the readability and debuggability of the verification process. Debug label information can be in string form. For example, for probe addresses selected from holed address ranges, the debug label can include information about the lower and upper limits of the holed address range (e.g., "hole_0a094_0a0a0"), thus clearly indicating the source of each probe address in the verification output log; for probe addresses selected from valid address ranges, the debug label can include the corresponding register module name and boundary location information (e.g., "u_sys_paxi1_edf_abm_start").

[0073] Preset data structure refers to a predefined data organization format used to combine and arrange the address value, address type label, and debug label information of each probe address according to uniform rules.

[0074] In this application, compile-time constants refer to constant data whose values ​​can be determined during the compilation phase of the hardware description language and cannot be changed during simulation. In the SystemVerilog language, compile-time constants can be declared using the `localparam` keyword. For example, `localparam bit [31:0] EVT_RSVD_ADDR[CNT]= '{32'h0000A000,32'h0000A01C, ...};` means storing an array of address values ​​in the form of compile-time constants.

[0075] An enumeration type is a user-defined data type whose values ​​are restricted to a predefined set of named values. In the SystemVerilog language, enumeration types can be declared using the `enum` keyword. For example, `typedef enum{EVT_RSVD_KIND_VALID, EVT_RSVD_KIND_HOLE} evt_rsvd_addr_kind_e;` defines an enumeration type used to represent address type labels.

[0076] In the verification constant package file, the address value, address type label, and debug label information of each probe address are organized into corresponding data elements according to a preset data structure. In some implementations, the three pieces of information can be stored in three parallel compile-time constant arrays, arranged in the same index order, so that the address value, address type label, and debug label information corresponding to the same index position belong to the same probe address. In other implementations, the three pieces of information can also be organized into a compile-time constant array of structure type, where each structure element contains an address value field, an address type label field, and a debug label information field.

[0077] Furthermore, the generation of the verification constant table can be achieved, but is not limited to, by the following method: the script outputs the evt_rsvd_addr_pkg package, which contains: EVT_RSVD_ADDR[]: Array of probe addresses; EVT_RSVD_KIND[]: HOLE / VALID enumeration; EVT_RSVD_LABEL[]: Debug tag (e.g., hole_0a094_0a0a0).

[0078] Automatically generate key information in (evt_rsvd_addr_pkg.sv).

[0079] This application stores the probe address values ​​as compile-time constants, ensuring that the address values ​​are determined at compile time. This eliminates the need for address calculations during simulation, avoiding the overhead of dynamic runtime calculations and improving verification efficiency. Furthermore, the compile-time constant values ​​cannot be changed during simulation, guaranteeing the consistency and determinism of each probe address during verification and preventing the unreproducible verification results caused by dynamically modifying address values.

[0080] By storing address type labels as an enumeration type, the use of enumeration types makes the comparison logic of address type labels in the verification code clearer, the code semantics more explicit, and easier to understand and maintain.

[0081] In one possible implementation of this application embodiment, when verifying the read / write operation results of the probe address based on the verification method corresponding to the address type label, the following methods can be used, but are not limited to: In response to the address type label being a first type label indicating a hole address, a reference value of the anchor register within the effective address range adjacent to the probe address is read; a first read return value is obtained by performing a read operation from the probe address, and the first read return value is compared with the expected return value to obtain a first comparison result; after performing a write operation from the probe address, a second read return value of the anchor register within the effective address range adjacent to the probe address is read, and the second read return value is compared with the reference value to obtain a second comparison result; after performing a write operation from the probe address, a third read return value is obtained by performing a read operation from the probe address, and the third read return value is compared with the expected return value to obtain a third comparison result; the verification result is determined based on the first comparison result, the second comparison result, and the third comparison result.

[0082] In the embodiments of this application, the anchor register refers to a register located within the effective address range adjacent to the current probe address, that is, a register adjacent to the hole address in the address space. The reference value refers to the initial value read from the anchor register before performing any read or write operation on the probe address. During the verification process, the verifier sends a bus read transaction to the anchor register through a front-door access method to obtain the current value of the anchor register as the reference value, and stores the reference value in the verification environment.

[0083] It should be noted that there are multiple ways to select the anchor register. For example, you can choose the register corresponding to the effective address interval before the hole address as the anchor register, or you can choose the register corresponding to the starting address of the effective address interval after the hole address as the anchor register, or you can choose registers in two adjacent effective address intervals as anchor registers.

[0084] The first read return value refers to the actual data value read from the empty address when performing the first read operation on that empty address. The expected return value refers to the default value that should be returned when performing a read operation on an empty address according to the chip design specifications, such as all 0s, all 1s, or a specific constant.

[0085] After verifying the read operation on the hole address, a write operation is performed on that hole address. Since the hole address is not within the decoding range of any register module, the data written to it should be ignored and will not affect any valid registers. However, in actual SOC integration, an address decoding logic error may cause the data written to the hole address to be incorrectly routed to an adjacent valid register module, thereby modifying the value of a register within that module—a write-through problem. To detect write-through, after performing the write operation on the hole address, the verification platform reads the value of the anchor register again, obtaining a second read return value. This second read return value is then compared with the previously recorded baseline value to determine if they match. This comparison operation yields a second comparison result, which characterizes whether the write operation on the hole address caused unintended effects on adjacent valid registers.

[0086] After performing a write operation to the empty address, in addition to checking whether the anchor register has been accidentally modified, it is also necessary to verify whether the read return value of the empty address itself after the write operation still meets expectations. Specifically, a read operation is performed again from the empty address to obtain the read return value of the empty address after the write operation, i.e., the third read return value. Then, the third read return value is compared with the expected return value to determine whether they are consistent. This comparison operation yields the third comparison result, which is used to characterize whether the read return value of the empty address after the write operation is correct.

[0087] The verification result is a conclusion on whether the read and write operations of the probe address have passed the verification. In this application, for a cavity address probe point marked with a first type label, the probe address is determined to have passed the cavity address verification only when the first comparison result, the second comparison result, and the third comparison result all indicate that they have passed.

[0088] This application's verification method for holed addresses covers read operation return value checks, write operation impact checks on adjacent registers, and read operation return value checks after write operations. Read operation return value checks can detect whether the holed address has been incorrectly decoded into a valid register module; write operation impact checks on adjacent registers can detect write penetration issues, preventing data written to the holed address from accidentally modifying adjacent valid registers; and read operation return value checks after write operations can further verify the write isolation characteristics of the holed address. This forms a comprehensive verification of the read and write behavior of holed addresses, effectively improving the coverage and defect detection capabilities of SOC integrated verification.

[0089] In one possible embodiment, verification of the probe address can also be achieved in, but is not limited to, the following ways: 1. Read the anchor register (anchor register, which can be configured and modified depending on usage) to record the baseline value; 2. Read the HOLE address and compare it with +EXP_HOLE_RDATA (expected return value) (default 0); 3. Write 0xDEADBEEF to HOLE, then read the anchor register to confirm there is no write penetration; 4. Read HOLE again to confirm that the value remains unchanged.

[0090] In one possible implementation of this application embodiment, when determining the verification result based on the first comparison result, the second comparison result, and the third comparison result, it can be implemented in the following ways, but not limited to: in response to the first comparison result indicating that the first read return value is the same as the expected return value, and the second comparison result indicating that the second read return value is the same as the benchmark value, and the third comparison result indicating that the third read return value is the same as the expected return value, the verification is determined to be successful; in response to the first comparison result indicating that the first read return value is different from the expected return value, and / or the second comparison result indicating that the second read return value is different from the benchmark value, and the third comparison result indicating that the third read return value is different from the expected return value, the verification is determined to be unsuccessful.

[0091] In the embodiments of this application, if the first read return value is consistent with the expected return value, it indicates that the read operation behavior of the hole address is normal and the hole address has not been incorrectly decoded to any valid register module; if the two are inconsistent, it indicates that the hole address may have a decoding anomaly, for example: the address was incorrectly routed to a certain register module, resulting in the return of the actual value of a certain register in that module instead of the expected return value of the hole address.

[0092] If the second read return value is consistent with the base value, it means that the value of the anchor register has not changed and the write operation of the hole address has not affected the adjacent valid registers; if the two are inconsistent, it means that the value of the anchor register has been accidentally modified, the write operation of the hole address has caused write penetration, and the hole address has a decoding anomaly.

[0093] If the third read return value is consistent with the expected return value, it means that the write operation did not affect the read return value of the empty address, and the read behavior of the empty address remains normal. If the third read return value is inconsistent with the expected return value, it means that the write operation changed the read return value of the empty address. This may indicate that the address was actually incorrectly decoded to a writable register module. After receiving the write operation, the internal state of the register module changed, thus returning data different from the expected return value during the read operation.

[0094] A hole address is considered to conform to design specifications only when all three conditions are met: a read operation on the hole address returns the expected default value; a write operation on the hole address does not affect the value of adjacent valid registers; and a read operation on the hole address after a write operation still returns the expected value. Failure to meet any of these three conditions indicates that the hole address has decoding or read / write behavior anomalies, and the verification result is considered unsuccessful.

[0095] This application determines the verification result by combining multiple comparison results, which can comprehensively evaluate the correctness of read operations, isolation of write operations, and stability of read operations after write operations of the holed address, thereby achieving complete verification of the read and write behavior of the holed address and effectively preventing the risk of missing other types of defects due to verifying only a single operation.

[0096] In one possible implementation of this application embodiment, when verifying the read / write operation result of the probe address based on the verification method corresponding to the address type label, the following methods can also be used, but are not limited to: in response to the address type label being a second type label indicating a valid address, a read operation is performed from the probe address, and the completion status of the read operation is verified, wherein the valid address is the address within the valid address range corresponding to the register module; in response to the completion status indicating that the read operation has been completed, the verification is determined to be successful.

[0097] In the embodiments of this application, the second type label is one of the address type labels, used to indicate that the probe address is located within a valid address range. A valid address refers to an address in the unified address space that has been actually occupied by a register module and can be correctly decoded and routed to the corresponding slave device.

[0098] The completion status refers to the response status information returned after a bus read transaction is completed, indicating whether the bus transaction was successfully completed. Each bus transaction is accompanied by a response signal or response status code upon completion, indicating the result of the transaction, such as: successful transaction completion, slave device error response, decoding error, or retry. By verifying the completion status of the read operation, it can be confirmed whether the decoding and response of the address are normal. If the address can be successfully read, it means that the address has been correctly decoded into the corresponding register module.

[0099] In one possible implementation of this application, in response to the target address being simultaneously labeled with a first type label and a second type label, the target address is determined to be a void address.

[0100] Corresponding to the above-described method for verifying void addresses, this application also proposes a system for verifying void addresses. Since the system embodiments of this application correspond to the method embodiments described above, details not disclosed in the system embodiments can be referred to the method embodiments described above, and will not be repeated here.

[0101] Figure 4 A schematic diagram of the structure of a hole address verification system provided in an embodiment of this application is shown below. Figure 4 As shown, it includes: The address boundary extraction module is used to obtain the address boundary information of multiple register modules in the chip in a unified address space. The address boundary information includes at least the start address and end address of each register module. The hole detection point generation module is used to determine the hole address range in the unified address space that is not occupied by any register module based on the address boundary information; The cavity detection point generation module is also used to select at least one detection address based on the cavity address range and to label the detection address with an address type label. The address type label includes a first type label for indicating that the detection address is a cavity address and / or a second type label for indicating that the detection address is a valid address. The verification constant packet generation module is used to generate a verification constant table based on the probe address and address type label. The verification constant table contains at least one address value and address type label corresponding to the probe address. The verification execution module is used to perform read and write operations on each probe address in the verification constant table, and verify the read and write operation results of the probe addresses based on the verification method corresponding to the address type label, so as to obtain the verification result.

[0102] It should be noted that the foregoing explanation of the method embodiments also applies to the system in the embodiments of this application, and the principle is the same. Therefore, the embodiments of this application are not limited thereto.

[0103] According to embodiments of this application, this application also provides an electronic device, a readable storage medium, and a computer program product.

[0104] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of this application 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 may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, 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 application described and / or claimed herein.

[0105] like Figure 5As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in ROM (Read-Only Memory) 502 or loaded from storage unit 508 into RAM (Random Access Memory) 503. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. I / O (Input / Output) interface 505 is also connected to bus 504.

[0106] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0107] The computing unit 501 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the hole address verification method. For example, in some embodiments, the hole address verification method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the aforementioned method for verifying the holed address by any other suitable means (e.g., by means of firmware).

[0108] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations 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.

[0109] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0110] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0111] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. 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).

[0112] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include 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 LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0113] Computer systems 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. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service system that addresses the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0114] It's important to note that artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies primarily include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0115] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0116] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. 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 application should be included within the scope of protection of this application.

Claims

1. A method for verifying void addresses, characterized in that, include: Obtain the address boundary information of each of the multiple register modules in the chip in a unified address space, wherein the address boundary information includes at least the start address and end address of each of the multiple register modules; Based on the address boundary information, determine the empty address range in the unified address space that is not occupied by any register module; At least one detection address is selected based on the void address range, and an address type label is marked on the detection address. The address type label includes a first type label for indicating that the detection address is a void address and / or a second type label for indicating that the detection address is a valid address. A verification constant table is generated based on the probe address and the address type label. The verification constant table contains at least one address value and address type label corresponding to the probe address. Perform read and write operations on each probe address in the verification constant table, and verify the read and write operation results of the probe address based on the verification method corresponding to the address type label to obtain the verification result; The step of selecting at least one detection address based on the cavity address range includes: Obtain the lower limit address and upper limit address of the target void address range, wherein the target void address range is any void address range; Detection addresses are selected at the lower limit address, the lower limit address plus a first offset, the upper limit address minus a second offset, and the upper limit address minus a first offset, respectively, wherein the first offset is less than the second offset; If the length of the target hole address range is less than the address length corresponding to the maximum data bit width of a single bus transmission, the probe address is not selected within the target hole address range. Obtain the target start address and target end address of the target register module, and select probe addresses at the target start address and the target end address minus a first offset, respectively. The target register module can be any register module. The step of generating a verification constant table based on the probe address and the address type label includes: Compile at least one of the probe addresses, the address type label, and the debug label information into a verification constant package file according to a preset data structure; The verification constant package file includes the verification constant table. In the verification constant package file, the address values ​​are stored in the form of compile-time constants, and the address type labels are stored in an enumeration type. The verification of the read / write operation results of the probe address based on the verification method corresponding to the address type label yields the following verification results: In response to the address type label being a first type label indicating a hole address, the reference value of the anchor register within the effective address range adjacent to the probe address is read; A first read return value is obtained by performing a read operation on the probe address, and the first read return value is compared with the expected return value to obtain a first comparison result; After the write operation is performed at the probe address, the second read return value of the anchor register in the effective address range adjacent to the probe address is read, and the second read return value is compared with the reference value to obtain the second comparison result. After a write operation is performed at the probe address, a read operation is performed at the probe address to obtain a third read return value. The third read return value is compared with the expected return value to obtain a third comparison result. The verification result is determined based on the first comparison result, the second comparison result, and the third comparison result.

2. The method according to claim 1, characterized in that, The acquisition of address boundary information of multiple register modules in the chip within a unified address space includes: The register backdoor address mapping file is parsed, and the register backdoor address mapping file records at least the mapping relationship between the register paths and address ranges of the plurality of register modules; Perform regular expression matching on each mapping relationship in the register backdoor address mapping file to obtain the register path, start address and end address corresponding to each of the multiple register modules; The address boundary information is constituted by the register path, the start address, and the end address.

3. The method according to claim 1, characterized in that, The step of determining the empty address range in the unified address space that is not occupied by any register module based on the address boundary information includes: The address range between the start address and the end address of each of the plurality of register modules is determined as the effective address range; According to the starting address in ascending order, the multiple valid address intervals within the unified address space are sorted to obtain the sorted valid address intervals; In the sorted valid address intervals, the address interval between the end address of the target valid address interval and the start address of the next valid address interval is determined as the void address interval, and the target valid address interval is any valid address interval in the sorted valid address intervals; And, the interval between the end address of the last valid address interval in the sorted valid address interval and the upper limit of the preset address window is determined as the void address interval.

4. The method according to claim 1, characterized in that, The step of determining the verification result based on the first comparison result, the second comparison result, and the third comparison result includes: In response to the first comparison result indicating that the first read return value is the same as the expected return value, and the second comparison result indicating that the second read return value is the same as the benchmark value, and the third comparison result indicating that the third read return value is the same as the expected return value, the verification is determined to be successful; In response to the first comparison result indicating that the first read return value is different from the expected return value, and / or the second comparison result indicating that the second read return value is different from the benchmark value, and / or the third comparison result indicating that the third read return value is different from the expected return value, the verification is determined to have failed.

5. The method according to claim 1, characterized in that, The verification of the read / write operation results of the probe address based on the verification method corresponding to the address type label yields the following verification results: In response to the address type label being a second type label indicating a valid address, a read operation is performed from the probe address, and the completion status of the read operation is verified. The valid address is an address within the valid address range corresponding to the register module. In response to the completion status indicating that the read operation has been completed, the verification is confirmed to be successful.

6. The method according to claim 1, characterized in that, After selecting at least one probe address based on the cavity address range, the method further includes: In response to a target address being labeled with both a first type of label and a second type of label, the target address is determined to be a void address.

7. A system for verifying void addresses, characterized in that, include: The address boundary extraction module is used to obtain the address boundary information of each of the multiple register modules in the chip in a unified address space. The address boundary information includes at least the start address and end address of each of the multiple register modules. A hole detection point generation module is used to determine the hole address range in the unified address space that is not occupied by any register module based on the address boundary information. The cavity detection point generation module is also used to select at least one detection address based on the cavity address range, and to label the detection address with an address type label, wherein the address type label includes a first type label for indicating that the detection address is a cavity address and / or a second type label for indicating that the detection address is a valid address; The verification constant packet generation module is used to generate a verification constant table based on the probe address and the address type label. The verification constant table contains at least one address value and address type label corresponding to the probe address. The verification execution module is used to perform read and write operations on each probe address in the verification constant table, and verify the read and write operation results of the probe address based on the verification method corresponding to the address type label, so as to obtain the verification result; The cavity detection point generation module is specifically used for: Obtain the lower limit address and upper limit address of the target void address range, wherein the target void address range is any void address range; Detection addresses are selected at the lower limit address, the lower limit address plus a first offset, the upper limit address minus a second offset, and the upper limit address minus a first offset, respectively, wherein the first offset is less than the second offset; If the length of the target hole address range is less than the address length corresponding to the maximum data bit width of a single bus transmission, the probe address is not selected within the target hole address range. Obtain the target start address and target end address of the target register module, and select probe addresses at the target start address and the target end address minus a first offset, respectively. The target register module can be any register module. The verification constant package generation module is specifically used for: Compile at least one of the probe addresses, the address type label, and the debug label information into a verification constant package file according to a preset data structure; The verification constant package file includes the verification constant table. In the verification constant package file, the address values ​​are stored in the form of compile-time constants, and the address type labels are stored in an enumeration type. The verification execution module is specifically used for: In response to the address type label being a first type label indicating a hole address, the reference value of the anchor register within the effective address range adjacent to the probe address is read; A first read return value is obtained by performing a read operation on the probe address, and the first read return value is compared with the expected return value to obtain a first comparison result; After the write operation is performed at the probe address, the second read return value of the anchor register in the effective address range adjacent to the probe address is read, and the second read return value is compared with the reference value to obtain the second comparison result. After a write operation is performed at the probe address, a read operation is performed at the probe address to obtain a third read return value. The third read return value is compared with the expected return value to obtain a third comparison result. The verification result is determined based on the first comparison result, the second comparison result, and the third comparison result.

Images