Chip prototype verification method and device, medium and product

Abstract

The invention discloses a chip prototype verification method and device, a medium and a product, and relates to the technical field of integrated circuit verification, and the method comprises the steps: dynamically dividing a central processing unit core of a multi-core chip into a first core group and a second core group in a chip prototype verification platform; performing data interaction on the first core group and the second core group through the inter-core communication agent to obtain a verification control instruction; converting the test case into a chip register operation instruction or a real-time operating system drive call instruction based on the verification control instruction; distributing the chip register operation instruction to the first core group to execute a hardware real-time verification process, and distributing the real-time operation system drive calling instruction to the second core group to execute a multi-task scheduling verification process so as to respectively obtain a corresponding register snapshot and a task scheduling log; and aligning the register snapshot with the task scheduling log according to a time axis so as to generate a chip function verification result report based on the alignment data. Cooperative verification of bare computer verification and real-time operating system verification is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of integrated circuit verification, and in particular to a chip prototype verification method, equipment, medium and product. Background Art

[0002] Prototype verification is a crucial step in the chip design and development process. By running the design code on an actual hardware platform, it verifies the chip's functionality, performance, and reliability, ensuring that the design meets its intended objectives. Prototype verification is typically performed on an FPGA (Field-Programmable Gate Array) or dedicated development board, providing an operating environment close to that of a real chip, helping engineers quickly identify and resolve issues.

[0003] Verification of SMP (Symmetrical Multi-Processing) architecture chips typically involves both bare-metal and operating system (OS) verification, conducted at different project stages. Pure bare-metal verification allows for rapid verification of hardware functionality (register operation, interrupt control) and is more efficient because it eliminates the need for OS boot and initialization. OS-level verification involves running the operating system on all cores, simulating a realistic multitasking scenario and verifying task scheduling and resource management. However, bare-metal testing is performed first, followed by OS testing, as bare-metal test cases must be refactored to accommodate the OS environment, resulting in inefficiency. Furthermore, the delay in OS verification prevents early identification of hardware-software interaction issues. Furthermore, the incompatibility between bare-metal and OS log formats makes correlation analysis difficult.

[0004] It can be seen that how to achieve comprehensive verification of multi-core collaboration scenarios in hybrid scenarios is a problem that technical personnel in this field need to solve. Summary of the Invention

[0005] The purpose of the embodiments of the present invention is to provide a chip prototype verification method, device, medium and product, which can realize comprehensive verification of multi-core collaboration scenarios in hybrid scenarios.

[0006] To solve the above technical problems, an embodiment of the present invention provides a chip prototype verification method, comprising: In a chip prototype verification platform, the central processing unit cores of a multi-core chip are dynamically divided into a first core group and a second core group; wherein the first core group and the second core group maintain clock synchronization and shared memory consistency; Performing data exchange between the first core group and the second core group through an inter-core communication agent to obtain a verification control instruction; Convert test cases into chip register operation instructions or real-time operating system driver call instructions based on verification control instructions; Allocate chip register operation instructions to the first core group to execute the hardware real-time verification process, and allocate real-time operating system driver call instructions to the second core group to execute the multi-task scheduling verification process to obtain corresponding register snapshots and task scheduling logs respectively; Align register snapshots with task scheduling logs by timeline to generate chip functional verification result reports based on the aligned data.

[0007] Optionally, dynamically dividing the central processing unit cores of the multi-core chip into a first core group and a second core group includes: If the real-time requirement of the test case meets the preset high real-time condition, assigning a corresponding first central processing unit core to the test case and dividing the first central processing unit core into a first core group; If the task complexity of the test case meets the preset high complexity condition, a corresponding second central processing unit core is allocated to the test case, and the second central processing unit core is divided into a second core group.

[0008] Optionally, after dynamically dividing the central processing unit cores of the multi-core chip into the first core group and the second core group, the method further includes: The clock references of the first core group and the second core group are bound to the same system clock source through the environment synchronization manager, or the time deviation between the first core group and the second core group is calibrated through timer interruption to maintain clock synchronization between the first core group and the second core group.

[0009] Optionally, binding the clock references of the first core group and the second core group to the same system clock source through the environment synchronization manager includes: The base time of the first core group is obtained through a global timer register, and the base time is mapped to the system clock source of the second core group.

[0010] Optionally, after dynamically dividing the central processing unit cores of the multi-core chip into the first core group and the second core group, the method further includes: Controlling data visibility of shared memory between the first core group and the second core group based on a preset refresh instruction and a memory barrier instruction through an environment synchronization manager; The cache consistency of the shared memory in the first core group and the second core group is controlled based on a hardware consistency protocol through the environment synchronization manager.

[0011] Optionally, controlling data visibility in the shared memory between the first core group and the second core group based on a preset refresh instruction and a memory barrier instruction through the context synchronization manager includes: After the first core group executes a shared memory data write operation, the environment synchronization manager triggers a preset refresh instruction to control cache refresh of the shared memory in the first core group and the second core group.

[0012] Optionally, performing data exchange between the first core group and the second core group through an inter-core communication agent to obtain a verification control instruction includes: The second core group and the first core group are interacted with each other through the mailbox register to obtain a verification control instruction including a source core identifier, a target peripheral address, an operation type code and a parameter list information.

[0013] Optionally, converting the test case into chip register operation instructions based on the verification control instructions includes: Analyze the test case operation steps and expected results; Parse and verify control instructions to obtain source core identifier, target peripheral address, operation type code and parameter list information; Determine a register operation type according to an expected result and an operation type code; wherein the register operation type includes register write, register read, bit set, and bit clear; Generate operand values ​​and data masks based on parameter list information; Constructing a chip register operation instruction sequence that represents timeout detection based on register operation type, target peripheral address, data mask, and operand value; A source core identifier is embedded in a sequence header of a chip register operation instruction sequence to obtain a chip register operation instruction.

[0014] Optionally, convert the test case into a real-time operating system driver call instruction based on the verification control instruction, including: Analyze the task dependencies and resource constraints of test cases to build a task trigger chain based on task dependencies; Parse and verify control instructions to obtain source core identifier, target peripheral address, operation type code and parameter list information; Map the target peripheral address to a virtual device handle; Select the corresponding operating system driver interface based on resource constraints and operation type code; Encapsulate the parameter list as interface call parameters of the operating system driver interface; A real-time operating system driver call instruction is constructed based on a virtual device handle, interface call parameters, an execution context identifier, and a task trigger chain; wherein the execution context identifier is an identifier derived from a source core identifier.

[0015] Optionally, the chip prototype verification method further includes: Sending interruption event evidence to the second core group via the first core group; The task status information is fed back to the first core group through the second core group.

[0016] Optionally, the chip register operation instructions are assigned to the first core group to execute the hardware real-time verification process, and the real-time operating system driver call instructions are assigned to the second core group to execute the multi-task scheduling verification process, so as to obtain corresponding register snapshots and task scheduling logs respectively, including: Polling the peripheral status register based on the chip register operation instruction until the polling status is a timeout state, so as to record the register snapshot corresponding to the timeout register operation; Creating multiple target tasks based on a real-time operating system driver call instruction to obtain contention log information when each target task competes for current real-time operating system resources; Based on the real-time operating system driver call instruction, the switching delay information and the priority inversion event log of each target task in the second core group are monitored to form a task scheduling log according to the competition log information, the switching delay information and the priority inversion event log.

[0017] Optionally, register snapshots and task scheduling logs are aligned on a timeline basis to generate a chip functional verification result report based on the aligned data, including: Converting the register snapshot timestamp of the first core group to the scheduling clock domain of the second core group to obtain the aligned register snapshot and the aligned task scheduling log; Generate a chip function verification result report based on the bare metal interrupt trigger event data, real-time operating system task wake-up data, real-time operating system resource release data, and bare metal core resource acquisition event data in the aligned register snapshot and the aligned task scheduling log.

[0018] In a second aspect, the present application discloses an electronic device, comprising: memory for storing computer programs; A processor is used to execute a computer program to implement the steps of the aforementioned chip prototype verification method.

[0019] In a third aspect, the present application discloses a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the aforementioned chip prototype verification method are implemented.

[0020] In a fourth aspect, the present application discloses a computer program product, including a computer program / instruction, which implements the steps of the aforementioned chip prototype verification method when executed by a processor.

[0021] The present application discloses a chip prototype verification method, comprising: in a chip prototype verification platform, dynamically dividing the central processing unit cores of a multi-core chip into a first core group and a second core group; wherein the first core group and the second core group maintain clock synchronization and shared memory consistency; performing data exchange between the first core group and the second core group through an inter-core communication agent to obtain verification control instructions; converting test cases into chip register operation instructions or real-time operating system driver call instructions based on the verification control instructions; allocating the chip register operation instructions to the first core group to execute a hardware real-time verification process, and allocating the real-time operating system driver call instructions to the second core group to execute a multi-task scheduling verification process to obtain corresponding register snapshots and task scheduling logs respectively; aligning the register snapshots and the task scheduling logs according to the time axis, so as to generate a chip function verification result report based on the aligned data.

[0022] The above technical solution demonstrates that dynamic core grouping enables the system to flexibly adapt to diverse verification requirements, separating bare-metal cores and RTOS cores, addressing the single verification mode issue inherent in traditional solutions. By driving test conversion through verification control instructions, bare-metal and RTOS verification are coordinated, avoiding the incomplete coverage caused by the split between the two modes in traditional solutions. Timeline alignment of the two logs creates a unified debug view, eliminating incompatibilities between register-level and task-level logs. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0024] Figure 1 A flow chart of a chip prototype verification method provided by an embodiment of the present invention; Figure 2 A schematic diagram of a chip prototype verification system architecture provided by an embodiment of the present invention; Figure 3 A data flow chart for chip prototype verification provided by an embodiment of the present invention; Figure 4 A use case generation flow chart for a test management layer provided in an embodiment of the present invention; Figure 5 A workflow diagram of a test case generation engine provided by the present invention; Figure 6 A test case allocation execution flow chart provided by the present invention; Figure 7 A test case execution flow chart provided by the present invention; Figure 8 An execution flow chart of an environment adaptation layer provided by the present invention; Figure 9 An execution flow chart of a bare metal adapter provided by the present invention; Figure 10 An execution flow chart of an RTOS adapter provided by the present invention; Figure 11 An execution flow chart of an environment synchronization manager provided by the present invention; Figure 12 An execution flow chart of a cache controller in an ARM structure provided by the present invention; Figure 13 A diagram of an electronic device provided by the present invention. DETAILED DESCRIPTION

[0025] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0026] The terms "including" and "having," as used in the present description and accompanying drawings, and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements and may include steps or elements that are not listed.

[0027] In order to enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0028] The chip's SMP (symmetric multiprocessor) architecture is a multi-core architecture in which multiple processor cores share the same physical memory and system resources. This architecture allows multiple cores to execute tasks simultaneously, significantly improving processing power and efficiency. In an SMP architecture, each core can independently run an operating system or application, while working together through efficient communication mechanisms to achieve parallel processing of complex tasks.

[0029] The CPU (Central Processing Unit) in a chip is the core component, responsible for executing program instructions, processing data, and controlling other hardware components. In a multi-core chip, each CPU core has an independent execution unit and instruction decoder, capable of independently running programs. Multiple cores work together through a high-speed cache and bus system, enabling efficient multitasking and data processing capabilities.

[0030] Prototyping is a crucial step in the chip design and development process. By running the design code on an actual hardware platform, it verifies the chip's functionality, performance, and reliability, ensuring that the design meets its intended objectives. Prototyping, typically performed on an FPGA or dedicated development board, provides an operating environment close to that of a real chip, helping engineers quickly identify and resolve issues.

[0031] Verification of SMP architecture chips typically involves both bare-metal and OS-based verification, conducted at different project stages. Bare-metal verification allows for rapid verification of hardware functionality (register operation, interrupt control), and is more efficient because it eliminates the need for OS boot and initialization. OS-based verification involves running the operating system on all cores, simulating a realistic multitasking scenario and verifying task scheduling and resource management.

[0032] The above verification mode has the following disadvantages: 1. Insufficient verification timeliness: OS verification is delayed, resulting in software-hardware interaction problems not being exposed early.

[0033] 2. High repetitive development costs: Bare-metal testing is performed first, and OS testing is introduced later. Bare-metal test cases need to be reconstructed to adapt to the OS environment, which is inefficient.

[0034] 3. Lack of verification scheme: With firmware upgrades, later products may use CPU0 to run the bare metal and CPU1 to run the OS (assuming the current SMP architecture has only two CPUs). However, this bare metal and OS interaction scenario is not covered in the prototype verification phase.

[0035] 4. Debugging gap: The formats of bare metal logs (register snapshots, serial port information) and OS logs (task status) are incompatible, making correlation analysis difficult.

[0036] To this end, the present invention provides a chip prototype verification solution that can achieve comprehensive verification of multi-core collaboration scenarios in hybrid scenarios.

[0037] Reference Figure 1 As shown, the present invention provides a chip prototype verification method, comprising: Step S11: In the chip prototype verification platform, dynamically divide the central processing unit cores of the multi-core chip into a first core group and a second core group; wherein the first core group and the second core group maintain clock synchronization and shared memory consistency.

[0038] In this embodiment, when a test case reaches the chip prototype verification platform, a core partitioning operation of the central processing unit of the multi-core chip is triggered.

[0039] Specifically, if the real-time requirement of the test case meets the preset high real-time condition, the corresponding first central processing unit core is allocated to the test case, and the first central processing unit core is divided into the first core group; it can be understood that if the real-time requirement of the test case is a microsecond response, the test case is determined to be a high real-time use case (for example: an interrupt response test case), and the corresponding first central processing unit core is allocated to the test case, and the first central processing unit core is divided into the first core group, that is, the bare metal core group.

[0040] Specifically, if the task complexity of the test case meets the preset high complexity condition, the corresponding second CPU core is assigned to the test case and the second CPU core is assigned to the second core group. It is understood that if the task complexity of the test case is multi-task dependency, the test case is determined to be a complex scheduling test case (for example, a multi-task competition test case), and the corresponding second CPU core is assigned to the test case and the second CPU core is assigned to the second core group, namely the RTOS (Real Time Operation System) core group.

[0041] It's important to note that the essence of this partitioning operation is to modify the core operating mode register (such as ARM SCR_EL3). For the bare-metal core group, the OS scheduler is disabled and the cores are directly connected to the hardware interrupt controller. For the RTOS core group, the task scheduler is enabled and the real-time operating system image is loaded. Furthermore, to ensure dynamic partitioning, the load of both core groups must be monitored for real-time adjustments. Specifically, when the bare-metal core group's load exceeds 90%, the idle RTOS cores are reconfigured to bare-metal mode. When tasks accumulate in the RTOS core group, the idle bare-metal cores are switched back to RTOS mode.

[0042] In this way, through the core group division, the bare metal core group performs hardware real-time verification (such as interrupt response) and the RTOS core group performs multi-task scheduling verification. The two run in parallel. Compared with the traditional serial verification of bare metal first and then OS, the total verification cycle is shortened.

[0043] In this embodiment, after the central processing unit cores of the multi-core chip are dynamically divided into the first core group and the second core group, it also includes: binding the clock references of the first core group and the second core group to the same system clock source through the environment synchronization manager, or calibrating the time deviation between the first core group and the second core group through a timer interrupt to maintain clock synchronization between the first core group and the second core group. Specifically, binding the clock references of the first core group and the second core group to the same system clock source through the environment synchronization manager includes: obtaining the reference time of the first core group through a global timer register, and mapping the reference time to the system clock source of the second core group. It can be understood that after completing the dynamic division of the central processing unit cores, the environment synchronization manager immediately starts the clock synchronization process, where the synchronization process can be divided into a dual-mode clock synchronization path.

[0044] Clock source binding clock synchronization: The environment synchronization manager uses the global timer register as the only clock source; the first core group (bare metal core group) directly reads the count value of this register as the reference time through atomic instructions; the second core group (RTOS core group) modifies the clock driver of the operating system kernel, writes the register address to the clock configuration register, and maps the register value to the operating system clock source, replacing its local timer.

[0045] Interrupt calibration clock synchronization: The environment synchronization manager periodically sends high-precision timer interrupts to the dual-core group. The first core group records the local timestamp of the interrupt arrival. The second core group compares the theoretical interrupt arrival time with the actual timestamp, dynamically calculating and compensating for clock skew. Specifically, when the time skew between the two core groups exceeds a threshold (e.g., 1 microsecond), the interrupt calibration clock synchronization process is retriggered. Synchronization calibration is enforced before critical verification stages (e.g., interrupt response testing).

[0046] By binding to the same hardware clock source or interrupt calibration, clock drift between bare-metal cores and OS cores can be fundamentally addressed, ensuring comparable timestamps for key events such as interrupt trigger times and task scheduling records. This improves the accuracy of causal relationship analysis for events across core groups. The clock synchronization mechanism eliminates occasional failures caused by inter-core timing deviations, increases the recurrence rate of failures in cross-core collaboration scenarios, and significantly reduces debugging blind spots. Hardware-level clock binding avoids the overhead of software synchronization, saving synchronization time for each test. Timing consistency guarantees eliminate the need for repeated execution of test cases in mixed verification scenarios due to clock issues, shortening the overall verification cycle. The nanosecond-level precision of the global timer register provides the foundation for microsecond-level real-time verification (such as interrupt delay detection), improving the detection rate of timing violations and reducing missed detections.

[0047] In this embodiment, after dynamically dividing the central processing unit (CPU) cores of a multi-core chip into a first core group and a second core group, the process further includes: controlling data visibility in the shared memory between the first and second core groups through a context synchronization manager based on preset refresh instructions and memory barrier instructions. Specifically, after the first core group performs a write operation to shared memory, the context synchronization manager triggers the preset refresh instruction to control cache flushing of the shared memory between the first and second core groups. It is understood that the synchronization process is triggered only after the first core group (bare metal core) performs a write operation to shared memory. The write operation includes key actions such as register configuration and DMA descriptor update. The preset refresh instruction specifically refers to a cache maintenance instruction, which is automatically inserted by the context synchronization manager into the instruction stream after the write operation. After the first core group writes to shared memory, the preset refresh instruction is immediately executed to force the cache data back to main memory. Subsequently, a full memory barrier instruction (DSB SY) is inserted to ensure that the refresh operation completes before executing subsequent instructions. Before reading shared memory, the second core group (RTOS core) executes the DMB ISH instruction to ensure data visibility. It's important to note that during synchronization, synchronization is enabled only for areas marked as shared memory (e.g., mailbox buffer addresses 0x8000_0000-0x8001_0000); synchronization is not required for core group-private memory areas (e.g., task stacks). Refresh intensity is dynamically adjusted based on shared memory access frequency, with refresh and full barrier strategies enabled for high-frequency access areas and only memory barriers for low-frequency areas. When a data conflict is detected (e.g., a checksum failure), the system automatically escalates to a DSB+ISB full barrier sequence.

[0048] This hardware-level collaboration between mandatory cache flushes after writes and memory barriers eliminates data inconsistencies between multiple cores, ensuring that the second core group has access to the latest shared data in real time. This improves the accuracy of cross-core collaborative verification results and reduces misjudgments caused by unflushed caches. Memory barrier instructions eliminate write buffer latency, ensuring that critical data such as interrupt trigger timestamps are immediately visible, reducing real-time detection errors. By synchronizing only shared memory regions, performance overhead is reduced compared to global cache flushes. The barrier instruction strength is selected as needed, reducing unnecessary synchronization operations and accelerating verification execution.

[0049] In this embodiment, the context synchronization manager controls cache coherence of shared memory between the first and second core groups based on a hardware coherence protocol. It is understood that the context synchronization manager enables a pre-defined hardware coherence protocol (e.g., the MOESI protocol of the ARM CCI-400) based on the chip architecture and configures the protocol control registers at system startup. A cache coherence domain (shareable domain) is set for the shared memory region (e.g., the address range 0x80000000-0x80100000), enforcing automatic coherence maintenance between core groups within this region. When the first core group (bare metal cores) modifies shared memory data, the hardware protocol automatically triggers a cache snooping mechanism: the cache controller of the second core group (RTOS cores) detects the modified address in real time. If the address matches, the local cache line is marked invalid or updated to the latest value. The core groups do not need to execute any flush or barrier instructions; data visibility is directly guaranteed by the hardware. The context synchronization manager collects protocol state machine information in real time and automatically injects a bus lock to resolve conflicts when it detects a state anomaly (e.g., multiple core groups simultaneously holding the Modified state). For scenarios where peripherals such as DMA (Data Memory Access) access shared memory, the I / O (Input / Output) coherence protocol is enabled. Specifically, before DMA transmission, the hardware protocol automatically writes back the relevant cache; after DMA completion, the cache of the affected core group is automatically invalidated.

[0050] This allows the hardware protocol to automatically maintain cache status, eliminating the performance loss of software refresh instructions and improving verification efficiency. A state-machine-based conflict detection mechanism reduces verification errors caused by cache inconsistencies. It supports collaborative access between multiple cores and peripherals, ensuring consistency in complex SoC (System-on-a-Chip) verification scenarios.

[0051] Step S12: Data is exchanged between the first core group and the second core group through the inter-core communication agent to obtain a verification control instruction.

[0052] In this embodiment, control instructions are exchanged between the second and first core groups via mailbox registers to obtain verification control instructions containing the source core identifier, target peripheral address, operation type code, and parameter list. As will be understood, the mailbox register hardware architecture provides four 32-bit mailbox registers (with fixed address mapping) dedicated to each CPU core, supporting atomic write operations and interrupt triggering mechanisms. The mailbox data format stores the source core identifier in the upper 16 bits, and the lower 16 bits are split into the operation type code (4 bits) and the target peripheral base address index (12 bits). The second core group writes the complete instruction (including the parameter list) into a shared memory ring buffer, then writes the buffer pointer and operation summary to the mailbox register of the first core group, triggering a mailbox interrupt. The first core group responds to the interrupt, reads the summary information from the mailbox, locates the shared memory area based on the second core group identifier, and extracts the complete parameter list. If the mailbox overflows, it automatically redirects to a backup mailbox, and records the transfer failure count in the performance monitoring register. If parameter verification fails (for example, an illegal address), an error code is returned via the reverse mailbox. Mailbox interrupts are bound to the highest hardware priority to ensure microsecond response times. Key instructions (e.g., interrupt triggers) are transmitted using mailbox + shared memory dual-channel redundant transmission.

[0053] In this way, the atomic operation and interrupt mechanism of the hardware mailbox register can realize microsecond-level instruction interaction and ensure real-time verification requirements.

[0054] In this embodiment, data exchange also includes: sending interrupt event evidence from the first core group to the second core group; and feedback of task status information from the second core group to the first core group. It is understood that the content and generation of interrupt event evidence specifically include: when the first core group captures a hardware interrupt, it accurately records the timestamp (from the global timer), interrupt vector number, and triggering peripheral address, forming a three-tuple of evidence. A dedicated interrupt status register (such as INT_STAT) stores the evidence in real time and is automatically captured by a hardware probe. The task status information feedback mechanism is as follows: when a task switch occurs, the second core group (RTOS) writes the task ID, status (running / ready / blocked), resource holding list, and time slice margin to a shared memory status table. The status table address is communicated to the first core group in real time via a mailbox register, ensuring microsecond-level update visibility. In this way, the interrupt event evidence is bound to the source task ID (such as the task to which the interrupt service thread belongs) through a cross-core correlation transmission protocol. Cross-core correlation is achieved through the interrupt evidence, task ID, and status table entry. Critical status changes (such as deadlock) trigger a high-priority mailbox interrupt, forcing the first core group to respond immediately. Automatically perform DC CIVAC cache refresh after interrupt evidence is written; insert DMB memory barrier before reading task status to prevent data tearing.

[0055] Step S13: Convert the test case into a chip register operation instruction or a real-time operating system driver call instruction based on the verification control instruction.

[0056] In this embodiment, a test case is converted into a chip register operation instruction based on a verification control instruction, including: parsing the test case's operation steps and expected results; parsing the verification control instruction to obtain a source core identifier, target peripheral address, operation type code, and parameter list information; determining the register operation type based on the expected result and operation type code; wherein register operation types include register write, register read, bit set, and bit clear; generating an operand value and a data mask based on the parameter list information; constructing a chip register operation instruction sequence that represents timeout detection based on the register operation type, target peripheral address, data mask, and operand value; and embedding the source core identifier in the sequence header of the chip register operation instruction sequence to obtain the chip register operation instruction. It is understood that the test case and verification control instruction are parsed simultaneously, wherein the test case is parsed to obtain the operation steps and expected results, and the verification control instruction is parsed to obtain the source core identifier, target peripheral address, operation type code, and parameter list, and an operation semantic mapping relationship is established. When the operation type code is a write and the expected result is not empty, it is automatically converted to a verification write (with a readback check inserted after the write); when the operation type code is a read, an expected result comparison instruction is forcibly inserted. The timeout detection method embeds a hardware timeout counter in polling instructions (such as status register checks) using the following format: <operation type> <address> <mask> <expected value> timeout=<threshold>. The atomic instruction format for the instruction sequence generation rule is the four-tuple <register operation type><target peripheral address><data mask><operand value> (e.g., SET_BIT 0x4000F000 0xFF 0x01). The sequence header embeds the source core identifier (e.g., [SRC:CPU1]), which is hard-linked to the logging system. A DSB (data barrier) instruction is then automatically appended to shared peripheral operations, and an ISB (instruction synchronization barrier) instruction is appended to interrupt-related operations, resulting in the final chip register operation instructions.

[0057] In this embodiment, converting a test case into a real-time operating system driver call instruction based on a verification control instruction includes: parsing the task dependency relationship and resource constraints of the test case to construct a task trigger chain based on the task dependency relationship; parsing the verification control instruction to obtain the source core identifier, target peripheral address, operation type code, and parameter list information; mapping the target peripheral address to a virtual device handle; selecting a corresponding operating system driver interface according to the resource constraints and operation type code; encapsulating the parameter list into an interface call parameter of the operating system driver interface; constructing a real-time operating system driver call instruction based on the virtual device handle, interface call parameter, execution context identifier, and task trigger chain; where the execution context identifier is an identifier derived based on the source core identifier. It can be understood that according to the task dependency relationship of the test case (such as task B is triggered after task A is completed), event waiting instructions and signal notification instructions are generated to form a task chain executable by hardware. Parse the source core identifier, target peripheral address, operation type code, and parameter list of the verification control instruction, where: the target peripheral address is mapped to a virtual device handle through IOMMU (Input / Output Memory Management Unit); the operation type code is dynamically bound to the OS driver API (Application Program Interface). Resource constraint hard coding: Convert the resource constraints (semaphores, locks) of the test case into instructions before and after the API call to prevent resource competition. Generate a globally unique execution context ID (ctx_<source core ID>_<case ID>) from the source core identifier and embed it in the task scheduling metadata. Combine the virtual device handle, API parameters, context ID, and task trigger chain to generate a standard call sequence, and the specific format is: <API function name>(<virtual device handle>, <parameter list>, <execution context>).

[0058] The automatic conversion of test cases is implemented as test instructions independent of the environment issued by the test management layer. Taking the UART test as an example, the instruction is TEST_UART_TX(id=UART0, data="Hello", timeout=100ms). The differences between bare-metal test cases and RTOS test cases are shown in Table 1 below: Table 1 Differences between Bare-Metal Test Cases and RTOS Test Cases To implement the automatic conversion of test cases, a bare-metal protocol encapsulation module and an RTOS API conversion module are introduced. The bare-metal protocol encapsulation module converts the case into a bare-metal test case, and the RTOS API conversion module converts the case into an RTOS test case, and uniformly calls the HAL (Hardware Abstraction Layer) interface for execution.

[0059] Step S14: Allocate chip register operation instructions to the first core group to execute the hardware real-time verification process, and allocate real-time operating system driver call instructions to the second core group to execute the multi-task scheduling verification process to obtain corresponding register snapshots and task scheduling logs respectively.

[0060] In this embodiment, the peripheral status register is polled based on chip register operation instructions until the polling status reaches a timeout state, thereby recording a register snapshot corresponding to the timed-out register operation. It is understood that when the chip register operation instruction explicitly includes the POLL opcode and the preset timeout threshold is greater than 0, the polling process is initiated. The polling operation is performed as follows: the physical address of the peripheral status register is directly read, disabling the use of memory cache to ensure data real-time. The status bit is immediately checked after each read, and polling is terminated if it meets expectations. The timeout determination operation includes: loading the timeout threshold into a timer when polling is initiated; when the timer overflow interrupt is triggered, forcibly terminating the polling and marking the timeout state. When a timeout occurs, three key register snapshots are captured: the polled target register (e.g., UART_STAT), the associated control register (e.g., UART_CTRL), and the system fault status register (e.g., FAULT_STATUS). The snapshot data is accompanied by a timestamp, the polling number, and the last read value. After a timeout, the peripheral is automatically reset to prevent fault propagation. The snapshot is stored in a dedicated ECC-protected memory area.

[0061] In this way, the forced timeout mechanism triggered by the hardware timer captures microsecond-level status register anomalies and solves the missed detection problem caused by thread scheduling delays in traditional polling.

[0062] In this embodiment, multiple target tasks are created based on the real-time operating system driver call instruction to obtain competition log information when each target task competes for the current real-time operating system resources; based on the real-time operating system driver call instruction, the switching delay information and priority inversion event log of each target task in the second core group are monitored to form a task scheduling log based on the competition log information, switching delay information and priority inversion event log.

[0063] Step S15: Aligning the register snapshot and the task scheduling log according to the time axis, so as to generate a chip function verification result report based on the aligned data.

[0064] In this embodiment, the register snapshot timestamps of the first core group are converted to the scheduling clock domain of the second core group to obtain an aligned register snapshot and aligned task scheduling log. A chip functional verification report is generated based on the bare-metal interrupt trigger event data, real-time operating system (RTOS) task wakeup data, real-time operating system (RTOS) resource release data, and bare-metal core resource acquisition event data in the aligned register snapshot and aligned task scheduling log. It is understood that converting the register snapshot timestamps of the bare-metal core group to the scheduling clock domain of the RTOS core group marks the causal chain of cross-core group events. The causal chain includes: OS task wakeup events corresponding to bare-metal interrupt trigger events; bare-metal core resource acquisition events corresponding to OS core resource release events. The core ratio between the bare-metal and RTOS core groups is dynamically adjusted based on the verification report, and this feedback is fed into the allocation strategy for subsequent test cases. The chip functional verification report includes register-level defect location information, real-time violation analysis, and multi-core resource contention deadlock detection results. This allows the system to trace back the task that most recently manipulated the register on the timeline when a register value error is detected; and to correlate the interrupt storm records of the bare-metal core group during the same period when a task is blocked. The verification strategy is dynamically optimized based on the alignment results: if interrupt response timeouts are detected continuously, the proportion of bare metal core groups is increased; if task priority inversion is detected, hardware scheduler stress test cases are injected.

[0065] Reference Figure 2 As shown, the present invention provides a chip prototype verification framework that supports hybrid verification of bare metal and real-time operating system (RTOS), which is suitable for system-level functional verification of multi-core homogeneous chips. The system is divided into four layers: Test management layer: responsible for test case generation, distribution and result analysis. Environment adaptation layer: provides bare metal / RTOS dual-mode verification environment isolation and protocol conversion. Hardware abstraction layer (HAL): implements unified access control of hardware resources. Target chip hardware: multi-core chip platform based on SMP architecture, that is, DUT prototype verification platform. The data flow of the entire system is divided into forward flow and reverse flow: Forward flow: After the test instructions are converted by the environment adaptation layer, the target hardware is operated through HAL. Reverse flow: The hardware status data is captured by HAL, processed by the environment adaptation layer, and fed back to the test management layer. The data flow is as follows: Figure 3 shown.

[0066] Reference Figure 4As shown, the role of the test management layer is to generate use cases, dynamically issue tasks, and analyze cross-mode data, including a test case generation engine, a task distribution controller, and an intelligent analysis engine. The test case generation engine automatically generates test cases based on verification requirements, and supports random generation (covering unknown scenarios) and manual template library calls (covering critical paths). Specifically, the input information of the engine is: verification requirements (target modules, coverage requirements). Manually predefined test templates (such as startup process, low power mode). The output is: a standardized test case set (including operation steps and expected results). As shown Figure 5 As shown in the figure, the execution flow of the use case generation engine is as follows: First, mode selection is performed. There are two types of mode selection: 1. Random generation: an algorithm is used to generate a random sequence of GPIO, UART, and DMA operations. 2. Template call: a scenario (such as DMA transfer) is selected from the template library and parameters (address, data length) are filled in. Then, the compliance check step begins, filtering out illegal operations (such as writing to a read-only register). Finally, the use case is output: a test instruction set that can be directly executed is generated.

[0067] Reference Figure 6 As shown, the task dispatch controller dynamically assigns test cases to bare metal core groups or RTOS core groups to optimize resource utilization. The task dispatch controller's input information includes: a test case queue (with priority tags) and real-time core group resource occupancy (CPU load, memory usage). Its output information includes: a task allocation table (specifying the core group that executes each test case). The specific execution process involves obtaining the load status of each core group in real time. Dynamic allocation: Bare metal core groups: assign high-real-time test cases (such as interrupt response tests). RTOS core groups: assign complex scheduling test cases (such as multi-task competition tests). Finally, it ensures that dependent test cases are executed sequentially.

[0068] Reference Figure 7 As shown in the figure, the intelligent analysis engine determines whether the use case execution result is passed based on the register snapshot of the bare metal core and the task log of the RTOS core. The input information of the intelligent analysis engine is: the register status of the bare metal core (such as interrupt flags, peripheral register values), and the task log of the RTOS core (such as scheduling records, semaphore status). The output is: verification result report (pass / fail, failure cause location). Figure 7 As shown in the figure, the specific execution process is as follows: The bare metal and RTOS logs are merged along the timeline. For the bare metal core, register values ​​are checked to ensure they meet expectations (e.g., correct GPIO levels). For the RTOS core, task execution order and resource usage are verified. Failed items (e.g., interrupt failures and task deadlocks) are then automatically marked.

[0069] Reference Figure 8As shown, the environment adaptation layer receives test cases from the test case management layer and distributes them to the bare metal adapter or RTOS adapter according to the execution mode. Both can execute the test cases separately on the bare metal core or RTOS core. If the test case involves both, it can also be executed interactively through the environment management synchronizer and the inter-core communication agent.

[0070] Furthermore, a hardware instruction fusion engine can be added to the environment adaptation layer. Implemented in FPGA programmable logic, the instruction fusion engine receives verification control instructions and test case raw data and directly outputs executable instructions. This engine, leveraging a pre-programmed library of multi-type instruction templates, directly receives verification control instructions and test case data from the test management layer, bypassing the parsing, decision-making, and packaging steps involved in the conversion process to achieve real-time instruction synthesis and output. Functionally, the engine integrates three levels of processing units: an instruction feature extraction unit, which uses parallel comparison circuitry to rapidly identify the operation types (such as register reads and writes, DMA transfers, and interrupt configurations) in test cases. A parameter mapping unit, which uses a hardware lookup table to populate the instruction fields with raw data according to the template format, supports dynamic adaptation of 16-bit to 64-bit instruction widths. Finally, a checksum generation unit, which adds a CRC checksum in real time, ensures instruction integrity. This all-hardware processing architecture reduces the latency of single instruction generation from the microseconds of software conversion to nanoseconds, making it particularly suitable for intensive verification scenarios involving high-frequency peripherals (such as high-speed ADCs and PCIe controllers running at over 1GHz), meeting the generation requirements of millions of instructions per second.

[0071] The engine strictly limits the range of parameter values ​​through hardware boundary checking circuits, reducing common vulnerabilities such as memory out-of-bounds and buffer overflows in software parsing; at the same time, its solidified instruction generation logic avoids instruction timing deviations caused by operating system scheduling delays, thereby improving the accuracy of instruction generation. In addition, the engine's built-in dynamic learning module can automatically optimize the template matching strategy by statistically analyzing the characteristic distribution of historical instruction streams. For example, for frequently appearing UART baud rate configuration instructions, its template priority is dynamically adjusted to shorten the synthesis time, thereby achieving continuous optimization of verification efficiency. The introduction of this hardware instruction fusion engine not only makes up for the performance bottleneck of traditional software conversion in high-frequency scenarios, but also improves the stability of instruction generation through hardware-level reliability design, providing key support for the high real-time and high-throughput verification requirements in mixed-mode verification.

[0072] Reference Figure 9 As shown in the figure, the bare metal adapter implements deterministic hardware operations and lightweight communication in an OS-less environment, stores task handles in a static array, executes tasks in a fixed order, or performs simple interrupt processing (compared to the RTOS adapter, it only saves system registers and cannot add interrupt context).

[0073] Reference Figure 10 As shown in the figure, the RTOS adapter implements virtualized resource management and scheduling within the OS environment, supporting virtualized drivers and interrupt threading. First, virtualized drivers include: address remapping: physical addresses are mapped to task-private virtual space through the IOMMU. Device instantiation: each task has its own virtual device context (such as an independent UART buffer). Next, interrupt threading includes: the upper half of the interrupt process: simply logging events and triggering thread semaphores. The lower half of the interrupt process: dedicated threads handle complex logic (such as DMA data transfer).

[0074] Reference Figure 11 As shown in Figure 1, when the test case involves the interaction between the bare metal core and the RTOS core, the environment synchronization manager must ensure clock synchronization and memory consistency between the two to prevent the failure of collaborative task execution. The environment synchronization manager must maintain clock domain alignment and memory consistency. Clock domain alignment ensures that the time base of the bare metal and RTOS cores is consistent. Figure 12 As shown in the figure, the cache controller in the ARM structure is used to ensure the read and write visibility of shared memory by multiple cores and achieve memory consistency maintenance.

[0075] In addition, an inter-core communication agent is used to exchange information between bare-metal cores and RTOS cores when they work together. This inter-core communication mechanism utilizes mailboxes and shared memory. Mailboxes: Each core is allocated four 32-bit mailboxes; they support atomic writes and interrupt triggering, and the message format includes the source core ID and command code. Shared memory: This area is divided into 16 blocks (8KB each) and managed using a ring buffer. Memory barrier instructions ensure multi-core access consistency.

[0076] The hardware abstraction layer also provides a unified hardware operation interface, shielding underlying hardware differences and enabling collaborative verification of bare-metal cores and OS cores, ensuring the reliability and portability of the verification environment. This layer includes register operation modules, interrupt management modules, and inter-core communication modules. The hardware abstraction layer also generates logs, which are returned to the environment adaptation layer. The environment adaptation layer then returns them to the test management layer for use case execution analysis.

[0077] The register operation module encapsulates hardware operations such as registers, interrupts, and communications, simplifying upper-layer calls and supporting both direct operations on bare-metal cores and virtualized access by OS cores. It enables direct access to physical addresses for bare-metal cores and maps physical addresses to virtual space via the IOMMU, isolating access permissions for different tasks. For example, a bare-metal core configures a timer by writing directly to the TIMER_CTRL register, while the OS core reads the peripheral status through a virtual driver, calling hal_uart_get_status().

[0078] The interrupt management module manages interrupt triggering, routing, and processing, optimizing real-time performance and multi-core collaboration efficiency. This module implements the following features: Peripheral interrupts are routed to the OS core group by default, but critical interrupts (such as DMA completion) can be dynamically redirected to the bare-metal core. The OS core interrupt service routine (ISR) only logs the event, offloading complex processing to the task thread to avoid blocking. For example, the bare-metal core responds to a high-speed ADC interrupt while the OS core handles a network protocol stack interrupt.

[0079] The inter-core communication module enables efficient data exchange and synchronization between the bare metal core and the OS core. It assigns fixed physical addresses to the bare metal core to create a bare metal core-exclusive area, and dynamically maps virtual addresses to create an OS core-shared area. For example, the bare metal core sends a sensor data-ready signal via a mailbox, and the OS core sends control instructions to the bare metal core via shared memory.

[0080] It can be seen that the hybrid verification mode proposed in this solution supports parallel testing of bare metal and OS cores, which can shorten the verification cycle. The unified log framework realizes the time axis alignment of register snapshots and task logs. The use case automatic conversion is realized through the environment adaptation layer, and the use case reuse rate is improved. It provides a full process guarantee from early verification to pre-tapeline debugging for complex SoC design, which promotes the shortening of chip R&D cycle and the leap in quality.

[0081] The present application discloses a chip prototype verification method, comprising: in a chip prototype verification platform, dynamically dividing the central processing unit cores of a multi-core chip into a first core group and a second core group; wherein the first core group and the second core group maintain clock synchronization and shared memory consistency; performing data exchange between the first core group and the second core group through an inter-core communication agent to obtain verification control instructions; converting test cases into chip register operation instructions or real-time operating system driver call instructions based on the verification control instructions; allocating the chip register operation instructions to the first core group to execute a hardware real-time verification process, and allocating the real-time operating system driver call instructions to the second core group to execute a multi-task scheduling verification process to obtain corresponding register snapshots and task scheduling logs respectively; aligning the register snapshots and the task scheduling logs according to the time axis, so as to generate a chip function verification result report based on the aligned data.

[0082] The above technical solution demonstrates that dynamic core grouping enables the system to flexibly adapt to diverse verification requirements, separating bare-metal cores and RTOS cores, addressing the single verification mode issue inherent in traditional solutions. By driving test conversion through verification control instructions, bare-metal and RTOS verification are coordinated, avoiding the incomplete coverage caused by the split between the two modes in traditional solutions. Timeline alignment of the two logs creates a unified debug view, eliminating incompatibilities between register-level and task-level logs.

[0083] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 13is a structural diagram of an electronic device according to an exemplary embodiment. Figure 13 The content herein shall not be construed as limiting the scope of use of this application. The electronic device may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the chip prototype verification method disclosed in any of the aforementioned embodiments. Furthermore, the electronic device in this embodiment may specifically be an electronic computer.

[0084] In this embodiment, the power supply 23 is used to provide operating voltage for various hardware devices on the electronic device; the communication interface 24 can create a data transmission channel between the electronic device and external devices. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0085] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or CD, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0086] The operating system 221 is used to manage and control the hardware devices on the electronic device and the computer program 222, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of implementing the chip prototype verification method performed by the electronic device disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program capable of implementing other specific tasks.

[0087] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program implements the aforementioned chip prototype verification method. The specific steps of this method can be referred to the corresponding contents disclosed in the aforementioned embodiments and will not be repeated here.

[0088] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0089] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0090] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0091] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0092] The above is a detailed introduction to the technical solution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only applicable to help understand the method of the present application and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A chip prototype verification method, characterized in that: include: In a chip prototype verification platform, the central processing unit cores of a multi-core chip are dynamically divided into a first core group and a second core group; wherein the first core group and the second core group maintain clock synchronization and shared memory consistency; Performing data exchange between the first core group and the second core group through an inter-core communication agent to obtain a verification control instruction; Converting the test case into a chip register operation instruction or a real-time operating system driver call instruction based on the verification control instruction; Allocating the chip register operation instruction to the first core group to execute a hardware real-time verification process, and allocating the real-time operating system driver call instruction to the second core group to execute a multi-task scheduling verification process, so as to obtain corresponding register snapshots and task scheduling logs respectively; The register snapshot and the task scheduling log are aligned according to a time axis, so as to generate a chip function verification result report based on the aligned data.

2. The chip prototype verification method according to claim 1, characterized in that: The method of dynamically dividing the central processing unit cores of the multi-core chip into a first core group and a second core group includes: If the real-time requirement of the test case meets the preset high real-time condition, assigning a corresponding first central processing unit core to the test case and dividing the first central processing unit core into a first core group; If the task complexity of the test case meets a preset high complexity condition, a corresponding second central processing unit core is allocated to the test case, and the second central processing unit core is divided into a second core group.

3. The chip prototype verification method according to claim 1, characterized in that: After dynamically dividing the central processing unit cores of the multi-core chip into the first core group and the second core group, the method further includes: The clock references of the first core group and the second core group are bound to the same system clock source through the environment synchronization manager, or the time deviation between the first core group and the second core group is calibrated through a timer interrupt to maintain clock synchronization between the first core group and the second core group.

4. The chip prototype verification method according to claim 3, characterized in that: Binding the clock references of the first core group and the second core group to the same system clock source through the environment synchronization manager includes: A reference time of the first core group is obtained through a global timer register, and the reference time is mapped to a system clock source of the second core group.

5. The chip prototype verification method according to claim 1, characterized in that: After dynamically dividing the central processing unit cores of the multi-core chip into the first core group and the second core group, the method further includes: Controlling data visibility in the shared memory between the first core group and the second core group based on a preset refresh instruction and a memory barrier instruction through an environment synchronization manager; The cache consistency of the shared memory in the first core group and the second core group is controlled based on a hardware consistency protocol through an environment synchronization manager.

6. The chip prototype verification method according to claim 5, characterized in that: The controlling the visibility of data in the shared memory between the first core group and the second core group based on a preset refresh instruction and a memory barrier instruction through the environment synchronization manager includes: After the first core group executes a shared memory data write operation, the environment synchronization manager triggers a preset refresh instruction to control cache refresh of the shared memory in the first core group and the second core group.

7. The chip prototype verification method according to claim 1, characterized in that: The performing data interaction between the first core group and the second core group through the inter-core communication agent to obtain a verification control instruction includes: The second core group and the first core group are interacted with each other through the mailbox register to obtain a verification control instruction including a source core identifier, a target peripheral address, an operation type code and a parameter list information.

8. The chip prototype verification method according to claim 7, characterized in that: The converting the test case into a chip register operation instruction based on the verification control instruction includes: Analyze the test case operation steps and expected results; Parsing and verifying the control instruction to obtain the source core identifier, the target peripheral address, the operation type code, and the parameter list information; Determining a register operation type according to the expected result and the operation type code; wherein the register operation type includes register write, register read, bit set, and bit clear; generating operand values ​​and data masks according to the parameter list information; Constructing a chip register operation instruction sequence representing timeout detection based on the register operation type, the target peripheral address, the data mask, and the operand value; The source core identifier is embedded in a sequence header of the chip register operation instruction sequence to obtain a chip register operation instruction.

9. The chip prototype verification method according to claim 7, characterized in that: Converting the test case into a real-time operating system driver call instruction based on the verification control instruction includes: Analyze the task dependencies and resource constraints of the test case to build a task trigger chain based on the task dependencies; Parsing and verifying the control instruction to obtain the source core identifier, the target peripheral address, the operation type code, and the parameter list information; Mapping the target peripheral device address to a virtual device handle; Selecting a corresponding operating system driver interface according to the resource constraint and the operation type code; Encapsulating the parameter list as interface call parameters of the operating system driver interface; A real-time operating system driver call instruction is constructed based on the virtual device handle, the interface call parameter, the execution context identifier, and the task trigger chain; wherein the execution context identifier is an identifier derived from the source core identifier.

10. The chip prototype verification method according to claim 7, characterized in that: Also includes: sending interruption event evidence to the second core group through the first core group; The task status information is fed back to the first core group through the second core group.

11. The chip prototype verification method according to claim 1, characterized in that: The chip register operation instruction is distributed to the first core group to execute a hardware real-time verification process, and the real-time operating system driver call instruction is distributed to the second core group to execute a multi-task scheduling verification process to obtain corresponding register snapshots and task scheduling logs respectively, including: Polling the peripheral status register based on the chip register operation instruction until the polling state is a timeout state, so as to record a register snapshot corresponding to the timeout register operation; Creating a plurality of target tasks based on the real-time operating system driver call instruction to obtain competition log information when each of the target tasks competes for current real-time operating system resources; Based on the real-time operating system driver call instruction, the switching delay information and the priority inversion event log of each target task in the second core group are monitored to form a task scheduling log according to the competition log information, the switching delay information and the priority inversion event log.

12. The chip prototype verification method according to any one of claims 1 to 11, characterized in that: The aligning the register snapshot with the task scheduling log according to the time axis so as to generate a chip function verification result report based on the aligned data includes: Converting the register snapshot timestamp of the first core group to the scheduling clock domain of the second core group to obtain an aligned register snapshot and an aligned task scheduling log; A chip function verification result report is generated based on the bare metal interrupt triggering event data, real-time operating system task wake-up data, real-time operating system resource release data, and bare metal core resource acquisition event data in the aligned register snapshot and the aligned task scheduling log.

13. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to execute the computer program to implement the steps of the chip prototype verification method according to any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the chip prototype verification method according to any one of claims 1 to 12.

15. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the steps of the chip prototype verification method according to any one of claims 1 to 12 are implemented.

Images