A CPU firmware interactive verification method and system based on TCL script transparent routing

Abstract

The application discloses a CPU firmware interactive verification method and system based on a TCL script transparent routing, relates to the field of integrated circuit EDA verification tools, and discloses that in existing SoC verification, a TCL script cannot transparently route a command to CPU firmware in simulation, thereby causing a local command and a firmware command to be called in a split mode. The application intercepts a user command through an unknown hook of TCL and writes the user command into a simulation global variable; a SystemVerilog unified distributor inquires a command type mark table; if the command is a local command, the local command is directly executed; if the command is a CPU command, the CPU command is sent to CPU firmware through a shared memory mailbox; CPU firmware analyzes and executes the CPU command, returns a result to the mailbox, writes the result into a TCL global variable through an SV layer, and presents the result to a user. The application enables the user to not distinguish a command execution subject, supports mixed parallel execution, four SV-CPU synchronization modes and timeout protection. The application significantly improves simulation verification efficiency and reusability of a SoC chip containing a CPU core, and reduces a verification environment integration threshold.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit EDA verification tools, specifically to a CPU firmware interactive verification method and system based on TCL script transparent routing. Background Technology

[0002] In SoC chip verification that includes CPU cores (such as RISC-V and ARM), there are two distinct testing requirements. The first is UVM testbench-side verification: Traditional UVM verification involves writing test cases in SystemVerilog to drive bus VIPs (such as AXI / AHB) to send transactions to the DUT. This approach is suitable for verifying bus protocol timing and peripheral functionality, but it cannot simulate real CPU software behavior. The second is CPU firmware-side verification: When a CPU core is embedded in the DUT (running an RTL-level CPU model in simulation), the verification team needs to write C firmware to execute on the CPU, accessing peripheral registers through the CPU's load / store instructions. This approach can verify the real CPU-peripheral interaction path, but firmware testing is completely separate from the UVM testbench. The core problems with existing technologies include: CPU firmware testing and UVM testbench are two independent systems, requiring verification engineers to maintain SV test cases and C firmware test cases separately; commands initiated from TCL interactive scripts cannot be transparently routed to CPU execution, and users must know which commands are executed by SV and which by CPU; the CPU firmware side lacks a general command framework, requiring each project to redevelop command parsing and distribution logic; the shared memory communication protocol between SV and CPU firmware lacks standardization, requiring each project to design its own synchronization mechanism; and there is a lack of ability to simultaneously control the mixed parallel execution of SV commands and CPU commands from TCL scripts.

[0003] To address the aforementioned issues, several patents have proposed partial solutions, but none have achieved transparent routing and unified distribution of CPU firmware commands from TCL scripts. For example, US9460261B2, "IC verification with mailbox," proposes a method for integrated circuit verification via mailboxes, which can automatically generate partial verification code. However, this patent does not address command interception and transparent routing at the TCL script layer, nor does it implement the function of distributing TCL commands to the CPU firmware for execution. Its mailbox mechanism is primarily geared towards inter-module communication, rather than seamless invocation for TCL users. CN113297017A, "SoC verification based on UVM," discloses a method for SoC verification through backdoor access to registers. However, its register access still requires implementation within the UVM environment via a backdoor path, failing to route TCL commands to the CPU firmware for execution via actual load / store instructions, and lacks a unified command distribution framework. CN115841089A, "UVM System-on-a-Chip Verification," proposes a method to enhance verification flexibility by overloading register adapters. However, this method is still limited to the UVM register model framework, does not provide end-to-end command routing capabilities from TCL scripts to CPU firmware, and does not solve the problem of parallel execution of mixed commands. US10664563B2, "Concurrent testbench & SW verification," describes a method for concurrent testing and software verification in a hardware accelerator environment. Its focus is on using hardware accelerators to improve simulation speed, rather than implementing transparent calls from TCL scripts to CPU firmware commands in a standard simulation environment, and it does not involve mechanisms such as TCL unknown hooks or shared memory mailbox protocols.

[0004] In summary, existing technologies lack an interactive verification method that allows verification engineers to uniformly invoke SystemVerilog native commands and CPU firmware commands within TCL scripts, while remaining completely transparent to users. This invention addresses this technological gap by proposing a CPU firmware interactive verification method and system based on transparent routing via TCL scripts. Summary of the Invention

[0005] The technical problem this invention aims to solve is to overcome existing deficiencies and provide a CPU firmware interactive verification method and system based on transparent routing using TCL scripts. This method enables: CPU command routing that is completely seamless for TCL users, where users do not need to know whether a command is executed locally by the SV or within the CPU firmware; automatic routing via the aip_cmd_cpu macro tag; and automatic transmission of commands and reception of results via the shared memory mailbox protocol. Furthermore, it provides standardized command registration, distribution, synchronization, and timeout protection mechanisms, effectively addressing the problems in the background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a CPU firmware interactive verification method based on TCL script transparent routing, characterized by comprising the following steps:

[0007] S1: In the TCL script layer, the non-built-in commands input by the user are intercepted through the unknown command hook of the TCL interpreter, the command string is written into the global variable in the simulation environment, and the simulation execution is resumed;

[0008] S2: In the SystemVerilog simulation layer, the running loop reads the command string from the global variable and calls the unified command dispatcher; the dispatcher queries the pre-stored command type tag table to determine whether the execution body of the command is SystemVerilog native or CPU firmware;

[0009] S3: If it is determined to be a SystemVerilog native command, the corresponding native processing function is called to execute it, and the result is written to the global result variable;

[0010] S4: If the command is determined to be a CPU firmware command, the command string is sent to the CPU firmware running in the simulation via the shared memory mailbox, and a timeout timer is started to wait for its return result.

[0011] S5: The CPU firmware reads and parses commands from the shared memory mailbox, calls the corresponding processing function to execute them, and then returns the result string through the mailbox;

[0012] S6: The SystemVerilog layer detects the returned result through polling or event mechanisms, reads the result string, and writes it into a preset TCL global result variable;

[0013] S7: The TCL script layer reads the result from the global result variable and returns it to the user. If the waiting time in step S4 exceeds the preset time, a timeout error is triggered, and the waiting is terminated.

[0014] In this system, users can read command execution results through the same TCL command without needing to know whether the command is executed in the SystemVerilog layer or the CPU firmware layer. Through the cooperation of the unknown command hook of the TCL interpreter and the unified command dispatcher, users can make indiscriminate calls to SystemVerilog native commands and CPU firmware commands, so that verification personnel do not need to know the actual execution location of the command.

[0015] Furthermore, in step S2, the command type tagging table is constructed through compile-time macro definitions: on the SystemVerilog side, the `aip_cmd_cpu(command_name)` macro is used to tag CPU firmware commands. After expansion, this macro generates an empty command executor subclass and marks the corresponding command name as a CPU command type in the associative array. The SystemVerilog side also provides a batch registration macro `aip_cpu_bridge_builtins`, which expands into multiple `aip_cmd_cpu` macro calls at once. This macro is used to quickly register a predefined set of CPU firmware commands, including memory read / write, endianness conversion, and polling. Through the compile-time macro `aip_cmd_cpu` and the batch registration macro `aip_cpu_bridge_builtins`, the declaration and registration of CPU commands can be completed with a single line of code, significantly reducing the workload of CPU command integration.

[0016] Furthermore, in steps S4 and S5, the shared memory mailbox communication protocol includes a command flag, a command data area, a response flag, and a response data area. Before sending a command, the SystemVerilog side clears the response flag and sets it to 1 after writing the command data. The CPU firmware side immediately clears the command flag when it detects that it is 1, and after execution, writes the result to the response data area and sets the response flag to 1. Through the handshake protocol between the command flag and response flag in the shared memory mailbox, the atomicity and conflict-free nature of command / response transmission between SystemVerilog and CPU firmware can be guaranteed, avoiding data races.

[0017] Furthermore, the waiting mechanism in step S4 supports at least one of the following four synchronization modes: pure polling mode, interrupt mode, event mode, and a hybrid interrupt and event mode. By providing four synchronization modes—pure polling, interrupt, event, and interrupt + event—the optimal synchronization strategy can be flexibly selected according to the verification scenario, achieving a balance between performance and resource overhead.

[0018] Furthermore, the event mode is implemented by defining monitoring logic within the module scope of SystemVerilog. This logic monitors the memory address corresponding to the response flag in the mailbox and triggers an event when the address value changes, achieving zero-latency waiting on the SystemVerilog side. By monitoring the memory address of the response flag and triggering the SV event in the event mode, zero-latency waiting for CPU response on the SV side can be achieved, eliminating the simulation time overhead caused by polling.

[0019] Furthermore, in step S5, the CPU firmware runs a lightweight command framework that does not rely on the standard C library. This framework provides command registration API, parameter parsing API, and result formatting and return API. The parameter parsing API includes cmd_get_int, cmd_get_long, and cmd_get_str for parsing memory addresses, register addresses, data values, and lengths from command strings. The result formatting and return API is cmd_return. Through this lightweight command framework that does not rely on the standard C library and its parameter parsing and result return APIs, command processing logic can be run directly in the bare-metal CPU environment without porting the operating system or standard library.

[0020] Furthermore, in step S1, hybrid parallel execution of TCL scripts is supported: users can simultaneously arrange SystemVerilog local commands and CPU firmware commands in the fork / join concurrent structure; the unified command dispatcher routes each command independently, enabling them to execute in parallel during simulation time. Through the fork / join concurrent structure of TCL scripts and the independent routing capability of the unified dispatcher, SV local commands and CPU firmware commands can be executed in parallel during simulation time, effectively verifying multi-master device concurrent access scenarios.

[0021] An interactive CPU firmware verification system based on TCL script transparent routing includes a TCL command interception module for intercepting user commands and forwarding them to the simulation environment; a SystemVerilog unified command distribution module for receiving commands and routing them to the local execution unit or CPU communication bridge unit according to a command type tagging table; a shared memory mailbox module for bidirectionally transmitting command and response strings between the SystemVerilog simulation environment and the CPU firmware, with its storage space simultaneously mapped to the backdoor access interface on the SystemVerilog side and the physical address space on the CPU firmware side; a CPU firmware command framework module for parsing, executing commands, and returning results; and a synchronization and timeout control module for implementing multiple synchronization modes between the SystemVerilog side and the CPU firmware side and providing a timeout protection mechanism for command execution. Through system-level integration of the TCL command interception module, SV unified command distribution module, shared memory mailbox module, CPU firmware command framework module, and synchronization and timeout control module, a complete transparent routing verification system can be constructed, covering the entire end-to-end command execution link.

[0022] Furthermore, the SystemVerilog unified command dispatch module includes a command type tag table and a command executor. The command executor queries the tag table and then calls a local processing function or sends the command to the shared memory mailbox module through the CPU communication bridge unit. Through the query-forward mechanism of the command type tag table and the command executor, the command dispatch logic and the specific execution logic can be decoupled, and the dispatcher code does not need to be modified when adding a new CPU command.

[0023] Furthermore, the shared memory mailbox module includes a command flag register written by the SystemVerilog side, a response flag register written by the CPU firmware side, and data buffers for storing command and response strings respectively. Through the shared memory layout of the command flag register, response flag register, and command / response data buffer, a compact and reliable cross-domain communication mechanism can be provided, while being compatible with both SV backdoor access and CPU direct addressing modes.

[0024] Compared with the prior art, the beneficial effects of the present invention are as follows: This CPU firmware interactive verification method and system based on TCL script transparent routing has the following advantages:

[0025] 1. This invention achieves seamless invocation of SystemVerilog native commands and CPU firmware commands through the cooperation of the TCL interpreter's unknown command hook and a unified command dispatcher. When users enter commands in the TCL script, they do not need to distinguish whether the command is executed locally on the SV side or in the CPU firmware. All commands use a unified syntax format and result reading method, greatly reducing the learning cost and mental burden for verification personnel. Simultaneously, this invention provides the compile-time macro `aip_cmd_cpu` and the batch registration macro `aip_cpu_bridge_builtins`. On the SystemVerilog side, only one line of code is needed to complete the marking or batch registration of CPU commands; on the CPU firmware side, the registration of command processing functions can be completed with a single line of code using `cmd_register`, minimizing the integration workload.

[0026] 2. This invention defines a compact shared memory mailbox communication protocol, comprising a command flag, a command data area, a response flag, and a response data area, with a total size of approximately 1KB. On the SystemVerilog side, the response flag is cleared before sending a command, and the command flag is set to 1 after writing command data. On the CPU firmware side, the command flag is cleared immediately upon detection, and the response flag is set after execution. This handshake protocol ensures the atomicity and conflict-free nature of command / response transmission, avoiding data races. The mailbox storage space is simultaneously mapped to the SV backdoor access interface and the CPU physical address space, compatible with both access modes.

[0027] 3. Regarding synchronization mechanisms, this invention provides four SV-CPU synchronization modes: pure polling, interrupt, event, and a hybrid interrupt + event mode. The pure polling mode is the simplest to implement and suitable for low-frequency command scenarios; the interrupt mode reduces power consumption through the CPU's WFI instruction; the event mode utilizes SystemVerilog's `@(event)` to achieve zero-latency waiting, improving efficiency by approximately 10 times in intensive command scenarios; the hybrid interrupt + event mode optimizes response speed on both sides simultaneously. Verification engineers can flexibly choose the optimal strategy based on specific scenarios. Furthermore, this invention sets a configurable timeout timer for each CPU command on the SystemVerilog side, using the `fork / join_any` structure to automatically terminate and report an error after a timeout, effectively avoiding the problem of infinite simulation hangs caused by unresponsive CPU firmware or command deadlock, thus improving the robustness of the verification process.

[0028] 4. This invention also provides a lightweight CPU firmware command framework implemented purely in C, which does not depend on any standard C library and is suitable for bare-metal RISC-V, ARM and other embedded environments. The framework includes core APIs such as command registration, parameter parsing (`cmd_get_int`, `cmd_get_long`, `cmd_get_str`), and result formatting return (`cmd_return`), allowing users to quickly extend custom commands; the built-in command set covers commonly used memory read / write, polling, data movement and other operations, and can be directly used in most verification scenarios.

[0029] 5. Regarding parallel execution capabilities, this invention allows SystemVerilog native commands and CPU firmware commands to be included simultaneously within the `fork / join` concurrent structure of TCL scripts. A unified command dispatcher independently determines the execution subject and routes each sub-command, enabling true parallel execution of bus transactions on the SV side and CPU firmware load / store operations, DMA transfers, etc., at the same simulation time point. This is of significant value for verifying complex scenarios such as bus arbitration logic, multi-master conflict handling, and deadlock detection. Simultaneously, this invention supports asynchronous execution mode for CPU commands. After sending a command, the TCL script can continue executing subsequent statements (such as advancing simulation time) without waiting for a CPU response, and then obtain the results through synchronous commands at an appropriate time. This is suitable for verifying long-term background operations, providing verification personnel with more refined timing control capabilities.

[0030] 6. Based on the method and system of this invention, verification engineers can directly configure and read peripheral registers such as UART, SPI, I2C, GPIO, Timer, and DMA within TCL scripts, and perform memory data integrity tests (including XOR stepping mode, address-dependent mode, etc.), endianness verification, interrupt response verification, and CPU algorithm function verification. All tests can be implemented flexibly through TCL scripts without recompiling the C firmware, significantly shortening the verification iteration cycle. Furthermore, this invention adopts a modular design; the virtual classes on the SystemVerilog side allow users to customize backdoor access implementations, adaptable to different emulators and memory models; the CPU firmware framework relies only on standard C syntax and is portable to any CPU architecture that supports bare-metal C compilation. Adding custom commands requires no modification to the dispatcher core code, exhibiting excellent scalability and portability.

[0031] 7. The invention effectively solves the problems in existing SoC verification, such as the inability of TCL scripts to transparently route to CPU firmware, the disconnect between SV and CPU environment, the lack of command framework, and the non-standard synchronization protocol. It significantly improves the simulation verification efficiency and reusability of chips containing CPU cores, and has outstanding substantive features and significant progress. Attached Figure Description

[0032] Figure 1 This is a flowchart of the entire TCL -> SV -> CPU end-to-end process of the present invention (steps on the left, code comparison on the right).

[0033] Figure 2 This is the command routing decision graph (SV local vs CPU firmware) of the present invention.

[0034] Figure 3 This is a schematic diagram of the aip_cmd_cpu macro expansion and CPU routing marking principle of the present invention;

[0035] Figure 4 This is a schematic diagram of the shared memory mailbox layout and communication protocol of the present invention;

[0036] Figure 5 This is a comparison diagram of the four synchronization modes of the present invention. Detailed Implementation

[0037] 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 skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] Please see Figure 1-5This invention provides a technical solution: a CPU firmware interactive verification method based on TCL script transparent routing, characterized by comprising the following steps:

[0039] S1: At the TCL script layer, non-built-in commands input by the user are intercepted through the unknown command hook of the TCL interpreter. The command string is written into the global variable in the simulation environment and the simulation execution is resumed. It supports the hybrid parallel execution of TCL scripts: users can arrange SystemVerilog local commands and CPU firmware commands simultaneously in the fork / join concurrent structure; the unified command dispatcher routes each command independently, so that they are executed in parallel during simulation time. Through the fork / join concurrent structure of TCL scripts and the independent routing capability of the unified dispatcher, SV local commands and CPU firmware commands can be executed in parallel during simulation time, effectively verifying multi-master device concurrent access scenarios.

[0040] S2: In the SystemVerilog simulation layer, the runtime loop reads command strings from global variables and calls the unified command dispatcher. The dispatcher queries the pre-stored command type tag table to determine whether the execution body of the command is SystemVerilog native or CPU firmware. The command type tag table is constructed through compile-time macro definitions: On the SystemVerilog side, the `aip_cmd_cpu(command_name)` macro is used to tag CPU firmware commands. After expansion, this macro generates an empty command executor subclass and marks the corresponding command name as the CPU command type in the associative array. The SystemVerilog side also provides a batch registration macro `aip_cpu_bridge_builtins`, which expands into multiple `aip_cmd_cpu` macro calls at once. This is used to quickly register predefined CPU firmware command sets, including memory read / write, endianness conversion, and polling. Through the compile-time macro `aip_cmd_cpu` and the batch registration macro `aip_cpu_bridge_builtins`, the declaration and registration of CPU commands can be completed with a single line of code, greatly reducing the workload of CPU command integration.

[0041] S3: If it is determined to be a SystemVerilog native command, the corresponding native processing function is called to execute it, and the result is written to the global result variable;

[0042] S4: If the command is identified as a CPU firmware command, the command string is sent to the CPU firmware running in the simulation via the shared memory mailbox, and a timeout timer is started to wait for its return result. The waiting mechanism supports at least one of the following four synchronization modes: pure polling mode, interrupt mode, event mode, and a hybrid interrupt and event mode. By providing four synchronization modes, pure polling, interrupt, event, and interrupt + event, the optimal synchronization strategy can be flexibly selected according to the verification scenario, achieving a balance between performance and resource overhead. The event mode is implemented by defining monitoring logic within the module scope of SystemVerilog. This logic monitors the memory address corresponding to the response flag in the mailbox. When the address value changes, an event is triggered, achieving zero-latency waiting on the SystemVerilog side. By monitoring the memory address of the response flag in the event mode and triggering the SV event, zero-latency waiting for the CPU response on the SV side can be achieved, eliminating the simulation time overhead caused by polling.

[0043] S5: The CPU firmware reads and parses commands from the shared memory mailbox, calls the corresponding processing function to execute them, and then returns the result string through the mailbox. The shared memory mailbox communication protocol includes command flags, command data area, response flags, and response data area. Before sending a command, the SystemVerilog side clears the response flag and sets it to 1 after writing the command data. The CPU firmware side immediately clears the command flag when it detects that it is 1, and after execution, writes the result to the response data area and sets the response flag to 1. Through the handshake protocol of command and response flags in the shared memory mailbox, the atomicity of command / response transmission between SystemVerilog and CPU firmware can be guaranteed. To ensure data race prevention and conflict avoidance, the CPU firmware runs a lightweight command framework that does not rely on the standard C library. This framework provides command registration API, parameter parsing API, and result formatting and return API. The parameter parsing API includes cmd_get_int, cmd_get_long, and cmd_get_str for parsing memory addresses, register addresses, data values, and lengths from command strings. The result formatting and return API is cmd_return. Through this lightweight command framework and its parameter parsing and result return APIs, which do not rely on the standard C library, command processing logic can be run directly in the bare-metal CPU environment without porting the operating system or standard library.

[0044] S6: The SystemVerilog layer detects the returned result through polling or event mechanisms, reads the result string, and writes it into a preset TCL global result variable;

[0045] S7: The TCL script layer reads the result from the global result variable and returns it to the user. If the waiting time in step S4 exceeds the preset time, a timeout error is triggered, and the waiting is terminated.

[0046] In this system, users can read command execution results through the same TCL command without needing to know whether the command is executed in the SystemVerilog layer or the CPU firmware layer. Through the cooperation of the unknown command hook of the TCL interpreter and the unified command dispatcher, users can make indiscriminate calls to SystemVerilog native commands and CPU firmware commands, so that verification personnel do not need to know the actual execution location of the command.

[0047] An interactive CPU firmware verification system based on TCL script transparent routing includes a TCL command interception module for intercepting user commands and forwarding them to the simulation environment; a SystemVerilog unified command distribution module for receiving commands and routing them to the local execution unit or CPU communication bridge unit according to the command type tagging table; a shared memory mailbox module for bidirectionally transmitting command and response strings between the SystemVerilog simulation environment and the CPU firmware, with its storage space simultaneously mapped to the backdoor access interface on the SystemVerilog side and the physical address space on the CPU firmware side; a CPU firmware command framework module for parsing, executing commands, and returning results; and a synchronization and timeout control module for implementing multiple synchronization modes between the SystemVerilog side and the CPU firmware side and providing a timeout protection mechanism for command execution. Through system-level integration of the TCL command interception module, SV unified command distribution module, shared memory mailbox module, CPU firmware command framework module, and synchronization and timeout control module, a complete transparent routing verification system can be built, covering the entire end-to-end command execution link.

[0048] The SystemVerilog unified command dispatch module includes a command type tag table and a command executor. The command executor queries the tag table and then calls a local processing function or sends the command to the shared memory mailbox module through the CPU communication bridge unit. Through the query-forward mechanism of the command type tag table and the command executor, the command dispatch logic and the specific execution logic can be decoupled. When adding a new CPU command, there is no need to modify the dispatcher code.

[0049] The shared memory mailbox module includes a command flag register written by the SystemVerilog side, a response flag register written by the CPU firmware side, and data buffers for storing command and response strings respectively. Through the shared memory layout of the command flag register, response flag register, and command / response data buffer, it can provide a compact and reliable cross-domain communication mechanism, while being compatible with both SV backdoor access and CPU direct addressing modes.

[0050] The present invention provides the following embodiments:

[0051] Example 1: CPU register read / write operations, enabling seamless user access.

[0052] This embodiment demonstrates how a verification user initiates a CPU register read command via a TCL script, and how the system transparently routes it to the CPU firmware for execution and returns the result, without the user needing to be aware of the command's execution location throughout the process.

[0053] The operation process is as follows:

[0054] First, import the command library of this invention into the TCL script. The user enters the command `cpu_read32 addr=0x40000000`. Since this command is not a built-in TCL command, the `unknown` hook of the TCL interpreter automatically intercepts the command string, writes it into the global variable `__tcl_cmd_ascii[]` in the simulation environment, and resumes the simulation.

[0055] Subsequently, the SystemVerilog-side runtime loop detects the new command and invokes the unified command dispatcher. The dispatcher queries the command type flag table `__aip_cmd_is_cpu["cpu_read32"]`, which is set to 1 by the compile-time macro ``aip_cmd_cpu(cpu_read32)`, thus determining it to be a CPU firmware command.

[0056] Next, the system sends the command to the CPU firmware via a shared memory mailbox. After parsing the command, the CPU firmware executes the actual `load` instruction to read data from physical address `0x40000000` and writes the result back to the mailbox via the `cmd_return` API. Upon detecting the response, the SystemVerilog side stores the result in a TCL global result variable.

[0057] Finally, users can obtain the result "data=0x12345678" using the unified `aip_read_result` command. Throughout the process, the calling method and result reading method of the `cpu_read32` command are completely consistent with the local commands executed on the SystemVerilog side (such as `write_reg`), achieving transparency to the user.

[0058] Example 2: Parallel execution of SystemVerilog native commands and CPU firmware commands

[0059] This embodiment demonstrates how to utilize the concurrency mechanism of TCL scripts in complex verification scenarios to simultaneously execute bus commands on the SystemVerilog side and processing commands on the CPU firmware side, in order to verify the system's multi-master device concurrent access capability.

[0060] In TCL scripts, the `fork / join` structure is used to execute the following commands concurrently:

[0061] ```tcl

[0062] fork

[0063] axi_write count=1000; # SystemVerilog local command: Send write transactions via AXI VIP

[0064] cpu_read32 addr=0x40000000; # CPU firmware command: CPU performs read operation

[0065] dma_test src=0x1000 dst=0x2000 len=4096 ;# CPU firmware command: Configure and start DMA for the CPU

[0066] Join

[0067] The unified command dispatcher in this invention independently performs type determination and routing for each command in the `fork` block. `axi_write` is identified as a SystemVerilog native command and directly calls the native processing function to send the transaction via the bus VIP. `cpu_read32` and `dma_test` are identified as CPU commands and are both sent to the CPU firmware for parallel execution via the shared memory mailbox.

[0068] Thanks to the independent routing and synchronization mechanism of this invention, these commands can be executed concurrently at the same simulation point in time, thereby effectively verifying key performance and functionalities such as bus arbitration logic and conflict handling when the CPU and DMA access memory simultaneously. `join` will only return after all commands have been executed, and "All done" will be output in the TCL script.

[0069] Example 3: Large-scale register configuration using TCL to execute CPU commands in batches.

[0070] This embodiment demonstrates how to use the present invention to configure a large number of CPU registers in batches through the loop control structure of TCL scripts, showcasing the efficiency and flexibility of this method in scenarios such as system initialization.

[0071] During the chip's power-on initialization phase, 256 consecutive register addresses need to be written with different initial values. The user writes the following TCL script:

[0072] ```tcl

[0073] for {set i 0} {$i < 256} {incr i} {

[0074] set addr [format "0x%X" [expr {0x40000000 + $i * 4}]]

[0075] set data [format "0x%X" $i]

[0076] cpu_write32 addr=$addr data=$data

[0077] }

[0078] In each loop, the TCL script dynamically constructs the target address `addr` and the data to be written `data`, and then calls the `cpu_write32` command. This CPU firmware command is completely sent to the CPU firmware side for execution through the transparent routing mechanism of this invention. The CPU firmware parses the address and data parameters in the command and completes the write to the register through the actual CPU `store` instruction.

[0079] This embodiment demonstrates that verification personnel can leverage the powerful text processing and control logic of TCL scripts to flexibly drive the CPU firmware to perform large-scale, parameterized hardware operations without recompiling the C firmware program for each test point, thus greatly improving verification efficiency.

[0080] Example 4: Peripheral Interaction Verification with Interrupt Response

[0081] This embodiment demonstrates how the present invention verifies a complete CPU-peripheral interaction link, including interrupt handling, particularly how the CPU firmware's interrupt service routine (ISR) responds when a peripheral device generates an interrupt, and how the TCL side obtains the processing result.

[0082] Assume the SoC to be verified contains a Timer peripheral. The verification steps are as follows:

[0083] First, configure the Timer and enable interrupts in the TCL script:

[0084] ```tcl

[0085] cpu_write32 addr=0x40030000 data=1000 ;# Set Timer reload value

[0086] cpu_write32 addr=0x40030004 data=0x03 ;# Enable Timer and enable interrupts

[0087] Then, the TCL command `run 20us` is used to advance the simulation time, causing the Timer to generate an overflow interrupt. At this point, the interrupt service routines (ISRs) pre-registered in the CPU firmware are triggered by the hardware interrupt signal. The ISRs perform operations such as reading the interrupt status, clearing interrupts, and accumulating the interrupt count.

[0088] Finally, the processing results are queried using a custom command in the TCL script:

[0089] ```tcl

[0090] cpu_read32 addr=0x40030008 ;# Read the Timer status register

[0091] puts “Timer status: [aip_read_result]”

[0092] get_irq_count; # Custom CPU command to read the interrupt count from the ISR.

[0093] puts “IRQ count: [aip_read_result]”

[0094] This embodiment fully demonstrates the ability of the present invention to support interrupt-driven interaction. From Timer configuration, interrupt generation, CPU response and processing, to the final result being returned to the TCL script, the entire process is seamlessly connected, and all operations on the CPU firmware are transparent to the TCL script.

[0095] Example 5: Verification of Algorithm Functionality Based on Custom CPU Firmware Commands

[0096] This embodiment demonstrates how to utilize the scalability of the present invention to register custom computational commands in the CPU firmware and call and scan parameters through a TCL script, thereby using a simulated CPU model to verify software algorithms or hardware accelerators.

[0097] First, a CRC32 calculation function is developed on the CPU firmware side, and then registered as a command using the framework of this invention:

[0098] ```c

[0099] void do_crc32(const char *args) {

[0100] int addr = cmd_get_int(args, “addr”, 0);

[0101] int len ​​= cmd_get_int(args, “len”, 0);

[0102] unsigned int crc = calculate_crc32((void*)addr, len);

[0103] cmd_return(“crc=0x%08x”, crc);

[0104] }

[0105] cmd_register(“crc32”, do_crc32);

[0106] On the TCL script side, this custom command can be invoked just like a built-in command:

[0107] ```tcl

[0108] cpu_memset addr=0x20000000 len=4096 val=0xABCDABCD ;# Prepare test data

[0109] crc32 addr=0x20000000 len=4096 ;# Call the CPU to calculate CRC

[0110] puts “CRC32: [aip_read_result]”

[0111] ;# Perform parameter scan

[0112] for {set len ​​64} {$len <= 4096} {set len ​​[expr {$len * 2}]} {

[0113] crc32 addr=0x20000000 len=$len

[0114] puts “CRC32(len=$len): [aip_read_result]”

[0115] }

[0116] This embodiment demonstrates that the CPU firmware command framework provided by this invention has strong extensibility. Verification personnel can easily encapsulate any computationally intensive or hardware-state-dependent functions into CPU commands, and then flexibly combine and call them in TCL scripts to implement complex verification logic without repeatedly compiling the entire firmware or writing separate C test programs.

[0117] Example 6: Complete Verification of DMA Data Transfer Function

[0118] This embodiment demonstrates how to use the present invention to perform end-to-end verification of the data transfer function of the DMA controller, including the entire process of source data preparation, DMA configuration startup, transfer completion waiting, and result data verification.

[0119] The verification steps are as follows:

[0120] First, in the TCL script, test data patterns are written to the SRAM source address region via CPU firmware commands:

[0121] ```tcl

[0122] for {set i 0} {$i < 64} {incr i} {

[0123] set addr [format "0x%X" [expr {0x20000000 + $i * 4}]]

[0124] set data [format "0x%X" [expr {$i * 0x11111111}]]

[0125] cpu_write32 addr=$addr data=$data

[0126] }

[0127] Secondly, configure the source address, destination address, and transfer length of the DMA controller through the CPU firmware and start the transfer:

[0128] ```tcl

[0129] cpu_write32 addr=0x40020000 data=0x20000000 ;# DMA_SRC

[0130] cpu_write32 addr=0x40020004 data=0x30000000 ;# DMA_DST

[0131] cpu_write32 addr=0x40020008 data=256;# DMA_LEN

[0132] cpu_write32 addr=0x4002000C data=0x01;# DMA_CTRL: start

[0133] Then, the polling command of this invention is used to wait for the DMA transfer to complete:

[0134] ```tcl

[0135] cpu_poll32 addr=0x40020010 mask=0x1 expect=0x1 timeout=10000

[0136] puts “DMA status: [aip_read_result]”

[0137] Finally, the target region data is read for verification, and SystemVerilog backdoor access commands are used for batch and rapid verification:

[0138] ```tcl

[0139] for {set i 0} {$i < 4} {incr i} {

[0140] set addr [format "0x%X" [expr {0x30000000 + $i * 4}]]

[0141] cpu_read32 addr=$addr

[0142] puts “DST[$addr] = [aip_read_result]”

[0143] }

[0144] cpu_memdump addr=0x30000000 len=64 ;# Batch reading of SV backdoor, high verification efficiency.

[0145] This embodiment demonstrates that the present invention, through a unified TCL command interface, can easily orchestrate complex DMA test processes, combining real access of CPU firmware to registers with rapid verification of backdoors on the SystemVerilog side, thus ensuring the authenticity of the verification while improving verification efficiency.

[0146] Example 7: UART Register Configuration and Status Check

[0147] This embodiment uses a UART controller as an example to demonstrate how to verify the CPU's read / write access path to peripheral registers and how to check the status of peripherals using this invention.

[0148] The TCL script is as follows:

[0149] ```tcl

[0150] # Configure UART control register and baud rate register

[0151] cpu_write32 addr=0x40010000 data=0x03 ;# UART_CTRL: Enable TX and RX

[0152] cpu_write32 addr=0x40010004 data=0x1A ;# UART_BAUD: Sets the baud rate division factor

[0153] # Read back to verify if the configuration was written successfully

[0154] cpu_read32 addr=0x40010000

[0155] puts “UART_CTRL: [aip_read_result]” ; # Expected output: data=0x00000003

[0156] cpu_read32 addr=0x40010004

[0157] puts “UART_BAUD: [aip_read_result]” ; # Expected output: data=0x0000001A

[0158] # Check if the UART status register (e.g., TX FIFO) is empty.

[0159] cpu_read32 addr=0x40010008

[0160] puts “UART_STATUS: [aip_read_result]”

[0161] In this embodiment, all `cpu_write32` and `cpu_read32` commands are executed on the CPU firmware side through the transparent routing mechanism of this invention, realistically simulating the hardware path of software drivers accessing peripheral registers. Verification personnel do not need to write any C language test code to complete the verification of peripheral register read / write functionality at the TCL script layer, and can easily cross-compare the results with the SystemVerilog bus monitor.

[0162] Example 8: Bus Arbitration Stress Test

[0163] This embodiment demonstrates how to utilize the hybrid parallel execution capability of the present invention to simultaneously drive the UVM bus sequence on the SystemVerilog side and the bus access commands on the CPU firmware side within the same simulation time, in order to verify the arbitration logic and deadlock avoidance mechanism of the SoC bus interconnect.

[0164] The TCL script uses a `fork / join` structure to concurrently execute the following workload:

[0165] ```tcl

[0166] fork

[0167] axi_write count=1000; # SV side: UVM AXI Master continuous write operations

[0168] axi_read count=1000; # SV side: UVM AXI Master continuous read operation

[0169] dma_test src=0x20000000 dst=0x30000000 len=65536 ;# CPU firmware: DMA bulk transfer

[0170] cpu_reg_scan base=0x40000000 count=64 ;# CPU firmware: scan peripheral registers

[0171] join

[0172] puts “Stress test completed — no deadlock, no data corruption”

[0173] During the aforementioned concurrent execution, the SystemVerilog-side AXI VIP and CPU firmware (via their bus interface) simultaneously initiate a large number of transactions to the system bus. The unified command dispatcher and synchronization mechanism of this invention ensure that these commands from different hosts can truly proceed in parallel during simulation. By observing the simulation logs and the final system state, verification personnel can confirm whether the bus arbiter can fairly serve all hosts, and whether there are data consistency issues or deadlocks. This embodiment fully demonstrates the powerful advantages of this invention in multi-host concurrent verification scenarios.

[0174] Example 9: Memory Data Integrity and Endianness Conversion Verification

[0175] This embodiment demonstrates how to utilize the loop control and parameter calculation capabilities of TCL scripts, in conjunction with the CPU firmware commands of this invention, to perform comprehensive data integrity testing and endianness conversion verification on SRAM or DDR memory regions.

[0176] The code for the memory data integrity test is as follows:

[0177] ```tcl

[0178] set fail 0

[0179] # Write phase: Write 256 32-bit data bytes using XOR mode.

[0180] for {set i 0} {$i < 256} {incr i} {

[0181] set addr [format "0x%X" [expr {0x20000000 + $i * 4}]]

[0182] set pattern [format "0x%X" [expr {$i ^ 0xA5A5A5A5}]]

[0183] cpu_write32 addr=$addr data=$pattern

[0184] }

[0185] # Reread verification phase

[0186] for {set i 0} {$i < 256} {incr i} {

[0187] set addr [format "0x%X" [expr {0x20000000 + $i * 4}]]

[0188] cpu_read32 addr=$addr

[0189] set result [aip_read_result]

[0190] set expect [format "data=0x%08x" [expr {$i ^ 0xA5A5A5A5}]]

[0191] if {$result ne $expect} {

[0192] puts “FAIL: $addr got=$result expect=$expect”

[0193] incr fail

[0194] }

[0195] }

[0196] puts “Memory test: [expr {256-$fail}] / 256 passed”

[0197] The endianness verification code is as follows:

[0198] ```tcl

[0199] # Writes a 32-bit data, using byte-by-byte swapping.

[0200] cpu_write32_swap addr=0x20001000 data=0x01020304

[0201] ;# Read back normally, observe the byte order

[0202] cpu_read32 addr=0x20001000

[0203] The output "Swap test: wrote 0x01020304, raw read=[aip_read_result]" is displayed. The expected output is data=0x04030201.

[0204] This embodiment demonstrates that the present invention allows verifiers to flexibly construct complex test modes (such as XOR step mode, all 0 / all 1, address-dependent mode, etc.) in TCL scripts and use CPU firmware commands to complete real memory access, thereby efficiently detecting the data retention capability of memory and the correctness of byte addressing.

[0205] Example 10: CPU Asynchronous Commands and Non-blocking Operations

[0206] This embodiment demonstrates the asynchronous command mode of the present invention, which allows the TCL script to continue executing subsequent TCL statements (such as advancing simulation time) after sending a CPU command without waiting for it to complete. This mode is suitable for verification scenarios that require long-running background operations (such as large-block DMA transfers).

[0207] TCL script example:

[0208] ```tcl

[0209] # Initiate DMA transfer in asynchronous mode (async=1 means do not wait for CPU response)

[0210] dma_test src=0x1000 dst=0x2000 len=65536 async=1

[0211] # Advance the simulation time by 10 microseconds while the DMA transfer is in progress.

[0212] run 10us

[0213] ;# At this point, DMA should be complete; check the data at the target address.

[0214] cpu_read32 addr=0x40004000

[0215] puts “DMA result check: [aip_read_result]”

[0216] In this embodiment, the `dma_test` command has the `async=1` parameter. After sending the command to the shared memory mailbox, the SystemVerilog side of this invention does not enter a loop waiting for a CPU response, but immediately returns to the TCL script layer. The `run 10us` command is executed, advancing the simulation time, while the CPU firmware processes the DMA command in parallel in the background. After the asynchronous wait time ends, the user sends a synchronous `cpu_read32` command to check the DMA execution result. This hybrid synchronous and asynchronous calling mode provides verification personnel with greater timing control flexibility, especially suitable for verifying background hardware operations that need to be coordinated with simulation time or other events.

[0217] The above embodiments fully demonstrate the wide range of application scenarios and significant technical effects of the CPU firmware interactive verification method and system based on TCL script transparent routing proposed in this invention in SoC chip verification.

[0218] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A CPU firmware interactive verification method based on TCL script transparent routing, characterized in that, Includes the following steps: S1: In the TCL script layer, the non-built-in commands input by the user are intercepted through the unknown command hook of the TCL interpreter, the command string is written into the global variable in the simulation environment, and the simulation execution is resumed; S2: In the SystemVerilog simulation layer, the running loop reads the command string from the global variable and calls the unified command dispatcher; the dispatcher queries the pre-stored command type tag table to determine whether the execution body of the command is SystemVerilog native or CPU firmware; S3: If it is determined to be a SystemVerilog native command, the corresponding native processing function is called to execute it, and the result is written to the global result variable; S4: If the command is determined to be a CPU firmware command, the command string is sent to the CPU firmware running in the simulation via the shared memory mailbox, and a timeout timer is started to wait for its return result. S5: The CPU firmware reads and parses commands from the shared memory mailbox, calls the corresponding processing function to execute them, and then returns the result string through the mailbox; S6: The SystemVerilog layer detects the returned result through polling or event mechanisms, reads the result string, and writes it into a preset TCL global result variable; S7: The TCL script layer reads the result from the global result variable and returns it to the user. If the waiting time in step S4 exceeds the preset time, a timeout error is triggered, and the waiting is terminated. Users can read command execution results through the same TCL command without being aware that the command is executed at the SystemVerilog layer or the CPU firmware layer.

2. The CPU firmware interactive verification method based on TCL script transparent routing according to claim 1, characterized in that: In step S2, the command type tag table is constructed through compile-time macro definitions: On the SystemVerilog side, the `aip_cmd_cpu(command_name)` macro is used to tag CPU firmware commands. After expansion, this macro generates an empty command executor subclass and marks the corresponding command name as a CPU command type in the associative array. The SystemVerilog side also provides a batch registration macro `aip_cpu_bridge_builtins`, which expands into multiple `aip_cmd_cpu` macro calls at once, used to quickly register a predefined set of CPU firmware commands, including memory read / write, endianness conversion, and polling.

3. The CPU firmware interactive verification method based on TCL script transparent routing according to claim 1, characterized in that: In steps S4 and S5, the shared memory mailbox communication protocol includes a command flag, a command data area, a response flag, and a response data area. Before sending a command, the SystemVerilog side clears the response flag and sets the command flag to 1 after writing the command data. The CPU firmware side immediately clears the command flag when it detects that the command flag is 1, and after execution, writes the result to the response data area and sets the response flag to 1.

4. The CPU firmware interactive verification method based on TCL script transparent routing according to claim 1, characterized in that: The waiting mechanism in step S4 supports at least one of the following four synchronization modes: pure polling mode, interrupt mode, event mode, and a hybrid interrupt and event mode.

5. The CPU firmware interactive verification method based on TCL script transparent routing according to claim 4, characterized in that: The event pattern is implemented by defining monitoring logic within the module scope of SystemVerilog. This logic monitors the memory address corresponding to the response flag in the mailbox. When the address value changes, an event is triggered, achieving zero-latency waiting on the SystemVerilog side.

6. The CPU firmware interactive verification method based on TCL script transparent routing according to claim 1, characterized in that: In step S5, the CPU firmware runs a lightweight command framework that does not depend on the standard C library. This framework provides command registration API, parameter parsing API, and result formatting and return API. The parameter parsing API includes cmd_get_int, cmd_get_long, and cmd_get_str for parsing memory addresses, register addresses, data values, and lengths from command strings. The result formatting and return API is cmd_return.

7. The CPU firmware interactive verification method based on TCL script transparent routing according to claim 1, characterized in that: In step S1, hybrid parallel execution of TCL scripts is supported: users can simultaneously schedule SystemVerilog native commands and CPU firmware commands in a fork / join concurrent structure; the unified command dispatcher routes each command independently, enabling them to execute in parallel during simulation time.

8. A CPU firmware interactive verification system based on TCL script transparent routing according to any one of claims 1-7, characterized in that: It includes a TCL command interception module, which intercepts user commands and forwards them to the simulation environment; and a SystemVerilog unified command distribution module, which receives commands and routes them to the local execution unit or CPU communication bridge unit according to the command type tag table. The shared memory mailbox module is used to bidirectionally transmit command and response strings between the SystemVerilog simulation environment and the CPU firmware. Its storage space is simultaneously mapped to the backdoor access interface on the SystemVerilog side and the physical address space on the CPU firmware side. The CPU firmware command framework module is used to parse and execute commands and return results. The synchronization and timeout control module is used to implement multiple synchronization modes between the SystemVerilog side and the CPU firmware side, and provides a timeout protection mechanism for command execution.

9. The CPU firmware interactive verification system based on TCL script transparent routing according to claim 8, characterized in that: The SystemVerilog unified command distribution module includes a command type tagging table and a command executor. The command executor queries the tagging table and then calls a local processing function or sends the command to the shared memory mailbox module via the CPU communication bridge unit.

10. The CPU firmware interactive verification system based on TCL script transparent routing according to claim 8, characterized in that: The shared memory mailbox module includes a command flag register written by the SystemVerilog side, a response flag register written by the CPU firmware side, and data buffers for storing command and response strings, respectively.

Images