A chip prototyping verification method, device, medium and product

Abstract

The application discloses a chip prototype verification method and device, medium and product, and relates to the technical field of integrated circuit verification, and comprises the following steps: in a chip prototype verification platform, a central processing unit core of a multi-core chip is dynamically divided into a first core group and a second core group; data interaction is performed on the first core group and the second core group through an inter-core communication agent to obtain a verification control instruction; a test case is converted into a chip register operation instruction or a real-time operating system driver calling instruction based on the verification control instruction; 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 calling instruction is distributed to the second core group to execute a multi-task scheduling verification process, so that corresponding register snapshots and task scheduling logs are obtained; the register snapshots and the task scheduling logs are aligned according to a time axis, so that a chip function verification result report is generated based on the aligned data. The application realizes the collaborative verification of bare machine and real-time operating system verification.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit verification technology, and in particular to a chip prototype verification method, equipment, medium, and product. Background Technology

[0002] Prototyping is a crucial step in chip design and development. It involves running design code on an actual hardware platform to verify the chip's functionality, performance, and reliability, ensuring the design meets expected goals. Prototyping is typically performed on FPGAs (Field-Programmable Gate Arrays) or dedicated development boards, providing a near-real-chip operating environment that helps engineers quickly identify and resolve issues.

[0003] Verification of SMP (Symmetrical Multi-Processing) architecture chips typically involves two modes: bare-metal verification and OS (Operating System) verification. These two modes are conducted at different stages of the project. Bare-metal verification can quickly verify hardware functions (register operations, interrupt control), and is more efficient because it eliminates the need for OS startup and initialization. OS-level verification, on the other hand, involves running the operating system on all cores to simulate real-world multitasking scenarios and verify task scheduling and resource management. However, performing bare-metal testing first and then introducing OS testing later requires refactoring bare-metal test cases to adapt to the OS environment, resulting in inefficiency. Furthermore, the time lag in OS verification prevents early exposure of hardware-software interaction issues. Additionally, the incompatibility between bare-metal logs and OS log formats makes correlation analysis difficult.

[0004] It is evident that how to achieve comprehensive verification of multi-core collaborative scenarios in mixed environments is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to provide a chip prototype verification method, device, medium, and product that can achieve comprehensive verification of multi-core collaborative scenarios in mixed environments.

[0006] To address the aforementioned technical problems, embodiments of the present invention provide a chip prototype verification method, comprising:

[0007] In the chip prototype verification platform, the central processing unit core of the multi-core chip is dynamically divided into a first core group and a second core group; the first core group and the second core group maintain clock synchronization and consistent shared memory.

[0008] Data exchange between the first core group and the second core group is conducted through an inter-core communication proxy to obtain verification control commands;

[0009] Based on verification control instructions, test cases are converted into chip register operation instructions or real-time operating system driver call instructions.

[0010] 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 the corresponding register snapshots and task scheduling logs respectively.

[0011] Align register snapshots and task scheduling logs along the timeline to generate chip functional verification result reports based on the aligned data.

[0012] Optionally, the central processing unit cores of the multi-core chip can be dynamically divided into a first core group and a second core group, including:

[0013] If the real-time requirements of the test case meet the preset high real-time conditions, allocate the corresponding first central processing unit core to the test case and divide the first central processing unit core into the first core group;

[0014] If the task complexity of a test case meets the preset high complexity condition, allocate a corresponding second central processing unit core to the test case and assign the second central processing unit core to the second core group.

[0015] Optionally, after dynamically dividing the central processing unit cores of the multi-core chip into a first core group and a second core group, it also includes:

[0016] The clock references of the first and second core groups can be bound to the same system clock source by the environment synchronization manager, or the time deviation between the first and second core groups can be calibrated by timer interrupts to keep the clocks of the first and second core groups synchronized.

[0017] Optionally, the clock references of the first core group and the second core group can be bound to the same system clock source via the environment synchronization manager, including:

[0018] The reference time of the first core group is obtained through the global timer register, and the reference time is mapped to the system clock source of the second core group.

[0019] Optionally, after dynamically dividing the central processing unit cores of the multi-core chip into a first core group and a second core group, it also includes:

[0020] The environment synchronization manager controls the visibility of shared memory in the first and second core groups based on preset refresh and memory barrier instructions;

[0021] The environment synchronization manager controls the cache consistency of shared memory in the first and second core groups based on the hardware consistency protocol.

[0022] Optionally, the visibility of shared memory between the first and second core groups can be controlled via the environment synchronization manager, based on preset refresh instructions and memory barrier instructions, including:

[0023] After the environment synchronization manager performs a shared memory data write operation in the first core group, it triggers a preset refresh instruction to control the cache refresh of shared memory in the first core group and the second core group.

[0024] Optionally, data exchange between the first core group and the second core group is performed via an inter-core communication proxy to obtain verification control instructions, including:

[0025] The second core group and the first core group interact with each other through the mailbox register to obtain verification control instructions containing source core identifier, target peripheral address, operation type code and parameter list information.

[0026] Optionally, test cases are converted into chip register operation instructions based on verification control instructions, including:

[0027] Analyze the operational steps and expected results of test cases;

[0028] Parse and verify the control instructions to obtain the source core identifier, target peripheral address, operation type code, and parameter list information;

[0029] The register operation type is determined based on the expected result and the operation type code; the register operation types include register write, register read, bit set, and bit clear.

[0030] Generate operation values ​​and data masks based on the parameter list information;

[0031] A sequence of chip register operation instructions representing timeout detection is constructed based on register operation type, target peripheral address, data mask, and operand value.

[0032] The source core identifier is embedded in the sequence header of the chip register operation instruction sequence to obtain the chip register operation instructions.

[0033] Optionally, test cases are converted into real-time operating system driver invocation instructions based on verification control instructions, including:

[0034] Analyze the task dependencies and resource constraints of test cases to construct a task triggering chain based on the task dependencies;

[0035] Parse and verify the control instructions to obtain the source core identifier, target peripheral address, operation type code, and parameter list information;

[0036] Map the target peripheral address to a virtual device handle;

[0037] Select the corresponding operating system driver interface based on resource constraints and operation type code;

[0038] The parameter list is encapsulated into interface call parameters of the operating system driver interface;

[0039] The real-time operating system driver calling instructions are constructed based on virtual device handles, interface call parameters, execution context identifiers, and task trigger chains; among them, the execution context identifier is an identifier derived from the source kernel identifier.

[0040] Optional chip prototype verification methods also include:

[0041] Evidence of the interruption event was sent from the first core group to the second core group.

[0042] The second core group feeds back the task status information to the first core group.

[0043] Optionally, chip register operation instructions are assigned to the first core group to execute the hardware real-time verification process, and 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 the corresponding register snapshots and task scheduling logs, including:

[0044] The peripheral status register is polled based on chip register operation instructions until the polling status is timeout, so as to record the register snapshot corresponding to the timeout register operation;

[0045] Multiple target tasks are created based on real-time operating system driver call instructions to obtain contention log information when each target task competes for the current real-time operating system resources.

[0046] Based on the real-time operating system driver call instruction, monitor the switching delay information and priority inversion event logs of each target task in the second core group, so as to form a task scheduling log based on the contention log information, switching delay information and priority inversion event logs.

[0047] Optionally, align register snapshots and task scheduling logs along the timeline to generate a chip functional verification result report based on the aligned data, including:

[0048] Convert the register snapshot timestamp of the first core group to the scheduling clock field of the second core group to obtain the aligned register snapshot and the aligned task scheduling log;

[0049] A chip functional verification result report is generated based on 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 from the aligned register snapshot and aligned task scheduling log.

[0050] Secondly, this application discloses an electronic device, comprising:

[0051] Memory, used to store computer programs;

[0052] A processor for executing computer programs to implement the steps of the aforementioned disclosed chip prototyping method.

[0053] Thirdly, this application discloses a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the aforementioned disclosed chip prototype verification method.

[0054] Fourthly, this application discloses a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the aforementioned disclosed chip prototype verification method.

[0055] This application discloses a chip prototype verification method, comprising: dynamically dividing the 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; wherein the first core group and the second core group maintain clock synchronization and shared memory consistency; exchanging data between the first core group and the second core group through an inter-core communication proxy 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 chip register operation instructions to the first core group to execute a hardware real-time verification process, and allocating real-time operating system driver call instructions 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; aligning the register snapshots and task scheduling logs according to the timeline so as to generate a chip functional verification result report based on the aligned data.

[0056] As can be seen from the above technical solutions, dynamic core grouping allows the system to flexibly adapt to different verification requirements, dividing the system into bare-metal cores and real-time operating system cores, thus solving the problem of the single verification mode in traditional solutions. By driving test conversion through verification control instructions, collaborative verification of bare-metal and real-time operating system systems is achieved, avoiding the incomplete coverage caused by the separation of the two modes in traditional solutions. Aligning the two types of logs along the timeline forms a unified debug view, avoiding the incompatibility problem between register-level and task-level logs. Attached Figure Description

[0057] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 This is a flowchart of a chip prototype verification method provided in an embodiment of the present invention;

[0059] Figure 2 This is a schematic diagram of a chip prototype verification system architecture provided in an embodiment of the present invention;

[0060] Figure 3 A data flow diagram for chip prototype verification provided in an embodiment of the present invention;

[0061] Figure 4 A flowchart for generating test cases for the test management layer is provided in this embodiment of the invention;

[0062] Figure 5 A flowchart illustrating the workflow of a test case generation engine provided by this invention;

[0063] Figure 6 A test case allocation and execution flowchart provided by the present invention;

[0064] Figure 7 A test case execution flowchart provided by the present invention;

[0065] Figure 8 An execution flowchart of an environment adaptation layer provided by the present invention;

[0066] Figure 9 The present invention provides an execution flowchart of a bare-metal adapter;

[0067] Figure 10 The present invention provides an execution flowchart of an RTOS adapter;

[0068] Figure 11 The present invention provides an execution flowchart of an environment synchronization manager;

[0069] Figure 12 The present invention provides an execution flowchart of an in-frame cache controller for an ARM architecture;

[0070] Figure 13 A diagram of an electronic device provided by the present invention. Detailed Implementation

[0071] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0072] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0073] 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 embodiments.

[0074] The SMP (Symmetric Multiprocessor) architecture of a chip 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 run an operating system or application independently, and they work together through efficient communication mechanisms to achieve parallel processing of complex tasks.

[0075] The CPU (Central Processing Unit / Processor) is the core component of a chip, responsible for executing program instructions, processing data, and controlling other hardware components. In multi-core chips, each CPU core has an independent execution unit and instruction decoder, enabling it to run programs independently. Multiple cores work together through a cache and bus system to achieve efficient multitasking and data processing capabilities.

[0076] Prototyping is a crucial step in chip design and development. It involves running the design code on an actual hardware platform to verify the chip's functionality, performance, and reliability, ensuring the design meets expected goals. Prototyping is typically performed on FPGAs or dedicated development boards, providing a near-real-chip operating environment that helps engineers quickly identify and resolve issues.

[0077] Verification of SMP architecture chips typically involves two modes: bare-metal mode and OS mode, which are conducted at different stages of the project. Bare-metal verification can quickly verify hardware functions (register operations, interrupt control), and this verification method is more efficient because it does not require OS startup and initialization. OS-level verification involves running an operating system on all cores to simulate real multi-tasking scenarios and verify task scheduling and resource management.

[0078] The above verification method has the following drawbacks:

[0079] 1. Insufficient verification timeliness: The OS verification is delayed, which prevents software and hardware interaction problems from being exposed in a timely manner.

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

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

[0082] 4. Debugging gap: The bare-metal log (register snapshot, serial port information) and OS log (task status) formats are incompatible, making correlation analysis difficult.

[0083] To this end, the present invention provides a chip prototype verification scheme that can achieve comprehensive verification of multi-core collaborative scenarios in mixed environments.

[0084] Reference Figure 1 As shown, the present invention provides a chip prototype verification method, comprising:

[0085] Step S11: In the chip prototype verification platform, the central processing unit core of the multi-core chip is 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 consistent shared memory.

[0086] In this embodiment, when the test case arrives at the chip prototype verification platform, the CPU core partitioning operation of the multi-core chip is triggered.

[0087] Specifically, if the real-time requirements of a test case meet the preset high real-time conditions, the test case is assigned a corresponding first CPU core and assigned to the first core group. It can be understood that if the real-time requirements of a test case are microsecond-level response, the test case is determined to be a high real-time test case (e.g., interrupt response test case), and the test case is assigned a corresponding first CPU core and assigned to the first core group, which is also the bare-metal core group.

[0088] Specifically, if the task complexity of a test case meets the preset high complexity condition, a corresponding second CPU core is allocated to the test case, and this second CPU core is assigned to the second core group. In other words, if the task complexity of a test case involves multi-task dependencies, then the test case is determined to be a complex scheduling test case (e.g., a multi-task contention test case), and a corresponding second CPU core is allocated to the test case, and this second CPU core is assigned to the second core group, which is the RTOS (Real-Time Operating System) core group.

[0089] It's important to note that the essence of the above partitioning operation is modifying the core runtime mode register (e.g., ARM SCR_EL3). Specifically, for the bare-metal core group, the OS scheduler is disabled, and the hardware interrupt controller is directly connected; for the RTOS core group, the task scheduler is enabled, and the real-time operating system image is loaded. Furthermore, to reflect dynamic partitioning, the load of both core groups needs to be monitored for real-time adjustments. Specifically, when the bare-metal core group load exceeds 90%, idle RTOS cores are reconfigured to bare-metal mode; when the RTOS core group experiences task backlog, idle bare-metal cores are switched to RTOS mode.

[0090] In this way, by dividing the core groups, the bare-metal core group performs real-time hardware verification (such as interrupt response), and the RTOS core group performs multi-task scheduling verification. The two run in parallel, which shortens the total verification cycle compared to the traditional serial verification of bare metal first and then OS.

[0091] In this embodiment, after dynamically dividing the CPU cores of the multi-core chip into a first core group and a second core group, the method further includes: binding the clock references of the first core group and the second core group to the same system clock source through an 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 CPU cores, the environment synchronization manager immediately starts the clock synchronization process, which can be divided into a dual-mode clock synchronization path.

[0092] 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 the register as the base time through atomic instructions; the second core group (RTOS core group) modifies the clock driver of the operating system kernel, writes the register address into the clock configuration register, and maps the register value to the operating system clock source, replacing its local timer.

[0093] Interrupt-based clock synchronization calibration: The environment synchronization manager periodically sends high-precision timer interrupts to the dual-core group; the first core group records the local timestamp when the interrupt arrives; the second core group compares the theoretical arrival time of the interrupt with the actual timestamp, dynamically calculating and compensating for clock deviation. Specifically, when the time deviation of the dual-core group exceeds a threshold (e.g., 1 microsecond), the interrupt-based clock synchronization calibration process is retried; synchronization calibration is forcibly performed before critical verification stages (e.g., interrupt response testing).

[0094] This approach, by binding to the same hardware clock source or interrupt calibration, eliminates clock drift between bare-metal cores and OS cores, ensuring the comparability of timestamps for critical events such as interrupt trigger times and task scheduling records. This improves the accuracy of causal relationship analysis for cross-core events; the clock synchronization mechanism eliminates sporadic faults caused by timing discrepancies between cores, increasing the fault reproducibility rate in cross-core collaboration scenarios and significantly reducing 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 to repeatedly execute test cases due to clock issues in hybrid verification scenarios, compressing 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 timing violation detection rate and reducing missed detections.

[0095] In this embodiment, after dynamically dividing the central processing unit cores of the multi-core chip into a first core group and a second core group, the method further includes: controlling the data visibility of shared memory in the first and second core groups through an environment synchronization manager, based on preset refresh instructions and memory barrier instructions; specifically, after the first core group performs a shared memory data write operation, the environment synchronization manager triggers preset refresh instructions to control the cache refresh of shared memory in the first and second core groups. It can be understood that the synchronization process is triggered only after the first core group (bare-metal cores) performs a shared memory write operation. The write operation includes key actions such as register configuration and DMA descriptor updates. The preset refresh instructions specifically refer to cache maintenance instructions, which are automatically inserted into the instruction stream after the write operation by the environment synchronization manager. After the first core group writes to shared memory, the preset refresh instructions are immediately executed to force the cache data to be flushed back to main memory; subsequently, a full memory barrier instruction DSB SY is inserted to ensure that subsequent instructions are executed only after the refresh operation is completed; before reading shared memory, the second core group (RTOS cores) executes the DMB ISH instruction to ensure data visibility. It is important to note that during synchronization, the synchronization mechanism is only enabled for regions marked as shared memory (e.g., mailbox buffer addresses 0x8000_0000-0x8001_0000); core group private memory regions (e.g., task stack) do not require synchronization. The refresh intensity is dynamically adjusted based on the access frequency of shared memory. High-frequency access regions are enabled with both refresh and full-barrier strategies, while low-frequency regions only use memory barriers. When a data conflict is detected (e.g., verification failure), the process automatically escalates to a DSB+ISB full-barrier sequence.

[0096] This approach, through hardware-level collaboration between forced cache flushing after a write and memory barriers, eliminates data inconsistency issues between multiple cores, ensuring that the second core group obtains the latest shared data in real time. This improves the accuracy of cross-core collaborative verification results and reduces false positives 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 the shared memory region, performance overhead is reduced compared to global cache flushing; selecting barrier instruction strength as needed reduces unnecessary synchronization operations and accelerates verification execution.

[0097] In this embodiment, an environment synchronization manager controls the cache consistency of shared memory between the first and second core groups based on a hardware consistency protocol. It is understood that the environment synchronization manager enables a preset hardware consistency protocol (e.g., the MOESI protocol for ARM CCI-400) according to the chip architecture and configures the protocol control register at system startup. A shared domain is set for the shared memory region (e.g., address range 0x80000000-0x80100000), forcing automatic consistency 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 monitoring 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 as invalid or updated to the latest value. The core groups do not need to execute any refresh or barrier instructions; data visibility is directly guaranteed by the hardware. The environment synchronization manager collects protocol state machine information in real time, and when an abnormal state is detected (e.g., multiple core groups simultaneously holding the Modified state), a bus lock is automatically injected to resolve the conflict. For scenarios where peripherals such as DMA (Data Memory Access) access shared memory, an I / O (Input / Output) coherence protocol is enabled. Specifically, before a DMA transfer, the hardware protocol automatically writes back the relevant cache; after the DMA is completed, the affected core group cache is automatically invalidated.

[0098] In this way, the hardware protocol automatically maintains the cache state, eliminating the performance overhead of software refresh instructions and improving verification efficiency; the state machine-based conflict detection mechanism reduces verification misjudgments caused by cache inconsistency. It supports collaborative access between multi-core and peripheral devices, achieving consistency guarantees in complex SoC (System-on-a-Chip) verification scenarios.

[0099] Step S12: Data exchange between the first core group and the second core group is conducted through the inter-core communication proxy to obtain verification control instructions.

[0100] In this embodiment, the second core group and the first core group interact with control instructions through mailbox registers to obtain verification control instructions containing source core identifier, target peripheral address, operation type code, and parameter list information. It can be understood that the mailbox register hardware structure has four 32-bit mailbox registers exclusively for each CPU core (fixed address mapping), supporting atomic write operations and interrupt triggering mechanisms. The mailbox data format stores the source core identifier in the high 16 bits and splits the low 16 bits into an operation type code (4 bits) + a target peripheral base address index (12 bits). The second core group writes the complete instruction (including the parameter list) to a shared memory circular buffer, and then writes the buffer pointer and operation digest to the mailbox register of the first core group, triggering a mailbox interrupt. The first core group responds to the interrupt, reads the digest information from the mailbox, locates the shared memory area based on the second core group identifier, and extracts the complete parameter list. When the mailbox overflows, it automatically redirects to a backup mailbox and records the transmission failure count in the performance monitoring register. When parameter verification fails (e.g., illegal address), an error code is returned through the reverse mailbox, and the mailbox interrupt is bound to the highest hardware priority to ensure microsecond-level response. Critical instructions (such as interrupt triggers) are transmitted using a dual-channel redundant transmission system consisting of mailboxes and shared memory.

[0101] In this way, the atomic operations and interrupt mechanism of the hardware mailbox register enable microsecond-level instruction interaction, ensuring real-time verification requirements.

[0102] In this embodiment, the data interaction also includes: sending interrupt event evidence to the second core group through the first core group; and feeding back task status information to the first core group through the second 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 to form a triplet of evidence. A dedicated interrupt status register (such as INT_STAT) stores the evidence in real time and automatically captures it through a hardware probe. The task status information feedback mechanism is as follows: when the second core group (RTOS) switches tasks, it writes the task ID, status (running / ready / blocked), resource holding list, and time slice remaining into a shared memory status table. The status table address is communicated to the first core group in real time by the mailbox register, ensuring microsecond-level updates are visible. 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 association transmission protocol, and cross-core association is achieved through interrupt evidence, task ID, and status table entries. Critical status changes (such as deadlock) trigger a high-priority mailbox interrupt, forcing the first core group to respond immediately. After interrupting the evidence writing, the DC CIVAC cache is automatically refreshed; a DMB memory barrier is inserted before reading the task status to prevent data tearing.

[0103] Step S13: Convert test cases into chip register operation instructions or real-time operating system driver call instructions based on verification control instructions.

[0104] In this embodiment, test cases are converted into chip register operation instructions based on verification control instructions. This includes: parsing the operation steps and expected results of the test cases; parsing the verification control instructions to obtain the source core identifier, target peripheral address, operation type code, and parameter list information; determining the register operation type based on the expected results and operation type code; wherein, the register operation type includes register write, register read, bit set, and bit clear; generating operation values ​​and a data mask based on the parameter list information; constructing a chip register operation instruction sequence representing timeout detection based on the register operation type, target peripheral address, data mask, and operation values; and embedding the source core identifier in the sequence header of the chip register operation instruction sequence to obtain the chip register operation instructions. It can be understood that test cases and verification control instructions are parsed simultaneously. Parsing the test cases yields the operation steps and expected results, while parsing the verification control instructions yields the source core identifier, target peripheral address, operation type code, and parameter list, establishing an operation semantic mapping relationship. When the operation type code is write and the expected result is not empty, it is automatically converted to a verification write (with a readback check inserted after writing); when the operation type code is read, an expected result comparison instruction is forcibly inserted. The timeout detection method involves embedding a hardware timeout counter within polling instructions (such as status register checks), formatted as: <operation type> <address> <mask> <expected value> timeout=<threshold>. The atomic instruction format for instruction sequence generation rules is: a quadruple <register operation type> <target peripheral address> <data mask> <operation value> (e.g., SET_BIT 0x4000F000 0xFF 0x01); the sequence header embeds a source core identifier (e.g., [SRC:CPU1]), hard-associated with the log system. Then, DSB (Data Barrier) instructions are automatically appended to shared peripheral operations, and ISB (Instruction Synchronization Barrier) instructions are appended to interrupt-related operations, resulting in the final chip register operation instructions.

[0105] 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 the interface call parameters of the operating system driver interface; constructing a real-time operating system driver call instruction based on the virtual device handle, interface call parameters, 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 wait 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 constraints are hard-coded: 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>).

[0106] The automated 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:

[0107] Table 1 Differences between Bare-Metal Test Cases and RTOS Test Cases

[0108]

[0109] To achieve automatic test case conversion, a bare-metal protocol encapsulation module and an RTOS API conversion module are introduced. The bare-metal protocol encapsulation module converts test cases into bare-metal test cases, and the RTOS API conversion module converts test cases into RTOS test cases. Both are executed by calling the HAL (Hardware Abstraction Layer) interface.

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

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

[0112] In this way, the forced timeout mechanism triggered by the hardware timer can capture microsecond-level status register anomalies, solving the problem of missed detection caused by thread scheduling delays in traditional polling.

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

[0114] Step S15: Align register snapshots and task scheduling logs along the timeline to generate a chip functional verification result report based on the aligned data.

[0115] In this embodiment, the register snapshot timestamp of the first core group is converted into the scheduling clock domain of the second core group to obtain the aligned register snapshot and the aligned task scheduling log. A chip functional verification result report is generated 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. It can be understood that converting the register snapshot timestamp of the bare-metal core group into the scheduling clock domain of the real-time operating system core group marks the causal chain of events across core groups. The causal chain includes: the OS task wake-up event corresponding to the bare-metal interrupt trigger event; and the bare-metal core resource acquisition event corresponding to the OS core resource release event. The core ratio of the bare-metal core group and the real-time operating system core group is dynamically adjusted based on the verification result report, and fed back to the allocation strategy of subsequent test cases. This chip functional verification report includes register-level defect location information, real-time violation analysis, and multi-core resource contention deadlock detection results. In this way, when a register value error is detected, the task that most recently operated on that register is traced back on the timeline; when task blocking is detected, the interrupt storm record of the bare-metal core group during the same period is associated. The verification strategy is dynamically optimized based on the alignment results: if interrupt response timeouts are detected continuously, the proportion of bare-metal cores is increased; if task priority inversion is detected, hardware scheduler stress test cases are injected.

[0116] Reference Figure 2 As shown, this invention provides a chip prototype verification framework that supports hybrid verification of bare-metal and real-time operating systems (RTOS), suitable for system-level functional verification of multi-core homogeneous chips. The system has a four-layer structure: Test Management Layer: responsible for test case generation, distribution, and result analysis. Environment Adaptation Layer: provides isolation and protocol conversion for bare-metal / RTOS dual-mode verification environments. Hardware Abstraction Layer (HAL): implements unified access control for hardware resources. Target Chip Hardware: a multi-core chip platform based on an SMP architecture, i.e., a DUT prototype verification platform. The entire system's data flow is divided into forward and reverse flows: Forward Flow: Test commands are converted by the Environment Adaptation Layer and then operate the target hardware through the HAL. Reverse Flow: Hardware status data is captured by the HAL, processed by the Environment Adaptation Layer, and then fed back to the Test Management Layer. The data flow is as follows: Figure 3 As shown.

[0117] Reference Figure 4As shown, the test management layer is responsible for test case generation, dynamic task distribution, and cross-mode data analysis. It includes 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, supporting random generation (covering unknown scenarios) and manual template library invocation (covering critical paths). Specifically, the engine's input information includes: verification requirements (target module, coverage requirements); manually predefined test templates (such as startup procedures, low-power modes). The output is: a standardized set of test cases (including operation steps and expected results). Figure 5 As shown, the execution flow of the test case generation engine is as follows: First, mode selection is performed, which is divided into two types: one is random generation: generating random operation sequences for GPIO, UART, and DMA through an algorithm; the other is template invocation: selecting a scenario (such as DMA transfer) from the template library and filling in parameters (address, data length). Then, the compliance verification step is entered, filtering out illegal operations (such as writing to a read-only register). Finally, test cases are output: generating a set of test instructions that can be executed directly.

[0118] Reference Figure 6 As shown, the task distribution controller dynamically allocates test cases to bare-metal core groups or RTOS core groups to optimize resource utilization. The input information for the task distribution controller includes: a test case queue (with priority markers) and real-time core group resource utilization (CPU load, memory usage). The output information is: a task allocation table (specifying the execution core group for each test case). The specific execution flow involves obtaining the load status of each core group in real time. Dynamic allocation: Bare-metal core groups: Allocate high real-time test cases (such as interrupt response tests). RTOS core groups: Allocate complex scheduling test cases (such as multi-task competition tests). Finally, it ensures that test cases with dependencies are executed sequentially.

[0119] Reference Figure 7 As shown, the intelligent analysis engine determines whether the test case execution result passes based on the bare-metal core's register snapshot and the RTOS core's task log. The input information for the intelligent analysis engine is: the bare-metal core's register status (e.g., interrupt flags, peripheral register values) and the RTOS core's task log (e.g., scheduling records, semaphore status). The output is: a verification result report (pass / fail, failure reason location). Figure 7 As shown, the specific execution flow is as follows: merge the logs of the bare metal core and the RTOS core according to the timeline. For the bare metal core, check whether the register values ​​meet expectations (e.g., GPIO levels are correct). For the RTOS core, verify whether the task execution order and resource usage are normal. Then, automatically mark the failed items (e.g., interrupt not triggered, task deadlock).

[0120] 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. The test cases can be executed independently on the bare metal core or the RTOS core. If the test cases involve both, they can also be executed interactively through the environment management synchronizer and the inter-core communication agent.

[0121] Furthermore, a hardware instruction fusion engine can be added to the environment adaptation layer. Implemented by FPGA programmable logic, this engine receives verification control instructions and raw test case data, then directly outputs executable instructions. Through a pre-programmed library of multiple instruction templates, the engine can directly receive verification control instructions and test case data from the test management layer, skipping the parsing, decision-making, and encapsulation steps in the conversion process, achieving real-time instruction synthesis and output. Functionally, the engine integrates three processing units: first, an instruction feature extraction unit, which quickly identifies the operation type in the test case (such as register read / write, DMA transfer, interrupt configuration, etc.) through parallel comparison circuitry; second, a parameter mapping unit, which uses hardware lookup tables to fill the raw data into the instruction field according to the template format, supporting dynamic adaptation of 16-bit to 64-bit wide instructions; and finally, a verification generation unit, which adds CRC checksums in real time to ensure instruction integrity. This all-hardware processing architecture reduces the generation latency of a single instruction from microseconds to nanoseconds, making it particularly suitable for intensive verification scenarios involving high-frequency peripherals (such as high-speed ADCs and PCIe controllers above 1GHz), meeting the generation requirements of millions of instructions per second.

[0122] The engine employs hardware boundary checking circuitry to strictly limit parameter value ranges, reducing common software parsing vulnerabilities such as memory out-of-bounds errors and buffer overflows. Simultaneously, its fixed instruction generation logic avoids instruction timing deviations caused by operating system scheduling delays, improving instruction generation accuracy. Furthermore, the engine's built-in dynamic learning module automatically optimizes template matching strategies by statistically analyzing the feature distribution of historical instruction streams. For example, for frequently occurring UART baud rate configuration instructions, it dynamically adjusts their template priority to shorten synthesis time, achieving continuous optimization of verification efficiency. The introduction of this hardware instruction fusion engine not only overcomes the performance bottleneck of traditional software conversion in high-frequency scenarios but also enhances the stability of instruction generation through hardware-level reliability design, providing crucial support for the high real-time and high-throughput verification requirements in mixed-mode verification.

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

[0124] Reference Figure 10 As shown, the RTOS adapter implements virtualization resource management and scheduling within the OS environment, supporting virtualization drivers and interrupt threading. First, the virtualization driver specifically includes: Address remapping: mapping physical addresses to task-private virtual spaces via the IOMMU; Device instantiation: each task has its own virtual device context (such as an independent UART buffer). Then, interrupt threading specifically includes: Interrupt top half: only recording events and triggering thread semaphores; Interrupt bottom half: complex logic (such as DMA data transfer) is handled by a dedicated thread.

[0125] Reference Figure 11 As shown, when test cases involve 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 collaborative task execution failures. The environment synchronization manager must maintain clock domain alignment and memory consistency. Clock domain alignment ensures that the time bases of the bare-metal and RTOS cores are consistent. Figure 12 As shown, the ARM architecture's internal cache controller ensures read and write visibility of shared memory across multiple cores, thereby achieving memory consistency maintenance.

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

[0127] The Hardware Abstraction Layer (HAL) also provides a unified hardware operation interface, shielding underlying hardware differences and enabling collaborative verification of bare-metal cores and OS cores. This ensures the reliability and portability of the verification environment, including register operation modules, interrupt management modules, and inter-core communication modules. The HAL also includes log generation, returning the generated logs to the environment adaptation layer, which then returns them to the test management layer for analysis of test case execution.

[0128] The register operation module encapsulates hardware operations such as registers, interrupts, and communication, simplifying upper-layer calls. It supports direct operation by the bare-metal core and virtualized access by the OS core. For the bare-metal core, it enables direct access to physical addresses, while for the OS core, it maps physical addresses to virtual space through the IOMMU, isolating access permissions for different tasks. For example, the bare-metal core can configure timers by directly writing to the TIMER_CTRL register, while the OS core can read peripheral status through the virtual driver by calling hal_uart_get_status().

[0129] The interrupt management module manages interrupt triggering, routing, and handling, optimizing real-time performance and multi-core collaboration efficiency. Its functions include: 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. For the OS core interrupt service routine (ISR), only events are logged; complex processing is handed over to task threads to avoid blocking. For example, the bare-metal core responds to high-speed ADC interrupts, while the OS core handles network protocol stack interrupts.

[0130] The inter-core communication module enables efficient data exchange and synchronization between the bare-metal core and the OS core. It allocates fixed physical addresses to the bare-metal core to create a dedicated area for the bare-metal core, and dynamically maps virtual addresses to create a shared area for the OS core. For example, the bare-metal core sends sensor data ready signals via a mailbox, and the OS core sends control commands to the bare-metal core via shared memory.

[0131] As can be seen, the hybrid verification mode proposed in this solution supports parallel testing of bare metal and OS core, which can shorten the verification cycle. The unified logging framework realizes the timeline alignment of register snapshots and task logs. The environment adaptation layer realizes automatic conversion of test cases and improves the reusability of test cases. It provides full-process protection for complex SoC design from early verification to pre-tape-out debugging, and promotes the shortening of chip development cycle and the leap in quality.

[0132] This application discloses a chip prototype verification method, comprising: dynamically dividing the 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; wherein the first core group and the second core group maintain clock synchronization and shared memory consistency; exchanging data between the first core group and the second core group through an inter-core communication proxy 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 chip register operation instructions to the first core group to execute a hardware real-time verification process, and allocating real-time operating system driver call instructions 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; aligning the register snapshots and task scheduling logs according to the timeline so as to generate a chip functional verification result report based on the aligned data.

[0133] As can be seen from the above technical solutions, dynamic core grouping allows the system to flexibly adapt to different verification requirements, dividing the system into bare-metal cores and real-time operating system cores, thus solving the problem of the single verification mode in traditional solutions. By driving test conversion through verification control instructions, collaborative verification of bare-metal and real-time operating system systems is achieved, avoiding the incomplete coverage caused by the separation of the two modes in traditional solutions. Aligning the two types of logs along the timeline forms a unified debug view, avoiding the incompatibility problem between register-level and task-level logs.

[0134] Furthermore, embodiments of this application also disclose an electronic device, Figure 13This is a structural diagram of an electronic device according to an exemplary embodiment. Figure 13 The content herein should not be construed as limiting the scope of this application. Specifically, the electronic device may 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 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the chip prototype verification method disclosed in any of the foregoing embodiments. Furthermore, the electronic device in this embodiment may specifically be an electronic computer.

[0135] 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, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

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

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

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

[0139] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0140] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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.

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

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

[0143] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A chip prototype verification method, characterized in that, include: In the chip prototype verification platform, the central processing unit core of the multi-core chip is 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; Data exchange between the first core group and the second core group is conducted through an inter-core communication proxy to obtain verification control commands; Based on the verification control instructions, test cases are converted into chip register operation instructions or real-time operating system driver call instructions. 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 the corresponding register snapshots and task scheduling logs respectively. Align the register snapshots with the task scheduling logs along the timeline to generate a chip functional verification result report based on the aligned data; The method of dynamically dividing the central processing unit core of a multi-core chip into a first core group and a second core group includes: If the real-time requirements of the test case meet the preset high real-time conditions, the test case is allocated a corresponding first central processing unit core, and the first central processing unit core is assigned to the first core group. If the task complexity of a 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 assigned to the second core group; The process of converting test cases into chip register operation instructions based on the verification control instructions includes: Analyze the operational steps and expected results of test cases; Parse and verify the control instructions to obtain the source core identifier, target peripheral address, operation type code, and parameter list information; The register operation type is determined based on the expected result and the operation type code; wherein, the register operation type includes register write, register read, bit set, and bit clear; Generate operation values ​​and data masks based on the parameter list information; A sequence of chip register operation instructions representing timeout detection is constructed based on the register operation type, the target peripheral address, the data mask, and the operation value. The source core identifier is embedded in the sequence header of the chip register operation instruction sequence to obtain the chip register operation instructions; Based on the verification control instructions, test cases are converted into real-time operating system driver invocation instructions, including: Analyze the task dependencies and resource constraints of the test cases, and construct a task triggering chain based on the task dependencies; Parse and verify the control instructions to obtain the 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 the resource constraints and the operation type code; The parameter list is encapsulated into interface call parameters of the operating system driver interface; The real-time operating system driver invocation instructions are constructed based on the virtual device handle, the interface call parameters, the execution context identifier, and the task trigger chain; wherein, the execution context identifier is an identifier derived from the source kernel identifier.

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

3. The chip prototype verification method according to claim 2, characterized in that, The step of 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 reference time of the first core group is obtained through the global timer register, and the reference time is mapped to the system clock source of the second core group.

4. The chip prototype verification method according to claim 1, characterized in that, After dynamically dividing the central processing unit cores of a multi-core chip into a first core group and a second core group, it also includes: The environment synchronization manager controls the visibility of shared memory in the first core group and the second core group based on preset refresh instructions and memory barrier instructions; The environment synchronization manager controls the cache consistency of shared memory in the first core group and the second core group based on the hardware consistency protocol.

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

6. The chip prototype verification method according to claim 1, characterized in that, The step of exchanging data between the first core group and the second core group through an inter-core communication proxy to obtain verification control commands includes: The second core group and the first core group interact with each other through the mailbox register to obtain verification control instructions containing source core identifier, target peripheral address, operation type code and parameter list information.

7. The chip prototype verification method according to claim 6, characterized in that, Also includes: Evidence of the interruption event is sent from the first core group to the second core group; The second core group feeds back the task status information to the first core group.

8. The chip prototype verification method according to claim 1, characterized in that, The step of allocating the chip register operation instructions to the first core group to execute the hardware real-time verification process, and allocating the 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, includes: Based on the chip register operation instructions, the peripheral status register is polled until the polling status is timeout, so as to record the register snapshot corresponding to the timeout register operation. Multiple target tasks are created based on the real-time operating system driver invocation instructions 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 instructions, monitor the switching delay information and priority inversion event logs of each target task in the second core group, so as to form a task scheduling log according to the contention log information, the switching delay information and the priority inversion event log.

9. The chip prototype verification method according to any one of claims 1 to 8, characterized in that, The process of aligning the register snapshot with the task scheduling log along the time axis to generate a chip functional verification result report based on the aligned data includes: The register snapshot timestamp of the first core group is converted into the scheduling clock field of the second core group to obtain the aligned register snapshot and the aligned task scheduling log; A chip function verification result report is generated based on the aligned register snapshot and 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 task scheduling log.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the chip prototype verification method as described in any one of claims 1 to 9.

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

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

Images