System-on-chip verification method, general verification methodology verification platform, verification device, system-on-chip and computer program product

Abstract

This application discloses an on-chip system verification method, a general verification methodology verification platform, a verification device, an on-chip system, and a computer program product. The on-chip system verification method includes: initiating a verification request to a shared memory region in the TCM of the on-chip system to be verified, which has K preset offset addresses. The verification request includes multiple read / write operations to be executed sequentially by the on-chip system to be verified. Each read / write operation carries at least its control word and target address information, where K is a natural number greater than 1; obtaining the read / write operation execution results returned by the on-chip system to be verified; and determining whether the on-chip system to be verified has passed the first verification based on the read / write operation execution results. This application can balance the flexibility of the verification environment and the authenticity of CPU function verification without requiring extensive software code maintenance.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a system-on-a-chip verification method, a general verification methodology verification platform, verification equipment, system-on-a-chip, and computer program products. Background Technology

[0002] In the verification process of System-on-Chips (SoCs), verification platforms based on the Universal Verification Methodology (UVM) can simulate the computational processing of the SoC's CPU in a simulation environment. This method directly accesses the bus, does not require CPU execution, and does not require writing or loading software code, making it highly versatile. However, its drawback is that it completely avoids the actual execution process of the CPU, resulting in poor verification realism. Summary of the Invention

[0003] This application provides a system-on-a-chip verification method, a general verification methodology verification platform, verification equipment, a system-on-a-chip, and a computer program product, so as to balance the flexibility of the verification environment and the authenticity of CPU function verification without requiring a large amount of software code maintenance.

[0004] In a first aspect, embodiments of this application provide an on-chip system verification method, applied to a general verification methodology verification platform, the method comprising: A verification request is initiated to a shared memory region with K preset offset addresses in the tightly coupled memory (TCM) of the system-on-chip to be verified. The verification request includes several read and write operations to be executed by the system-on-chip to be verified one by one. Each read and write operation carries at least its control word and target address information, and K is a natural number greater than 1. Obtain the read / write operation execution results returned by the system-on-chip to be verified, and determine whether the system-on-chip to be verified has passed the first verification based on the read / write operation execution results.

[0005] In at least one possible implementation, initiating a verification request to a preset shared memory region in the TCM of the system-on-chip to be verified specifically includes: According to the preset address mapping rules, the control word and target address information carried by each read and write operation are respectively filled into the corresponding offset address in the shared memory region; Of the K offset addresses, M offset addresses are used to store the target address carried by the read / write operation, one offset address is used to store the control word carried by the read / write operation, and at least one offset address is used to store the target data of the read / write operation; M is a natural number less than K.

[0006] In at least one possible implementation, the control word includes at least an operation type and a data width, wherein the operation type is set to a read operation or a write operation, and the data width is set to a power of 2 bytes, where N is a non-negative integer.

[0007] In at least one possible implementation, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule specifically includes: Fill the control word carried by each read / write operation into the offset address used to store the control word; Fill the target address of the write operation requesting 2 to the power of N bytes into the M offset addresses corresponding to the offset address of the data width of 2 to the power of N bytes; or The target address of the read operation is filled into the M offset addresses corresponding to the offset address of the read operation.

[0008] In at least one possible implementation, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule further includes: Fill the preset redundant data into M-1 offset addresses other than the offset address occupied by the target address of this read / write operation.

[0009] In at least one possible implementation, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule further includes: The preset redundant data is filled into the offset address used to store the target data in this read operation.

[0010] In at least one possible implementation, the target data of the write operation is filled into an offset address used to store the target data.

[0011] In at least one possible implementation, the target address of the read operation and the target address of the write operation, which stores the data width aligned with it, are filled into the same offset address in a time-division multiplexing manner.

[0012] In at least one possible implementation, obtaining the read / write operation execution result returned by the system-on-chip to be verified specifically includes: The read / write operation result is obtained by polling the execution result flags written by the on-chip system to the offset address used to store the control word; or The read / write operation result is obtained by accessing the offset address used to store the control word through a backdoor; or The read / write operation results are obtained through the interface module set up between the TCM and the TCM.

[0013] In at least one possible implementation, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule specifically includes: The control word carried by each read / write operation is filled into a preset first offset address within the shared memory region; and Fill the target address of the requested 1-byte write operation into the preset second offset address within the shared memory region; or Fill the target address of the requested 2-byte write operation into the preset third offset address within the shared memory region; or Fill the target address of the requested 4-byte write operation into the preset fourth offset address within the shared memory region; or Fill the target address of the read operation into the fourth offset address; and Fill the pre-defined redundant data into the third and fourth offset addresses, which are not occupied by the target address of the 1-byte write operation requested in this request; or Fill the pre-defined redundant data into the second and fourth offset addresses, which are not occupied by the target address of the 2-byte write operation requested in this request; or Fill the pre-defined redundant data into the second and third offset addresses, which are not occupied by the target address of the 4-byte write operation requested in this request; or The preset redundant data is filled into the second offset address, the third offset address, and the fifth offset address, which are not occupied by this read operation.

[0014] In at least one possible implementation, the on-chip system verification method further includes: Before initiating a verification request, wait for the system-on-chip to be verified to complete the initialization process; Based on any at least one operation in the initialization process, including instruction fetch, decoding, execution flow, enable cache, and bus interface unit, determine whether the on-chip system to be verified has passed the second verification.

[0015] Secondly, embodiments of this application provide a general verification methodology verification platform, including a driver for performing the steps in the system-on-chip verification method described in the first aspect.

[0016] In at least one possible implementation, the verification platform further includes a sequence, a register model, an adapter, and a sequencer; The sequence is used to call the register model to obtain the address information of the hardware registers in the on-chip system to be verified, generate read / write operation transactions, and pass them to the adapter; The adapter is used to convert read / write operation transactions from the register model into the transfer type required by the driver and then send them to the sequencer; The sequencer is used to transmit the read / write operation transactions to the driver.

[0017] In at least one possible implementation, the sequencer and driver are encapsulated in a proxy.

[0018] In at least one possible implementation, the driver communicates with the tightly coupled memory of the system-on-chip to be verified via an interface module.

[0019] In at least one possible implementation, the driver is also used to parse the read / write operation transaction and generate the control word based on the parsing result.

[0020] Thirdly, embodiments of this application provide an on-chip system verification method, applied to an on-chip system, the method comprising: The verification request is obtained from the UVM verification platform from the shared memory region of TCM with K preset offset addresses. The verification request includes several read and write operations to be executed one by one. Each read and write operation carries at least its control word and target address information, and K is a natural number greater than 1. Based on the control word and target address information carried by the read / write operation, the corresponding read / write operation is executed, and the execution result of the read / write operation is returned to the UVM verification platform.

[0021] In at least one possible implementation, the step of performing the corresponding read / write operation based on the control word and target address information carried by the read / write operation specifically includes: According to the preset address mapping rules, the control word and target address information carried by the read / write operation are obtained from the corresponding offset address in the shared memory region; The read / write operation is performed based on the control word and target address information; Among the K offset addresses, M offset addresses are used to store the target address carried by the read / write operation, another offset address is used to store the control word carried by the read / write operation, and at least one offset address is used to store the target data of the read / write operation, where M is a natural number less than K.

[0022] In at least one possible implementation, the control word carries at least an operation type and a data width, and the step of performing the read / write operation based on the control word and the target address information specifically includes: The control word is obtained from the offset address used to store the control word; The operation type and data width carried by the control word are parsed. The operation type is parsed as a read operation or a write operation, and the data width is parsed as bytes that are powers of 2, where N is a non-negative integer. If the parsing result is a write operation, then read the target address from the offset address corresponding to the width of the write operation data from the M offset addresses, and after obtaining the target data of the write operation from the offset address used to store the target data, write it to the target address; If the parsing result is a read operation, then the target address is read from the offset address corresponding to the read operation among the M offset addresses, and then the target data is read from it.

[0023] In at least one possible implementation, performing the read / write operation further includes: In response to the parsing of redundant data filled in the offset address, the redundant data is directly ignored.

[0024] In at least one possible implementation, after reading the target data therein, the method further includes: Write the target data to the offset address used to store the target data.

[0025] In at least one possible implementation, the control word is obtained by polling a preset offset address within the shared region for storing the control word.

[0026] In at least one possible implementation, after each read / write operation is completed, the method further includes: Clear the control word in the offset address used to store the control word in the shared memory region to set the execution result flag.

[0027] In at least one possible implementation, the offset address of the target address for the read operation and the offset address of the target address for the write operation that is aligned with its data width are set to the same offset address that is time-division multiplexed.

[0028] In at least one possible implementation, the step of performing the corresponding read / write operation based on the parsed operation type and data width specifically includes: If the parsing result is a request for a 1-byte write operation, then the target address of the write operation is obtained from the preset second offset address in the shared memory area, and the target data is obtained from the preset fifth offset address in the shared memory area and written into the corresponding target address. If the parsing result is a request for a 2-byte write operation, then the target address of the write operation is obtained from the preset third offset address in the shared memory area, and the target data is obtained from the fifth offset address and written into the corresponding target address. If the parsing result is a request for a 4-byte write operation, then the target address of the write operation is obtained from the preset fourth offset address in the shared memory area, and the target data is obtained from the fifth offset address and written into the corresponding target address. If the parsing result is a read operation, then after obtaining the target address of the read operation from the fourth offset address, the target data therein is read.

[0029] In at least one possible implementation, the on-chip system verification method further includes: Perform initialization operations, which include at least one of instruction fetch, decoding, execution flow, enable cache, and bus interface unit; In at least one possible implementation, the on-chip system verification method further includes: After each read / write operation is verified, the execution result should be cleared at least to await the next read / write operation.

[0030] Fourthly, embodiments of this application provide an on-chip system, including: TCM has a shared memory region with K preset offset addresses, where K is a natural number greater than 1, which is connected to the general verification methodology verification platform. A kernel unit for executing the on-chip system verification method described in the third aspect.

[0031] In at least one possible implementation, the TCM is connected to the general verification methodology verification platform via an interface module.

[0032] In at least one possible implementation, the kernel unit performs initialization operations after the system is powered on by executing boot code stored in the boot read-only memory.

[0033] In at least one possible implementation, the kernel unit continuously polls the control word status in the shared memory region after initialization by executing boot code embedded in the boot read-only memory.

[0034] Fifthly, embodiments of this application provide a verification device, including a first processor and a first memory, wherein the first memory stores computer instructions, and when the first processor executes the computer instructions, the first processor performs the steps in the on-chip system verification method described in the first aspect.

[0035] Sixthly, embodiments of this application provide a system-on-a-chip, including a second processor and a second memory, wherein the second memory stores computer instructions, and when the second processor executes the computer instructions, the second processor performs the steps in the system-on-a-chip verification method described in the third aspect.

[0036] In a seventh aspect, embodiments of this application provide a computer program product, including computer program code, which, when run on a computer, causes the computer to perform the steps in the system-on-chip verification method described in the first or third aspect.

[0037] The beneficial effects of the embodiments of this application are: This application embodiment uses the UVM verification platform as the test controller and the CPU in the SoC as the execution engine. The two interact through a pre-defined shared memory area in the TCM to exchange verification requests and execution results. This not only takes advantage of the UVM verification platform's flexibility and programmability, eliminating the need to write independent software for each test case, but also ensures that the CPU's core functions (fetch, decode, execute, etc.) and key modules (cache, bus interface, etc.) are truly verified. This achieves the technical effect of balancing the flexibility of the verification environment and the authenticity of CPU function verification without requiring a large amount of software code maintenance. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a schematic diagram of the architecture of the system-on-a-chip according to an embodiment of this application.

[0040] Figure 2 This is a flowchart illustrating the system-on-chip verification method according to the first embodiment of this application.

[0041] Figure 3 This is a schematic diagram of the process of filling data into the TCM in the on-chip system verification method of the first embodiment of this application.

[0042] Figure 4 This is a schematic diagram of the structure of the general verification methodology verification platform according to an embodiment of this application.

[0043] Figure 5 This is a flowchart illustrating the on-chip system verification method according to the second embodiment of this application.

[0044] Figure 6 This is a flowchart illustrating the process of performing read / write operations in the on-chip system verification method according to the second embodiment of this application.

[0045] Figure 7 This is a schematic diagram of the structure of the system-on-a-chip according to an embodiment of this application.

[0046] Figure 8 This is a schematic diagram of the on-chip system verification process according to an embodiment of this application.

[0047] Figure 9 This is a schematic diagram of the structure of the verification device according to an embodiment of this application.

[0048] Figure 10 This is a schematic diagram of the structure of the system-on-a-chip according to an embodiment of this application. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0050] It should be noted that: throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions; in the description of this application, the terms "center," "longitudinal," "lateral," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the scope of protection of this application; in the description of this application, "first," "second," etc., are only used to distinguish each other, and do not indicate their degree of importance or order, etc.

[0051] In the description of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, they can refer to fixed connections, movable connections, or detachable connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; they can refer to the internal communication between two components, etc. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0052] A System-on-Chip (SoC), also known as a system-on-a-chip, is a complete, functional electronic system that integrates most of the functional modules of a traditional computer system onto a single chip. Please refer to [link / reference]. Figure 1 A SoC typically contains the following components: CPU cores (one or more, which may be of different architectures), or kernel units, are used to execute operating system and application instructions; The memory controller (DRAM, SRAM controller) is used to manage access to off-chip or on-chip SRAM; Storage interface, used to connect storage devices (eMMC, UFS, NAND / NOR Flash, etc.). Peripheral interfaces (USB, PCIe, SPI, UART, I2C, etc.) are used to connect external devices; Bus / on-chip network (AXI, AHB, APB or NoC) is used to connect various modules to achieve high-speed communication; The power management unit (PMU) is used to control the chip's power consumption and power supply strategy.

[0053] During SoC verification, it is necessary to simulate the complete workflow of the entire system-on-a-chip. The CPU, as the core of hardware and software co-control, first reads and executes the boot code stored in the Boot ROM from the preset boot address. Then, it initializes the clock, configures the memory controller and various peripherals. After initialization, the CPU obtains the hardware status through the bus, processes it internally, and then issues commands to other hardware modules via the bus. Therefore, bus access is a crucial way for the CPU to interact with other hardware modules. There are two existing methods for controlling hardware modules in system-on-a-chip verification: The first approach is based on software access patterns. This method requires writing corresponding C or assembly language programs for specific test scenarios, compiling them, and loading them into the SoC's memory model (such as ROM, TCM, or system memory). This approach is highly dependent on software, and for hundreds or thousands of test cases, a large amount of software code needs to be maintained. Moreover, software development lags behind system-level verification, resulting in serious deficiencies in versatility and reusability, placing a heavy burden on verification management.

[0054] The second method involves directly accessing the bus within the simulation environment of the UVM verification platform. This method bypasses the normal CPU execution flow and directly drives the signals between the CPU and the bus within the UVM verification platform's simulation environment using hardware description languages ​​(Verilog / SystemVerilog) and according to the timing requirements of bus protocols such as AXI / AHB. It forces read and write transactions to complete the interaction with the hardware module and simulates the CPU's computational processing through the SV model. This method does not require CPU execution or software code and has strong versatility, but its most significant drawback is that it completely avoids verifying the CPU's own functionality. This method cannot verify whether the CPU's configuration, instruction fetching, or caching behavior is correct, or whether the bus interface unit can handle various responses normally. It cannot reflect the CPU core's instruction fetching, decoding, and execution flow when actually running software, resulting in poor verification accuracy.

[0055] In view of this, the embodiments of this application provide a system-level chip verification method for CPU interaction with UVM verification environment. By abstracting the software processing flow into SV (Systemverilog) based sequence to complete CPU control, it does not rely on large-scale software resource investment, and can reuse the test sequences of module verification and subsystem verification, effectively improving verification efficiency and shortening the verification cycle. At the same time, the bus access part is implemented by the actual CPU running software code, ensuring the completeness of CPU module functional verification.

[0056] Please refer to Figure 2 The first embodiment of this application provides an on-chip system verification method. This first embodiment is applied to a general verification methodology verification platform. The method includes: In step S101, a verification request is initiated to a shared memory region in the TCM of the system-on-chip to be verified, which has K preset offset addresses. The verification request includes several read and write operations to be executed by the system-on-chip to be verified one by one. Each read and write operation carries at least its control word and target address information, and K is a natural number greater than 1. In step S102, the read / write operation execution result returned by the system-on-chip to be verified is obtained, and the system-on-chip to be verified is determined to pass the first verification based on the read / write operation execution result.

[0057] Compared to existing UVM verification platforms that communicate with the SoC via a standard bus (such as AXI): Because the CPU has multiple channels, including complex communication mechanisms, burst transmissions, out-of-order responses, and different ID management, the internal register states of ordinary bus peripherals are usually not directly accessible through backdoors, or the access path is extremely complex. If the verification environment directly drives the bus to read and write registers, it completely bypasses the CPU, which is equivalent to only verifying the bus slave device and cannot expose various problems in the actual CPU execution process.

[0058] TCM is a high-speed, low-latency memory directly connected to the CPU core. Its interface is typically very simple, approximating a single-cycle SRAM interface, with a fixed physical address and predetermined access timing. In RTL, TCM is usually an instantiated memory array, bypassing cache and bus arbitration. It contains basic signals such as address, write data, read data, enable, and write control, without complex communication mechanisms or burst transmission logic. The verification environment can directly read and write its internal storage through UVM backdoors (uvm_hdl_deposit / uvm_hdl_read). This allows UVM components to directly populate command packets or read return data without simulating bus timing, significantly improving the execution efficiency of the verification environment and eliminating bus arbitration and transmission latency.

[0059] Therefore, in this embodiment, the UVM verification platform actively initiates a verification request to the shared memory region of the TCM, so that the verification process does not rely on large-scale software code. The flexibility and programmability of the UVM verification platform can be used to generate test stimuli. At the same time, the CPU is incentivized to respond to the verification request and perform real bus access, which can fully verify the CPU's instruction fetching, decoding, execution process, as well as key modules such as cache and bus interface units, thus balancing the authenticity, flexibility and efficiency of the verification.

[0060] In at least one possible implementation, initiating a verification request to a preset shared memory region in the TCM of the system-on-chip to be verified specifically includes: According to the preset address mapping rules, the control word and target address information carried by each read and write operation are respectively filled into the corresponding offset address in the shared memory region; Of the K offset addresses, M offset addresses are used to store the target address carried by the read / write operation, one offset address is used to store the control word carried by the read / write operation, and at least one offset address is used to store the target data of the read / write operation; M is a natural number less than K.

[0061] In this embodiment, a deterministic communication protocol is formed between the verification environment and the CPU through preset address mapping rules and fixed offset address allocation, eliminating the need for complex interaction logic; the control word is stored separately from the target address and target data, which facilitates CPU polling and parsing, effectively reducing the implementation complexity on both the software and hardware sides.

[0062] In at least one possible implementation, the control word includes at least an operation type and a data width, wherein the operation type is set to a read operation or a write operation, and the data width is set to a power of 2 bytes, where N is a non-negative integer.

[0063] In this embodiment, by encoding the operation type and data width in the control word, the CPU can clearly know the specific requirements of this operation; the data width adopts a power of 2 byte (1 / 2 / 4 bytes, etc.), which is compatible with the bus access granularity of common CPUs, making it easy for the CPU to directly use the corresponding storage instructions (STRB / STRH / STR / LDR, etc.) to execute the operation, effectively improving the instruction execution efficiency.

[0064] Please refer to Figure 3 In at least one possible implementation of the first embodiment of this application, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule specifically includes: In step S1011, the control word carried by each read / write operation is filled into the offset address used to store the control word; In step S1012, the target address of the write operation requesting a power of N bytes of 2 is filled into the M offset addresses corresponding to the offset address of the data width of the power of N bytes of 2. In step S1013, the target address of the read operation is filled into the M offset addresses corresponding to the offset address of the read operation.

[0065] In this embodiment, the target addresses of write operations with different data widths are stored in different offset addresses, thereby realizing the direct implicit encoding of data width information using address offsets without the need for additional parameter passing; read operations uniformly use a fixed offset address to store the target address, thereby simplifying the CPU parsing logic and improving the determinism of command processing.

[0066] In at least one possible implementation, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule further includes: In step S1014, preset redundant data is filled into M-1 offset addresses other than the offset address occupied by the target address of this read / write operation.

[0067] In this embodiment, by filling in the system's preset redundant data, it is ensured that during each read / write operation, the free offset address in the shared memory area is written with a placeholder value (dummy), avoiding misjudgment caused by the CPU reading residual old data; at the same time, it maintains the uniformity of the communication data structure, which is convenient for debugging and expansion.

[0068] In at least one possible implementation, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule further includes: In step S1015, preset redundant data is filled into the offset address used to store the target data in this read operation.

[0069] In this embodiment, by filling the offset address (e.g., base_addr+00) used for storing target data (data to be read from the target address by the SoC) in the read operation with preset redundant data (at which time the target data has not yet been read, the offset address has no valid value), it is ensured that the address is written with a known value every time a read operation is requested, avoiding the mixing of the target data written by the CPU after performing the read operation with the old data left over from the previous operation; at the same time, this design ensures that the redundant data in the address will not be mistaken by the CPU as valid read data before the read operation is completed, thus guaranteeing the security of the data path.

[0070] In at least one possible implementation, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule further includes: In step S1016, the target data of the write operation is filled into the offset address used to store the target data.

[0071] In this embodiment, by directly filling the target data of the write operation (the data to be written to the target address by the SoC) into the predefined target data storage offset address in the shared memory (e.g., base_addr+00), the CPU can obtain the target data from the same fixed offset address when performing the write operation. This eliminates the need to search for different data sources based on the data width or operation type, thereby simplifying the implementation logic of the write operation in the ROMCODE and improving the consistency of command parsing.

[0072] In at least one possible implementation, the target address of the read operation and the target address of the write operation, which stores the data width aligned with it, are filled into the same offset address in a time-division multiplexing manner.

[0073] In this embodiment, the target addresses of read and write operations with data width alignment simultaneously meet the address alignment requirements and share the same offset address (e.g., base_addr+0x04). This simplifies the CPU parsing logic, effectively reduces the address occupancy of shared memory regions, and saves TCM storage resources. At the same time, since read and write operations do not occur simultaneously, the time-division multiplexing does not generate address conflicts by utilizing the inherent mutual exclusion of read and write operations. This saves storage resources without affecting the correctness of command execution, thus achieving safe and efficient address reuse.

[0074] In at least one possible implementation, obtaining the read / write operation execution result returned by the system-on-chip to be verified specifically includes: The read / write operation result is obtained by polling the execution result flags written by the on-chip system to the offset address used to store the control word; or The read / write operation result is obtained by accessing the offset address used to store the control word through a backdoor; or The read / write operation results are obtained through the communication interface established with the TCM.

[0075] In this application embodiment, multiple methods for monitoring execution results are provided, so that the verification environment can select the most suitable solution according to specific simulation requirements. For example, the polling method is simple and direct, the backdoor access method does not require additional signal connection, and the interface monitoring method can achieve more precise timing control.

[0076] In at least one possible implementation, the step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule specifically includes: The control word carried by each read / write operation is filled into a preset first offset address (e.g., base_addr+0x10) within the shared memory region; and Fill the target address of the requested 1-byte write operation into the preset second offset address (e.g., base_addr+0xC) within the shared memory region; or Fill the target address of the requested 2-byte write operation into the preset third offset address (e.g., base_addr+0x8) within the shared memory region; or Fill the target address of the requested 4-byte write operation into the preset fourth offset address (e.g., base_addr+0x4) within the shared memory region; or Fill the target address of the read operation into the fourth offset address (e.g., base_addr+0x4); and Fill the pre-defined redundant data into the third offset address (e.g., base_addr+0x8) and fourth offset address (e.g., base_addr+0x4) that are not occupied by the target address of the 1-byte write operation requested in this request; or Fill the pre-defined redundant data into the second offset address (e.g., base_addr+0xC) and the fourth offset address (e.g., base_addr+0x4) that are not occupied by the target address of the 2-byte write operation requested in this request; or Fill the second offset address (base_addr+0xC) and the third offset address (base_addr+0x8) that are not occupied by the target address of the 4-byte write operation requested in this request with preset redundant data (such as base_addr+0x18); or The preset redundant data is filled into the second offset address (e.g., base_addr+0xC), the third offset address (e.g., base_addr+0x8), and the fifth offset address (e.g., base_addr+00), which are not occupied by the target address of this read operation.

[0077] In this embodiment, a complete command packet structure is formed by explicitly allocating specific offset addresses (such as base_addr+0x10, +0x0C, +0x08, +0x04, etc.). This structure precisely allocates the address storage location and redundancy padding location for each type of operation and data width read / write operation. This allows the CPU to read information from the corresponding offset address based solely on the data width information in the control word, eliminating the need for complex address calculations or masking operations. The parsing logic is extremely simple and efficient, significantly reducing the complexity of the ROMCODE.

[0078] Please continue to refer to this. Figure 2 In at least one possible implementation of the first embodiment of this application, the embodiment further includes: In step S103, before initiating the verification request, the system-on-chip to be verified is waited for to complete the initialization process; In step S104, based on any at least one operation in the initialization process, such as instruction fetch, decoding, execution flow, enable cache, and bus interface unit, it is determined whether the on-chip system to be verified has passed the second verification.

[0079] In this embodiment, the verification environment waits for the SoC to complete the initialization process before initiating read and write operations, ensuring that the CPU has entered a stable polling state. More importantly, the initialization process itself includes the actual operation of key modules such as instruction fetching, decoding, execution, and enabling cache and bus interface units of the CPU core. By monitoring these processes, the correctness of the above-mentioned key functions and modules is verified indirectly, without the need to write separate test cases.

[0080] Please refer to Figure 4 This application also provides a general verification methodology verification platform, including a driver, for executing the steps in the on-chip system verification method described in any at least one possible implementation of the foregoing embodiments.

[0081] In this embodiment, the above-mentioned system-on-chip verification method is solidified into a driver component in the UVM verification platform, thereby enabling the driver to be reused as a standard module in different verification environments. Users only need to integrate the driver into a specific UVM environment and configure the corresponding register model and adapter to obtain all the verification capabilities provided by this embodiment, which significantly reduces the deployment threshold.

[0082] In at least one possible implementation, the verification platform further includes a sequence, a register model, an adapter, and a sequencer; The sequence is used to call the register model to obtain the address information of the hardware registers in the on-chip system to be verified, generate read / write operation transactions, and pass them to the adapter; The adapter is used to convert read / write operation transactions from the register model into the transfer type required by the driver and then send them to the sequencer; The sequencer is used to transmit the read / write operation transactions to the driver.

[0083] In this embodiment, by reusing the standard register model, sequencer, and adapter architecture of the UVM verification platform, the underlying complex TCM filling and interaction protocols are automatically completed by the adapter and driver. This design minimizes the user's learning cost and code modification.

[0084] In at least one possible implementation, the sequencer and driver are encapsulated in a proxy.

[0085] By implementing the embodiments of this application, the sequencer and driver are encapsulated in a proxy, forming an independently reusable and configurable interface proxy, which facilitates rapid deployment in module-level, subsystem-level, and system-level verification environments.

[0086] In at least one possible implementation, the driver communicates with the tightly coupled memory of the system-on-chip to be verified via an interface module.

[0087] The interface module can flexibly support backdoor access (uvm_hdl_deposit) and frontdoor signal driving, which enhances the platform's adaptability. The driver does not need to care about the specific RTL implementation details of TCM (such as address mapping and timing requirements), and can complete data filling and status monitoring simply by calling the unified interface method.

[0088] In at least one possible implementation, the driver is also used to parse the read / write operation transaction and generate the control word based on the parsing result.

[0089] In this embodiment, the driver assumes the responsibility of transaction parsing and control word generation, allowing the upper-layer sequence and register models to provide only high-level transaction information (target address, target data, byte enable, operation type) without needing to concern themselves with the specific encoding rules and address mapping details of the control word. This layered design reduces the development complexity of test cases while centralizing the control word generation logic within the driver, facilitating the maintenance and upgrade of the address mapping protocol, and improving the reusability and maintainability of the verification platform.

[0090] Please refer to Figure 5 The second embodiment of this application also provides an on-chip system verification method, which is applied to an on-chip system. The method includes: In step S201, a verification request from the UVM verification platform is obtained from the shared memory region of the TCM with K preset offset addresses. The verification request includes several read and write operations to be executed one by one. Each read and write operation carries at least its control word and target address information, and K is a natural number greater than 1. In step S202, the corresponding read / write operation is executed according to the control word and target address information carried by the read / write operation, and the execution result of the read / write operation is returned to the UVM verification platform.

[0091] In this embodiment, the on-chip system passively receives and executes the verification request initiated by the verification environment through the shared memory area of ​​the TCM, thereby eliminating the need to write and load software separately for each test case and greatly reducing the amount of software maintenance. At the same time, the CPU actually executes each load / store instruction, and its fetch, decode, pipeline, cache and bus interface modules are fully stimulated, realizing comprehensive verification of the CPU's core functions and key modules.

[0092] In at least one possible implementation, the step of performing the corresponding read / write operation based on the control word and target address information carried by the read / write operation specifically includes: According to the preset address mapping rules, the control word and target address information carried by the read / write operation are obtained from the corresponding offset address in the shared memory region; The read / write operation is performed based on the control word and target address information; The shared memory region is pre-set with K offset addresses. Among these K offset addresses, M offset addresses are used to store the target address carried by the read / write operation, another offset address is used to store the control word carried by the read / write operation, and at least one offset address is used to store the target data of the read / write operation. M is a natural number less than K.

[0093] In this embodiment, the same address mapping rules as the verification environment are adopted, enabling the SoC to correctly parse the command packets filled by the verification environment. The fixed offset address allocation and redundant data filling structure ensure that the CPU can obtain the required information through simple address offset reading without complex protocol stack parsing, effectively improving the command response speed.

[0094] Please refer to Figure 6 In at least one possible implementation of the second embodiment of this application, the control word carries at least an operation type and a data width, and the step of performing the read / write operation based on the control word and the target address information specifically includes: In step S2011, the control word is obtained from the offset address used to store the control word; In step S2012, the operation type and data width carried by the control word are parsed. The operation type is parsed as a read operation or a write operation, and the data width is parsed as bytes that are powers of 2, where N is a non-negative integer. In step S2013, if the parsing result is a write operation, the target address is read from the offset address corresponding to the width of the write operation data from the M offset addresses, and the target data of the write operation is obtained from the offset address used to store the target data and then written to the target address. In step S2014, if the parsing result is a read operation, then the target address is read from the offset address corresponding to the read operation stored in the M offset addresses, and then the target data is read from it.

[0095] In this embodiment, the CPU obtains the operation type and data width by parsing the control word, and then directly reads the target address / target data from the corresponding offset address according to the width. There is no need to perform address alignment adjustment or width conversion, which greatly simplifies the implementation of ROMCODE and ensures high efficiency of response.

[0096] In at least one possible implementation, performing the read / write operation further includes: In step S2015, in response to the parsing of redundant data carried by the read / write operation, the redundant data is directly ignored.

[0097] In this embodiment, the CPU actively ignores redundant padding data when parsing commands, thus avoiding misprocessing of invalid data.

[0098] In at least one possible implementation, after reading the target data therein, the method further includes: In step S2016, the target data is written to the offset address used to store the target data.

[0099] In this embodiment of the application, by writing the read target data to a predefined offset address (e.g., base_addr+00) in the shared memory region, the verification environment can directly obtain the result of the read operation through backdoor access or interface monitoring, without the CPU actively initiating additional data transmission. This simplifies the process of returning read data and ensures that the verification environment can obtain the read value in a timely and accurate manner for comparison and verification.

[0100] In at least one possible implementation, the control word is obtained by polling a preset offset address within the shared region for storing the control word.

[0101] In this embodiment, the requests issued by the verification environment are detected in real time with minimal hardware and software overhead through polling, avoiding the delay of interrupt response and the complexity of interrupt vector configuration. This makes the request response time deterministic and extremely short (usually only a few clock cycles), thereby ensuring the real-time performance and determinism of read and write operations in the verification environment.

[0102] Please continue to refer to this. Figure 5 In at least one possible implementation of the second embodiment of this application, after each read / write operation is completed, the method further includes: In step S203, the control word in the offset address used to store the control word in the shared memory region is cleared in order to set the execution result flag.

[0103] In this embodiment of the application, by clearing the control word (writing 0) after the read and write operations are completed, an operation completion signal is sent to the verification environment, forming a complete request-response mechanism, which ensures that the verification environment can accurately perceive the execution status of each request.

[0104] In at least one possible implementation, the offset address of the target address for the read operation and the offset address of the target address for the write operation that is aligned with its data width are set to the same offset address that is time-division multiplexed.

[0105] In this embodiment, the target addresses of read and write operations with data width alignment simultaneously meet the address alignment requirements and share the same offset address (e.g., base_addr+0x04). This effectively simplifies the CPU parsing logic, reduces the address occupancy of shared memory regions, and saves limited TCM storage resources. At the same time, by utilizing the inherent mutual exclusion of read and write operations in time, time-division multiplexing will not cause address conflicts, thus saving storage resources without affecting the correctness of command execution, achieving safe and efficient address reuse.

[0106] In at least one possible implementation, the step of performing the corresponding read / write operation based on the parsed operation type and data width specifically includes: If the parsing result is a request for a 1-byte write operation, then the target address of the write operation is obtained from the preset second offset address in the shared memory area, and the target data is obtained from the preset fifth offset address in the shared memory area and written into the corresponding target address. If the parsing result is a request for a 2-byte write operation, then the target address of the write operation is obtained from the preset third offset address in the shared memory area, and the target data is obtained from the fifth offset address and written into the corresponding target address. If the parsing result is a request for a 4-byte write operation, then the target address of the write operation is obtained from the preset fourth offset address in the shared memory area, and the target data is obtained from the fifth offset address and written into the corresponding target address. If the parsing result is a read operation, then after obtaining the target address of the read operation from the fourth offset address, the target data therein is read.

[0107] In this embodiment, by further refining the specific execution flow of 1 / 2 / 4-byte write and read operations, the source of the target address and the source / destination of the target data under each operation are clearly defined. This refined instruction-level description allows the ROMCODE to be directly translated into assembly code, significantly reducing the difficulty of firmware development, while effectively ensuring that the CPU's execution logic remains consistent and concise regardless of changes in operation type and data width.

[0108] In at least one possible implementation, the on-chip system verification method further includes: In step S200, an initialization operation is performed, which includes at least one of instruction fetch, decoding, execution flow, enable cache, and bus interface unit; In this embodiment of the application, the key module operations such as instruction fetching, decoding, and execution during the initialization phase, as well as cache enabling and bus interface unit operations, can themselves constitute the first verification of the CPU core functions.

[0109] In at least one possible implementation, the on-chip system verification method further includes: After each read / write operation is verified, the execution result should be cleared at least to await the next read / write operation.

[0110] In this embodiment, the execution result flag is cleared after each read / write operation, restoring the control word address of the shared memory to its initial state. The verification environment can then perceive the completion status and initiate the next request. This completion-clear mechanism effectively ensures the reliability of serial execution of multiple requests.

[0111] Please refer to Figure 7 This application also provides an on-chip system, including: TCM 201 has a shared memory region with K offset addresses pre-defined for connection to a general verification methodology verification platform, where K is a natural number; Kernel unit 202 is used to execute the on-chip verification method applied to the on-chip system according to any possible implementation of any of the foregoing embodiments.

[0112] In this embodiment, the above-described SoC verification method is embedded as firmware code executed by the on-chip system hardware structure TCM201 and kernel unit 202, thereby enabling system-level verification of the SoC in a simulation environment before tape-out, in conjunction with the UVM verification platform. Since the ROMCODE is embedded within the SoC, no external software loading is required during the verification process, improving the automation level of the verification.

[0113] In at least one possible implementation, the TCM is connected to the general verification methodology verification platform via an interface module.

[0114] In at least one possible implementation, the kernel unit 202 performs initialization operations after the system is powered on by executing boot code stored in the boot read-only memory 203.

[0115] In this embodiment, the boot code is embedded in a read-only memory, thereby enabling the automatic completion of the initialization process of key modules such as TCM and cache after the CPU is powered on without loading any external software, ensuring the repeatability and consistency of the verification environment; at the same time, the embedded code is not affected by changes in test cases, avoiding the maintenance overhead caused by writing and loading initialization programs separately for each test case.

[0116] In at least one possible implementation, the kernel unit 202 continuously polls the control word status in the shared memory region after the initialization process is completed by executing boot code embedded in the boot read-only memory 203.

[0117] In at least one possible implementation, the kernel unit 202 executes the corresponding read / write operation after continuously polling the control word status in the shared memory region to ensure it is valid (non-zero) after completing the initialization process by executing the boot code embedded in the boot read-only memory 203.

[0118] In at least one possible implementation, the kernel unit 202 executes the boot code embedded in the boot read-only memory 203, performs the corresponding read and write operations, clears the offset address used to store the control word in the shared memory region to zero, and returns the read and write operation execution result to the UVM verification platform.

[0119] The following describes in detail the UVM verification platform, TCM shared memory region definition, address mapping rules, and ROMCODE firmware of embodiments of this application.

[0120] Please continue to refer to this. Figure 4 The verification environment in this application embodiment is built on the UVM verification platform and mainly includes the following components: Register model (reg_model): The standard UVM register model, used to abstract the hardware registers in a SoC; Sequences are used to invoke the register model for read and write operations; The adapter (fw_reg_adapt) is used to implement bidirectional conversion between the standard register operation structure (uvm_reg_bus_op) and the custom transaction (fw_reg_transaction). This component converts the uvm_reg_bus_op structure of the register model into fw_reg_transaction, facilitating the parsing of information such as address and byte_en in the driver. This includes register-to-bus (reg to bus) and bus-to-register (bus to reg) conversions. The parameters of fw_reg_transaction are wr_rd_type, address, data, and byte_en. Sequencer (fw_reg_sequencer): Used to forward transactions (fw_reg_transaction) to the driver; Driver (fw_reg_driver): Used to receive fw_reg_transaction forwarded from the sequencer fw_reg_sequencer, parse fw_reg_transaction, fill the TCM shared memory area according to the address mapping rules, and monitor the operation completion flag; Agent (fw_reg_agent): Used to encapsulate drivers, sequencers, and optional monitors to form a reusable interface agent; Interface module (fw_reg_intf): Connects the verification environment to the SoC's TCM signal for backdoor access or signal monitoring.

[0121] TCM shared memory region definition: In the SoC's TCM, a shared memory region is pre-defined, starting at address base_addr, and the following key offset addresses are defined, the contents of which are shown in Table 1 below: Table 1. Offset Address Definition Table

[0122] Address mapping rules: The driver determines the data width based on the byte_en (byte enable) in the transaction. For example, the control word data structure is {byte_en_type, rsv, wr_rd_type}, with the lowest 8 bits encoded as 0x01 for write and 0x02 for read; the highest 8 bits are 0x00, 0x01, and 0x02, representing 1 byte, 2 bytes, and 4 bytes valid, respectively. Data is filled according to the following address mapping rules: A single byte is valid for a write operation (only one bit of byte_en is valid): Target address → base_addr + 0x0C; Control word {8'h0,16'h0,8'h1} → base_addr + 0x10; Redundant data (such as base_addr+0x18) → base_addr+0x04 and base_addr+0x08.

[0123] Two valid write operations (byte_en has two consecutive valid bits): Target address → base_addr + 0x08; Control word {8'h1,16'h0,8'h1} → base_addr + 0x10; Redundant data → base_addr+0x04 and base_addr+0x0C.

[0124] 4-byte valid write operation (byte_en fully valid): Target address → base_addr + 0x04; Control word {8'h2,16'h0,8'h1} → base_addr+0x10; Redundant data → base_addr+0x08 and base_addr+0x0C.

[0125] Read operation: Target address → base_addr + 0x04; Control word {8'h1,16'h0,8'h2} → base_addr + 0x10; Redundant data → base_addr+0x00, base_addr+0x08, base_addr+0x0C.

[0126] Those skilled in the art will understand that the address offset, control word encoding, and data width support in this example can all be adjusted according to the specific SoC design. For example, larger widths such as 8 bytes and 16 bytes can be supported by simply expanding the redundancy padding rules; the bit allocation of the control word can also be changed. Any technical solution that utilizes the TCM shared memory region, actively padding commands in the verification environment, or CPU polling execution falls within the protection scope of this application.

[0127] ROMCODE (Firmware Code): A piece of boot code (ROMCODE) is embedded in the SoC's Boot ROM. The ROMCODE execution flow is as follows: Initialization phase: After the system is powered on and reset, the Core starts from address 0x0, loads and executes the initialization code from the ROM, completes the necessary initialization process for the TCM and SoC, enables the I-Cache, and completes the necessary peripheral initialization. The specific configuration can be made according to the SoC and Core type.

[0128] Polling phase: Core reads the value of base_addr+0x10 in a loop to check the register read / write operation: if it is 0, it continues to poll; if it is not 0, it detects that the request is valid, performs command parsing, and writes or reads data from the corresponding address to complete the read / write operation.

[0129] Command parsing: Read the control word and determine the lowest 8 bits: if it is 0x01, perform a write operation; if it is 0x02, perform a read operation; read the highest 8 bits to determine the data width.

[0130] Perform a write operation: Read the target address from the corresponding offset address based on the data width: 1 byte is read from +0x0C, 2 bytes are read from +0x08, and 4 bytes are read from +0x04; Read and write data from base_addr (values ​​are taken according to the data width); Execute the store instruction (STRB / STRH / STR) to write data to the target address; Write 0 to base_addr+0x10 to indicate that the write operation is complete.

[0131] Perform a read operation: Read the target address from base_addr+0x04; Execute the Load Directive (LDR) to read the target data; Write the read target data into base_addr; Write 0 to base_addr+0x10 to indicate that the read operation is complete.

[0132] Loop: Returns to polling.

[0133] The following is for reference. Figure 8 Describe in detail the specific process of SoC verification by the UVM verification platform: Step 1: Test case verification The verification environment will wait for the SoC to complete the initialization process before fw_reg_equence calls the read and write methods of the register model reg_model to perform read and write operations; The fw_reg_adapt component converts register read / write operations into the transfer type required by fw_reg_driver and passes them to fw_reg_sequencer; fw_reg_sequencer sends it to fw_reg_driver; In the driver, data is filled into the shared memory area of ​​TCM through backdoor writing according to the preset address mapping rules; Step 2: Generate the operation structure from the register model The register model reg_model converts operations into uvm_reg_bus_op structures, which contain address, data, byte enable, operation type, etc.

[0134] Step 3: Adapter Conversion The adapter fw_reg_adapt converts the uvm_reg_bus_op structure into a custom transaction fw_reg_transaction, which contains the fields: wr_rd_type (read / write type), address (target address), data (target data), and byte_en (byte enable).

[0135] Step 4: Sequencer forwarding Transactions are sent to the driver fw_reg_driver via the sequencer fw_reg_sequencer.

[0136] Step 5: Fill the driver with TCM After receiving a transaction, the driver fw_reg_driver parses the transaction, determines the data width based on byte_en, generates a control word, and writes the information to the corresponding offset address of the TCM through a backdoor access (uvm_hdl_deposit) according to the address mapping rules, and writes the control word to base_addr+0x10.

[0137] Step 6: CPU detection and execution The CPU polls base_addr+0x10 and finds a non-zero value, indicating that a control word has been written to that address. It then reads the control word, parses the operation type and data width, and performs the actual register read / write operation according to the logic in the ROMCODE. After the read / write operation is complete, base_addr+0x10 is cleared.

[0138] Step 7: Drive monitoring complete The driver fw_reg_driver detects the completion flag in one of two ways: The backdoor accesses base_addr+0x10 and polls until the value is 0; Connect the memory entity corresponding to base_addr+0x10 to the interface module fw_reg_intf, and detect whether the read and write operations are completed by monitoring the changes in the corresponding memory entity signal.

[0139] Step 8: Return the read data (read-only operation) For read operations, the driver fw_reg_driver accesses the read data stored at base_addr through a backdoor, constructs a response transaction, and returns it to the register model through the adapter.

[0140] Compared to existing technologies, the SoC verification process in this application does not require extensive software intervention. By interacting with the verification environment through the CPU, it inherits the authenticity of software drivers, covering the functional verification of key modules such as CPU core instruction fetching, decoding, execution flow, cache, and bus interface units. Furthermore, the flexible control of test stimuli through the UVM verification platform eliminates the need to write and maintain separate software code for each test case. Therefore, this application significantly improves the flexibility and reusability of testing while ensuring verification authenticity. It more closely resembles the CPU's operating scenario in a real system, helping to identify and expose software process issues and potential configuration errors and system interaction problems during core integration as early as possible, thus improving the completeness and reliability of SoC verification.

[0141] The following describes several read / write operation examples of embodiments of this application. The technical concept of these examples is as follows: The UVM verification platform acts as the master test controller, while the CPU in the SoC serves as the execution engine. Both interact with each other via a pre-defined shared memory region in the TCM (Test Module). The verification environment fills the control word, target address, and redundant data for read / write operations into the specified offset address in the TCM according to a pre-defined address mapping rule, notifying the CPU by filling the control word with a non-zero value. The CPU runs the boot code (ROMCODE) embedded in ROM, continuously polling the control word address after initialization. Upon detecting a non-zero value, it parses the command and executes the actual hardware register read / write operation, clearing the control word upon completion. The verification environment detects the control word being cleared, thus confirming the operation's completion. This approach leverages the flexible programmability of the UVM platform (eliminating the need to write independent software for each test case) while ensuring that the CPU's core functions and key modules (instruction fetch, decoding, execution, caching, and bus interface) are realistically executed and verified.

[0142] Example 1: 4-byte write operation Assuming the CPU has completed the initialization process and the previous write operation has been successfully completed, the status value of base_addr+0x10 is 0, and the CPU maintains a polling state for base_addr+0x10.

[0143] Verify the environment setup for the next write operation: target address 0x2000_1004, data 0xAABBCCDD, byte enable 4'b1111.

[0144] The driver parses byte_en=4'b1111, determines it as a 4-byte write operation, writes the target address 0x2000_1004 to base_addr+0x04, writes the control word {8'h2,16'h0,8'h1}=0x02000001 to base_addr+0x10, and fills redundant data into base_addr+0x08 and base_addr+0x0C.

[0145] When the CPU polls and finds that base_addr+0x10 is non-zero, it parses out that the data width is 4 and the operation type is write operation. Then, it reads the target address 0x2000_1004 from base_addr+0x04 and the target data 0xAABBCCDD from base_addr. The Core executes the STR instruction and writes the target data to the target address through the AMBA bus. After completion, it clears base_addr+0x10 to zero.

[0146] The drive detected the zeroing and confirmed that the write operation was complete.

[0147] Example 2: Read operation Verify the read operation for environment construction: target address 0x3000_0000, length 4 bytes.

[0148] Driver analysis determines it to be a read operation: write the target address 0x3000_0000 to base_addr+0x04, write the control word {8'h2,16'h0,8'h2}=0x02000002 to base_addr+0x10, and add redundant data to base_addr, base_addr+0x08, and base_addr+0x0C.

[0149] When the CPU polls and finds that base_addr+0x10 is non-zero, it parses the operation type as a read operation, reads the target address 0x3000_0000 from base_addr+0x04, the Core executes LDR to read 4 bytes of data (let's assume it's 0xDEADBEEF), writes it to base_addr, and clears the control word to zero.

[0150] The driver detects that the control word has been cleared, reads 0xDEADBEEF from the base_addr backdoor, and returns it to the register model to confirm that the read operation is complete.

[0151] Example 3: Reusing Multiple Test Cases Since all register operations are described through a register model and sequence mechanism, test cases only need to call different sequences or set different random constraints, eliminating the need to rewrite C language programs for each test case. For example, a random read / write test sequence can use UVM's uvm_sequence to randomly generate addresses, data, and byte enable, while the CPU-side ROMCODE remains unchanged. This significantly reduces software maintenance costs, and because the CPU actually executes every load / store instruction, its instruction fetch, decoding, pipeline, and cache modules are fully verified, ensuring comprehensive functional coverage.

[0152] Please refer to Figure 9 This application embodiment also provides a verification device, including a first processor 11 and a first memory 12. The first memory 12 is coupled to the first processor 11 and is used to store computer program code, which includes computer instructions. When the first processor 11 reads the computer instructions from the first memory 12, the first processor 11 executes the steps in the on-chip system verification method applied to the UVM verification platform in any of the possible implementations of the foregoing embodiments.

[0153] Please refer to Figure 10This application also provides a system-on-a-chip, including a second processor 21 and a second memory 22, the second memory 22 being coupled to the second processor 21, the second memory 22 being used to store computer program code, the computer program code including computer instructions, when the second processor 21 reads the computer instructions from the second memory 22, causing the second processor 21 to execute the steps in the system-on-a-chip verification method applied to the system-on-a-chip in any possible implementation of any of the foregoing embodiments.

[0154] This application also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to perform the steps of the method in any of the possible implementations of the foregoing embodiments.

[0155] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0156] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. An on-chip system verification method, applied to a general verification methodology verification platform, characterized in that, The on-chip system verification method includes: A verification request is initiated to a shared memory region with K preset offset addresses in the tightly coupled memory of the on-chip system to be verified. The verification request includes several read and write operations to be executed by the on-chip system to be verified one by one. Each read and write operation carries at least its control word and target address information, and K is a natural number greater than 1. Obtain the read / write operation execution results returned by the system-on-chip to be verified, and determine whether the system-on-chip to be verified has passed the first verification based on the read / write operation execution results.

2. The on-chip system verification method according to claim 1, characterized in that, The specific steps of initiating a verification request to a pre-defined shared memory region in the tightly coupled memory of the on-chip system to be verified include: According to the preset address mapping rules, the control word and target address information carried by each read and write operation are respectively filled into the corresponding offset address in the shared memory region; Of the K offset addresses, M offset addresses are used to store the target address carried by the read / write operation, another offset address is used to store the control word carried by the read / write operation, and at least one address is used to store the target data of the read / write operation; M is a natural number less than K.

3. The on-chip system verification method according to claim 2, characterized in that, The control word includes at least an operation type and a data width, wherein the operation type is set to a read operation or a write operation, and the data width is set to a power of 2 bytes, where N is a non-negative integer.

4. The on-chip system verification method according to claim 3, characterized in that, The step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to the preset address mapping rules specifically includes: Fill the control word carried by each read / write operation into the offset address used to store the control word; Fill the target address of the write operation requesting 2 to the power of N bytes into the M offset addresses corresponding to the offset address of the data width of 2 to the power of N bytes; or The target address of the read operation is filled into the M offset addresses corresponding to the offset address of the read operation.

5. The on-chip system verification method according to claim 4, characterized in that, The step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule further includes: Fill the preset redundant data into M-1 offset addresses, excluding the offset address occupied by the target address of this read / write operation.

6. The on-chip system verification method according to claim 5, characterized in that, The step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to a preset address mapping rule further includes: The preset redundant data is filled into the offset address used to store the target data in this read operation.

7. The on-chip system verification method according to claim 5, characterized in that, The target address of the read operation and the target address of the write operation, which stores the data width aligned with it, are filled into the same offset address using time-division multiplexing.

8. The on-chip system verification method according to claim 5, characterized in that, The specific steps of obtaining the read / write operation execution results returned by the on-chip system to be verified include: The read / write operation result is obtained by polling the execution result flags written by the on-chip system to the offset address used to store the control word; or The read / write operation result is obtained by accessing the offset address used to store the control word through a backdoor; or The results of the read and write operations are obtained through an interface module provided with the tightly coupled memory.

9. The on-chip system verification method according to claim 5, characterized in that, The step of filling the control word and target address information carried by each read / write operation into the corresponding offset address within the shared memory region according to the preset address mapping rules specifically includes: The control word carried by each read / write operation is filled into a preset first offset address within the shared memory region; and Fill the target address of the requested 1-byte write operation into the preset second offset address within the shared memory region; or Fill the target address of the requested 2-byte write operation into the preset third offset address within the shared memory region; or Fill the target address of the requested 4-byte write operation into the preset fourth offset address within the shared memory region; or Fill the target address of the read operation into the fourth offset address; and Fill the pre-defined redundant data into the third and fourth offset addresses, which are not occupied by the target address of the 1-byte write operation requested in this request; or Fill the pre-defined redundant data into the second and fourth offset addresses that are not occupied by the 2-byte write operation of this request; or Fill the pre-defined redundant data into the second and third offset addresses, which are not occupied by the target address of the 4-byte write operation requested in this request; or The preset redundant data is filled into the second, third, and fifth offset addresses that are not occupied in this read operation.

10. The on-chip system verification method according to any one of claims 1-9, characterized in that, The on-chip system verification method further includes: Before initiating the verification request, wait for the on-chip system to be verified to complete the initialization process; Based on any at least one operation in the initialization process, including instruction fetch, decoding, execution flow, enable cache, and bus interface unit, determine whether the on-chip system to be verified passes the second verification; and / or In response to receiving the read operation execution result, the target data stored in the shared memory area is obtained. If the target data matches the read operation, the verification is successful.

11. A universal verification methodology verification platform, characterized in that, The general verification methodology verification platform includes: A driver for performing the steps in the system-on-chip verification method as described in any one of claims 1-10.

12. The universal verification methodology verification platform according to claim 11, wherein the universal verification methodology verification platform further includes a sequence, a register model, an adapter, and a sequencer, characterized in that: The sequence is used to call the register model to obtain the address information of the hardware registers in the on-chip system to be verified, generate read / write operation transactions, and pass them to the adapter; The adapter is used to convert read / write operation transactions from the register model into the transfer type required by the driver and then send them to the sequencer; The sequencer is used to transmit the read / write operation transactions to the driver.

13. The universal verification methodology verification platform according to claim 12, characterized in that, The sequencer and driver are encapsulated in a proxy; and / or, the driver communicates with the tightly coupled memory of the system-on-chip to be verified via an interface module; and / or, the driver is also used to parse the read / write operation transaction and generate the control word based on the parsing result.

14. A system-on-a-chip verification method, applied to a system-on-a-chip, characterized in that, The on-chip system verification method includes: A verification request from a general verification methodology verification platform is obtained from a shared memory region of a tightly coupled memory with K preset offset addresses. The verification request includes several read and write operations to be executed one by one. Each read and write operation carries at least its control word and target address information, where K is a natural number greater than 1. Based on the control word and target address information carried by the read / write operation, the corresponding read / write operation is executed, and the execution result of the read / write operation is returned to the general verification methodology verification platform.

15. The on-chip system verification method according to claim 14, characterized in that, The step of executing the corresponding read / write operation based on the control word and target address information carried by the read / write operation specifically includes: According to the preset address mapping rules, the control word and target address information carried by the read / write operation are obtained from the corresponding offset address in the shared memory region; The read / write operation is performed based on the control word and target address information; Among the K offset addresses, M offset addresses are used to store the target address carried by the read / write operation, another offset address is used to store the control word carried by the read / write operation, and at least one offset address is used to store the target data of the read / write operation, where M is a natural number less than K.

16. The on-chip system verification method according to claim 15, characterized in that, The control word carries at least an operation type and a data width, and the step of performing the read / write operation based on the control word and the target address information specifically includes: The control word is obtained from the offset address used to store the control word; The operation type and data width carried by the control word are parsed, wherein the operation type is parsed as a read operation or a write operation, and the data width is parsed as bytes to the power of 2, where N is a non-negative integer; Based on the parsed operation type and data width, execute the corresponding read and write operations.

17. The on-chip system verification method according to claim 16, characterized in that, The specific steps of performing the corresponding read / write operations based on the parsed operation type and data width include: If the parsing result is a write operation, then the target address of the write operation is read from the offset address corresponding to the data width of the write operation from the M offset addresses, and the target data of the write operation is obtained from the offset address where the target data is stored and written to the target address of the write operation. If the parsing result is a read operation, then the target address of the read operation is read from the offset address corresponding to the target address of the read operation among the M offset addresses, and then the target data is read from it.

18. The on-chip system verification method according to claim 17, characterized in that, The process of performing the read / write operation also includes: In response to the parsing of redundant data padded within the offset address, the redundant data is directly ignored; and / or After reading the target data, the process also includes: Write it to the offset address where the target data is stored; and / or The control word is obtained by polling a preset offset address within the shared memory region for storing the control word; and / or After each corresponding read / write operation is performed, the following is also included: Clear the control word from the preset offset address used to store the control word within the shared memory region to set the execution result flag; and / or Among the M offset addresses, the offset address storing the target address of the read operation and the offset address storing the target address of the write operation that is aligned with its data width are set to the same offset address that is time-division multiplexed.

19. The on-chip system verification method according to claim 16, characterized in that, The specific steps of performing the corresponding read / write operations based on the parsed operation type and data width include: If the parsing result is a request for a 1-byte write operation, then the target address of the write operation is obtained from the preset second offset address in the shared memory area, and the target data is obtained from the preset fifth offset address in the shared memory area and written into the corresponding target address. If the parsing result is a request for a 2-byte write operation, then the target address of the write operation is obtained from the preset third offset address in the shared memory area, and the target data is obtained from the fifth offset address and written into the corresponding target address. If the parsing result is a request for a 4-byte write operation, then the target address of the write operation is obtained from the preset fourth offset address in the shared memory area, the target data is obtained from the fifth offset address, and then written into the corresponding target address. If the parsing result is a read operation, then after obtaining the target address of the read operation from the fourth offset address, the target data therein is read.

20. The on-chip system verification method according to any one of claims 14-19, characterized in that, The on-chip system verification method further includes: Perform initialization operations, which include at least one of instruction fetch, decode, execute, enable cache, and bus interface unit; and / or After each read / write operation is verified, the execution result should be cleared at least to await the next read / write operation.

21. A system-on-a-chip, characterized in that, Including: Tightly coupled memory has a shared memory region with K preset offset addresses, where K is a natural number greater than 1, which is connected to a general verification methodology verification platform. A kernel unit for performing the on-chip system verification method as described in any one of claims 14-20.

22. The system-on-a-chip according to claim 21, characterized in that, The tightly coupled memory is connected to the universal verification methodology verification platform via an interface module; and / or The kernel unit executes the boot code embedded in the boot read-only memory to perform initialization operations after the system is powered on, and / or, after initialization is completed, continuously polls the control word status in the shared memory region.

23. A verification device, characterized in that, The system includes a first processor and a first memory, the first memory being coupled to the first processor. The first memory is used to store computer program code, the computer program code including computer instructions. When the first processor reads the computer instructions from the first memory, the first processor performs the steps of the system-on-chip verification method as described in any one of claims 1-10.

24. A system-on-a-chip, characterized in that, The system includes a second processor and a second memory, the second memory being coupled to the second processor. The second memory is used to store computer program code, the computer program code including computer instructions, which, when read from the second memory, cause the second processor to perform the steps in the system-on-chip verification method as described in any one of claims 14-20.

25. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the steps of the system-on-chip verification method as described in any one of claims 1-10 and 14-20.

Images