Chip verification method, device, equipment, storage medium and program product

Abstract

The application provides a chip verification method, device, equipment, storage medium and program product, and relates to the technical field of integrated circuits. The method comprises the following steps: obtaining configuration information corresponding to a current verification task based on interface management configuration information; creating at least one sender instance and at least one receiver instance corresponding to the current verification task in a verification environment based on the configuration information corresponding to the current verification task; determining a constraint condition corresponding to the current verification task based on access rule configuration information, wherein the constraint condition is used to define an access rule between the sender instance and the receiver instance; and executing the current verification task in the verification environment based on the constraint condition corresponding to the current verification task. The method can realize NOC multi-level verification sharing of a verification environment, thereby reducing the waste of time and resources.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and in particular to a chip verification method, apparatus, device, storage medium, and program product. Background Technology

[0002] Chip verification is the process of checking whether the designed chip circuit diagram is correct and whether it can work properly.

[0003] NOC (Network-on-Chip) is a communication infrastructure within a chip, responsible for routing and transmitting data between various functional units within the chip (such as the CPU (Central Processing Unit), GPU (Graphics Processing Unit), and memory controller), efficiently and correctly transmitting data from the sender (master) to the receiver (slave). NOC multi-level verification refers to verifying the chip at different levels, including module-level verification, subsystem-level verification, and system-level verification.

[0004] In current chip verification solutions, different verification environments need to be built for different levels of verification, which results in a waste of time and resources. Summary of the Invention

[0005] This application provides a chip verification method, apparatus, device, storage medium, and program product. The technical solution provided by this application is as follows:

[0006] According to one aspect of the embodiments of this application, a chip verification method is provided, the method comprising:

[0007] Based on the interface management configuration information, obtain the configuration information corresponding to the current verification task; wherein, the interface management configuration information includes the configuration information corresponding to the verification tasks of multiple levels of the chip to be verified, and the configuration information corresponding to the current verification task is used to indicate the functional unit in the chip to be verified that acts as the sender and the functional unit that acts as the receiver when the current verification task is executed.

[0008] Based on the configuration information corresponding to the current verification task, at least one sender instance and at least one receiver instance corresponding to the current verification task are created in the verification environment;

[0009] Based on the access rule configuration information, the constraints corresponding to the current verification task are determined, and the constraints are used to indicate the access rules between the sender instance and the receiver instance.

[0010] Based on the constraints corresponding to the current verification task, the at least one sender instance and the at least one receiver instance are applied in the verification environment to execute the current verification task and obtain the verification result of the current verification task.

[0011] According to one aspect of the embodiments of this application, a chip verification apparatus is provided, the apparatus comprising:

[0012] The information acquisition module is used to acquire the configuration information corresponding to the current verification task based on the interface management configuration information; wherein, the interface management configuration information includes the configuration information corresponding to the verification tasks of multiple levels of the chip to be verified, and the configuration information corresponding to the current verification task is used to indicate the functional unit in the chip to be verified that acts as the sender and the functional unit that acts as the receiver when the current verification task is executed.

[0013] The instance creation module is used to create at least one sender instance and at least one receiver instance corresponding to the current verification task in the verification environment based on the configuration information corresponding to the current verification task.

[0014] The condition determination module is used to determine the constraint conditions corresponding to the current verification task based on the access rule configuration information. The constraint conditions are used to indicate the rules between the sender instance and the receiver instance.

[0015] The task execution module is used to execute the current verification task based on the constraints corresponding to the current verification task, and apply the at least one sender instance and the at least one receiver instance in the verification environment to obtain the verification result of the current verification task.

[0016] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the chip verification method described above.

[0017] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is executed by a processor to implement the chip verification method described above.

[0018] According to one aspect of the embodiments of this application, a chip is provided, the chip including programmable logic circuits and / or program instructions, which, when the chip is running, are used to implement the chip verification method described above.

[0019] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the chip verification method described above.

[0020] The technical solutions provided in this application embodiment may have the following beneficial effects:

[0021] By defining interface management configuration information, which contains configuration information corresponding to multiple verification tasks at different levels, it is possible to create sender and receiver instances corresponding to any level of verification task in the verification environment based on this interface management configuration information. Then, combined with predefined access rules, the above verification tasks are executed in the verification environment, realizing that multiple verification tasks at different levels can share the same verification environment, which helps to reduce the waste of time and resources. Attached Figure Description

[0022] Figure 1 This is a flowchart of a chip verification method provided in one embodiment of this application;

[0023] Figure 2 This is a schematic diagram of the various subsystems included in the chip to be verified provided in one embodiment of this application;

[0024] Figure 3 This is a schematic diagram illustrating the definition of master and slave for a NOC subsystem-level verification task, provided in one embodiment of this application.

[0025] Figure 4 This is a schematic diagram illustrating the definition of master and slave for a NOC system-level verification task, provided in one embodiment of this application.

[0026] Figure 5 This is a block diagram of a chip verification apparatus provided in one embodiment of this application;

[0027] Figure 6 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0029] Chip verification is the process of checking whether the designed chip circuit diagram is correct and whether it can function properly. From the initial chip architecture design to the final tape-out, verification work runs through the entire design process, accounting for about 70% of the total workload of chip design.

[0030] The sheer scale of chip design, the exponentially increasing complexity of chip structures, ubiquitous connectivity, and platform security place higher demands on chip design and manufacturing processes. In an environment of advanced processes, a perfectly functioning chip requires multi-level, iterative verification.

[0031] NOC (Network Controller) is a communication infrastructure within a chip, responsible for data routing and transmission between various functional units (such as CPU, GPU, and memory controller) within the chip, efficiently and correctly transmitting data from the sender (master) to the receiver (slave). NOC multi-level verification refers to verifying the chip at different levels, such as module-level verification, subsystem-level verification, and system-level verification. Each level has a different focus.

[0032] Block-level verification focuses on verifying the functionality of a specific functional unit within the chip. Subsystem-level verification focuses on verifying the connections and communication between different functional units of the chip, typically involving a portion of the Network Object Configuration (NOC). System-level verification focuses on verifying the entire chip, such as verifying whether the entire chip functions correctly, whether the hardware and software work together seamlessly, and whether data flows correctly and efficiently throughout the chip; this involves the complete NOC.

[0033] In related technologies, for module-level verification, a simple verification environment needs to be built focusing solely on the specific functional unit to be verified. For subsystem-level verification, a verification environment is built that includes all functional units within the subsystem and their interconnections (NOC interfaces). For system-level verification, a complex verification environment is built that includes all subsystems of the entire chip, a complete NOC network, and the ability to run real or simulated software.

[0034] In current chip verification solutions, different verification environments need to be built for different levels of verification, which results in a waste of time and resources.

[0035] Based on this, embodiments of this application provide a chip verification method that enables multi-level NOC verification to share a verification environment, thereby reducing the waste of time and resources.

[0036] The method provided in this application can be executed by a computer device in each step. Optionally, the computer device can be an electronic device with data computing and storage capabilities, such as a PC (Personal Computer), a computer, or a server.

[0037] Please refer to Figure 1 The diagram illustrates a flowchart of a chip verification method provided in one embodiment of this application. The execution subject of this method can be the computer device described above. The method may include at least one of the following steps 110-140.

[0038] Step 110: Based on the interface management configuration information, obtain the configuration information corresponding to the current verification task; wherein, the interface management configuration information includes the configuration information corresponding to the verification tasks at multiple levels of the chip to be verified, and the configuration information corresponding to the current verification task is used to indicate the functional units in the chip to be verified that act as the sender and the functional units that act as the receiver when executing the current verification task.

[0039] The chip to be verified can be any chip that needs to be verified. It should be understood that the chip to be verified can be a designed chip circuit diagram, not necessarily a chip that has already been fabricated. Because chip fabrication is costly, it is often necessary to verify the chip before fabrication to ensure that it functions correctly.

[0040] The interface management configuration information contains configuration information for multiple verification tasks at different levels for the chip to be verified. For each level of verification task, the configuration information defines the functional units in the chip to be verified that act as the sender (master) and the functional units that act as the receiver (slave) when executing the verification task at that level. The current verification task can be any one of the multiple verification tasks at different levels.

[0041] In some embodiments, the chip to be verified includes at least one subsystem, and each subsystem includes at least one functional unit. For example, as... Figure 2 As shown, the chip to be verified includes at least one of the following subsystems: SM (System Management) subsystem (shown as sm_ss in the figure), computing subsystem (including at least one of cpu_ss, gpu_ss, and npu_ss output in the figure), storage subsystem (shown as ddr_ss in the figure), expansion and interconnect subsystem (including at least one of pcie_ss and peri_ss output in the figure), and NOC subsystem (shown as NOC in the figure).

[0042] The SM subsystem is responsible for basic chip control and low-power management, essentially serving as the chip's operational hub. The SM subsystem may include at least one of the following functional units: an SPI (Serial Peripheral Interface) controller, a QSPI (Quad Serial Peripheral Interface) controller, a UART (Universal Asynchronous Receiver / Transmitter) controller, and a MCU (Microcontroller Unit). The SPI controller is used to connect low-speed devices, such as sensors. The QSPI controller is used for flash memory communication. The UART controller is used for debug communication. The MCU is a lightweight processor used to handle system management tasks.

[0043] The computing subsystem may include at least one of the following subsystems: CPU subsystem (shown as cpu_ss in the diagram), GPU subsystem (shown as gpu_ss in the diagram), and NPU subsystem (shown as npu_ss in the diagram). The computing subsystem is responsible for high-performance computing tasks and is the chip's computing engine. The CPU subsystem may be a multi-core CPU cluster, including multiple APs (Application Processors). The GPU subsystem may include functional units such as graphics processing cores and texture processing units. The NPU subsystem may include functional units such as neural network accelerators and tensor computation units.

[0044] The storage subsystem manages off-chip memory access, acting as the chip's data warehouse manager. The storage subsystem may include functional units such as a 64-channel DDR (Double Data Rate) memory controller and a memory scheduler.

[0045] The expansion and interconnect subsystem provides external device connectivity and high-speed data transmission, serving as the chip's external interface. This subsystem may include at least one of the following subsystems: a PCIe (Peripheral Component Interconnect Express) subsystem (shown as pcie_ss in the diagram) and a peripheral subsystem (shown as peri_ss in the diagram). The PCIe subsystem may include functional units such as a PCIe root compound and a high-speed serial controller. The peripheral subsystem may include functional units such as an I2C (Inter-Integrated Circuit) controller, a GPIO (General Purpose Input Output) module, and a USB (Universal Serial Bus) / SDIO (Secure Digital Input Output) interface controller.

[0046] The Network Address Channel (NOC) is the chip's internal communication network. The NOC subsystem connects various subsystems and is responsible for data routing and transmission between them. By introducing network routing technology, the NOC forms an efficient data transmission path within the chip, replacing the traditional bus architecture and solving bandwidth bottlenecks and latency issues. It provides parallel communication capabilities for modules such as the processor core, memory units, and AI (Artificial Intelligence) accelerators, improving overall system performance and scalability.

[0047] In some embodiments, the verification tasks at multiple different levels include: a system-level verification task and at least one subsystem-level verification task. The system-level verification task is used to verify the chip as a whole. The subsystem-level verification task is used to verify a subsystem within the chip.

[0048] For example, multiple verification tasks at different levels include: system-level verification tasks and at least one of the following subsystem-level verification tasks: SM subsystem-level verification tasks, computing subsystem-level verification tasks (such as CPU subsystem-level verification tasks, GPU subsystem-level verification tasks, NPU subsystem-level verification tasks), storage subsystem-level verification tasks, expansion and interconnect subsystem-level verification tasks (such as PCIe subsystem-level verification tasks, peripheral subsystem-level verification tasks), NOC subsystem-level verification tasks, and so on.

[0049] The NOC subsystem-level verification task refers to the phase of testing the NOC itself and within a relatively localized environment containing multiple related modules (subsystems). The focus of this phase is to verify whether the NOC's connectivity and communication functions are normal within this localized scope.

[0050] For example, the focus of system-level verification tasks is to verify the entire chip, such as whether the entire chip is working properly, whether the software and hardware can work together, and whether the data flows correctly and efficiently between different subsystems of the chip. This involves the complete NOC.

[0051] For example, the focus of subsystem-level verification tasks is to verify the connections and communication between different functional units of the chip, such as verifying whether a certain subsystem is working properly, and whether the flow of data within a certain subsystem is correct and efficient. This usually involves a part of the NOC (Network Object Configuration).

[0052] Optionally, such as Figure 3 As shown, for NOC subsystem-level verification tasks, verification engineers simulate each subsystem (such as sm_ss, cpu_ss, etc.) as a "data sender" (Master) and "data receiver" (Slave) corresponding to the interfaces (Ports) that the NOC module connects to. The NOC module has many physical or logical interfaces, which are the points of connection between the NOC and various external subsystems. Each interface is the entry or exit point for the NOC to receive data (from other subsystems) or send data (to other subsystems). The "data sender" (Master) actively sends access requests (read or write) to the NOC, requesting access to a specific Slave. For example, if the CPU wants to read data from memory (DDR), the CPU is the Master. The "data receiver" (Slave) receives requests from the Master (forwarded by the NOC) and responds (such as returning data or confirming the write). For example, if memory (DDR) receives a read request from the CPU and returns data, the DDR is the Slave.

[0053] For each NOC input port connected to a subsystem, the verification environment instantiates a Slave Verification Component (UVC) at that port. From the perspective of this port, data flows into the NOC; that is, the NOC receives requests from the external Master through this port. This Slave UVC simulates the behavior of the subsystem sending requests to the NOC. In this scenario, the subsystem acts as the Master, but the NOC's port receives requests, so the Slave UVC is instantiated to simulate the peer's behavior.

[0054] For a NOC output port connected to a subsystem, the verification environment instantiates a Master Verification Component (UVC) at that port. From the port's perspective, data flows out of the NOC; that is, the NOC sends requests or data to an external slave from this port. This Master UVC simulates the NOC sending requests to that subsystem. In this scenario, the subsystem acts as a slave, but since the NOC's port sends requests, the Master UVC is instantiated to simulate the peer's behavior.

[0055] Instantiate the corresponding Master or Slave verification components for the NOC interface (Port) connected to these subsystems to simulate the behavior of the subsystem interacting with the NOC through this interface. The verification component itself represents the communication role (Master / Slave) on the interface, rather than directly becoming the hardware of that subsystem.

[0056] Optionally, such as Figure 4 As shown, for system-level verification tasks, verification engineers will simulate the external interfaces of specific functional modules (IP cores) within each subsystem (such as sm_ss, cpu_ss, etc.) as "data senders" (Masters) and "data receivers" (Slaves) corresponding to these Sub_NOC interfaces, based on the interfaces (Ports) of the lower-level, finer-grained NOC modules (Sub_NOCs). The NOC itself may be a complex, hierarchical network, for example, containing multiple Sub_NOCs. A Sub_NOC refers to a lower-level, more localized network module within the NOC network. The Sub_NOC interface is the physical or logical interface through which a Sub_NOC exchanges data with external entities (such as the specific functional modules / IP cores connected to that Sub_NOC).

[0057] In subsystem-level verification tasks, the entire subsystem (such as sm_ss) is typically treated as a black box, focusing only on its interaction with the NOC through one or a few interfaces. System-level verification tasks, however, require a deeper dive into the subsystem's internals. Each subsystem consists of multiple specific functional modules (IP cores) (e.g., sm_ss includes SM_SPI_M / S, SM_QSPI_M / S, SM_UART_M / S, SM_MCU_M / S, etc.). These specific IP cores are the entities that actually generate data (Master behavior) or consume data (Slave behavior). Each of them has its own independent interface connecting to the NOC (usually connected to a specific Sub_NOC).

[0058] For a Sub_NOC input port connected to an IP core interface (data flowing into the Sub_NOC), the authentication environment instantiates a Slave Authentication Component (UVC) at that port. This is because, from the perspective of this port, data flows into the Sub_NOC; that is, the Sub_NOC receives requests from the external IP core (acting as the Master) through this port. This Slave UVC simulates the behavior of that IP core sending requests to the Sub_NOC.

[0059] For a Sub_NOC output port connected to an IP core interface (data flows out of the Sub_NOC), the authentication environment instantiates a Master Authentication Component (UVC) at that port. This is because, from the perspective of this port, data flows out of the Sub_NOC; that is, the Sub_NOC sends requests or data from this port to the external IP core (acting as a Slave). This Master UVC simulates the behavior of the Sub_NOC sending requests to that IP core.

[0060] Here, Master / Slave refers to the role of the UVC instantiated in the verification environment. This role is determined by the data flow of Sub_NOCPort, ultimately simulating the behavior of the IP core interface. In a real chip, this IP core may be either a Master or a Slave.

[0061] Because multiple interface protocol modules in a chip design (such as SPI, QSPI, UART, DDR controller, etc.) participate simultaneously in both NOC system-level verification and NOC subsystem-level verification, this provides a natural foundation for reusing the same verification environment across different verification levels. However, in these two different verification tasks, the specific locations (ports) where the Master / Slave verification components (UVCs) representing these modules are connected to the NOC differ. To address the issues arising from this location difference, this application collects and configures the key configuration information of the Master / Slave (including parameters such as address width, data width, and ID width, as well as their specific locations in the design) into a file called UVC_INFO, which is the interface management configuration information mentioned above.

[0062] In some embodiments, taking the current verification task as an example, the configuration information corresponding to the current verification task includes: attribute information of at least one functional unit in the chip to be verified that acts as the sender, and attribute information of at least one functional unit in the chip to be verified that acts as the receiver, when the current verification task is executed. The attribute information includes at least one of the following: name, data bit width, address bit width, and position in the chip to be verified.

[0063] For example, ADDR_WIDTH is the address bus width; DATA_WIDTH is the data bus width; WID_WIDTH is the write transaction ID width, used to distinguish concurrent write requests; RID_WIDTH is the read transaction ID width, used to distinguish concurrent read requests; AUSER_WIDTH is the address channel user-defined signal width; ALEN_WIDTH is the address channel burst length signal width; RTL_HIER_RTL_FILE is an example location that specifies which specific location (hierarchy) and which file (file) in the design (RTL) the Master / Slave UVC should connect to. For example, SM_SS_M in subsystem-level verification might connect to noc_top.port_sm_ss in the top-level NOC. As another example, SM_SPI_M in system-level verification might connect to sub_noc_sm.port_spi in the Sub_NOC.

[0064] The UVC_INFO file records the definitions of all Master / Slave UVCs that may be used in different levels of verification. For each UVC, all its key configuration parameters (address width, data width, etc.) and the most critical location information (RTL_HIER_RTL_FILE) are recorded.

[0065] Step 120: Based on the configuration information corresponding to the current verification task, create at least one sender instance and at least one receiver instance corresponding to the current verification task in the verification environment.

[0066] When building the verification environment, the system reads a configuration file named UVC_INFO (i.e., the interface management configuration information mentioned above). This file contains the definition information of all Master and Slave verification components (UVCs) that may be used in NOC subsystem-level verification and NOC system-level verification. The verification environment selects the corresponding Master / Slave definition information from this file based on the current verification level (subsystem-level or system-level) and specific requirements. Then, it dynamically creates (instantiates) these components within the verification environment and connects them to the locations specified in the design (RTL). Instantiation refers to the dynamic creation of instances of specific Master or Slave verification components (UVCs) according to the descriptions in UVC_INFO when the program runs (verification environment starts).

[0067] For example, UVC instances specifically used for system-level verification include at least one of the following: SM_SPI_M / SM_SPI_S, representing the UVC of the SPI master / slave interface controller; SM_QSPI_M / SM_QSPI_S, representing the UVC of the QSPI master / slave interface controller; SM_UART_M / SM_UART_S, representing the UVC of the UART master / slave interface controller; and SM_MCU_M / SM_MCU_S, representing the UVC of the MCU interface controller. During system-level verification, the verification environment reads the UVC information corresponding to these specific, fine-grained IP modules from UVC_INFO and creates these UVC instances on their respective connected Sub_NOC Ports. This reflects the characteristic of system verification penetrating into specific modules within subsystems.

[0068] For example, a UVC instance specifically used for subsystem-level verification (such as SM subsystem-level verification) includes at least one of the following: SM_SS_M / SM_SS_S. During subsystem-level verification, the verification environment reads this UVC information, representing the entire subsystem, from UVC_INFO and creates this UVC instance on the top-level NOC Port connecting to the subsystem. This reflects the characteristic of subsystem verification treating the subsystem as a black box as a whole.

[0069] For example, both system-level and subsystem-level verification require UVC instances that include at least one of the following: DDR_LL0_S, DDR_LL1_S, ..., DDR_LL63_S, representing Slave UVCs for 64 DDR memory channel controllers. The UVC definition information for these DDR controllers exists only once in UVC_INFO. However, both subsystem-level verification (potentially testing within the DDR subsystem) and system-level verification (testing the entire chip's access to DDR) require the use of Slave UVCs representing these specific DDR channels.

[0070] When the verification environment starts, it determines whether the current verification task corresponds to a subsystem-level or system-level verification task. Then, it retrieves all UVC entries suitable for the current verification task from the UVC_INFO file. For subsystem-level verification tasks, it instantiates SM_SS_M / SM_SS_S (representing the entire sm_ss) and DDR_LLx_S (representing a specific DDR channel, if the test involves DDR). For system-level verification tasks, it instantiates SM_SPI_M / SM_SPI_S, SM_QSPI_M / SM_QSPI_S, SM_UART_M / SM_UART_S, SM_MCU_M / SM_MCU_S (representing specific IPs within sm_ss), DDR_LLx_S (representing specific DDR channels), and UVCs for specific IPs within other subsystems such as CPU and GPU. For shared components (such as DDR_LLx_S), regardless of the verification task level, the verification environment will instantiate them based on the same definition information in UVC_INFO whenever the test requires them.

[0071] In some embodiments, step 120 includes: creating at least one sender instance corresponding to the current verification task in the verification environment based on attribute information of at least one functional unit in the chip to be verified as a sender when the current verification task is executed, wherein each sender instance is created based on attribute information of a functional unit as a sender; and creating at least one receiver instance corresponding to the current verification task in the verification environment based on attribute information of at least one functional unit in the chip to be verified as a receiver when the current verification task is executed, wherein each receiver instance is created based on attribute information of a functional unit as a receiver.

[0072] Because the configuration information corresponding to the current verification task includes attribute information of at least one functional unit in the chip to be verified that acts as the sender, and attribute information of at least one functional unit in the chip to be verified that acts as the receiver, at least one sender instance and at least one receiver instance corresponding to the current verification task can be created in the verification environment based on this configuration information.

[0073] The aforementioned at least one sender instance can be created based on the attribute information of at least one functional unit in the chip under test that acts as a sender. For example, a corresponding sender instance is created based on the attribute information of a functional unit in the chip under test that acts as a sender. This sender instance corresponds to the name, data bit width, address bit width, and location in the chip under test indicated by the aforementioned attribute information.

[0074] The aforementioned at least one receiver instance can be created based on the attribute information of at least one functional unit in the chip to be verified that acts as a receiver. For example, a corresponding receiver instance is created based on the attribute information of a functional unit in the chip to be verified that acts as a receiver. This receiver instance corresponds to the name, data bit width, address bit width, and location in the chip to be verified indicated by the aforementioned attribute information.

[0075] The above method enables the accurate creation of at least one sender instance and at least one receiver instance corresponding to the current verification task based on the configuration information corresponding to the current verification task, ensuring the availability of the created sender instance and receiver instance.

[0076] Step 130: Based on the access rule configuration information, determine the constraints corresponding to the current verification task. The constraints are used to indicate the access rules between the sender instance and the receiver instance.

[0077] To clearly define and manage the complex communication relationships within the chip, including who can access whom and what the address ranges are, this application introduces access rule configuration information. This access rule configuration information can also be implemented as a structured table, hence it can also be called the ADDR_MAP table, used to centrally and clearly describe the aforementioned access relationships and address boundary information. This table consists of three main parts, describing the address space partitioning (REGION_INFO), slave device ownership (SLAVE_INFO), and master device access permissions (MASTER_INFO).

[0078] In some embodiments, the access rule configuration information includes: region information (REGION_INFO), receiver information (SLAVE_INFO), and sender information (MASTER_INFO).

[0079] Region information indicates the address information used to divide the address space of the chip under verification into multiple regions. Each region includes one or more functional units. The purpose of region information is to divide the entire chip's large, contiguous physical address space into several smaller, logical regions. Optionally, region information includes fields such as region name, start address, and end address. The region name (region_name) is a unique identifier for the region. The start address (start_addr) is the starting physical address of the region. The end address (end_addr) is the ending physical address of the region. By dividing the chip into regions, address management and access control are simplified.

[0080] Receiver information is used to indicate the region to which each slave in the chip under test belongs. The purpose of receiver information is to define which region(s) each slave belongs to. The address range of a slave must fall entirely within the address range of one or more regions. Optionally, receiver information may include fields such as slave name and region name. The slave name (slave_name) is the unique identifier of the slave. The region name (region_name) is the name of the region to which the slave belongs; this field indicates which region the slave belongs to. Receiver information establishes the affiliation relationship between slaves and regions. Knowing which region a slave belongs to reveals its approximate address range (limited by the region's start_addr and end_addr). For example, a DDR controller (DDR_LL0_S) might belong to the DDR_REGION.

[0081] Sender information is used to indicate the regions that each sender (Master) in the chip under test is allowed to access. The purpose of sender information is to define which regions each sender (Master) is authorized to access; this is the core of access control. Optionally, sender information may include fields such as sender name and region name. The sender name (master_name) is a unique identifier for the sender. The region name (region_name) refers to the region name that the sender is allowed to access; this field indicates which region the Master has permission to enter. Managing Master access to Slave indirectly through Regions greatly simplifies configuration. For example, the CPU (CPU_Master) might be authorized to access MEM_REGION (containing all DDR controllers) and PERI_REGION (containing peripheral controllers).

[0082] Optionally, the sender information also indicates which regions the sender (Master) is allowed to access, and which receivers (Slaves) the sender (Master) is allowed to access and / or is prohibited from accessing. Master access permissions are granted per Region, not directly per Slave. If a Master is authorized to access a Region (region_name), it automatically gains access to all Slaves within that Region (because these Slaves belong to that Region). However, if the sender information also defines which receivers (Slaves) the sender (Master) is prohibited from accessing within a region, then the sender (Master) cannot access these receivers (Slaves). This approach allows for flexible definition of which receivers (Slaves) the sender (Master) is allowed to access and / or is prohibited from accessing within a region, thus more flexibly meeting fine-grained verification requirements.

[0083] In some embodiments, step 130 includes: determining the access rules between the sender instance and the receiver instance corresponding to the current verification task based on the region information, receiver information and sender information, and obtaining the constraint conditions corresponding to the current verification task.

[0084] Since the region information indicates multiple regions in the address space of the chip under test, the receiver information indicates the region to which the receiver in the chip under test belongs, and the sender information indicates the regions that the sender in the chip under test is allowed to access, as well as the receivers that the sender is allowed to access and / or prohibits access to within those regions, combining the above three aspects of information, along with the positions of the sender and receiver instances in the chip under test, it is possible to determine which sender instance is allowed to access which receiver instances(s), and which sender instance is prohibited from accessing which receiver instances(s). In other words, the access rules between the sender and receiver instances can be determined as constraints. For example, if receiver instance 1 and receiver instance 2 both belong to region A, and a certain sender instance is allowed to access region A, and the prohibited receiver instances in region A include receiver instance 1 but not receiver instance 2, then it can be determined that the sender instance is allowed to access receiver instance 2 and prohibited from accessing receiver instance 1.

[0085] By configuring access rules, the access rules between the sender and receiver instances can be determined accurately and efficiently, ensuring that the current verification task can be executed accurately in accordance with the constraints in subsequent stages.

[0086] Step 140: Based on the constraints corresponding to the current verification task, apply at least one sender instance and at least one receiver instance in the verification environment to execute the current verification task and obtain the verification result of the current verification task.

[0087] After the above steps 120 and 130, on the one hand, at least one sender instance and at least one receiver instance corresponding to the current verification task are created in the verification environment, and on the other hand, the constraints corresponding to the current verification task are determined to define the access rules between the sender instance and the receiver instance, so that the current verification task can be executed in the verification environment.

[0088] In some embodiments, based on the constraints corresponding to the current verification task, test cases for executing the current verification task are generated by a script. These test cases are then executed in the verification environment for at least one sender instance and at least one receiver instance to obtain the verification result of the current verification task. Optionally, the script can be a Python script, which can automatically generate test cases for executing the current verification task. The computer device then executes these test cases to perform the current verification task.

[0089] In some embodiments, the address information used by the system-level verification task has additional flag bits compared to the address information used by the subsystem-level verification task. For example, the address information used by the system-level verification task is 52 bits, while the address information used by the subsystem-level verification task is 48 bits; the extra 4 bits are additional flag bits. These flag bits can be used to distinguish different subsystems, different security domains, or other attributes that need to be globally distinguishable.

[0090] In system-level verification tasks, the Master (the device initiating the access) sends a 52-bit global address. However, when this access request finally reaches the target subsystem (such as DDR SUB_NOC), the subsystem internally processes it using its own 48-bit local address. This means that the scoreboard used in the subsystem verification environment is designed to handle 48-bit local addresses. If the data packet with the 52-bit global address from system-level verification is directly sent to the subsystem-level verification scoreboard for comparison, the comparison will fail or result in an error due to the address width mismatch (4 extra flag bits).

[0091] To address the bit-width mismatch issue and achieve a shared scoreboard, this application proposes using a callback function. When the current verification task is a system-level verification task, this function executes test cases against at least one sender instance and at least one receiver instance in the verification environment to obtain the verification result of the current verification task. This includes: during the execution of the test cases, obtaining the receiver's address information contained in the access request initiated by the sender; removing the identifier bits from the receiver's address information to obtain the updated address information of the receiver; and submitting the updated address information of the receiver to a result comparator to obtain the verification result of the current verification task. The result comparator is used to obtain the data to be verified for the current verification task from the receiver based on the updated address information of the receiver, and compare the data to be verified with the expected result.

[0092] In a system-level verification environment, when the master initiates an access request with a 52-bit global address, this request traverses the entire chip path. The key point is that just as the data packet for this access request is about to enter the verification monitoring range of the target subsystem (such as DDR SUB_NOC), the system-level verification environment triggers a pre-set callback function. This callback function removes the extra 4 bits of the global address. After processing by the callback function, the original 52-bit global address is converted into a 48-bit local address. This converted address format is now completely consistent with the address format used internally by the target subsystem (such as DDR SUB_NOC). The data packet converted by the callback function (now with a 48-bit local address) is sent to the scoreboard used by the subsystem verification environment. Because this scoreboard is designed to handle 48-bit local addresses, it can correctly understand the address and compare the received data (the actual result) with the expected result. This achieves the goal of reusing the scoreboard from subsystem-level verification for result comparison in system-level verification.

[0093] Optionally, the result comparator obtains the data to be verified for the current verification task from the receiver based on the updated address information of the receiver, and compares the data to be verified with the expected result; if the data to be verified is the same as the expected result, the verification result of the current verification task is determined to be passed; if the data to be verified is different from the expected result, the verification result of the current verification task is determined to be failed.

[0094] By using the above methods, the address width difference between system-level verification (52-bit global addr) and subsystem-level verification (48-bit local addr) can be overcome, enabling a shared verification environment (especially a shared scoreboard).

[0095] In summary, the technical solution provided by this application defines interface management configuration information, which contains configuration information corresponding to multiple verification tasks at different levels. Therefore, based on this interface management configuration information, sender instances and receiver instances corresponding to any level of verification task can be created in the verification environment. Then, combined with predefined access rules, the above verification tasks are executed in the verification environment, realizing that multiple verification tasks at different levels can share the same verification environment, which helps to reduce the waste of time and resources.

[0096] Furthermore, this verification method, which uses a shared verification environment across multiple NOC levels, eliminates the need to rebuild the NOC verification environment when performing verification at various levels, especially at the NOC subsystem and system levels. For the differentiated master / slave information at each level, it is only necessary to maintain the configuration information uniformly through interface management, and instantiate the master and slave in the verification environment as needed. For complex paths, it is only necessary to first divide them into smaller regions based on the address; each region can include one or more slaves. Finally, the path is determined by the master pointing to different slaves, and then the access rule configuration information is drawn. A script program then transforms the access rule configuration information into the constraints of the test cases for the current verification task, enabling unified invocation. Managing the configuration information through interfaces and access rule configuration information makes the master / slave information and access relationships more accurate, while also improving verification efficiency.

[0097] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0098] Please refer to Figure 5 This diagram illustrates a block diagram of a chip verification apparatus according to an embodiment of this application. The apparatus has the functionality to implement the method examples described above; this functionality can be implemented in hardware or by hardware executing corresponding software. The apparatus can be the computer device described above, or it can be located within a computer device. The apparatus 500 may include: an information acquisition module 510, an instance creation module 520, a condition determination module 530, and a task execution module 540.

[0099] The information acquisition module 510 is used to acquire the configuration information corresponding to the current verification task based on the interface management configuration information; wherein, the interface management configuration information includes the configuration information corresponding to the verification tasks of multiple levels of the chip to be verified, and the configuration information corresponding to the current verification task is used to indicate the functional unit in the chip to be verified that acts as the sender and the functional unit that acts as the receiver when the current verification task is executed.

[0100] The instance creation module 520 is used to create at least one sender instance and at least one receiver instance corresponding to the current verification task in the verification environment based on the configuration information corresponding to the current verification task.

[0101] The condition determination module 530 is used to determine the constraint conditions corresponding to the current verification task based on the access rule configuration information. The constraint conditions are used to indicate the access rules between the sender instance and the receiver instance.

[0102] The task execution module 540 is used to execute the current verification task in the verification environment based on the constraints corresponding to the current verification task, by applying the at least one sender instance and the at least one receiver instance, and to obtain the verification result of the current verification task.

[0103] In some embodiments, the configuration information corresponding to the current verification task includes: attribute information of at least one functional unit in the chip to be verified as the sender and attribute information of at least one functional unit in the chip to be verified as the receiver when the current verification task is executed; wherein, the attribute information includes at least one of the following: name, data bit width, address bit width, and position in the chip to be verified.

[0104] In some embodiments, the instance creation module 520 is configured to: create at least one sender instance corresponding to the current verification task in the verification environment based on attribute information of at least one functional unit in the chip to be verified acting as a sender when the current verification task is executed, wherein each sender instance is created based on attribute information of a functional unit acting as a sender; and create at least one receiver instance corresponding to the current verification task in the verification environment based on attribute information of at least one functional unit in the chip to be verified acting as a receiver when the current verification task is executed, wherein each receiver instance is created based on attribute information of a functional unit acting as a receiver.

[0105] In some embodiments, the access rule configuration information includes: region information, used to indicate address information dividing the address space of the chip to be verified into multiple regions; wherein each region includes one or more functional units; receiver information, used to indicate the region to which each receiver in the chip to be verified belongs; sender information, used to indicate the regions that each sender in the chip to be verified is allowed to access, and used to indicate the receivers that the sender allows and / or prohibits from accessing in the regions that the sender is allowed to access.

[0106] In some embodiments, the condition determination module 530 is used to determine the access rules between the sender instance and the receiver instance corresponding to the current verification task based on the region information, the receiver information and the sender information, so as to obtain the constraint conditions corresponding to the current verification task.

[0107] In some embodiments, the task execution module 540 is configured to generate test cases for executing the current verification task based on the constraints corresponding to the current verification task through a script program; execute the test cases for the at least one sender instance and the at least one receiver instance in the verification environment to obtain the verification result of the current verification task.

[0108] In some embodiments, the plurality of verification tasks at different levels include: a system-level verification task and at least one subsystem-level verification task. The address information used by the system-level verification task has additional identifier bits compared to the address information used by the subsystem-level verification task. The task execution module 540 is configured to: obtain the address information of the receiver contained in the access request initiated by the sender during the execution of the test case; remove the identifier bits contained in the address information of the receiver to obtain the updated address information of the receiver; submit the updated address information of the receiver to a result comparator to obtain the verification result of the current verification task; wherein, the result comparator is configured to obtain the data to be verified for the current verification task from the receiver based on the updated address information of the receiver, and compare the data to be verified with the expected result.

[0109] In some embodiments, the chip to be verified includes at least one subsystem, and each subsystem includes at least one functional unit; the multiple verification tasks at different levels include: a system-level verification task and at least one subsystem-level verification task; the system-level verification task is used to verify the chip to be verified as a whole; the subsystem-level verification task is used to verify one subsystem of the chip to be verified.

[0110] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0111] Please refer to Figure 6 This diagram illustrates a structural block diagram of a computer device provided in one embodiment of this application. The computer device 60 may include: a processor 61, a memory 62, a communication interface 63, and a bus 65.

[0112] The processor 61 includes one or more processing cores, and the processor 61 executes various functional applications and information processing by running software programs and modules.

[0113] The memory 62 can be used to store computer programs, and the processor 61 is used to execute the computer programs to implement the chip verification method described above.

[0114] Communication interface 63 can be used to communicate with other devices, such as sending and receiving data.

[0115] The memory 62 is connected to the processor 61 via bus 65.

[0116] Furthermore, memory 62 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, including but not limited to: magnetic disks or optical disks, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), SRAM (Static Random-Access Memory), ROM (Read-Only Memory), magnetic storage, flash memory, and PROM (Programmable Read-Only Memory).

[0117] Those skilled in the art will understand that Figure 6 The structure shown does not constitute a limitation on the computer device 60, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0118] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program, when executed by a processor, implements the chip verification method described above. Optionally, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0119] In an exemplary embodiment, a chip is also provided, the chip including programmable logic circuits and / or program instructions, which, when the chip is running, are used to implement the chip verification method described above.

[0120] In an exemplary embodiment, a computer program product is also provided, the computer program product including a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, causing the computer device to perform the chip verification method described above.

[0121] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0122] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A chip verification method, characterized in that, The method includes: Based on the interface management configuration information, the configuration information corresponding to the current verification task is obtained. The interface management configuration information includes configuration information corresponding to multiple levels of verification tasks for the chip to be verified. These multiple levels of verification tasks include system-level verification tasks and at least one subsystem-level verification task. The configuration information corresponding to the current verification task is used to indicate the functional units in the chip to be verified that act as the sender and the functional units that act as the receiver when executing the current verification task. The address information used by the system-level verification task has additional identifier bits compared to the address information used by the subsystem-level verification task. Based on the configuration information corresponding to the current verification task, at least one sender instance and at least one receiver instance corresponding to the current verification task are created in the verification environment; Based on the access rule configuration information, the constraints corresponding to the current verification task are determined, and the constraints are used to indicate the access rules between the sender instance and the receiver instance. Based on the constraints corresponding to the current verification task, the at least one sender instance and the at least one receiver instance are applied in the verification environment to execute the current verification task and obtain the verification result of the current verification task. When the current verification task is the system-level verification task, obtain the address information of the receiver instance contained in the access request initiated by the sender instance; Remove the flag bits from the address information of the receiver instance to obtain the updated address information of the receiver instance; The updated address information of the receiver instance is submitted to the result comparator to obtain the verification result of the current verification task; wherein, the result comparator is used to obtain the data to be verified for the current verification task from the receiver instance based on the updated address information of the receiver instance, and compare the data to be verified with the expected result.

2. The method according to claim 1, characterized in that, The configuration information corresponding to the current verification task includes: attribute information of at least one functional unit in the chip to be verified as the sender and attribute information of at least one functional unit in the chip to be verified as the receiver when the current verification task is executed; wherein, the attribute information includes at least one of the following: name, data bit width, address bit width, and position in the chip to be verified; The step of creating at least one sender instance and at least one receiver instance corresponding to the current verification task in the verification environment based on the configuration information corresponding to the current verification task includes: Based on the attribute information of at least one functional unit in the chip to be verified that acts as a sender when the current verification task is executed, at least one sender instance corresponding to the current verification task is created in the verification environment, wherein each sender instance is created based on the attribute information of a functional unit that acts as a sender. Based on the attribute information of at least one functional unit in the chip to be verified as a receiver when the current verification task is executed, at least one receiver instance corresponding to the current verification task is created in the verification environment, wherein each receiver instance is created based on the attribute information of a functional unit as a receiver.

3. The method according to claim 1, characterized in that, The access rule configuration information includes: Region information is used to indicate address information that divides the address space of the chip to be verified into multiple regions; wherein each region includes one or more functional units; Receiver information is used to indicate the region to which each receiver in the chip to be verified belongs; Sender information is used to indicate the areas that each sender in the chip to be verified is allowed to access, and to indicate the receivers that the sender allows and / or prohibits access to in the areas that the sender is allowed to access; The step of determining the constraints corresponding to the current verification task based on access rule configuration information includes: Based on the region information, the receiver information, and the sender information, the access rules between the sender instance and the receiver instance corresponding to the current verification task are determined, and the constraints corresponding to the current verification task are obtained.

4. The method according to claim 1, characterized in that, The step of applying the at least one sender instance and the at least one receiver instance in the verification environment based on the constraints corresponding to the current verification task, and obtaining the verification result of the current verification task, includes: Based on the constraints corresponding to the current verification task, test cases for executing the current verification task are generated by a script program; The test cases are executed in the verification environment for the at least one sender instance and the at least one receiver instance to obtain the verification result of the current verification task.

5. The method according to any one of claims 1 to 4, characterized in that, The chip to be verified includes at least one subsystem, and each subsystem includes at least one functional unit. The verification tasks at multiple levels include: system-level verification tasks and at least one subsystem-level verification task; The system-level verification task is used to verify the chip to be verified as a whole; The subsystem-level verification task is used to verify one of the subsystems in the chip to be verified.

6. A chip verification device, characterized in that, The device includes: The information acquisition module is used to acquire the configuration information corresponding to the current verification task based on the interface management configuration information. The interface management configuration information includes configuration information corresponding to multiple levels of verification tasks for the chip to be verified. These multiple levels of verification tasks include system-level verification tasks and at least one subsystem-level verification task. The configuration information corresponding to the current verification task is used to indicate the functional units in the chip to be verified that act as the sender and the functional units that act as the receiver when executing the current verification task. The address information used by the system-level verification task has additional identifier bits compared to the address information used by the subsystem-level verification task. The instance creation module is used to create at least one sender instance and at least one receiver instance corresponding to the current verification task in the verification environment based on the configuration information corresponding to the current verification task. The condition determination module is used to determine the constraint conditions corresponding to the current verification task based on the access rule configuration information. The constraint conditions are used to indicate the access rules between the sender instance and the receiver instance. The task execution module is used to execute the current verification task in the verification environment based on the constraints corresponding to the current verification task, by applying the at least one sender instance and the at least one receiver instance, and to obtain the verification result of the current verification task. The task execution module is configured to, when the current verification task is the system-level verification task, obtain the address information of the receiving instance contained in the access request initiated by the sending instance; remove the identifier bits contained in the address information of the receiving instance to obtain the updated address information of the receiving instance; and submit the updated address information of the receiving instance to the result comparator to obtain the verification result of the current verification task; wherein, the result comparator is configured to, based on the updated address information of the receiving instance, obtain the data to be verified for the current verification task from the receiving instance, and compare the data to be verified with the expected result.

7. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, which is loaded and executed by the processor to implement the chip verification method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is executed by a processor to implement the chip verification method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, and a processor reads from and executes the computer program to implement the chip verification method as described in any one of claims 1 to 5.

Images