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, relates to the technical field of chip design, is applied to a hardware debugger of a simulation test tool, and comprises the following steps: analyzing a capability maturity model script; the analyzed script and the execution mode switching condition are sent to a central processing unit of the field programmable gate array, so that the central processing unit determines a current execution mode according to the analyzed script and the execution mode switching condition; test case codes of different execution modes in the capability maturity model script are stored in different data areas of a preset memory pool respectively, so that a central processing unit obtains the corresponding test case codes based on the current execution mode, verification data are generated according to the test case codes and peripheral equipment of a pre-configured chip, and the verification data are stored in the preset memory pool; returning the verification data to a hardware debugger of the simulation test tool; and generating a prototype verification report based on the verification data and the expected data to complete chip prototype verification. And chip prototype verification can be realized by dynamically switching verification modes.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of chip design, in particular to a chip prototype verification method, device, medium and product. BACKGROUND

[0002] In the process of chip design and development, prototype verification is a key link to ensure the correctness and stability of the design. Verification is usually carried out on FPGA (Field Programmable Gate Array) or special development boards, which can provide a running environment close to the real chip and help engineers quickly find and solve problems. Through prototype verification, designers can run design code on a hardware platform to verify the function, performance and reliability of the chip, and ensure that the design meets the expected target. Prototype verification usually includes bare machine mode and OS mode, which are carried out in different stages of the project: Bare machine mode: directly running on hardware without the intervention of an operating system, suitable for direct control and testing of hardware resources, verifying hardware functions (such as register operations, interrupt control). OS mode: running a real-time operating system (RTOS), simulating a real multi-tasking scenario, verifying task scheduling and resource management.

[0003] Although prototype verification technology is becoming mature, the traditional method still has the following significant defects, which restrict the verification efficiency and reliability:

[0004] 1. Mode switching relies on manual intervention, and the verification process is fragmented;

[0005] 1.1 Complexity of manual switching: When switching between bare machine mode (direct hardware operation) and operating system (such as RTOS) mode, the hardware environment needs to be reconfigured, different firmware needs to be loaded, or the verification script needs to be adjusted, which is tedious and prone to errors.

[0006] 1.2 Low verification efficiency: Frequent manual switching leads to a prolonged verification period, especially when iterating multiple scenarios, the development team needs to repeatedly wait for the environment to reset, and the resource utilization rate is significantly reduced.

[0007] 2. Fault diagnosis relies on post-analysis, and the debugging efficiency is insufficient;

[0008] 2.1 Occasional faults are difficult to track: Random errors (such as timing violations, memory overflow) are difficult to reproduce in traditional verification, and developers need to spend a lot of time manually setting breakpoints or adding debugging code.

[0009] 2.2 Loss of on-site information: When a fault occurs, if the system state (such as register values, task stacks) is not captured in time, key data may be lost, making it difficult to analyze the root cause.

[0010] It can be seen that how to solve the complexity, inefficiency, low resource utilization, and difficulty in tracking occasional faults of manual mode switching is a problem that needs to be considered by those skilled in the art. SUMMARY

[0011] An embodiment of the application provides a chip prototype verification method, device, medium and product, which can solve the problems of complexity, inefficiency, low resource utilization, and difficulty in tracking occasional faults of manual mode switching. The specific scheme is as follows:

[0012] In a first aspect, the application discloses a chip prototype verification method applied to a hardware debugger of a simulation test tool, comprising:

[0013] Analyzing a capability maturity model script to obtain a corresponding parsed script; the capability maturity model script is a script generated by a functional engine of the simulation test tool based on a test case of a chip;

[0014] Sending the parsed script and an execution mode switching condition to a central processor of a field programmable gate array, so that the central processor determines a current execution mode of the prototype verification according to the parsed script and the execution mode switching condition; the execution mode includes a bare machine mode and a running real-time operating system mode;

[0015] Storing test case codes corresponding to different execution modes in the capability maturity model script in different data areas of a preset memory pool, so that the central processor obtains corresponding test case codes from the preset memory pool based on the current execution mode, generates corresponding verification data according to the test case codes and preconfigured peripherals of the chip, and returns the verification data to the hardware debugger of the simulation test tool; the data areas include a bare machine mode data area, a running real-time operating system mode data area, and a shared data area; the shared data area is used to store execution mode switching parameters;

[0016] Generating a corresponding prototype verification report based on the verification data and expected data to complete the chip prototype verification.

[0017] Optionally, before sending the parsed script and the execution mode switching condition to the central processor of the field programmable gate array, the method further comprises:

[0018] Sending a reset instruction to the central processor, so that the central processor performs a reset and initialization operation according to the reset instruction, and returns an initialization completion signal after the initialization is completed;

[0019] Triggering the operation of sending the parsed script and the execution mode switching condition to the central processor of the field programmable gate array according to the initialization completion signal.

[0020] Optionally, the parsed script and the execution mode switching condition are sent to a central processing unit of the field programmable gate array, including:

[0021] The parsed script is sent to the central processing unit of the field programmable gate array through a joint test action group interface or a serial wire debug protocol.

[0022] Optionally, the chip prototype verification method further includes:

[0023] The function engine of the simulation test tool develops a custom function according to actual verification requirements in the prototype verification process; the custom function includes any one or a combination of configuring an execution mode switching condition, loading firmware, reading register data and memory data in real time, and controlling the central processing unit to execute a flow; the execution mode switching condition includes completion of a test phase, an exception, a user instruction, and cyclic switching according to a time slice.

[0024] Optionally, the test case of the chip includes a test case name, an execution mode, parameters of the test case, an initialization action before execution, an operation after execution, and a constraint condition of an expected result.

[0025] Correspondingly, the central processing unit determines a current execution mode of the prototype verification according to the parsed script and the execution mode switching condition, including:

[0026] The central processing unit determines the current execution mode of the prototype verification according to the execution mode set in the parsed script and the execution mode switching condition.

[0027] Optionally, the register data includes any one or a combination of runtime context information of the central processing unit, an interrupt control state, a physical address of an interrupt vector table in a bare machine mode, a peripheral register snapshot, context information of a running task, interrupt configuration of a running real-time operating system mode dependent system, and memory management configuration information; the memory data includes any one or a combination of an interrupt vector table, a runtime stack, a system clock count value when the register snapshot is generated, a checksum, a virtual peripheral state of a driver layer, a running real-time operating system kernel version identifier, and a scheduler activity flag.

[0028] Optionally, the chip prototype verification method further includes:

[0029] After the register data and the memory data are read through the custom function, the register data and the memory data are saved to a state snapshot library, so that the register data and the memory data corresponding to an execution mode after switching are obtained from the state snapshot library when the execution mode is switched.

[0030] Optionally, the bare machine mode data area is configured to store preset interrupt vector tables and test case codes in the logic mode; the real-time operating system mode data area is configured to store test case codes in the real-time operating system mode; and the real-time operating system mode is configured to establish an identity mapping between a virtual address and a physical address.

[0031] Optionally, the central processing unit obtains corresponding test case codes from the preset memory pool based on the current execution mode, including:

[0032] If the current execution mode is the bare machine mode, the test case codes in the logic mode are obtained from the bare machine mode data area of the preset memory pool.

[0033] If the current execution mode is the real-time operating system mode, the memory protection unit is configured to control the central processing unit to prohibit access to the bare machine mode data area, and the test case codes in the real-time operating system mode are obtained from the real-time operating system mode data area of the preset memory pool.

[0034] Optionally, the corresponding verification data is generated according to the test case codes and the peripherals of the chip configured in advance, and the verification data is returned to the hardware debugger of the simulation test tool, including:

[0035] The central processing unit determines a verification target according to the test case codes, so that the peripherals return corresponding verification data based on the verification target, and the verification data is returned to the hardware debugger of the simulation test tool.

[0036] Optionally, before the corresponding verification data is generated according to the test case codes and the peripherals of the chip configured in advance, the method further includes:

[0037] The register parameters of the peripherals are configured, and the peripherals include any one or a combination of several of general-purpose input / output ports, clocks and interrupt controllers.

[0038] Optionally, the chip prototype verification method further includes:

[0039] In the prototype verification process, whether there is a hardware failure is monitored;

[0040] If there is, the failure site data is collected and solidified, so that debugging and failure analysis are performed according to the failure site data.

[0041] In a second aspect, the present application discloses an electronic device, including:

[0042] A memory is configured to store a computer program.

[0043] A processor is configured to execute the computer program to realize the steps of the chip prototype verification method.

[0044] Thirdly, the present invention discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned chip prototype verification method.

[0045] Fourthly, the present invention discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the aforementioned chip prototype verification method.

[0046] In this invention, the hardware debugger of the simulation test tool parses the capability maturity model script to obtain the corresponding parsed script. The capability maturity model script is a script generated by the functional engine of the simulation test tool based on the chip's test cases. The parsed script and execution mode switching conditions are sent to the central processing unit of the field-programmable gate array (FPGA) so that the central processing unit can determine the current execution mode for prototype verification based on the parsed script and the execution mode switching conditions. The execution modes include bare-metal mode and real-time operating system (RTOS) running mode. The test case codes corresponding to different execution modes in the capability maturity model script are stored in different data areas of a preset memory pool, so that the central processing unit can obtain the corresponding test case codes from the preset memory pool based on the current execution mode, generate corresponding verification data based on the test case codes and pre-configured chip peripherals, and return the verification data to the hardware debugger of the simulation test tool. The data areas include a bare-metal mode data area, a ROS running mode data area, and a shared data area. The shared data area is used to store execution mode switching parameters. Based on the verification data and expected data, a corresponding prototype verification report is generated to complete the chip prototype verification.

[0047] Beneficial Effects: This invention achieves automatic switching between bare-metal mode and RTOS mode based on execution mode switching conditions using simulation testing tools, ensuring the flexibility and efficiency of the verification process. By partitioning the physical address space, logical isolation between the OS and bare-metal code areas is achieved, ensuring the independence between the two verification modes and avoiding conflicts and errors during mode switching. It solves the problems of complexity, inefficiency, and low resource utilization associated with manual mode switching in traditional verification methods. Attached Figure Description

[0048] 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.

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

[0050] Figure 2 A schematic diagram of a test case provided in an embodiment of the present invention;

[0051] Figure 3 A schematic diagram illustrating a field provided in an embodiment of the present invention;

[0052] Figure 4 This is a schematic diagram illustrating the content saved in a bare-metal mode core state snapshot, as provided in an embodiment of the present invention.

[0053] Figure 5 This is a schematic diagram illustrating the content saved in a kernel state snapshot of an RTOS mode, as provided in an embodiment of the present invention.

[0054] Figure 6 A schematic diagram of address space partitioning provided in an embodiment of the present invention;

[0055] Figure 7 This is a schematic diagram of a peripheral application provided in an embodiment of the present invention;

[0056] Figure 8 A schematic diagram of a fault monitoring script provided in an embodiment of the present invention;

[0057] Figure 9 A schematic diagram of a specific host-side component provided in an embodiment of the present invention;

[0058] Figure 10 This is a schematic diagram of specific components on an FPGA side provided in an embodiment of the present invention;

[0059] Figure 11 A system architecture diagram provided for an embodiment of the present invention;

[0060] Figure 12 A timing diagram of a chip prototype verification process provided in an embodiment of the present invention;

[0061] Figure 13 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0062] 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.

[0063] 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.

[0064] 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.

[0065] Despite the increasing maturity of prototype verification technology, traditional methods still suffer from the following significant drawbacks, which limit verification efficiency and reliability:

[0066] Mode switching relies on manual intervention, resulting in a fragmented verification process: The complexity of manual switching: Switching between bare-metal mode (direct hardware operation) and operating system (such as RTOS) mode requires reconfiguring the hardware environment, loading different firmware, or adjusting verification scripts, a tedious and error-prone process. Low verification efficiency: Frequent manual switching extends the verification cycle, especially during multi-scenario iterations, where development teams must repeatedly wait for environment resets, significantly reducing resource utilization.

[0067] Fault diagnosis relies on post-incident analysis, resulting in insufficient debugging efficiency: intermittent faults are difficult to trace: random errors (such as timing violations and memory overflows) are difficult to reproduce in traditional verification, requiring developers to spend a lot of time manually setting breakpoints or adding debugging code. Loss of on-site information: when a fault occurs, if the system state (such as register values ​​and task stacks) is not captured in time, critical data may be lost, making root cause analysis difficult.

[0068] To address the aforementioned technical problems, this invention discloses a chip prototype verification method, device, medium, and product, which can solve the problems of complexity, inefficiency, low resource utilization, and difficulty in tracking occasional faults in manual mode switching.

[0069] See Figure 1 As shown, this embodiment of the invention provides a chip prototype verification method, applied to a hardware debugger of a simulation testing tool, comprising:

[0070] Step S11: Parse the capability maturity model script to obtain the corresponding parsed script; the capability maturity model script is a script generated by the functional engine of the simulation test tool based on the chip's test cases.

[0071] In this embodiment of the invention, the verification scheme is divided into two parts: the host-side (PC) and the FPGA-side. In one specific embodiment, the simulation testing tools include, but are not limited to, TRACE32. The host-side (PC) includes: a test case management component, a TRACE32 functional engine, TRACE32 debugger hardware, and a state snapshot library. The test case management component defines YAML (YAML Ain't Markup Language, a human-friendly data serialization standard) format test suites and stores them on the host side. That is, the test cases for the chip are defined through the test case management component. Test case names, modes, and key parameters can be specified, and the content of the test suite is defined by the user. Each test case can index a series of CPU (Central Processing Unit) or hardware operations in the FPGA-side memory. Examples are shown below. Figure 2 As shown, the specific field descriptions in the example are as follows: Figure 3 As shown.

[0072] The TRACE32 function engine includes two functions: 1. Format conversion; 2. Custom function storage. In the format conversion function: the test suite is in YAML format, which is simple to define and user-friendly, but TRACE32 cannot recognize it. Therefore, a conversion from YAML to CMM (Capability Maturity Model) is required. The following conversion rules are defined, with GPIO (General-purpose input / output) and UART (Universal Asynchronous Receiver / Transmitter) tests as examples, as shown in Table 1 below.

[0073] Table 1 Example of Conversion Rules

[0074]

[0075] Therefore, the TRACE32 functional engine converts the chip's test cases into capability maturity model scripts, and then sends them to the hardware debugger of the simulation test tool (TRACE32 hardware debugger). After obtaining the capability maturity model script, the hardware debugger of the simulation test tool parses the script to obtain the corresponding parsed script.

[0076] In addition, the simulation testing tool's functional engine can develop custom functions based on actual verification needs during prototype verification. Custom functions include configuring execution mode switching conditions, loading firmware, real-time reading of register and memory data, and controlling any one or a combination of several of the central processing unit's execution flow. Execution mode switching conditions include test phase completion, exception occurrence, user instructions, and cyclic switching based on time slices.

[0077] Specifically, custom function storage includes loading firmware, real-time reading and writing of registers and memory, and controlling the CPU execution flow (pause, single step, run), etc. If other functions need to be implemented, they can be developed in CMM format. Table 2 below provides examples of the implementation of core functions.

[0078] Table 2. Examples of Core Function Implementation

[0079]

[0080] Step S12: Send the parsed script and execution mode switching conditions to the central processing unit of the field-programmable gate array (FPGA) so that the central processing unit can determine the current execution mode of prototype verification based on the parsed script and execution mode switching conditions; the execution mode includes bare-metal mode and running real-time operating system mode.

[0081] In this embodiment of the invention, TRACE32 is a commercial tool that can establish a connection with an FPGA (Field-Programmable Gate Array) via the JTAG (Joint Test Action Group) interface, thereby enabling the debugging and verification of the FPGA. In this solution, the role of TRACE32 is to execute the CMM script stored in the TRACE32 function engine and transmit the corresponding content to the FPGA via JTAG to achieve FPGA configuration and control. Meanwhile, the FPGA side of this invention includes a CPU (during test case execution, the CPU executes bare-metal or RTOS test cases according to preset instructions) and a unified memory pool. Therefore, in this invention, the hardware debugger of the simulation test tool sends the parsed script to the central processing unit of the FPGA via the Joint Test Action Group interface or a serial line debugging protocol.

[0082] In addition, before sending the parsed script and execution mode switching conditions to the central processing unit of the field-programmable gate array, the hardware debugger of the simulation test tool sends a reset command to the central processing unit so that the central processing unit can perform reset and initialization operations according to the reset command, and return an initialization completion signal after initialization is completed; the operation of sending the parsed script and execution mode switching conditions to the central processing unit of the field-programmable gate array is triggered according to the initialization completion signal.

[0083] After the parsed script and execution mode switching conditions are sent to the central processing unit (CPU) of the field-programmable gate array (FPGA), the CPU can determine the current execution mode for prototype verification based on the execution mode set in the parsed script and the execution mode switching conditions, since the chip's test cases include test case names, execution modes, test case parameters, pre-execution initialization actions, post-execution operations, and expected result constraints. In this invention, during dynamic verification mode switching, the system can trigger mode switching based on preset conditions (such as test phase completion, anomaly detection, user instructions, or time slice scheduling). The switching process involves multiple steps, including pausing the current mode operation, saving the current mode state, loading the target mode state, resetting the CPU, environment initialization and security configuration, resuming the execution flow, and post-switch monitoring and anomaly handling. Through these steps, the system can achieve efficient and reliable switching between bare-metal mode and RTOS mode. Specifically, test phase completion: In prototype verification or performance testing, when the test cases are executed and the results meet expectations, the system automatically switches to the next phase (e.g., switching from bare-metal mode to OS mode). Anomaly Detection: By monitoring system metrics (such as CPU utilization and memory leaks), a switch is triggered when an anomaly threshold is detected (e.g., switching from bare-metal mode to OS mode). User Commands: Administrators or users can actively send commands (e.g., `systemctl switch-mode`) via API (Application Programming Interface) or command line to change system behavior and switch modes. Time-Slice Scheduling: The operating system, based on a time-slice round-robin strategy, forcibly switches process states after a task times out (e.g., switching from bare-metal mode to OS mode).

[0084] In this embodiment of the invention, to enable dynamic switching between bare-metal and RTOS states, the host-side state snapshot library uses the debugging tool TRACE32 to read register and memory contents via the JTAG interface and store them in the state snapshot library, or restores the contents from the state snapshot library. To correctly restore the previous state, the contents to be saved in both bare-metal and RTOS states are defined. Register data includes any one or a combination of several of the following: CPU runtime context information, interrupt control status, physical address of the interrupt vector table in bare-metal mode, peripheral register snapshot, context information of the running task, interrupt configuration dependent on the system running the real-time operating system, and memory management configuration information. Memory data includes any one or a combination of several of the following: interrupt vector table, runtime stack, system clock count value at the time of register snapshot generation, checksum, virtual peripheral status of the driver layer, and kernel version identifier and scheduler activity flag of the running real-time operating system.

[0085] Considering the limited on-chip memory size of FPGA implementations, the state snapshot library is stored on the host side. Taking the ARM-Cortex-M processor as an example, the contents that need to be saved for the bare-metal mode core state snapshot and the RTOS mode core state snapshot are as follows: Figure 4 and Figure 5 As shown.

[0086] Furthermore, the hardware debugger of this invention's simulation testing tool reads register and memory data through a custom function and saves the register and memory data to a state snapshot library. This allows for the retrieval of register and memory data corresponding to the new execution mode from the state snapshot library when switching execution modes. In this way, the state snapshot library ensures the continuity and reliability of the verification process by saving and restoring the states of CPU registers, peripheral configurations, and critical memory areas in real time. During mode switching, the system can quickly save the current state and restore the previous state, avoiding verification interruptions due to state loss.

[0087] Step S13: Store the test case codes corresponding to different execution modes in the capability maturity model script into different data areas of the preset memory pool, so that the central processing unit can obtain the corresponding test case codes from the preset memory pool based on the current execution mode, generate corresponding verification data according to the test case codes and the pre-configured chip peripherals, and return the verification data to the hardware debugger of the simulation test tool; the data area includes the bare-metal mode data area, the real-time operating system mode data area, and the shared data area; the shared data area is used to store execution mode switching parameters.

[0088] In this embodiment of the invention, most prototype verification platforms enable the MMU (Memory Management Unit) during bare-metal or OS boot and configure it with an identical mapping, meaning the virtual address equals the physical address. When the OS uses an identical mapping between virtual and physical addresses, theoretically, the memory layout does not need to isolate the bare-metal and OS code areas. However, in actual verification, logical isolation is still required to ensure the reliability of mode switching and the determinism of state recovery. Furthermore, bare-metal code typically fixes the interrupt vector table at 0x00000000, and if the OS attempts to register its own interrupt handler at the same address after boot, the interrupt service in bare-metal mode will be overwritten. Even with an identical mapping, the OS kernel's loading address must avoid critical initialization code in the bare-metal environment (such as the Bootloader) to prevent the system from failing to enter bare-metal mode upon reset. Therefore, this invention implements memory partitioning. The data area includes a bare-metal mode data area, a real-time operating system mode data area, and a shared data area; the shared data area is used to store execution mode switching parameters. The bare-metal mode data area stores the preset interrupt vector table and test case code in logical mode; the real-time operating system mode data area stores the test case code in real-time operating system mode; and the real-time operating system mode configures the identity mapping between virtual addresses and physical addresses. The specific address space division is as follows: Figure 6 As shown. Furthermore, the test case code corresponding to different execution modes in the capability maturity model script is stored in different data areas of a preset memory pool. If the current execution mode is bare-metal mode, the test case code is stored in the bare-metal mode data area (…). Figure 6 The bare-metal reserved area in the system. If the current execution mode is OS mode, the test case code is stored in the data area of ​​the real-time operating system mode (...). Figure 6 (The OS kernel area in the code). In this way, through identity mapping logical isolation and cross-mode data sharing, this method ensures the stability and data consistency of the verification. Identity mapping logical isolation achieves the independence of the OS and bare-metal code areas by dividing the physical address space, and is protected by the MPU. Cross-mode data sharing ensures data consistency between the two verification modes by passing switching parameters (such as fault codes and log cache) through a fixed shared memory area. This data sharing mechanism makes the verification process more coherent and facilitates the transmission and analysis of verification results in different modes.

[0089] After storing the test case codes corresponding to different execution modes in the capability maturity model script into different data areas of a preset memory pool, the central processing unit (CPU) can retrieve the corresponding test case codes from the preset memory pool based on the current execution mode. If the current execution mode is bare-metal mode, the CPU retrieves the test case codes for logical mode from the bare-metal mode data area of ​​the preset memory pool. If the current execution mode is running a real-time operating system (RTOS) mode, the CPU is prevented from accessing the bare-metal mode data area by setting a memory protection unit, and the CPU retrieves the test case codes for the ROS mode from the ROS mode data area of ​​the preset memory pool.

[0090] In this embodiment of the invention, before generating corresponding verification data based on test case code and pre-configured chip peripherals, the default values ​​of the peripherals are configured. For example, the initial states of peripherals such as GPIO, clock, and interrupt controllers are set to ensure that the peripherals are in a controllable and known initial environment. Configuring the default values ​​of peripherals means setting their register parameters to a predefined initial state through software code before the peripherals (such as GPIO, clock, interrupt controllers, etc.) are used for the first time, to ensure that the peripherals start working from a controllable and known starting point. The core purpose of this process is to eliminate hardware uncertainties and potential conflicts. Therefore, this invention configures the register parameters of peripherals; peripherals include any one or a combination of general purpose input / output ports, clocks, and interrupt controllers. UART, GPIO, Timer, etc., mentioned here are general peripherals included in most chips, and are mentioned in this invention only for verifying general test cases. The typical applications of each peripheral in the verification process are as follows. Figure 7 As shown.

[0091] Afterwards, the CPU determines the verification target based on the test case code, so that the peripheral device returns corresponding verification data based on the verification target, and the verification data is returned to the hardware debugger of the simulation test tool. In this process, the CPU reads the test cases (binary instructions or scripts) from the storage device (such as Flash), parses them, and determines the verification target (such as register configuration, peripheral trigger conditions). In bare-metal mode, instructions are executed directly; in OS mode, peripheral driver interfaces are mapped through system calls (such as mmap()). The CPU configures peripheral registers (such as UART baud rate, GPIO direction) through I / O instructions or bus protocols. If it is necessary to dynamically load the FPGA bitstream file, the CPU completes hardware reconfiguration through DMA or a dedicated interface (such as JTAG). During test case execution, in bare-metal mode: the CPU polls the peripheral status (such as while(!UART_RX_READY)) or responds to interrupts (such as DMA completion interrupts). In OS mode: the test threads are managed by the task scheduler, and the peripheral driver provides callback functions (such as read() / write()). Finally, the CPU compares the data returned by the peripherals (such as the sampled values ​​of the ADC (analog-to-digital converter)) with the expected results and generates a test report (with pass / fail flags). In summary, in bare-metal mode: the CPU loads the test case, configures the UART baud rate, sends data, polls the receive buffer, checks the CRC, and finally returns verification data. In OS mode: the test case is broken down into tasks → written to a file descriptor via `write()` → waits for interrupt callbacks → logs are recorded, and finally, verification data is returned.

[0092] In addition, during the interaction between the CPU and peripherals, the CPU interacts with peripherals through the address bus (addressing), data bus (transfer), and control bus (instructions), while the I / O controller (such as ICH) coordinates access priorities. Peripherals connect to the CPU through I / O interfaces, which are responsible for signal conversion (such as level and protocol adaptation). DMA (Direct Memory Access) acceleration: Large data transfers (such as video streams) are handled directly by the DMA controller, reducing CPU intervention.

[0093] Step S14: Generate a corresponding prototype verification report based on the verification data and expected data to complete the chip prototype verification.

[0094] In this embodiment of the invention, the verification data and expected data are ultimately compared, and a prototype verification report is determined based on the comparison results. The verification data consists of the actual performance parameters and functional data obtained after running test cases on the FPGA prototype platform. The expected data consists of predefined functional indicators and performance parameters based on the design specifications and simulation results. Therefore, the measured data is compared item by item with the expected design values; significant deviations (such as timing violations, missing functions, etc.) are identified and analyzed, and statistical methods are used to quantify the degree of difference. This confirms whether the chip design meets the specifications, ultimately completing the chip prototype verification.

[0095] Furthermore, during the prototype verification process, this invention monitors for hardware faults; if any are found, it collects and archives fault data for debugging and fault analysis. Some fault monitoring scripts include... Figure 8 As shown. In this way, the TRACE32 tool automatically monitors the fault scenario and collects fault field data, accelerating the debugging and root cause localization process.

[0096] Beneficial Effects: This invention achieves automatic switching between bare-metal mode and RTOS mode based on execution mode switching conditions using simulation testing tools, ensuring the flexibility and efficiency of the verification process. By partitioning the physical address space, logical isolation between the OS and bare-metal code areas is achieved, ensuring the independence between the two verification modes and avoiding conflicts and errors during mode switching. It solves the problems of complexity, inefficiency, and low resource utilization associated with manual mode switching in traditional verification methods.

[0097] Based on the previous embodiment, this invention discloses a chip prototype verification method that enables seamless switching between bare-metal and OS modes using the TRACE32 tool. It saves / restores CPU registers, peripheral configurations, and critical memory region states in real time. The physical address space is partitioned, with the OS and bare-metal code areas independent and protected by the MPU. Switching parameters (such as fault codes and log caches) are passed through a fixed shared memory region. The specific chip prototype verification method will be described in detail below.

[0098] In this embodiment of the invention, the verification scheme consists of two parts: a host-side PC and an FPGA-side. The specific components of the host-side are as follows: Figure 9 As shown, the specific components on the FPGA side are as follows: Figure 10 As shown in the diagram. The overall system architecture is as follows. Figure 11As shown, the test case management component generates a YAML script and sends it to the TRACE32 functional engine. The TRACE32 functional engine then sends instructions to the TRACE32 debugger hardware. The TRACE32 debugger hardware sends the capability maturity model script, generated by the simulation test tool's functional engine based on the chip's test cases, to the FPGA chip. The FPGA chip's central processing unit then retrieves the corresponding test case code from a preset memory pool based on the current execution mode. Based on the test case code and pre-configured chip peripherals, it generates corresponding verification data and returns the verification data to the simulation test tool's hardware debugger. The data area includes a bare-metal mode data area, a real-time operating system mode data area, and a shared data area. The shared data area stores execution mode switching parameters. Finally, based on the verification data and expected data, a corresponding prototype verification report is generated to complete the chip prototype verification.

[0099] The specific prototype verification process under different execution modes is as follows: Figure 12 As shown. First, test cases for the chip are defined through the test case management component and sent to the TRACE32 functional engine. The TRACE32 functional engine converts the chip's test cases into capability maturity model scripts (including CPU initialization instructions), and then sends them to the hardware debugger of the simulation test tool (TRACE32 hardware debugger). The hardware debugger sends a reset instruction to the CPU and loads the image into a unified memory pool (bare-metal code is placed in the bare-metal area, and RTOS code is placed in the OS area). After resetting the CPU and loading the image, the CPU initializes, starts executing code from a specified address, and performs preliminary hardware self-tests, memory initialization, and other operations. The TRACE32 hardware debugger loads the CPU startup code and test case code into the unified memory pool. In addition, the TRACE32 hardware debugger configures the default values ​​of peripherals, such as setting the initial states of peripherals such as GPIO, clock, and interrupt controller, to ensure that peripherals are in a controllable and known initial environment. After receiving the initialization completion signal from the CPU, the TRACE32 hardware debugger sends a start test instruction to the CPU. After receiving the instruction, the CPU reads the test case content from the memory pool. When the CPU executes test cases, taking triggering a GPIO interrupt as an example, the CPU executes an instruction to generate an interrupt on the GPIO. Upon receiving the instruction, the GPIO peripheral generates an interrupt, which is then received by the CPU. After receiving the interrupt event, the CPU sends the interrupt information to the TRACE32 hardware debugger. This interrupt information includes the interrupt number and timestamp. The TRACE32 hardware debugger compares the returned information, such as the interrupt number, with the expected information in the test case and sends the comparison result to a reporting system. If it is a performance test case, it sends the performance data to an analysis and reporting system for analysis.

[0100] After the aforementioned bare-metal test cases are executed, the system switches to OS mode to start the OS. The TRACE32 hardware debugger issues a pause command to the CPU. Upon receiving the command, the CPU stops running. After the CPU stops running, the TRACE32 hardware debugger reads the contents of the 0x0000-0xFFFF address range from the memory pool. This address stores the bare-metal state information. Then, it adds verification data to the state information and saves it in the state snapshot library. It loads the OS mode startup code and OS mode scenario test cases into the specified location in the memory pool. It also sends a reset command to the CPU to set the CPU's execution address. After setting, it issues a command to the CPU to continue execution, switching from the paused state to the running state. After the OS mode execution ends, the TRACE32 hardware debugger submits a test end flag to the analysis and reporting system. If an abnormal snapshot exists, the analysis and reporting system retrieves the abnormal snapshot and generates a corresponding test report, ultimately returning to the test case management component to complete the chip prototype verification. It should be noted that during the switching execution mode process, this invention resets some hardware resources (such as the interrupt controller, memory protection, and peripheral ownership transfer) to ensure stable operation of the target mode and avoid state pollution.

[0101] Beneficial Effects: This invention achieves seamless switching between bare-metal mode and RTOS mode using the TRACE32 tool, solving the problems of complexity, inefficiency, low resource utilization, and difficulty in tracking intermittent failures associated with manual mode switching in traditional verification methods. It achieves efficient and reliable mode switching. During batch regression verification of test cases, it can automatically switch between bare-metal mode and RTOS mode based on test case attributes, achieving automated execution. Furthermore, the TRACE32 tool can automatically monitor fault scenarios and save fault conditions, facilitating subsequent problem reproduction and localization.

[0102] Furthermore, embodiments of this application also disclose an electronic device, Figure 13 This is a structural diagram of an electronic device according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. Specifically, the electronic device may include: at least one processor 11, at least one memory 12, a power supply 13, a communication interface 14, an input / output interface 15, and a communication bus 16. The memory 12 stores a computer program, which is loaded and executed by the processor 11 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.

[0103] In this embodiment, the power supply 13 is used to provide operating voltage for various hardware devices on the electronic device; the communication interface 14 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 15 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.

[0104] In addition, the memory 12, 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 121, computer program 122, etc., and the storage method can be temporary storage or permanent storage.

[0105] The operating system 121 is used to manage and control the various hardware devices on the electronic device and the computer program 122, 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 122 may further include a computer program capable of performing other specific tasks.

[0106] 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.

[0107] Furthermore, this application also discloses a computer program product, including a computer program / instructions; wherein, when the computer program / instructions are executed by a processor, they implement the aforementioned disclosed chip prototype verification method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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, Hardware debuggers used in simulation testing tools include: The capability maturity model script is parsed to obtain the corresponding parsed script; the capability maturity model script is a script generated by the functional engine of the simulation test tool based on the chip's test cases; The parsed script and execution mode switching conditions are sent to the central processing unit of the field-programmable gate array (FPGA) so that the FPGA can determine the current execution mode for prototype verification based on the parsed script and the execution mode switching conditions; the execution modes include bare-metal mode and real-time operating system mode. The test case codes corresponding to different execution modes in the capability maturity model script are stored in different data areas of a preset memory pool, so that the central processing unit can obtain the corresponding test case codes from the preset memory pool based on the current execution mode, generate corresponding verification data according to the test case codes and pre-configured chip peripherals, and return the verification data to the hardware debugger of the simulation test tool; the data area includes a bare-metal mode data area, a real-time operating system mode data area, and a shared data area; the shared data area is used to store execution mode switching parameters; Based on the verification data and expected data, a corresponding prototype verification report is generated to complete the chip prototype verification.

2. The chip prototype verification method according to claim 1, characterized in that, Before sending the parsed script and execution mode switching conditions to the central processing unit of the field-programmable gate array, the method further includes: A reset command is sent to the central processing unit so that the central processing unit can perform a reset and initialization operation according to the reset command, and return an initialization completion signal after the initialization is completed; The operation of sending the parsed script and execution mode switching conditions to the central processing unit of the field-programmable gate array is triggered by the initialization completion signal.

3. The chip prototype verification method according to claim 1, characterized in that, Sending the parsed script and execution mode switching conditions to the central processing unit of the field-programmable gate array includes: The parsed script is sent to the central processing unit of the field-programmable gate array via the joint test workgroup interface or serial line debugging protocol.

4. The chip prototype verification method according to claim 1, characterized in that, Also includes: During the prototype verification process, the functional engine of the simulation testing tool develops custom functions based on actual verification requirements. These custom functions include configuring execution mode switching conditions, loading firmware, real-time reading of register and memory data, and controlling the execution flow of the central processing unit, or any combination of these functions. The execution mode switching conditions include completion of the test phase, occurrence of an exception, user instructions, and cyclic switching based on time slices.

5. The chip prototype verification method according to claim 4, characterized in that, The test cases for the chip include the test case name, execution mode, test case parameters, initialization actions before execution, operations after execution, and constraints on the expected results. Accordingly, the central processing unit determines the current execution mode for prototype verification based on the parsed script and the execution mode switching conditions, including: The central processing unit determines the current execution mode for prototype verification based on the execution mode set in the parsed script and the execution mode switching conditions.

6. The chip prototype verification method according to claim 4, characterized in that, The register data includes any one or a combination of several of the following: CPU runtime context information, interrupt control status, physical address of the interrupt vector table in bare-metal mode, peripheral register snapshot, running task context information, interrupt configuration of the system dependent on the running real-time operating system mode, and memory management configuration information; the memory data includes any one or a combination of several of the following: interrupt vector table, runtime stack, system clock count value at the time of register snapshot generation, checksum, virtual peripheral status of the driver layer, and kernel version identifier of the running real-time operating system and scheduler activity flag.

7. The chip prototype verification method according to claim 6, characterized in that, Also includes: After reading register data and memory data through the custom function, the register data and memory data are saved to the state snapshot library so that when switching execution modes, the register data and memory data corresponding to the switched execution mode can be obtained from the state snapshot library.

8. The chip prototype verification method according to claim 1, characterized in that, The bare-metal mode data area is used to store a preset interrupt vector table and test case code in the logical mode; the real-time operating system mode data area is used to store test case code in the real-time operating system mode. Furthermore, the real-time operating system mode configuration establishes an identical mapping between virtual addresses and physical addresses.

9. The chip prototype verification method according to claim 8, characterized in that, The central processing unit retrieves the corresponding test case code from the preset memory pool based on the current execution mode, including: If the current execution mode is bare-metal mode, then the test case code in the logical mode is obtained from the bare-metal mode data area of ​​the preset memory pool; If the current execution mode is the real-time operating system mode, the central processing unit is controlled to prevent access to the bare-metal mode data area by setting the memory protection unit, and the test case code in the real-time operating system mode is obtained from the real-time operating system mode data area of ​​the preset memory pool.

10. The chip prototype verification method according to claim 1, characterized in that, The step of generating corresponding verification data based on the test case code and pre-configured chip peripherals, and returning the verification data to the hardware debugger of the simulation test tool, includes: The central processing unit determines the verification target based on the test case code, so that the peripheral device returns the corresponding verification data based on the verification target, and the verification data is returned to the hardware debugger of the simulation test tool.

11. The chip prototype verification method according to claim 1, characterized in that, Before generating the corresponding verification data based on the test case code and the pre-configured chip peripherals, the process further includes: Configure the register parameters of the peripheral device; the peripheral device includes any one or a combination of general purpose input / output ports, clock, and interrupt controller.

12. The chip prototype verification method according to any one of claims 1 to 11, characterized in that, Also includes: During prototype verification, monitor for hardware failures; If present, the fault site data is collected and solidified for debugging and fault analysis based on the fault site data.

13. 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 12.

14. 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 12.

15. A computer program product comprising a computer program / 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 12.

Images