Register verification method, electronic device and storage medium

Abstract

Embodiments of the present disclosure provide a register verification method, an electronic device and a storage medium, and relate to the technical field of chip verification. The method comprises: obtaining register attribute information and verification configuration information of a chip to be verified; determining target registers of each subsystem in the chip to be verified according to the register attribute information and the verification configuration information; and executing a test case corresponding to a target semantic attribute of the target registers to perform register verification. The chip to be verified comprises a plurality of subsystems, each subsystem comprises a plurality of registers, the register attribute information comprises one or more hardware semantic attributes of each register of the chip to be verified in the chip to be verified hardware architecture and related to a hardware access control mechanism, the verification configuration information comprises a target semantic attribute and a set sampling number of each subsystem, and an attribute label of the target register comprises the target semantic attribute. In this way, the efficiency and reliability of register verification can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of chip verification technology, and more specifically, to a register verification method, electronic device, and storage medium. Background Technology

[0002] With the continuous development of chip technology, increasingly complex chip architectures such as Very Large Scale Devices (VLSI) (SoC) have emerged. These complex chip architectures typically integrate a large number of registers. As one of the basic functional units in chip hardware architecture, registers are used to store chip configuration parameters, status information, and control instructions. The correctness of register access is fundamental to the reliable operation of the chip. Therefore, during the chip verification phase, it is necessary to perform functional verification of the register access paths to verify the correctness of register access and improve the reliability of chip functionality.

[0003] In related technologies, register verification can be performed based on the Register Abstraction Layer (RAL) model of the Universal Verification Methodology (UVM). For example, register verification can be achieved by using full traversal access or forced read / write via backdoor paths. However, the register verification methods in these technologies are time-consuming and cannot meet the needs of agile chip development. Therefore, how to provide a register verification method that can balance verification efficiency and reliability has become an urgent technical problem to be solved. Summary of the Invention

[0004] One objective of this disclosure is to provide a new technical solution for register verification.

[0005] According to a first aspect of the present disclosure, a register verification method is provided, the method comprising: Obtain register attribute information and verification configuration information of the chip to be verified; wherein, the chip to be verified includes multiple subsystems, each subsystem includes multiple registers, the register attribute information includes attribute tags of each register of the chip to be verified, the attribute tags are used to characterize one or more hardware semantic attributes of the register in the hardware architecture of the chip to be verified related to the hardware access control mechanism, and the verification configuration information includes target semantic attributes and the set sampling number of each subsystem, the target semantic attribute is the attribute to be verified among one or more of the hardware semantic attributes; The target register of each subsystem in the chip to be verified is determined based on the register attribute information and the verification configuration information; wherein, the target register of each subsystem includes a set number of registers sampled from multiple registers of the subsystem, and the attribute label of the target register contains the target semantic attribute, and the set number of samples is less than the total number of registers in the subsystem; Test cases corresponding to the target semantic attributes are executed for the target register to perform register verification.

[0006] Optionally, determining the target register of each subsystem in the chip to be verified based on the register attribute information and the verification configuration information includes: For each subsystem of the chip to be verified, the registers whose attribute labels contain the target semantic attribute are obtained from multiple registers of the subsystem as a candidate register set corresponding to the subsystem; From the candidate register set corresponding to the subsystem, a predetermined number of registers are selected from the candidate register set based on a pre-defined target sampling algorithm, and these are used as the target registers corresponding to the subsystem.

[0007] Optionally, the target sampling algorithm includes a maximum-minimum intermediate address boundary sampling algorithm; the step of selecting the predetermined number of registers from the candidate register set as the target registers corresponding to the subsystem based on the pre-defined target sampling algorithm includes: Determine the register address value of each candidate register in the candidate register set; The registers with the largest, smallest, and middle address values ​​are designated as the first type of registers; Randomly select multiple candidate registers from the candidate registers other than the first type of registers as the second type of registers; The target register is determined based on the first type of register and the second type of register.

[0008] Optionally, the target sampling algorithm includes a random sampling algorithm that samples based on a set random seed; the method further includes: The sampling verification steps are executed in multiple rounds. Each sampling verification step includes determining the target register of each subsystem in the chip to be verified based on the register attribute information and the verification configuration information. The test cases corresponding to the target semantic attributes are executed for the target registers to perform register verification. The random seeds used in different rounds of sampling verification steps are different.

[0009] Optionally, the hardware semantic attributes include at least one of security attributes, virtualization attributes, or reserved address attributes; the security attributes are used to identify registers controlled by security access permissions; the virtualization attributes are used to identify registers related to virtualization function isolation; and the reserved address attributes are used to identify registers whose addresses fall into unmapped reserved intervals in the chip address space.

[0010] Optionally, the test cases corresponding to the security attributes are security test cases, which include: switching the security access identifier and non-security access identifier of the verification intellectual property core, and accessing the register to verify the security access control logic of the register.

[0011] Optionally, the test cases corresponding to the virtualization attributes are virtualization test cases, which include: switching the physical function identifier and virtual function identifier of the verification intellectual property core, and accessing the registers to verify the access isolation control logic of the registers under different virtualization function identities.

[0012] Optionally, the test case corresponding to the reserved address attribute is a reserved address test case, which includes: initiating a read / write access to the unmapped reserved address corresponding to the register, and verifying whether the read / write access triggers an access error response.

[0013] Optionally, executing test cases corresponding to the target semantic attributes for the target register to perform register verification includes: Based on the test cases, determine the bus read / write transactions of the target register and the expected response results corresponding to the bus read / write transactions; By verifying the main device interface of the intellectual property core, the bus read / write transaction is initiated to the bus address corresponding to the target register; The actual response result returned by the chip to be verified for the bus read / write transaction is obtained through the main device interface. The verification result of the target register is determined based on the actual response result and the expected response result.

[0014] Optionally, the verification configuration information may also include the address information of special registers that are prohibited from access; the target register does not include the special registers. The special register includes at least one of the following: A phase-locked loop configuration register that controls the clock frequency; A fuse bit register with one-time write capability; Debug registers are used to control the debug interface of the chip being verified.

[0015] According to a second aspect of the present disclosure, an electronic device is provided, including a memory and a processor, the memory being configured to store computer instructions, and the processor being configured to invoke the computer instructions from the memory to perform the method described in the first aspect.

[0016] According to a third aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, the computer program implementing the method described in the first aspect when executed by a processor.

[0017] Based on the register verification method provided in this disclosure, register attribute information, including hardware semantic attribute tags related to hardware access control mechanisms, is assigned to each register in the chip to be verified. Based on the register attribute information and verification configuration information, a set number of target registers with attribute tags containing the target semantic attributes are sampled from multiple registers in each subsystem of the chip to be verified. This achieves a hierarchical sampling mechanism and enables controllable directional sampling verification driven by hardware semantic attributes. Compared with full random sampling, this method improves verification reliability and significantly reduces verification time compared with full traversal schemes. It improves the efficiency of register verification while taking reliability into account, thereby meeting the high-frequency regression verification requirements in agile chip development.

[0018] Other features and advantages of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure.

[0020] Figure 1 This is a schematic diagram of an application scenario in which the technical solutions provided in the embodiments of this disclosure can be applied.

[0021] Figure 2 This is a schematic diagram of the structure of a chip to be verified provided in an embodiment of this disclosure.

[0022] Figure 3 This is a flowchart illustrating a register verification method provided in an embodiment of this disclosure.

[0023] Figure 4 This is a flowchart illustrating another register verification method provided in an embodiment of this disclosure.

[0024] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0025] Various exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0026] The following description of at least one exemplary embodiment is merely illustrative and is not intended to limit this disclosure or its application or use. Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and apparatus may be considered part of the specification.

[0027] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it need not be discussed further in subsequent figures.

[0028] This disclosure relates to a technical solution for register verification. Figure 1 This is a schematic diagram illustrating an application scenario where the technical solutions provided in the embodiments of this disclosure can be applied. For example... Figure 1 As shown, this application scenario may include a test platform 100, an operation terminal 200, and a chip to be verified 110.

[0029] The test platform 100 can be used for register verification, for example, to execute the register verification method provided in this disclosure embodiment. This register verification method can be triggered by an AI agent and / or a human engineer deployed on the test platform. The register verification method can be used to simulate or test the chip to be verified. The chip to be verified can be one or more chips of any type, such as a very large-scale SoC. This chip may include one or more of the following: a graphics processing unit (GPU), a general-purpose graphics processing unit (GPGPU), a neural network processing unit (NPU), a tensor processing unit (TPU), or a central processing unit (CPU), and may also include memory. In some examples, the test platform may include a processor, on which the register verification method is executed. This processor may include at least one of a CPU, GPU, GPGPU, NPU, and TPU. Exemplarily, the test platform may further include a memory, which may include at least one of Static Random Access Memory (SRAM), Read-Only Memory (ROM), or Erasable Programmable Read-Only Memory (EPROM). The memory can be used to store a computer program that, when executed by a processor, controls the processor to perform the register verification method of embodiments of this disclosure.

[0030] The operating terminal 200 and the test platform 100 can establish a connection via an interface device or a communication device. Users can transmit register verification-related data, files, or other information (such as operation instructions) to the test platform via the operating terminal. The test platform can read the user-input data, files, or other information and execute the register verification method of this embodiment. Users can also manage the execution process of the register verification method on the test platform via the operating terminal; for example, users can start, pause, stop, or exit the execution process of the register verification method.

[0031] In some examples, the operating terminal can be any electronic device with data processing capabilities, such as a desktop computer, laptop, or workstation. Users can send verification configuration information to the test platform via the operating terminal, including configuration parameters such as the semantic attributes of the target to be verified, the set sampling quantity for each subsystem, and the address information of special registers that are prohibited from access. The test platform can be a verification environment built based on the Universal Verification Methodology (UVM) for functional verification of the chip to be verified. After receiving the verification configuration information from the operating terminal, the test platform can determine the target registers to be verified based on the verification configuration information and the register attribute information of the chip to be verified, and execute the corresponding test cases for the target registers to complete the register access path verification. The test platform can then feed back the verification results to the operating terminal.

[0032] exist Figure 1 In the application scenario shown, the test platform 100, the operation terminal 200, and the chip to be verified 110 are illustrated as different physical devices. It should be noted that the test platform 100 and the operation terminal 200 can be integrated on the same physical device, and the chip to be verified 110 and the test platform 100 can also be integrated on the same physical device. This embodiment of the disclosure does not limit this.

[0033] Figure 2 This is a schematic diagram of the structure of a chip to be verified according to an embodiment of this disclosure. Figure 2 As shown, the chip to be verified 110 may include multiple subsystems. For example, the chip to be verified may include N subsystems, such as a first subsystem 111, a second subsystem 112, ..., an Nth subsystem 11N. Each subsystem of the chip to be verified may include multiple registers.

[0034] The chip to be verified can be a very large-scale system-on-a-chip (SOC), where the number of subsystems N can be an integer ranging from tens to hundreds, and the number of registers in each subsystem can reach thousands to tens of thousands.

[0035] exist Figure 1In the application scenarios shown, the register verification methods in related technologies mainly adopt the Register Abstraction Layer (RAL) model of general verification methodologies. For example, all registers in the chip to be verified can be read and written one by one to achieve full traversal access. However, due to the large number of registers in the chip to be verified, a single full traversal takes a very long time, making it difficult to meet the high-frequency regression requirements of agile development. Another example is that register reads and writes can be forced directly through backdoor paths at the Hardware Description Language (HDL) level. However, this method bypasses the physical bus path and cannot verify the functional correctness of the bus protocol, address decoder, and permission check modules, leading to the omission of SOC-level path defects. Yet another example is that access addresses and data can be generated for testing based on constraint-based random verification. However, this method lacks an understanding of the chip's specific hardware semantic attributes, resulting in a large number of random test cases being wasted on invalid addresses or non-target attributes. Furthermore, it is difficult to cover specific scenarios such as secure access control and virtualization function isolation. Moreover, random access may touch destructive registers, causing test suspension or hardware damage.

[0036] This disclosure provides a novel method for register verification. By assigning register attribute information, including hardware semantic attribute tags related to hardware access control mechanisms, to each register in the chip under test, and based on the register attribute information and verification configuration information, a set number of target registers with attribute tags containing target semantic attributes are sampled from multiple registers in each subsystem of the chip under test. This achieves a hierarchical sampling mechanism, enabling controllable directional sampling verification driven by hardware semantic attributes. Compared with full random sampling, this method improves verification reliability and significantly reduces verification time compared with full traversal schemes. It improves the efficiency of register verification while maintaining reliability, thereby solving all or part of the aforementioned problems.

[0037] Figure 3 This is a flowchart illustrating a register verification method provided in an embodiment of this disclosure. The register verification method can be performed by... Figure 1 The test platform shown can be used for execution, or it can be executed by any electronic device. For example... Figure 3 As shown, the register verification method of this embodiment may include the following steps S310 to S330.

[0038] Step S310: Obtain the register attribute information and verification configuration information of the chip to be verified.

[0039] The chip to be verified can be, for example, Figure 1 or Figure 2The chip to be verified 110 shown may include multiple subsystems, and each subsystem may include multiple registers.

[0040] In some examples, the register attribute information may include attribute labels for each register of the chip under test, which can be used to characterize one or more hardware semantic attributes of the register in relation to the hardware access control mechanism in the hardware architecture of the chip under test.

[0041] This hardware semantic attribute can characterize the register's attributes at the chip hardware level, related to access permission control, functional isolation access control, address mapping access control, etc. Through this hardware semantic attribute, the register's behavior under different access scenarios can be determined. By assigning attribute labels to registers, the verification process can gain the ability to understand the characteristics of the chip hardware architecture, thereby enabling verification of specific hardware semantic attributes.

[0042] In some examples, the hardware semantic attribute may include at least one of the following: security, virtualization, reserved address, or normal read / write attribute, which will be described below.

[0043] Security attributes can be used to identify registers controlled by security access permissions. For example, access to a register with a security attribute label requires meeting specific security access conditions, such as having a specific security access identifier. When a master device accessing the register does not have the corresponding security access permissions, access to that register can be denied. For instance, in a chip supporting TrustZone security isolation technology, registers located in the secure zone or registers controlled by security configuration registers can only be accessed by master devices with a security access identifier; access by a master device without a security access identifier can trigger a permission denial response. Exemplarily, the address of a register with a security attribute label can be an address located in the secure zone or controlled by a security configuration register.

[0044] Virtualization attributes can be used to identify registers associated with virtualization function isolation. This virtualization function isolation can occur in chips supporting virtualization technologies such as Single Root I / O Virtualization (SR-IOV), where the same physical hardware resource can be virtualized into multiple virtual functions, and register access between different virtual functions needs to be isolated. Registers with virtualization attributes can present different access permissions or data content from the perspectives of physical functions (PF) and virtual functions (VF). When the Virtual Machine Identifier (VMID) or Address Space Identifier (ASID) carried by the host device does not match, the access can trigger an isolation rejection response. For example, the address of a register labeled with virtualization attributes can be an address that supports SR-IOV and exhibits differences between the physical and virtual function perspectives.

[0045] The reserved address attribute can be used to identify registers whose addresses fall within an unmapped reserved region of the chip's address space. For example, the address space of the chip to be verified may contain mapped regions and unmapped reserved regions. Mapped regions may correspond to actual existing hardware registers or memory, while unmapped reserved regions may not correspond to any valid hardware resources. Register addresses with the reserved address attribute may be located within unmapped reserved regions. When a read or write access is initiated to this address, the chip may return an access error response or an access timeout response to indicate that the address is inaccessible. For example, the address of a register with the reserved address attribute may be located within the reserved address space of the chip to be verified.

[0046] General read / write attributes can be common function registers. For example, general read / write attributes can be used to identify registers that can be read from or written to; for instance, they can be registers not subject to security access control and not involved in virtualization function isolation, or registers subject to security access control or involved in virtualization function isolation. For example, a register with general read / write attributes can be read and written by any accessing master device under non-security and non-virtualization mechanisms. Access to this register does not require a specific security or virtualization identifier, and its access behavior can follow general read / write timing and data format.

[0047] In some examples, register attribute information can be obtained by parsing the memory-mapped I / O (MMIO) address map provided by the design. This address map records information such as the address range, access permissions, and subsystem to which each register belongs in the chip under test. The address map can be parsed automatically using scripts to extract the address information of each register and add corresponding attribute tags to the registers based on the characteristics of the address region. For example, register addresses located in the secure region can be labeled with a security attribute; register addresses supporting SR-IOV and exhibiting PF and VF perspective differences can be labeled with a virtualization attribute; addresses falling into unmapped reserved regions can be labeled with a reserved address attribute; and other regular function register addresses can be labeled with a general read / write attribute.

[0048] In some examples, a register may have one or more attribute labels. For example, the same register may have attribute labels for both security and virtualization attributes, or it may have labels for security, virtualization, and general read / write attributes. Optionally, a register with a reserved address attribute may not have other attributes, such as security, virtualization, and general read / write attributes.

[0049] In some examples, the verification configuration information described above may include a target semantic attribute and a set sampling number for each subsystem. The target semantic attribute may be an attribute to be verified among one or more hardware semantic attributes.

[0050] For example, the target semantic attribute can be a type of hardware semantic attribute that the user expects to focus on or verify during register verification. The user can send this verification configuration information to the test platform via an operating terminal, specifying that the target semantic attribute for this verification is any one or more of the hardware semantic attributes, so as to perform targeted verification on registers in the chip to be verified that have the target semantic attribute. For example, if the target semantic attribute includes a security attribute, targeted verification can be performed on registers in the chip to be verified that have security attributes. As another example, if the target semantic attribute includes a virtualization attribute, targeted verification can be performed on registers with virtualization attributes. Yet another example, if the target semantic attribute includes a reserved address attribute, targeted verification can be performed on registers with reserved address attributes.

[0051] The aforementioned sampling number characterizes the number of registers selected from registers with target semantic attributes within each subsystem. This sampling number can be less than the total number of registers in the subsystem. By limiting the sampling number, verification time can be significantly shortened while achieving verification coverage.

[0052] In some examples, the set sampling number can be the minimum of a user-preset fixed value and the number of registers with the target semantic attributes within the subsystem. For example, the user can specify that each subsystem samples 16 registers. If the number of registers with the target semantic attributes in the first subsystem is 32, then the set sampling number for the first subsystem is 16; if the number of registers with the target semantic attributes in the second subsystem is 8, then the set sampling number for the second subsystem is 8.

[0053] In other examples, the set sampling number can be determined based on a fixed proportion of the number of registers with the target semantic attributes within the subsystem. This fixed proportion can be a pre-defined proportion. For example, a user can set the fixed proportion to 10%, and determine the set sampling number for each subsystem based on this fixed proportion and the number of registers with the target semantic attributes within each subsystem.

[0054] In other examples, the set sampling number can be determined based on a fixed value, a fixed ratio, and the number of registers with target semantic attributes within the subsystem. For example, the candidate sampling number of the subsystem can be determined based on the fixed ratio and the number of registers with target semantic attributes within each subsystem, and the minimum value between the candidate sampling number and the fixed value can be used as the set sampling number.

[0055] In some examples, the verification configuration information described above may also include the address information of a special register that is prohibited from access. This special register may be one that, if verified, would cause a test hang, hardware damage, or other unforeseen consequences, and may not be included in the target register for verification. For example, this special register may include at least one of a phase-locked loop configuration register, a fuse bit register, a debug register, or other registers that are prohibited from random access, which will be described separately below.

[0056] The phase-locked loop (PLL) configuration register can be a register that controls the clock frequency. For example, this PLL configuration register can be used to configure the internal clock frequency of the chip under test. Incorrect writing to this register will cause abnormal clock frequency, which may lead to chip malfunction or test platform hang. Therefore, it can be set as a special register that is inaccessible.

[0057] The fuse bit register may include a register with one-time write capability. For example, the fuse bit register may be used to store permanent configuration information of the chip, which cannot be recovered once written, and an incorrect write to this register may cause permanent damage to the chip.

[0058] The debug register may include registers for controlling the chip's debug interface. For example, the debug register can control the chip's debug functions, and random access to this register may trigger unexpected debug mode switching, leading to test process interruption or verification environment anomalies.

[0059] In some examples, the address information of special registers can be provided through a blacklist in the verification configuration information. This blacklist can record the address information of all special registers that are prohibited from random access. This blacklist can be stored in the form of a file or configuration, for example, it can be accumulated by the user based on engineering experience and provided to the test platform via a file. The test platform can automatically filter the register addresses in the blacklist during the sampling process.

[0060] Step S320: Determine the target register of each subsystem in the chip to be verified based on the register attribute information and verification configuration information.

[0061] Each subsystem's target register may include a predetermined number of registers sampled from multiple registers within that subsystem, and the target register's attribute label may include the aforementioned target semantic attribute. This predetermined number of samples may be less than or equal to the total number of registers in the subsystem; for example, it may be less than or equal to the total number of registers in the subsystem whose attribute labels include the aforementioned target semantic attribute.

[0062] For example, the target register can be a register that needs to be tested in register verification. The sampling process described above can be a process of selecting a subset of registers from the set of registers that meet certain conditions (e.g., attribute labels contain target semantic attributes) of each subsystem according to a specific strategy. Through sampling, key verification scenarios can be covered with a smaller test scale without performing a full traversal.

[0063] In some examples, if the verification configuration information includes the address information of special registers that are prohibited from access, then the target register does not include the special registers determined based on the verification configuration information; conversely, if the verification configuration information does not include the address information of special registers that are prohibited from access, then the target register does not need to consider special registers.

[0064] By introducing a blacklist of prohibited special register addresses into the verification configuration information and automatically filtering these special registers during the target register determination phase, test suspension or hardware corruption caused by random access during the verification process can be prevented, thereby improving the security and stability of the verification process and also increasing verification efficiency.

[0065] In some examples, sampling can be performed separately for each subsystem to achieve a hierarchical sampling mechanism. The sampling strategy within each subsystem can be a random sampling strategy or other sampling strategies. For example, each subsystem in the chip to be verified can be traversed, and for each subsystem, a set of registers whose attribute labels contain or are equal to the target semantic attribute and whose addresses are not on the blacklist (i.e., the address information of special registers that are prohibited from access) can be selected from the set of registers using a preset strategy to generate the target registers of the subsystem (i.e., the final test register list). The preset strategy can include a maximum-minimum-mid address boundary sampling strategy (e.g., a Max-Min-Mid strategy, which can forcibly select the maximum, minimum, and middle addresses of the address space, combined with random sampling to cover the boundaries) or an array sampling mode, etc. For example, the array sampling mode can uniformly extract samples from the candidate register set at fixed intervals as target registers. For example, after sorting the candidate registers by address value, registers are selected sequentially with equal steps (i.e., the interval value obtained by dividing the total number by the target sampling number), so that the sampling results are uniformly distributed throughout the entire address space. Compared to pure random sampling, array sampling mode can achieve uniform coverage of the address space and avoid the local clustering problem that may occur in random sampling.

[0066] Step S330: Execute test cases corresponding to the target semantic attributes for the target register to perform register verification.

[0067] The test case can be a verification scenario designed for a specific hardware semantic attribute. By executing the test case, the access behavior of the register under that hardware semantic attribute can be verified to meet expectations. Different target semantic attributes can correspond to different test cases. For example, when the target semantic attribute includes a security attribute, the test cases corresponding to the security attribute can be executed. As another example, when the target semantic attribute includes a virtualization attribute, the test cases corresponding to the virtualization attribute can be executed. Yet another example, when the target semantic attribute includes a reserved address attribute, the test cases corresponding to the reserved address attribute can be executed. And yet another example, when the target semantic attribute includes a general read / write attribute, the test cases corresponding to the general read / write attribute can be executed.

[0068] In some examples, the test cases corresponding to the aforementioned security attributes include: switching the secure access flag and non-secure access flag of the Verification IP (VIP) to access the register to verify the register's secure access permission control logic. The VIP can be a reusable verification component used to verify a specific bus protocol. This component can simulate the behavior of the bus master device and initiate bus transactions conforming to the protocol specifications. The secure access flag can be a signal or flag bit carried by the VIP when initiating a bus transaction, indicating secure access permissions, while the non-secure access flag can indicate non-secure access permissions. For example, if the target register is register A with a security attribute, in this test case, the VIP can first be configured to carry the secure access flag to initiate a read / write transaction to the address of register A, verifying whether the read / write transaction is successfully completed and checking whether the read data or the data read back after writing meets expectations. Then, the VIP can be configured to carry the non-secure access flag to initiate another read / write transaction to the address of register A, verifying whether the read / write transaction triggers a permission denial response. This permission denial response can be an error response signal defined in the bus protocol. By initiating access with the non-secure access flag, it can be verified whether the access triggers a permission denial response. If the security access control logic of register A is correct, access carrying a non-secure access flag can be denied, the VIP will receive a permission denial response, and the contents of register A will not be modified. If the VIP does not receive a permission denial response, or the contents of register A are illegally modified, it indicates that the security access control logic may be flawed. This test case verifies whether the chip's access control function under the security mechanism is correctly implemented. It should be noted that the bus in this example can be the bus between various subsystems within the chip under verification, such as the PCIe bus or UCIe bus.

[0069] In other examples, test cases corresponding to virtualization attributes include: switching between the physical function identifier and virtual function identifier of the verification intellectual property core, and accessing registers to verify the access isolation control logic of registers under different virtualization function identities. The physical function identifier can be a signal or flag bit carried by the VIP when initiating a bus transaction, representing the physical function identity; the virtual function identifier can represent the virtual function identity. In chips supporting SR-IOV virtualization technology, the same physical hardware resource can be virtualized into multiple virtual functions. Register access between different virtual functions needs to be isolated from each other. The virtual function identifier typically includes a Virtual Machine Identifier (VMID) or an Address Space Identifier (ASID). For example, if the target register is register B with virtualization attributes, in this test case, the VIP can first be configured to carry the physical function identifier and initiate a read / write transaction to the address of register B, verifying whether the read / write transaction is successfully completed. Then, the VIP can be configured to carry the virtual function identifier, for example, a virtual function identifier with VMID of 1, and again initiate a read / write transaction to the address of register B, verifying whether the access result of this read / write transaction from the perspective of the virtual function is isolated from that from the perspective of the physical function. The VIP is then configured to carry a virtual function identifier with VMID 2, initiating a read / write transaction to the address of register B to verify whether access between different virtual functions is isolated from each other. Further, when an access is initiated with an unauthorized function identifier, it is verified whether the access triggers an isolation rejection response. For example, if virtual function 1 attempts to access a register address belonging only to virtual function 2, this access can be rejected, and the VIP can receive an isolation rejection response. The isolation rejection response can be an error response signal defined in the bus protocol. If the virtualization function isolation logic is correct, unauthorized access can be rejected. If the VIP does not receive an isolation rejection response, it indicates that the virtualization function isolation logic may have a defect. This test case verifies whether the chip's register function isolation mechanism is correctly implemented in a virtualization scenario.

[0070] In some examples, test cases for reserved address attributes include: initiating read / write access to an unmapped reserved address corresponding to a register, and verifying whether the read / write access triggers an access error response. An unmapped reserved address can be an address range in the chip's address space that has not been allocated to any valid hardware resources. When accessing this address range, the chip can return an access error response to indicate that the address is inaccessible. For example, if the target register is address C with a reserved address attribute, configure the VIP to initiate a read / write transaction to address C, and verify whether the read / write transaction triggers an access error response, such as returning a bus error or terminating within a timeout threshold. If the reserved address attribute processing logic for address C is correct, the VIP can receive a bus error response or detect an access timeout within the timeout threshold without a system hang. If the VIP does not receive an error response or a system hang occurs, it indicates that the reserved address attribute processing logic may be defective. This test case verifies whether the chip's registers correctly implement address inclusion for reserved address attributes.

[0071] In some other examples, test cases corresponding to general read / write attributes include: verifying read / write operations on registers, such as verifying the read / write attributes of mapped address registers. For instance, if the target register is register D with general read / write attributes, the VIP is configured not to carry a security access identifier and a virtual function identifier. A read / write transaction is initiated to the address of register D, and the success of the read / write transaction is verified. The read data or the data read back after writing is checked to see if it matches expectations. This test case verifies whether the chip's general read / write operations on registers are correctly implemented.

[0072] In this way, by customizing corresponding test cases for various hardware semantic attributes, differentiated verification of security isolation logic, virtualization function isolation logic, reserved address error response and regular read and write functions is achieved. This makes the verification logic of different hardware semantic attributes consistent with the actual hardware behavior of the chip, improves the pertinence and effectiveness of verification, and enhances the reliability of register verification.

[0073] By employing the method described in steps S310 to S330, register attribute information, including hardware semantic attribute tags related to the hardware access control mechanism, is assigned to each register in the chip to be verified. Based on the register attribute information and verification configuration information, a set number of target registers with attribute tags containing target semantic attributes are sampled from multiple registers in each subsystem of the chip to be verified. This achieves a hierarchical sampling mechanism and enables controllable directional sampling verification driven by hardware semantic attributes. Compared with full random sampling, this improves verification reliability and significantly reduces verification time compared with the full traversal scheme. It improves the efficiency of register verification while maintaining reliability, thereby meeting the high-frequency regression verification requirements in agile chip development.

[0074] In some examples of this disclosure, the register verification performed in step S330 above may include steps S3301 to S3304.

[0075] Step S3301: Determine the bus read / write transactions of the target register and the expected response results corresponding to the bus read / write transactions based on the test cases.

[0076] For example, the bus read / write transaction can be a read or write operation initiated based on the bus protocol. The bus read / write transaction may include information such as transaction address, transaction type (read or write), transaction data (write operation), and transaction attributes (such as security identifier, virtualization identifier, etc.). The expected response result may include the response result that the chip under test, designed according to the test case, can return for the bus read / write transaction. For example, the response result may include information such as response type (success response, error response, etc.) and response data (read operation).

[0077] Step S3302: By verifying the master device interface of the intellectual property core, initiate a bus read / write transaction to the bus address corresponding to the target register.

[0078] For example, the master device interface is an interface provided by the Validation Intellectual Property Core (VIP) for initiating bus transactions. This interface can simulate the behavior of a bus master device, initiating read and write transactions according to the timing and signal requirements of the bus protocol. The bus address refers to the address of the target register in the chip's bus address space. In some examples, the VIP's master device interface is connected to the bus interface of the chip under test. The master device interface initiates bus read and write transactions to the bus address of the target register. These transactions pass through internal chip hardware units such as bus interconnects, address decoders, and permission checking modules to reach the subsystem where the target register resides.

[0079] Step S3303: Obtain the actual response result returned by the chip to be verified for the bus read / write transaction through the master device interface.

[0080] The actual response result refers to the actual response returned by the chip under test for bus read and write transactions. This response result may include information such as response type and response data.

[0081] Step S3304: Determine the verification result of the target register based on the actual response result and the expected response result.

[0082] The verification result refers to determining whether the access behavior of the target register meets expectations by comparing the actual response result with the expected response result. In some examples, if the actual response result matches the expected response result, the verification of the target register is considered successful. If the actual response result does not match the expected response result, the verification of the target register is considered unsuccessful.

[0083] In some examples, taking a test case corresponding to a security attribute and register A as the target register, the bus read / write transactions determined in step S3301 can include read transactions carrying a security access identifier and read transactions carrying a non-security access identifier. For read transactions carrying a security access identifier, the expected response is a success response, and the response data is the current value of the target register. For read transactions carrying a non-security access identifier, the expected response is a permission denial response. By determining the bus read / write transactions and the expected response results, a basis for judgment can be provided for subsequent actual verification. Furthermore, for write transactions, the expected response result can also include whether the value of the register is correctly updated after the write.

[0084] Further, in steps S3302 to S3304, the VIP's master device interface can initiate a read transaction carrying a security access identifier. The transaction address is the bus address of register A. This read transaction is transmitted to the chip to be verified via the bus. The chip's internal permission check module checks the security identifier of the transaction, confirms that the transaction has secure access rights, and allows the transaction to access register A. The slave device returns the current value of register A as response data. After receiving this response data, the VIP's master device interface can record it as the actual response result. For a read transaction carrying a security access identifier, the actual response result is a successful response and the response data is the current value of register A, which is consistent with the expected response result, confirming that the verification is successful.

[0085] Furthermore, the VIP's master interface can also initiate read transactions carrying a non-secure access identifier. The chip's internal permission check module checks the transaction's security identifier, confirms that the transaction does not have secure access rights, denies the transaction's access to register A, and returns a permission denial response. The VIP's master interface receives this permission denial response and records it as the actual response result. Thus, for read transactions carrying a non-secure access identifier, the actual response result is a permission denial response, consistent with the expected response result, confirming that the verification has passed.

[0086] If a read transaction carrying a non-secure access identifier actually responds successfully, while the expected response is a permission denied response, then the actual response is inconsistent with the expected response, and the verification is deemed a failure, indicating a defect in the security access control logic of register A. The verification result can be recorded in a verification report for analysis by verification engineers or design engineers. Optionally, the verification result can be fed back from the test platform to the operating terminal for user viewing.

[0087] In some examples of this disclosure, the above step S320, which determines the target register of each subsystem in the chip to be verified based on register attribute information and verification configuration information, may include: for each subsystem of the chip to be verified, obtaining registers whose attribute labels contain target semantic attributes from multiple registers of the subsystem as a candidate register set corresponding to the subsystem; and selecting a set number of registers from the candidate register set corresponding to the subsystem based on a pre-set target sampling algorithm as the target register corresponding to the subsystem.

[0088] For example, the candidate register set can be the set of all registers within a subsystem whose attribute labels match the target semantic attribute. For instance, suppose the chip to be verified includes a first subsystem and a second subsystem, the target semantic attribute is a security attribute, and the sampling quantity is set to 10. For the first subsystem, all registers whose attribute labels contain the security attribute are selected from multiple registers in that subsystem. If the number of selected registers is 50, then these 50 registers constitute the candidate register set corresponding to the first subsystem.

[0089] Furthermore, a blacklist filtering mechanism can be applied when obtaining the candidate register set. For example, if the verification configuration information contains the address information of special registers that are prohibited from access, then when filtering registers whose attribute labels contain the target semantic attribute, registers whose addresses are in the blacklist will be further excluded. This ensures that the candidate register set does not contain special registers, avoiding the selection of registers that should not be accessed during subsequent sampling, and improving the reliability of register verification.

[0090] In some examples, the target sampling algorithm described above can be a strategy for selecting target registers from a set of candidate registers. For instance, if the set of candidate registers corresponding to the first subsystem contains 50 registers, and the sampling quantity is set to 10, then 10 registers can be selected from the 50 registers as the target registers corresponding to the first subsystem based on the target sampling algorithm. For other subsystems (e.g., the second to the Nth subsystems), the target registers corresponding to each subsystem can be determined in the same way.

[0091] In this way, by determining the target register of each subsystem in the chip to be verified through two stages of attribute filtering and random sampling, the target register can be determined more efficiently and accurately, thereby improving the reliability of register verification.

[0092] In some examples, the target sampling algorithm described above may include a maximum and minimum intermediate address boundary sampling algorithm; the method of selecting a set number of registers from the candidate register set as the target registers corresponding to the subsystem based on a pre-defined target sampling algorithm may include: determining the register address value of each candidate register in the candidate register set; designating the registers with the largest, smallest, and median register address values ​​as first-class registers; randomly selecting multiple candidate registers from the other candidate registers besides the first-class registers as second-class registers; and determining the target register based on the first-class registers and the second-class registers.

[0093] For example, the register address value can be the physical address of the register in the chip address space. In some examples, if the candidate register set contains multiple registers such as register A, register B, and register C, the address value of each register can be read from the register attribute information. For example, the address value of register A is 0x1000, the address value of register B is 0x2000, the address value of register C is 0x3000, and so on. By determining the address values ​​of each candidate register, a maximum-minimum intermediate address boundary sampling algorithm can be executed to determine a first category of registers, which can be registers whose address values ​​are located at the boundary and intermediate positions in the candidate register set.

[0094] For example, if the candidate register set contains 50 registers, the address values ​​of these 50 registers are sorted. The register with the smallest address value is denoted as Register Min, the register with the largest address value is denoted as Register Max, and the register with the middle address value is denoted as Register Mid. For example, the address value of Register Min is 0x1000, the address value of Register Max is 0xFFFF, and the address value of Register Mid is 0x8000. Registers Min, Max, and Mid are designated as the first type of register. By forcibly selecting registers at the boundaries and middle positions of the address space, the operating state of the address decoder in different address ranges can be covered.

[0095] The second type of registers mentioned above can be registers randomly selected from the candidate register set, excluding the first type of registers. For example, if the sampling quantity is set to 10, and 3 registers have already been selected as the first type of registers, then from the 50 registers in the candidate register set, the 3 selected first type registers are excluded, and 7 registers are randomly selected from the remaining 47 registers as the second type of registers. Random selection can be implemented based on a random number generator, for example, using a pseudo-random number generator to generate 7 unique random indices, and selecting the corresponding registers from the remaining 47 registers based on the random indices.

[0096] Furthermore, the first type of registers and the second type of registers can be merged to obtain the target registers corresponding to the subsystem. For example, if the first type of registers contains 3 registers and the second type of registers contains 7 registers, merging them will result in 10 target registers.

[0097] In this way, the maximum and minimum intermediate address boundary sampling algorithm not only achieves forced coverage of the address space boundary and intermediate position, but also provides statistical coverage of other address ranges through random sampling. Thus, with a limited number of samples, it can simultaneously cover the address space boundary and randomly distributed areas, improving the detection capability of potential boundary defects in a single sampling.

[0098] In some examples, the target sampling algorithm described above may include a random sampling algorithm that samples based on a set random seed.

[0099] For example, the random seed can be an initialization parameter of a pseudo-random number generator. Different random seeds can cause the pseudo-random number generator to produce different random number sequences. The initial value of the random seed can be set by the user in the verification configuration information, or it can be randomly generated by the test platform. The test platform can use the random seed to initialize the pseudo-random number generator, and randomly select a set number of registers as target registers from the candidate register set based on the random numbers generated by the pseudo-random number generator. Since the random number sequence is related to the random seed, different random seeds can select different target registers.

[0100] In some examples, the register verification method may further include: cyclically executing multiple rounds of sampling verification steps. These sampling verification steps may include steps S320 and S330, namely, determining the target register for each subsystem in the chip to be verified based on register attribute information and verification configuration information, and executing test cases corresponding to the target semantic attributes for the target register to perform register verification. When cyclically executing multiple rounds of sampling verification steps, the random seeds used in different rounds of sampling verification steps can be different, thus ensuring that the target registers selected in different rounds are different.

[0101] For example, if the user specifies 10 rounds of sampling verification, the first round uses a random seed of 1, the second round uses a random seed of 2, and so on, with the tenth round using a random seed of 10. In each round of sampling verification, a set number of registers are randomly selected from the candidate register set of each subsystem as target registers based on the random seed of the current round, and the target registers are verified. Since the random seeds are different in different rounds, the target registers selected in each round are also different. Through multiple rounds of sampling verification, more registers in the candidate register set can be statistically covered, thereby improving the coverage and reliability of the verification.

[0102] In this way, by using multiple rounds of sampling verification steps and changing the random seed, this example can cover different subsets of register samples in each round of verification while keeping the verification time controllable. After multiple iterations and regressions, the coverage of registers can be improved, and even statistical coverage of the complete address space of the target attribute register can be achieved. This enables the completeness of long-term verification while controlling the scale of a single verification.

[0103] Figure 4 This is a flowchart illustrating another register verification method provided in an embodiment of this disclosure. Figure 4 As shown, the method may include one or more of the steps S410 to S450.

[0104] Step S410: Register attribute parsing and classification.

[0105] In some examples, a design-provided MMIO address mapping table can be input into the test platform to assign hardware semantics to the registers, supporting subsequent targeted sampling. For instance, the mapping table can be parsed via a script to add attribute tags to the registers. These attribute tags can include hardware semantic attributes, which may include at least one of the following: security, virtualization, reserved address (Hole), or normal read / write attributes. This allows the acquisition of the register attribute information for the chip under test.

[0106] Step S420, Configuration Management and Blacklist Filtering.

[0107] For example, the testing platform can receive verification configuration information (such as configuration parameters) input by the user, determine the verification target based on the verification configuration information, and improve the security of the test.

[0108] In some examples, users can specify target semantic attributes, a blacklist file, and a set sampling quantity for each subsystem. The blacklist file may include address information for special registers that are prohibited from random access, such as clock PLLs, fuse bits, debug interfaces, etc.

[0109] It should be noted that the specific implementation of steps S410 and S420 can also refer to the process of obtaining register attribute information or obtaining verification configuration information in step S310 of the foregoing embodiments of this disclosure, which will not be repeated here.

[0110] Step S430: Layered sampling.

[0111] For example, the test platform can perform tiered sampling based on the register attribute information obtained in step S410 and the verification configuration information (e.g., configuration parameters) obtained in step S420 to obtain the target register to be verified, thereby improving the coverage of key attributes while controlling the test scale. Optionally, this tiered sampling can be tiered random sampling.

[0112] In some examples, each subsystem in the chip to be verified can be traversed. For each subsystem, a set of registers within that subsystem whose attribute labels contain or equal to the target semantic attribute and whose addresses are not on the blacklist (i.e., the address information of special registers that are prohibited from access) is selected. If the set of registers is not empty, a preset strategy is used to select a set number of samples to generate the target registers of the subsystem (i.e., the final test register list). This preset strategy may include a Max-Min-Mid strategy or an array sampling mode, etc.

[0113] Step S430 may include an attribute determination step, such as determining whether the attribute label of the currently sampled register contains the target semantic attribute. If the determination result is negative, it means that the current register does not meet the target semantic attribute, and the process returns to the hierarchical sampling step to continue sampling the next register. If the determination result is positive, it means that the current register meets the target semantic attribute, and the current register can be used as the target register, proceeding to step S440 to execute the test case.

[0114] It should be noted that the specific implementation of step S430 can also refer to the description of step S320 in the foregoing embodiments of this disclosure, and will not be repeated here.

[0115] Step S440: Execute the test cases.

[0116] In this step, test cases corresponding to the target semantic attributes can be determined based on the target semantic attributes, and the test cases corresponding to the target semantic attributes can be executed for the target register to perform register verification.

[0117] For example, the corresponding test cases can be executed based on the VIP front door path verification.

[0118] The test cases corresponding to the target semantic attributes can include at least one of the following: security test cases, virtualization test cases, reserved address test cases, and general read / write test cases. This VIP front-door path verification can initiate bus read / write transactions to the Design Under Test (DUT) through the VIP's master device interface. The DUT can be the chip to be verified, such as an instance of the chip to be verified simulated or emulated in the verification environment. The VIP's master device interface is connected to the DUT's bus interface. After the bus read / write transactions initiated by the VIP are processed by the DUT's internal hardware unit, the DUT returns the actual response result.

[0119] In this step, the correctness of the SOC-level physical path can be verified through real bus transactions. Instead of using the backdoor path of the RAL model, a real Read / Write Transaction is initiated through the bus VIP Master interface to improve test reliability. Specifically, security test cases can switch the VIP's Secure / Non-secure access flags to verify the access control logic; virtualization test cases can attach VMID / ASID flags to verify the isolation of the PF / VF view; reserved address test cases (Hole test) can verify whether unmapped addresses return bus errors or terminate within a timeout threshold; and general read / write test cases (Normal test) can verify the read / write attributes of mapped address registers.

[0120] It should be noted that the specific implementation of step S440 can also refer to the description of step S330 in the foregoing embodiments of this disclosure, and will not be repeated here.

[0121] Step S450, regression testing.

[0122] For example, regression testing can be performed using a regression system that can manage the execution of multi-round sampling verification. The regression system can change the random seed and re-trigger steps S410 to S440 to achieve multi-round regression verification. In some examples, during multi-round regression verification, steps S410 and S420 can be executed only in the first round of verification, and subsequent rounds of verification can execute only steps S430 and S440 to improve verification efficiency.

[0123] In this step, the verification can be determined by comparing the actual bus response with the expected response. When the target semantic attribute is a reserved address attribute, it can be verified whether an error response is returned and no hangup occurs; when the target semantic attribute is a security attribute, it can be verified whether insecure access returns a permission error.

[0124] In this way, the actual response result returned by the bus VIP can be used to determine whether the verification is successful, and long-term statistical coverage can be achieved through multiple rounds of regression verification. For example, by changing the random seed to perform multiple rounds of regression, statistical coverage of the entire address space can be achieved.

[0125] By employing the methods described in steps S410 to S450, and introducing multi-dimensional hardware semantic attribute tags, the verification process gains an understanding of the chip's hardware architecture characteristics. This allows for targeted verification of specific hardware semantic attributes, avoiding the waste of numerous invalid test cases in random verification common in related technologies. By independently executing layered random sampling within each subsystem, local coverage is achieved while limiting the global test scale, reducing the full traversal time from several hours to minutes, meeting the high-frequency regression requirements of agile development. By initiating real bus read / write transactions using the VIP's master device interface, the functional correctness of the bus interconnect, address decoding, and permission checking modules is verified, covering the SOC-level physical path and filling the blind spots of traditional RAL backdoor verification. Furthermore, a blacklist mechanism filters destructive registers, effectively preventing erroneous operations on special registers such as the PLL configuration register, fuse bit register, and debug register, improving the operational stability of the verification platform and preventing test suspension or hardware damage. By cyclically executing multiple rounds of sampling verification and changing the random seed, statistical coverage of the entire address space is achieved, improving the verification coverage.

[0126] This disclosure also provides an electronic device, such as... Figure 5As shown, the electronic device 500 may include a processor 510 and a memory 520. The memory can be used to store computer instructions, and the processor can be used to retrieve computer instructions from the memory to execute all or part of the steps of any of the methods in the foregoing embodiments of this disclosure. The processor may be one or more, and these processors may execute instructions individually or jointly. Similarly, the memory may be one or more, and these memories may store the aforementioned computer instructions individually or jointly. In some examples, the processor may be a CPU, GPU, GPGPU, NPU, or TPU, or it may be a chip in the form of an Application Specific Integrated Circuit (ASIC), System on Chip (SOC), Field Programmable Gate Array (FPGA), Programmable Logic Array (PLA), etc. In some examples, the electronic device may be any type of terminal device, workstation, or server, etc., and this embodiment does not limit this. Optionally, the electronic device may be... Figure 1 The test platform shown.

[0127] This disclosure also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements all or part of the steps of any of the methods in the foregoing embodiments of this disclosure. Optionally, the computer-readable storage medium may be a non-transitory storage medium, but is not limited thereto, and may also be a temporary storage medium.

[0128] This disclosure also provides a computer program product that may include a computer program that, when executed by a processor, can implement all or part of the steps of any of the methods in the foregoing embodiments of this disclosure.

[0129] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0130] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and apparatuses according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, unit, or part of a circuit. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should be noted that embodiments of the present disclosure may include some or all of the functions marked in the multiple blocks in the drawings, and may also include other functions not shown in the blocks in the drawings. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented in hardware that performs the specified function or action, or in a combination of dedicated hardware and computer instructions. Unless otherwise specified, implementation in hardware, implementation in software, and implementation in a combination of software and hardware may be equivalent.

[0131] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of this disclosure is defined by the appended claims.

Claims

1. A register verification method, characterized in that, The method includes: Obtain register attribute information and verification configuration information of the chip to be verified; wherein, the chip to be verified includes multiple subsystems, each subsystem includes multiple registers, the register attribute information includes attribute tags of each register of the chip to be verified, the attribute tags are used to characterize one or more hardware semantic attributes of the register in the hardware architecture of the chip to be verified related to the hardware access control mechanism, and the verification configuration information includes target semantic attributes and the set sampling number of each subsystem, the target semantic attribute is the attribute to be verified among one or more of the hardware semantic attributes; The target register of each subsystem in the chip to be verified is determined based on the register attribute information and the verification configuration information; wherein, the target register of each subsystem includes a set number of registers sampled from multiple registers of the subsystem, and the attribute label of the target register contains the target semantic attribute, and the set number of samples is less than the total number of registers in the subsystem; Test cases corresponding to the target semantic attributes are executed for the target register to perform register verification.

2. The method according to claim 1, characterized in that, The step of determining the target register of each subsystem in the chip to be verified based on the register attribute information and the verification configuration information includes: For each subsystem of the chip to be verified, the registers whose attribute labels contain the target semantic attribute are obtained from multiple registers of the subsystem as a candidate register set corresponding to the subsystem; From the candidate register set corresponding to the subsystem, a predetermined number of registers are selected from the candidate register set based on a pre-defined target sampling algorithm, and these are used as the target registers corresponding to the subsystem.

3. The method according to claim 2, characterized in that, The target sampling algorithm includes a maximum and minimum intermediate address boundary sampling algorithm; the step of selecting a predetermined number of registers from the candidate register set as the target registers corresponding to the subsystem based on the pre-defined target sampling algorithm includes: Determine the register address value of each candidate register in the candidate register set; The registers with the largest, smallest, and middle address values ​​are designated as the first type of registers; Randomly select multiple candidate registers from the candidate registers other than the first type of registers as the second type of registers; The target register is determined based on the first type of register and the second type of register.

4. The method according to claim 2, characterized in that, The target sampling algorithm includes a random sampling algorithm based on a set random seed; the method further includes: The sampling verification steps are executed in multiple rounds. Each sampling verification step includes determining the target register of each subsystem in the chip to be verified based on the register attribute information and the verification configuration information. The test cases corresponding to the target semantic attributes are executed for the target registers to perform register verification. The random seeds used in different rounds of sampling verification steps are different.

5. The method according to claim 1, characterized in that, The hardware semantic attributes include at least one of security attributes, virtualization attributes, or reserved address attributes; The security attribute is used to identify registers that are subject to security access permissions; The virtualization attributes are used to identify registers related to virtualization function isolation; The reserved address attribute is used to identify registers whose addresses fall into unmapped reserved intervals in the chip's address space.

6. The method according to claim 5, characterized in that, The test cases corresponding to the security attributes are security test cases, which include: switching the security access identifier and non-security access identifier of the verification intellectual property core, accessing the register, and verifying the security access permission control logic of the register; The test cases corresponding to the virtualization attributes are virtualization test cases. The virtualization test cases include: switching the physical function identifier and virtual function identifier of the intellectual property core for verification, and accessing the register to verify the access isolation control logic of the register under different virtualization function identities. The test cases corresponding to the reserved address attribute are reserved address test cases, which include: initiating read and write access to the unmapped reserved address corresponding to the register, and verifying whether the read and write access triggers an access error response.

7. The method according to any one of claims 1 to 6, characterized in that, The step of executing test cases corresponding to the target semantic attributes for the target register to perform register verification includes: Based on the test cases, determine the bus read / write transactions of the target register and the expected response results corresponding to the bus read / write transactions; By verifying the main device interface of the intellectual property core, the bus read / write transaction is initiated to the bus address corresponding to the target register; The actual response result returned by the chip to be verified for the bus read / write transaction is obtained through the main device interface. The verification result of the target register is determined based on the actual response result and the expected response result.

8. The method according to any one of claims 1 to 6, characterized in that, The verification configuration information also includes the address information of special registers that are prohibited from access; the target register does not include the special registers; The special register includes at least one of the following: A phase-locked loop configuration register that controls the clock frequency; A fuse bit register with one-time write capability; Debug registers are used to control the debug interface of the chip being verified.

9. An electronic device, characterized in that, The method includes a memory and a processor, the memory being used to store computer instructions, and the processor being used to retrieve the computer instructions from the memory to perform the method of any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images