A remote command interaction system and method for chip emulation based on DPI-C Socket

Abstract

The application discloses a chip simulation remote command interaction system and method based on DPI-C Socket+, which comprises a C client, a DPI-C Socket bridge and a SystemVerilog command registration and distribution center. The client sends a text command through a network; the bridge establishes a non-blocking TCP server in the simulator through a DPI-C interface, supports multi-client concurrent connection, and schedules the command through a double-priority queue; and the command registration center defines a remote command through a single-line macro, adopts a unified 'key=value' text protocol to analyze parameters, and supports parallel execution and runtime discovery of the command. The method enables a user to remotely and interactively control a verification platform from outside during simulation running, without modifying code and recompiling, solves the problem of lack of interactivity of traditional static use cases, and greatly improves flexibility and efficiency of verification and debugging.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit EDA verification tools, specifically to a remote command interaction system and method for chip simulation based on DPI-C Socket. Background Technology

[0002] Currently, mainstream stimulus control methods have significant limitations in the functional verification process of digital chips (especially SoCs). The most common method, pure SystemVerilog / UVM static test cases, binds the test scenario to the code statically. This means that any addition or modification must be recompiled in the simulation environment, which can take anywhere from several minutes to tens of minutes. Furthermore, it completely lacks runtime interactivity, preventing engineers from intervening in the control in real time after the simulation starts, severely restricting the flexibility of debugging.

[0003] To enhance interactivity, two supplementary solutions exist in the industry, but neither is perfect. The first is the DPI-C direct function call method. While this method can call C functions, the imported functions are strongly coupled to specific scopes, and it lacks a unified command registration and dispatch mechanism, requiring each function to handle routing separately. The second is a Socket-based network communication method. This approach provides low-level communication APIs, but remains at the interface level, lacking a high-level command dispatch framework. Users must implement complex command parsing and scheduling logic themselves, resulting in low development efficiency.

[0004] Similar limitations exist in related patented technologies. For example, US Patent 6421823B1 discloses a bidirectional socket excitation interface, but it focuses on signal-level interaction and does not build a command-level registration and distribution center, nor does it support multi-client management. US Patent 2024427679A1 relates to a DPI hardware / software communication channel for FPGAs, but its application target (FPGA hardware simulation) differs from the software simulator environment of this invention. US Patent 10664563B2 relates to the verification of concurrent test platforms and software drivers, but its solution is mainly geared towards hardware accelerator environments. Chinese Patent CN114265786A discloses an automated testing method, but it uses serial communication and signal force methods, rather than a network command interaction architecture based on DPI-C and Socket.

[0005] In summary, existing technical solutions generally suffer from core defects such as cumbersome command registration (traditional methods require scattered maintenance of approximately 23 lines of code), lack of a unified command dispatcher and self-describing "key-value" parameter protocol, lack of support for multi-client concurrent management and priority scheduling, and inability to achieve remote parallel command execution (such as fork / join). Related patent literature also largely focuses on low-level signal interfaces or specific hardware communication, failing to construct a complete closed-loop framework from "network client" to "unified command execution within the emulator." Therefore, we propose a chip simulation remote command interaction system and method based on DPI-C Socket. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to overcome the existing defects and provide a chip simulation remote command interaction system and method based on DPI-C Socket, which can integrate non-blocking network communication, unified command registration and distribution and efficient development interface, and can effectively solve the problems in the background technology.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A remote command interaction system for chip emulation based on DPI-C Socket includes a C client program, a DPI-C Socket bridge, and a SystemVerilog command registration and distribution center. The C client program is used to send text-formatted commands to the emulator over the network and receive responses. The DPI-C Socket bridge, imported through the DPI-C interface of SystemVerilog (SV), is used to establish and manage non-blocking TCP servers within the emulator, receive commands from the C client program, and return execution results. The SystemVerilog command registration and distribution center provides a macro-registration mechanism for commands and uniformly parses and executes commands from the DPI-C Socket bridge.

[0009] The C client program is a command-line tool based on the readline library, which supports command history, auto-completion, and result highlighting; the DPI-C Socket bridge handles multiple client connections concurrently through multiple thread modules (at least two).

[0010] By integrating the C client, DPI-C Socket bridge, and SystemVerilog command registry, a complete remote command interaction closed-loop framework can be built, solving the problems of the lack of runtime interaction capabilities in the existing pure SV static use case approach and the lack of a unified high-level command distribution mechanism in the existing DPI-C or Socket solutions, and realizing standardized command control from the network to the simulator's internal workings.

[0011] Furthermore, the DPI-C Socket bridge includes: a C-side non-blocking Socket function library, imported via DPI-C, used to create listening sockets, accept client connections non-blockingly, and receive and send data; and an SV-side multi-threaded bridge module, used to manage listening threads, client connection processing threads, file reading threads, and command execution threads, enabling concurrent processing of multiple client (at least two) connections and reception of multiple command sources (at least two), wherein the file reading thread is used to read batch commands from a specified file.

[0012] By using a non-blocking Socket function library and a multi-threaded management module, a high-performance communication server can be established inside the simulator, solving the problem that most existing solutions are single-client blocking modes. This enables support for up to 64 concurrent client connections and provides a foundation for scheduling different command sources (network, file).

[0013] Furthermore, the SV-side multi-threaded bridge module is equipped with a dual-priority mailbox queue, including a high-priority mailbox for receiving real-time network interaction commands and a low-priority mailbox for receiving file batch processing commands, to ensure that high-priority commands are executed first.

[0014] By setting up a dual-priority mailbox queue, real-time interactive commands from network clients and batch processing commands from files can be scheduled in a hierarchical manner, ensuring the real-time response of interactive debugging commands and optimizing the user experience.

[0015] Furthermore, the SystemVerilog command registry and dispatch center includes: a command base class, which defines the general interface and fields of commands and automatically registers them to the global command registry upon instantiation; a macro command registration unit, which automatically generates specific command subclasses containing parameter parsing, type conversion, and task invocation logic through single-line macro calls; and a command dispatcher, which parses the command string sent by the client, searches for the corresponding command object in the global command registry, and drives its execution. The SystemVerilog command registry and dispatch center also supports runtime command discovery, which can respond to specific query commands and return a list of all currently registered commands.

[0016] By designing a command base class, macro registration, and a unified dispatcher, the code required to add a new command can be reduced from approximately 23 lines in three separate places (SV declaration, C implementation, and routing code) to a single macro call, improving development efficiency by about 95% and solving the problems of cumbersome command registration, lack of a unified dispatcher, and lack of runtime discovery capabilities in existing technologies.

[0017] Furthermore, the SystemVerilog command registration and dispatch center also supports parallel command execution. The command dispatcher can parse command strings in the format of "fork...join" and schedule the tasks corresponding to multiple commands to be executed in parallel or controlled parallel mode. The controlled parallel mode includes the join_any mode.

[0018] By supporting the parsing and execution of command strings in the "fork...join" format, it is possible to schedule multiple tasks to be executed in parallel, which solves the problem that existing technologies lack remote fork / join parallel execution capabilities, thereby improving the execution efficiency of batch operations or complex test scenarios.

[0019] A remote command interaction method for chip emulation based on DPI-C Socket includes the following steps:

[0020] S1: In the SystemVerilog verification environment, define remote callable commands through macro registration;

[0021] S2: Start the simulation, initialize the DPI-C Socket bridge, establish a TCP server and start listening;

[0022] S3: One or more external C client programs establish a network connection with the TCP server;

[0023] S4: The client sends a text-formatted command request to the DPI-C Socket bridge;

[0024] S5: The DPI-C Socket bridge routes command strings to the SystemVerilog command registry and dispatch center;

[0025] S6: The SystemVerilog command registry and distribution center parses and executes commands, generating result strings;

[0026] S7: Return the result string to the client that sent the command via the DPI-C Socket bridge;

[0027] In step S2, multiple (at least two) client connections are accepted and processed through multiple (at least two) threads.

[0028] By following the above steps, a complete standardized process can be achieved, from initiating text commands from a remote client to executing them within the simulator and returning results. This allows engineers to interactively control the verification platform from the outside in real time during simulation, without modifying the code or recompiling, greatly improving the flexibility of debugging and testing.

[0029] Furthermore, in step S5, commands from different clients are received by the multi-threaded modules (at least two multi-threaded modules) in the DPI-C Socket bridge and placed into a shared command queue to wait for sequential execution, thereby achieving the scheduling of concurrent commands from multiple clients.

[0030] By using multi-threaded reception and unified queue scheduling, command requests from multiple concurrent clients can be processed in an orderly manner, avoiding conflicts and enabling simultaneous operation or collaborative debugging by multiple users.

[0031] Furthermore, the shared command queue is a dual-priority queue. Real-time interactive commands from network clients enter the high-priority queue, while batch processing commands from file reading enter the low-priority queue. The command dispatcher prioritizes processing commands in the high-priority queue.

[0032] The dual-priority queue scheduling mechanism ensures that urgent debugging commands entered by users on the terminal are executed before batch processing commands from automated scripts, guaranteeing immediate response to interactive operations.

[0033] Furthermore, in step S4, the command string sent by the client is in the format of "command name key1=value1 key2=value2". In step S6, the SystemVerilog command registration and distribution center parses the input parameters according to this "key-value" format, performs base recognition and conversion on the "value" part, and supports multiple number representation formats including decimal, hexadecimal and binary.

[0034] By adopting a unified, self-describing "key=value" text protocol, the problems of inconsistent parameter passing and different command signatures in existing technologies can be solved, making the command interface clearer and easier to use, and supporting multiple number bases to adapt to hardware verification scenarios.

[0035] Furthermore, in step S4, the command string sent by the client supports the syntax "fork command A, command B join". In step S6, the SystemVerilog command registration and dispatch center will schedule the tasks corresponding to command A and command B to be executed in parallel, and return the summary result after both are completed.

[0036] By supporting the "fork...join" syntax at the command protocol level, users can intuitively and conveniently initiate parallel tasks on remote clients, simplifying the writing and control process of parallel test scenarios.

[0037] Compared with the prior art, the beneficial effects of the present invention are as follows: This chip simulation remote command interaction method and system based on DPI-C Socket has the following advantages:

[0038] 1. By using a macro command registration mechanism, the code required to add a new remote command, which traditionally required approximately 23 lines of code scattered across SystemVerilog declarations, C function implementations, and command routing, is simplified to a single macro call. This reduces the code size by about 95%, significantly lowering development complexity and the probability of errors. Simultaneously, engineers can interactively control the verification platform, inject test stimuli, or query status in real-time via a remote client during simulation runtime, without modifying code or recompiling the simulation environment. This breaks the limitations of traditional static test cases and provides unprecedented flexibility for debugging and exploratory testing.

[0039] 2. Through the design of the DPI-C non-blocking Socket server and the SV-side multi-threaded bridge, it supports up to 64 concurrent connections and command requests from external clients. A unique dual-priority mailbox queue mechanism (high priority for network interaction commands, low priority for file batch processing commands) intelligently schedules tasks, ensuring immediate responses to real-time debugging commands issued by users from the terminal. While guaranteeing multi-client support, it also balances the real-time nature of interaction with the throughput of batch operations. In particular, the bridge includes a listening thread, a client connection processing thread, a command execution thread, and a file reading thread, enabling the reception of multiple command sources (network commands and file batch processing commands are received independently and queued accordingly), further improving the system's scalability and automated testing capabilities.

[0040] 3. The system constructs a complete command closed loop from the network to the simulator's internal structure. A unified "command name key=value" self-describing text protocol ensures clear and standardized parameter transmission, and automatically supports parsing multiple formats such as decimal, hexadecimal, and binary. The built-in command registry and dispatcher provide runtime command discovery capabilities (such as the `help` command). More importantly, the system natively supports the "fork ... join" parallel execution syntax at the remote command protocol level, allowing users to directly initiate the parallel execution of multiple commands on the client side. This effectively improves the execution efficiency of batch configuration or complex testing scenarios, a high-level control capability not found in existing technical solutions.

[0041] Practical verification has shown that this system is stable and reliable. Real-world application in mainstream EDA simulators (such as VCS) demonstrates that the system can correctly parse and execute various commands, including register read / write, arithmetic operations, and "fork…join" parallel operations. Parameter parsing is accurate, results are returned correctly, and parallel commands are completed within the same simulation time, effectively proving its practicality and efficiency in real-world chip functional verification environments.

[0042] 4. There is a significant synergistic effect among the various technical features of this invention, resulting in unexpected technical effects that exceed the sum of the individual effects of each feature. Specifically: (1) Synergy between the communication layer and the scheduling layer: The organic combination of non-blocking socket, bridge with at least two threads, and dual-priority queue enables the system to support up to 64 concurrent clients while still ensuring the immediate response of real-time interactive commands (the waiting time for high-priority queue commands is less than one simulation cycle), avoiding the problem of batch processing scripts blocking user commands in traditional solutions; (2) Synergy between the registration layer and the distribution layer: The cooperation between macro registration and unified dispatcher reduces the amount of code for adding commands from about 23 lines to 1 line (a reduction rate of about 95%), and there is no need to maintain any routing code. This efficiency improvement The effect is far greater than the sum of the effects that can be achieved by using macros alone or dispatchers alone; (3) The collaboration between the protocol layer and the scheduling layer: the cooperation of the unified "key=value" text protocol and the dual priority queue makes the command parameters self-descriptive, and the developers do not need to write different parameter parsing logic for commands of different priorities, which further reduces the complexity of the system; (4) The superposition of the above synergistic effects makes the system form a complete closed loop of "definition → reception → distribution → scheduling → search → execution → return", which is something that existing technical solutions (such as solutions that only provide underlying communication, or internal solutions that only provide registration mechanisms but lack communication capabilities) cannot achieve. Attached Figure Description

[0043] Figure 1 This is a diagram of the overall system architecture of the present invention;

[0044] Figure 2 This is a schematic diagram illustrating concurrent connections between multiple clients according to the present invention;

[0045] Figure 3 This is a schematic diagram illustrating the macro-command registration and expansion of the present invention;

[0046] Figure 4 This is a complete flowchart of the command execution of the present invention. Detailed Implementation

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

[0048] Please see Figure 1-4The present invention provides a technical solution: a chip simulation remote command interaction system based on DPI-C Socket, including a C client program, a DPI-C Socket bridge and a SystemVerilog command registration and distribution center.

[0049] C client program: Used to send text-formatted commands to the emulator over the network and receive responses. This program is a command-line tool based on the readline library, supporting command history, auto-completion, result highlighting, automatic reconnection, and color output. Asynchronous reception is achieved through the select system call, providing a user-friendly interactive experience.

[0050] The DPI-C Socket bridge, imported through the SystemVerilog (SV) DPI-C interface, is used to establish and manage non-blocking TCP servers within the emulator, receiving commands from C client programs and returning execution results. This bridge specifically includes:

[0051] The C-side non-blocking socket function library, imported via DPI-C, provides a series of non-blocking network functions. Examples include: `sv_socket_init()` for creating a listening socket, `sv_socket_accept_nonblock()` for accepting client connections non-blockingly, `sv_socket_recv_nonblock()` for receiving data non-blockingly (including logic for handling packet fragmentation), `sv_socket_send()` for sending responses, `sv_socket_close()` for closing the connection, and `sv_socket_is_valid_fd()` for validating file descriptors. The C-side maintains a global client table, supporting up to 64 concurrent connections, and all functions operate in non-blocking mode.

[0052] SV-side multi-threaded bridge module: Typically implemented as a class (e.g., aip_c_bridge) to manage four concurrent threads:

[0053] 1) A listening thread continuously calls accept to accept new client connections, and forks a processing thread for each new connection;

[0054] 2) Client connection processing thread, one for each active client, responsible for receiving (recv) the command string sent by the client and putting it into the high-priority mailbox.

[0055] 3) File reading thread (optional), used to read batch commands from a specified file and put them into a low-priority mailbox;

[0056] 4) The command execution thread retrieves the command from the mailbox, calls the exec() function of the command dispatcher to execute it, and sends the result back to the client through the corresponding connection.

[0057] The DPI-C Socket bridge can be enabled in the simulation environment via a single-line startup macro (e.g., aip_c_bridge_create(c_bridge,"0.0.0.0", 8888, "")). Through the non-blocking Socket function library and multi-threaded management module, a high-performance communication server can be established within the simulator, solving the problem that most existing solutions operate in a single-client blocking mode. This enables support for up to 64 concurrent client connections and provides a foundation for scheduling different command sources (network, file).

[0058] SystemVerilog (SV) Command Registry and Distribution Center: Provides a macro registration mechanism for commands and a unified parsing and execution mechanism for commands from the DPI-C Socket bridge. This center includes:

[0059] Command base class: For example, the aip_cmd base class contains fields such as cmd_name, args_in, result_out, status, and a virtual task cmd_exec(). Its constructor new(name) automatically registers the command object to a global associative array (e.g., __aip_cmd_registry[name]) during instantiation.

[0060] Macro command registration unit: Used to automatically generate specific command subclasses containing parameter parsing, type conversion, and task invocation logic through a single-line macro call, greatly simplifying the command registration process. For example:

[0061]

[0062]

[0063]

[0064]

[0065]

[0066]

[0067] Macro Name use Example aip_cmd_task Register a command with no input or output parameters. aip_cmd_task(hello, ops::hello) aip_cmd_1i Register a command with one input parameter. aip_cmd_1i(delay, ops::delay, int, ns, 100) aip_cmd_2i1o Register a command with 2 input parameters and 1 output parameter. aip_cmd_2i1o(wr, ops::wr, int, addr, 0, int, data, 0, int, status) aip_cmd_str_1i Register a command with one string input parameter. aip_cmd_str_1i(echo, ops::echo, msg, "hi")

[0068] Command dispatcher: The main function is `exec(cmd_str, source)`, which parses the command string sent by the client, looks up the corresponding command object in the global command registry, and drives its execution. Its workflow is: parse command name -> look up the command object in the global registry -> call the object's `cmd_exec()` task -> return the result string. For unknown commands, an error (such as `$fatal`) may be triggered.

[0069] Parameter parsing: The command dispatcher has a built-in parameter parsing function, supporting a unified text format of "command name key1=value1 key2=value2". The `get_arg(args, key)` function extracts the value of a specific key, `parse_int_arg()` supports automatic radix recognition and conversion for the "value" part (e.g., 100 (decimal), 0x64 (hexadecimal), 0b1100100 (binary)), and `parse_string_arg()` is used to process string parameters.

[0070] The SystemVerilog Command Registry and Dispatch Center also supports runtime command discovery, responding to specific query commands (such as help) and returning a list of all currently registered commands. Through the design of a command base class, macro registration, and a unified dispatcher, the code required to add a new command can be reduced from approximately 23 lines (spanning three locations: SV declaration, C implementation, and routing code) to a single macro call, improving development efficiency by approximately 95%.

[0071] By integrating the C client, DPI-C Socket bridge, and SV command registry, a complete remote command interaction closed-loop framework can be built, solving the problems of the lack of runtime interaction capabilities in the existing pure SV static use case approach and the lack of a unified high-level command distribution mechanism in the existing DPI-C or Socket solutions, and realizing standardized command control from the network to the simulator's internal workings.

[0072] The SV-side multi-threaded bridge module employs a dual-priority mailbox queue, including a high-priority mailbox for receiving real-time network interactive commands and a low-priority mailbox for receiving file batch processing commands, ensuring that high-priority commands are executed first. The command execution thread prioritizes processing commands in the high-priority mailbox. By setting up the dual-priority mailbox queue, real-time interactive commands from network clients and batch processing commands from files can be scheduled hierarchically, ensuring the real-time response of interactive debugging commands and optimizing the user experience.

[0073] The SystemVerilog command registration and dispatch center also supports parallel command execution. The command dispatcher can parse command strings in the format "fork … join" and schedule tasks corresponding to multiple commands to be executed in parallel or controlled parallel mode. Controlled parallel mode includes the join_any mode. By supporting the "fork … join" syntax at the command protocol level, users can intuitively and conveniently initiate parallel tasks on remote clients, solving the problem of the lack of remote fork / join parallel execution capabilities in existing technologies, thereby improving the execution efficiency of batch operations or complex testing scenarios.

[0074] The various technical features of this invention form multiple synergistic relationships, collectively constituting a complete closed-loop framework for remote command interaction:

[0075] (I) Coordination of Communication and Scheduling: The non-blocking Socket function library works in conjunction with the SV-side multi-threaded bridge to achieve reception splitting for at least two concurrent client connections; the dual-priority mailbox queue is classified and stored according to the command source (network real-time command or file batch processing command), and is scheduled by a unified execution thread according to priority. The three work together—non-blocking ensures that the receiving thread is not suspended, at least two threads achieve source splitting, and dual priority ensures that urgent commands take precedence—achieving both multi-client concurrency and priority response to real-time commands without blocking the simulation main thread.

[0076] (II) Coordination between Registration and Distribution: The macro command registration unit automatically generates command subclasses during macro expansion and automatically registers them to the global command registry through the base class constructor; after parsing the client command string, the command dispatcher directly looks up the corresponding command object in the registry and drives its execution. The two work together—macros implement "declaration equals registration," and the dispatcher implements "table lookup equals routing"—reducing the amount of code for adding commands from approximately 23 lines to 1 line, a reduction of approximately 95%.

[0077] (III) Collaboration between Protocol and Parsing: The unified text protocol "command name key1=value1 key2=value2" is consistent with the parameter declaration format in macros. When macros expand, parameter parsing code conforming to this protocol is automatically generated. Developers only need to declare the parameter name and type, and the system automatically handles key-value extraction, multi-base conversion (decimal / hexadecimal / binary), and type mapping, achieving zero parsing code.

[0078] (iv) Synergy between parallel syntax and scheduling framework: The command dispatcher has a built-in fork / join syntax parsing engine. After parsing, it searches for at least two command objects in the global registry, schedules them for parallel execution, and aggregates the results after all (or any) commands are completed and returns them uniformly. This capability relies on the aforementioned global registry and unified dispatcher, which is not achievable in existing solutions.

[0079] A remote command interaction method for chip emulation based on DPI-C Socket includes the following steps:

[0080] S1: In the SystemVerilog verification environment, define remote callable commands through macro registration;

[0081] S2: Start the simulation, initialize the DPI-C Socket bridge (e.g., by calling the startup macro), establish a TCP server and start listening, and accept and process multiple client connections through multiple threads;

[0082] S3: One or more external C client programs establish a network connection with the TCP server;

[0083] S4: The client sends a text-formatted command request to the DPI-C Socket bridge. The command string format sent by the client is "command name key1=value1 key2=value2". The command string sent by the client supports the syntax "fork commandA, commandB join".

[0084] S5: The DPI-C Socket bridge routes command strings to the SystemVerilog command registry and dispatch center. Commands from different clients are received by the multi-threaded module in the DPI-C Socket bridge and placed into a shared command queue for sequential execution, enabling scheduling of concurrent commands from multiple clients. The shared command queue is a dual-priority queue: real-time interactive commands from network clients enter the high-priority queue, while batch processing commands from file reading enter the low-priority queue. The command dispatcher prioritizes commands in the high-priority queue. Through multi-threaded reception and unified queue scheduling, command requests from multiple concurrent clients can be processed in an orderly manner, avoiding conflicts and enabling simultaneous operation or collaborative debugging by multiple users. The dual-priority queue scheduling mechanism ensures that urgent debugging commands entered by users on the terminal are executed before batch processing commands from automated scripts, guaranteeing immediate response to interactive operations.

[0085] S6: The SystemVerilog Command Registry and Dispatch Center parses and executes commands, generating result strings. It parses input parameters according to the "key-value" format, performs radix recognition and conversion on the "value" part, and supports multiple numerical representation formats including decimal, hexadecimal, and binary. By adopting a unified, self-describing "key=value" text protocol, it solves the problems of inconsistent parameter passing and different command signatures in existing technologies, making the command interface clearer and easier to use, and supporting multiple radix inputs to adapt to hardware verification scenarios. For commands in the "fork…join" format, the SystemVerilog Command Registry and Dispatch Center will schedule multiple tasks corresponding to these commands to execute in parallel (supporting join / join_any modes, etc.), and return a summary result after all (or any) tasks are completed.

[0086] S7: Return the resulting string to the client that sent the command via the DPI-C Socket bridge.

[0087] By following the above steps, a complete standardized process can be achieved, from initiating text commands from a remote client to executing them within the simulator and returning results. This allows engineers to interactively control the verification platform from the outside in real time during simulation, without modifying the code or recompiling, greatly improving the flexibility of debugging and testing.

[0088] Specific application examples

[0089] Example 1: Basic Register Read / Write Verification

[0090] This example demonstrates how to register a basic register read / write command using a single-line macro and interact with it through a client.

[0091] Step 1: Register the command in the SystemVerilog verification environment

[0092] By using macro registration, remotely callable `write_reg` (write register) and `read_reg` (read register) commands are defined. This step simplifies the approximately 23 lines of code that would traditionally need to be maintained in three places (SV declaration, C implementation, and routing) into two lines of macro calls.

[0093] `aip_cmd_2i1o(write_reg, reg_ops::write_reg, int, addr, 0, int, data,0, int, status)`aip_cmd_1i1o(read_reg, reg_ops::read_reg, int, addr, 0, int,data)

[0094] Step 2: Start the simulation and initialize the server.

[0095] In the test platform, the DPI-C Socket bridge is enabled via a single startup macro, allowing it to establish a TCP server within the emulator.

[0096] `aip_c_bridge_create(c_bridge, "0.0.0.0", 8888, "")

[0097] Step 3: Compile and run the simulation

[0098] vcs -sverilog -ntb_opts uvm +incdir+. -timescale=1ns / 1ps -CFLAGS "-std=c99" sv_socket_dpi.c tb.sv -o simv. / simv

[0099] This embodiment verifies the core process of the system: a text command in the format of "key=value" is sent from a remote client, bridged via network and DPI-C, and finally executed on the SV side and the result is returned. The whole process does not require modification of the code or recompilation of the simulation environment.

[0100] Example 2: Concurrent Connections and Command Processing for Multiple Clients

[0101] This embodiment illustrates the system's ability to support multiple clients connecting and sending commands simultaneously.

[0102] After the simulation in Example 1 is run, open two or more independent terminals, start the client program and connect to the same simulation server (127.0.0.1:8888).

[0103] Client A executes: write_reg addr=0x20 data=0xCAFE

[0104] Client B simultaneously executes: read_reg addr=0x10

[0105] The system's internal DPI-C Socket bridge forks an independent processing thread for each client connection. Commands from different clients are received by their respective processing threads and placed in high-priority mailboxes. The command execution thread retrieves commands from the mailboxes in order, calls the dispatcher to execute them, and then accurately returns the results to the corresponding clients. This mechanism ensures that multiple users can operate simultaneously or perform collaborative debugging without command interference.

[0106] Example 3: Parallel command execution supporting fork / join

[0107] > fork write_reg addr=0x30 data=0x111, write_reg addr=0x31 data=0x222join OK: status=0x0> read_reg addr=0x30 OK: data=0x111> read_reg addr=0x31OK: data=0x222

[0108] Example 4: Automated Testing Using Python Scripts

[0109] This embodiment demonstrates the ability to easily write automated test scripts using a high-level programming language (such as Python) through the system's standardized TCP text interface.

[0110] import sockets = socket.socket(socket.AF_INET, socket.SOCK_STREAM)s.connect(("10.0.0.1", 8888))for addr in range(256):s.sendall("write_reg addr=%d data=0x%x\n" % (addr, addr*0x100))assert s.recv(4096).strip().startswith("OK")print("All 256 registers verified OK")

[0111] This Python script automates the writing and result verification of 256 registers, fully demonstrating the advantages of exposing simulation control capabilities as standardized network services, making it extremely easy to automate verification using a rich software ecosystem.

[0112] Example 5: Comparative Verification of Synergistic Effects

[0113] To verify the synergistic effect of the various technical features of this invention, the applicant set up a comparative experiment. Under the same hardware environment (CPU: Intel Xeon E5-2680 v4, RAM: 64GB) and emulator (VCS Q-2020.03-SP2-7), the following three configurations were tested respectively:

[0114] Configuration A: Non-blocking Socket communication only (no multithreading, no dual-priority queue);

[0115] Configuration B: Non-blocking Socket + Multi-threaded Bridge (without dual priority queue);

[0116] Configuration C: The complete solution of this invention (non-blocking Socket + multi-threaded bridge + dual priority queue + macro registration + unified dispatcher + fork / join support).

[0117] Experiment Result 1: Comparison of Command Response Latency (8 concurrent clients, 100 commands per client)

[0118] A 2.17ms No distinction 8.43ms B 0.89ms No distinction 3.21ms C 0.32ms 1.24ms 1.05ms

[0119] The high-priority command latency of configuration C is reduced by about 85% compared to configuration A and by about 64% compared to configuration B. Moreover, while supporting priority scheduling, the low-priority command latency is still better than that of configuration A, which fully demonstrates the synergistic effect of "non-blocking + multi-threading + dual priority".

[0120] Experiment Result 2: Comparison of Code Development Efficiency (10 New Commands Added)

[0121] Traditional method (no macros, no dispatcher) 230 lines 120 lines Manual routing table Using only macros (without a unified dispatcher) 120 lines 60 lines Manual registration is still required. Distributor only (no macro registration) 150 lines 80 lines zero This invention (macro + dispatcher) 10 lines zero zero

[0122] The code size of this invention is reduced by about 92% compared to "using macros only" and by about 93% compared to the dispatcher, proving that macro registration and unified dispatcher work together to produce unexpected technical effects.

[0123] Experimental Result 3: Time Saving in Parallel Execution of fork / join

[0124] When the remote client sends the command "fork write_reg addr=0x30 data=0x111, write_reg addr=0x31 data=0x222 join", the two write operations are completed at the same simulation time (9943570 ns), with a total time of 100 ns; if executed sequentially, it would take 200 ns. This 50% time saving demonstrates the practical value of remote parallel syntax.

[0125] 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 chip emulation remote command interaction system based on DPI-C Socket, characterized in that: It includes a C client program, a DPI-C Socket bridge, and a SystemVerilog command registration and distribution center. The C client program is used to send text-formatted commands to the emulator over the network and receive responses. The DPI-C Socket bridge, imported through the DPI-C interface of SystemVerilog (SV), is used to establish and manage non-blocking TCP servers within the emulator, receive commands from the C client program, and return execution results. The SystemVerilog command registration and distribution center provides a macro-registration mechanism for commands and uniformly parses and executes commands from the DPI-C Socket bridge.

2. The chip emulation remote command interaction system based on DPI-C Socket according to claim 1, characterized in that: The DPI-C Socket bridge includes: a C-side non-blocking socket function library, imported via DPI-C, used to create listening sockets, accept client connections non-blockingly, and receive and send data; and an SV-side multi-threaded bridge module, used to manage listening threads, client connection processing threads, file reading threads, and command execution threads, enabling concurrent processing of multiple client connections and reception of multiple command sources.

3. The chip emulation remote command interaction system based on DPI-C Socket according to claim 2, characterized in that: The SV-side multi-threaded bridge module is equipped with a dual-priority mailbox queue, including a high-priority mailbox for receiving real-time network interaction commands and a low-priority mailbox for receiving file batch processing commands, to ensure that high-priority commands are executed first.

4. The chip emulation remote command interaction system based on DPI-C Socket according to claim 1, characterized in that: The SystemVerilog command registry and dispatch center includes: a command base class, which defines the general interface and fields of commands and automatically registers them to the global command registry upon instantiation; a macro command registration unit, which automatically generates specific command subclasses containing parameter parsing, type conversion, and task invocation logic through single-line macro calls; and a command dispatcher, which parses the command string sent by the client, finds the corresponding command object in the global command registry, and drives its execution. The SystemVerilog command registry and dispatch center also supports runtime command discovery, which can respond to specific query commands and return a list of all currently registered commands.

5. A remote command interaction system for chip emulation based on DPI-C Socket according to claim 4, characterized in that: The SystemVerilog command registration and dispatch center also supports parallel command execution. The command dispatcher can parse command strings in the format "fork...join" and schedule tasks corresponding to multiple commands to be executed in parallel or controlled parallel mode. Controlled parallel mode includes the join_any mode.

6. A remote command interaction method for chip emulation based on DPI-C Socket according to any one of claims 1-5, characterized in that, Includes the following steps: S1: In the SystemVerilog verification environment, define remote callable commands through macro registration; S2: Start the simulation, initialize the DPI-C Socket bridge, establish a TCP server and start listening; S3: One or more external C client programs establish a network connection with the TCP server; S4: The client sends a text-formatted command request to the DPI-C Socket bridge; S5: The DPI-C Socket bridge routes command strings to the SystemVerilog command registry and dispatch center; S6: The SystemVerilog command registry and distribution center parses and executes commands, generating result strings; S7: Return the resulting string to the client that sent the command via the DPI-C Socket bridge.

7. The remote command interaction method for chip emulation based on DPI-C Socket according to claim 6, characterized in that: In step S5, commands from different clients are received by the multi-threaded module in the DPI-C Socket bridge and placed in a shared command queue to wait for sequential execution, thereby achieving the scheduling of concurrent commands from multiple clients.

8. The remote command interaction method for chip emulation based on DPI-C Socket according to claim 7, characterized in that: The shared command queue is a dual-priority queue. Real-time interactive commands from network clients enter the high-priority queue, while batch processing commands from file reading enter the low-priority queue. The command dispatcher prioritizes processing commands in the high-priority queue.

9. A remote command interaction method for chip emulation based on DPI-C Socket according to claim 6, characterized in that: In step S4, the command string sent by the client is in the format "command name key1=value1 key2=value2". In step S6, the SystemVerilog command registration and distribution center parses the input parameters according to the "key-value" format, performs base recognition and conversion on the "value" part, and supports at least one number representation format including decimal, hexadecimal and binary.

10. A remote command interaction method for chip emulation based on DPI-C Socket according to claim 9, characterized in that: In step S4, the command string sent by the client supports the syntax "fork command A, command B join". In step S6, the SystemVerilog command registration and distribution center will schedule the tasks corresponding to command A and command B to be executed in parallel, and return the summary result after both are completed.

Images