Simulation verification method, simulator and storage medium

Abstract

This application provides a simulation verification method, simulator, and storage medium. The method is applied to a simulation verification system, which includes a simulator and a server. The simulator runs front-end silicon design code for a microprocessor architecture, verification logic code, and monitoring code. The method includes: the simulator performing a functional verification process on the front-end silicon design code of the microprocessor architecture by calling the verification logic code, and monitoring the functional verification process by calling the monitoring code. The functional verification process includes triggering first firmware code to verify the correctness of the execution instruction sequence between the application processor, input / output processor, and peripheral controller. The simulator sends the obtained monitoring data to the server, enabling the server to verify the functionality of the front-end silicon design code of the microprocessor architecture based on the monitoring data. This method improves the efficiency of simulation verification.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a simulation verification method, simulator, and storage medium. Background Technology

[0002] In microprocessors, frequent interactions between the application processor and peripheral controllers can degrade processor performance and hinder efficient operation. To address this issue, input / output processors (I / O processors) are introduced into the microprocessor to act as intermediaries between the application processor and peripheral controllers, thus creating a multi-core microprocessor. In this multi-core microprocessor, the I / O processor handles the interaction with the peripheral controllers on behalf of the application processor, reducing the workload on the application processor and thereby improving the performance of both the application processor and the entire microprocessor.

[0003] Before formally producing the aforementioned microprocessor containing input / output processors, it is necessary to simulate and verify the microprocessor, especially its input / output processors. Existing simulation and verification methods for this microprocessor typically rely on simulation software logs after simulation to analyze errors and anomalies and determine whether the microprocessor architecture functions correctly. This simulation and verification method has low analysis efficiency, especially when complex problems arise, requiring a considerable amount of time to identify the problem. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a simulation verification method, simulator, and storage medium, which can improve the efficiency of simulation verification.

[0005] This application provides a simulation verification method applied to a simulation verification system. The simulation verification system includes a simulator and a server. The simulator runs front-end silicon design code, verification logic code, and monitoring code for a microprocessor architecture. The microprocessor architecture includes an application processor, an input / output processor, and at least one peripheral controller. The input / output processor contains first firmware code. The method includes: the simulator performing a functional verification process on the front-end silicon design code of the microprocessor architecture by calling the verification logic code; and monitoring the functional verification process by calling the monitoring code. The functional verification process includes triggering the first firmware code to verify the correctness of the execution instruction sequence between the application processor, the input / output processor, and the peripheral controller. The simulator sends the obtained monitoring data to the server, so that the server verifies the functionality of the front-end silicon design code of the microprocessor architecture based on the monitoring data.

[0006] A second aspect of this application provides a simulator applied to a simulation verification system, the simulation verification system further including a server. The simulator runs front-end silicon design code, verification logic code, and monitoring code for a microprocessor architecture. The microprocessor architecture includes an application processor, an input / output processor, and at least one peripheral controller. The input / output processor contains first firmware code. The simulator performs a functional verification process on the front-end silicon design code of the microprocessor architecture by calling the verification logic code, and monitors the functional verification process by calling the monitoring code. The functional verification process includes triggering the first firmware code to verify the correctness of the execution instruction sequence between the application processor, the input / output processor, and the peripheral controller. The simulator sends the obtained monitoring data to the server, so that the server verifies the functionality of the front-end silicon design code of the microprocessor architecture based on the monitoring data.

[0007] A third aspect of this application provides another simulator, including a processor and a memory, wherein the memory is used to store program instructions and / or data, and the processor is used to call the program instructions stored in the memory to execute the above-described simulation verification method.

[0008] A fourth aspect of this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the simulation verification method described above.

[0009] In the simulation verification method provided in this application, the simulator performs a functional verification process on the front-end silicon design code of the microprocessor architecture by calling verification logic code. During the verification process, monitoring code is also called to monitor the functional verification process and send the monitoring data to the server. The server can directly verify the functionality of the front-end silicon design code of the microprocessor architecture based on the monitoring data. This solution monitors the simulation verification process through separate code during the functional verification of the front-end silicon design code of the microprocessor architecture. This allows the server to directly verify the functionality of the front-end silicon design code of the microprocessor architecture through monitoring data, and enables the server to determine the correctness of the functionality of the front-end silicon design code of the microprocessor architecture in real time based on the monitoring data during the simulation verification process. Compared to existing technologies that require analyzing simulation software logs after simulation verification to discover errors or anomalies, the simulation verification method provided in this application is more efficient.

[0010] In some implementations, the monitoring code includes a first monitoring code and a second monitoring code. The emulator monitors the functional verification process by calling the monitoring code, including: the emulator monitoring the program counter status of the input / output processor and / or the interrupt signal status between the input / output processor and the application processor by calling the first monitoring code; and the emulator monitoring the bus signals between the input / output processor and the application processor and / or the peripheral controller by calling the second monitoring code. In this implementation, by dividing the monitoring code into monitoring the internal state of the processor and monitoring the communication interface according to the monitoring object and function, anomalies can be systematically captured from both control flow and communication flow dimensions. This allows the server to more quickly and accurately locate whether the problem originates from an internal processor anomaly or a data interaction error, thereby ensuring that the firmware hot-swap mechanism can be accurately triggered.

[0011] In some implementations, the first monitoring code includes a first sub-monitoring code and a second sub-monitoring code. The simulator monitors the counting state of the input / output processor and / or the interrupt signal state between the input / output processor and the application processor by calling the first monitoring code. This includes: the simulator monitoring the counting state of the program counter of the input / output processor by calling the first sub-monitoring code, and terminating the functional verification process and generating a first termination signal if an abnormal counting state of the program counter is detected; and / or, the simulator monitoring the interrupt signal state between the input / output processor and the application processor by calling the second sub-monitoring code, and terminating the functional verification process and generating a second termination signal if an abnormal interrupt signal state between the input / output processor and the application processor is detected. This design enables the server to directly and without delay receive explicit hardware anomaly events, thereby eliminating the need for post-event analysis of large amounts of raw signal data, accelerating the response process from anomaly occurrence to firmware update decision, and further improving simulation verification efficiency.

[0012] In some implementations, the emulator monitors the program counter status of the input / output processor by calling the first sub-monitoring code. If an abnormality is detected in the program counter's count status, the emulator terminates the functional verification process and generates a first termination signal. This includes: the emulator monitoring the program counter value of the input / output processor by calling the first sub-monitoring code; if the program counter value remains unchanged for a first set time period, the emulator calls the timing code in the first sub-monitoring code to start timing; if the timing reaches a second set time period and the program counter value remains unchanged, the emulator determines that the program counter's count status is abnormal, terminates the functional verification process, and generates a first termination signal. In this implementation, by introducing a two-level timeout judgment mechanism, short pauses during normal processor execution are avoided from being misjudged as fatal errors. An exception report is only triggered after the shutdown state continues for more than a preset threshold, thus ensuring the accuracy of program counter anomaly detection, effectively filtering invalid exception reports, and ensuring that firmware hot-swapping is only triggered when truly needed.

[0013] In some implementations, the simulator monitors the interrupt signal status between the input / output processor and the application processor by calling the second sub-monitoring code. If an abnormal interrupt signal status is detected between the input / output processor and the application processor, the simulator terminates the functional verification process and generates a second termination signal. This includes: if the simulator detects a valid interrupt signal between the input / output processor and the application processor by calling the second sub-monitoring code, it calls the timing code in the second sub-monitoring code to start timing; if the timing reaches a third set duration, and the interrupt signal between the input / output processor and the application processor remains valid throughout the timing process, the simulator determines that the interrupt signal status between the input / output processor and the application processor is abnormal, terminates the functional verification process, and generates a second termination signal. By monitoring the duration of a continuously valid interrupt signal, this solution can accurately identify this hangup state, thereby automatically and quickly discovering handshake failures at the communication protocol level. This avoids the inefficient method of only being able to reverse-engineer the root cause of the problem by checking for errors in the final data result, thus improving the speed of problem localization.

[0014] In some implementations, the emulator monitors bus signals between the input / output processor and the application processor and / or the peripheral controller by calling the second monitoring code. This includes: the emulator sampling the bus signals between the input / output processor and the application processor, and / or between the input / output processor and the peripheral controller, by calling the second monitoring code, and generating bus monitoring data based on the sampled signal data. In this implementation, by continuously sampling and recording the bus signals, bus monitoring data that can be analyzed later is generated, providing the server with a complete and detailed communication log. When the system reports an error due to a communication failure, the server can analyze this data to reconstruct the data interaction process before the error, thereby quickly distinguishing whether the problem stems from a hardware design flaw or a firmware logic error.

[0015] In some implementations, the simulator sends the obtained monitoring data to the server, enabling the server to verify the functionality of the pre-silicon design code of the microprocessor architecture based on the monitoring data. This includes: the simulator sending a first termination signal and / or a second termination signal to the server, enabling the server to determine, based on the first termination signal and / or the second termination signal, that the first firmware code cannot correctly execute the current functional verification process of the pre-silicon design code of the microprocessor architecture; and / or, the simulator sending bus monitoring data to the server, enabling the server, upon receiving simulation error data sent by the simulator, to determine, based on the bus monitoring data, that the first firmware code cannot correctly execute the current functional verification process of the pre-silicon design code of the microprocessor architecture; wherein, the bus monitoring data is obtained by the simulator by calling the second monitoring code to monitor the bus signals between the input / output processor and the application processor and / or the peripheral controller. By distinguishing and processing different types of monitoring data, accurate responses to anomalies are achieved. For identified hardware anomalies, a high-speed processing path that directly triggers the process ensures timely firmware hot-swapping; for communication log data, it can be combined with simulation error events to identify the root cause of problems during testing and avoid repeated error correction. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1This is a schematic diagram of a microprocessor architecture provided in an embodiment of this application.

[0018] Figure 2 This is a schematic diagram of another microprocessor architecture provided in an embodiment of this application.

[0019] Figure 3 This is a schematic diagram of the structure of a simulation verification system provided in an embodiment of this application.

[0020] Figure 4 This is a flowchart illustrating a simulation verification method provided in an embodiment of this application.

[0021] Figure 5 This is a schematic diagram of another simulation verification system provided in an embodiment of this application. Detailed Implementation

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

[0023] Figure 1 This illustrates a typical microprocessor architecture. See also Figure 1 As shown, in this microprocessor architecture, the processor, DDR (Double Data Rate Synchronous Dynamic Random Access Memory), and peripheral controllers are interconnected via an on-chip network. Specifically, the processor and peripheral controllers establish separate pathways through the on-chip network. When multiple peripheral controllers exist, the processor establishes separate pathways with each peripheral controller through the on-chip network, allowing the processor to directly communicate with each peripheral controller.

[0024] The data communication process between the processor and the peripheral controller can be divided into several stages: the processor initiates a request, the peripheral controller responds to the request, the peripheral controller sends a response message back to the processor, and the processor receives the response message. Because the processor and peripheral controller interact directly, during an interaction, the processor must wait for each of the above stages to complete before it can perform other operations.

[0025] As microprocessor architectures become more feature-rich and highly integrated, more and more peripheral controllers are being integrated into them. In this context, the communication and interaction between the processor and peripheral controllers become more frequent. Each interaction with a peripheral controller goes through the aforementioned multiple stages, causing the processor's resources to be consumed for extended periods during the communication and interaction process with the peripheral controller. This is especially true when the peripheral controller is a low-speed peripheral controller, as its slow response speed can severely impact the processor's performance.

[0026] In addition, the processor needs to load the peripheral controller's driver to communicate with the peripheral controller. When there are many peripheral controllers, the processor needs to load many peripheral controller drivers. Furthermore, when the peripheral controller driver needs to be updated or upgraded, the processor needs to continue to upgrade the peripheral controller driver one by one. All of these processes will cause a lot of resource consumption to the processor.

[0027] To address the aforementioned technical problems, this application proposes a new microprocessor architecture that improves the structure and function of existing microprocessor architectures. This new architecture optimizes the communication method between the processor and the peripheral controller, thereby improving the communication efficiency between the processor and the peripheral controller, reducing the resource consumption of the processor, and improving processor performance.

[0028] See Figure 2 As shown, the microprocessor architecture proposed in this application includes: An application processor, an input / output processor (IOP), and at least one peripheral controller.

[0029] The application processor and the input / output processor are connected via an on-chip network. The input / output processor has an internal network interconnect module, through which it connects to at least one peripheral controller. Various types of buses and bus interfaces can be integrated into the network interconnect module, such as AXI bus and interface, APB bus and interface, etc.

[0030] On-chip networks (ABCs) serve as communication networks between various components within a microprocessor architecture, providing communication links between these components. ABCs can integrate various types of buses and bus interfaces, such as the AXI bus and its interface.

[0031] The application processor includes a first processor core, which is, for example, an application processor core. This application processor core is the computing and control center of the entire processor architecture and is used to execute instructions and perform operations.

[0032] The microprocessor architecture described above also includes a first memory DDR, which serves as the memory for the entire microprocessor architecture and can be used to store the firmware programs of the application processor and / or input / output processor.

[0033] The input / output processor includes a second processor core and a second SRAM, which are connected via an internal network interconnect module. The second processor core serves as an intermediary between the application processor and at least one peripheral controller, while the second SRAM stores the firmware required by the input / output processor.

[0034] In this embodiment of the application, the second processor core mentioned above is specifically a RISC-V (Reduced Instruction Set Computer-Five) core, that is, a processor core with a RISC-V instruction architecture, which mainly completes instruction access for modules with low real-time requirements such as low-speed peripherals.

[0035] The first processor core in the application processor, as the main processor core of the entire microprocessor architecture, is also used to control the startup of other processor cores in the microprocessor architecture, such as the second processor core in the input / output processor. For example, before the second processor core in the input / output processor starts up, the first processor core of the application processor copies the firmware program stored in memory to the second memory (SRAM) of the input / output processor, so that the second processor core in the input / output processor can load the firmware program from the SRAM and start running.

[0036] When the storage space of the second memory SRAM in the input / output processor is insufficient to store the complete firmware program of the input / output processor, a portion of the firmware program can be stored in the second memory SRAM, and the remaining firmware program can be stored in the first memory DDR.

[0037] At least one peripheral controller in the aforementioned microprocessor architecture may include any external device connected to the microprocessor architecture or the controller corresponding to an external device interface, such as a UART (Universal Asynchronous Receiver / Transmitter) controller, an I2C (Inter-Integrated Circuit) controller, an SPI (Serial Peripheral Interface) controller, an SD (Secure Digital) card controller, a GMAC (Gigabit Media Access Controller) controller, and so on.

[0038] In this embodiment, the peripheral controller may include a low-speed peripheral controller. This embodiment connects the low-speed peripheral controller to the application processor via an input / output processor (I / O processor), allowing the I / O processor to perform communication interactions with the low-speed peripheral. This avoids the application processor directly communicating with the low-speed peripheral, which could negatively impact the application processor's performance.

[0039] In other embodiments, the high-speed peripheral controller in the microprocessor architecture can be directly connected to the application processor, thereby enabling the application processor to communicate and interact directly with the high-speed peripheral controller, ensuring the smooth execution of high-speed peripheral interaction services.

[0040] Additionally, in some embodiments, the application processor can also interact directly with certain low-speed peripheral controllers when the input / output processor is saturated.

[0041] In some embodiments, it is possible to flexibly select which peripheral controllers are connected to the application processor via an input / output processor, or to flexibly select which peripheral controllers are directly connected to the application processor. Alternatively, for a given peripheral controller, it can interact directly with the application processor in some situations, or it can interact with the application processor through an input / output processor in others.

[0042] The aforementioned input / output processors serve as intermediaries between the application processor and each peripheral controller. The application processor only needs to be connected to the input / output processor, and the input / output processor is connected to each peripheral controller separately. This eliminates the need for the application processor to establish separate communication links with each peripheral controller.

[0043] Furthermore, based on the aforementioned input / output processor configuration, in interaction scenarios between the application processor and the peripheral controller, the input / output processor can replace the application processor in performing at least some of the interaction operations with the peripheral controller, thereby saving the processing resources of the application processor.

[0044] For example, when the application processor needs to access any one of the target peripheral controllers, it only needs to send the access request for the target peripheral controller to the input / output processor. The second processor core in the input / output processor performs the access to the target peripheral controller according to the access request sent by the application processor, such as sending the access request to the target peripheral controller, and when it receives the access result returned by the target peripheral controller in response to the above access request, it feeds back the access result returned by the target peripheral controller to the application processor.

[0045] When any target peripheral controller among the peripheral controllers needs to send data to the application processor, it first sends a data transmission request to the input / output processor. This data transmission request can be a set request or signal, such as an interrupt request or interrupt signal. After receiving the data transmission request, the second processor core in the input / output processor accesses the target peripheral controller to obtain the data to be transmitted and stores the data to be transmitted in the input / output processor. Then, the second processor core in the input / output processor sends a notification message to the application processor, notifying the application processor to read the aforementioned data to be transmitted from the input / output processor. When the application processor receives the notification message, it can read the data to be transmitted from the input / output processor at an opportune time.

[0046] In the above embodiments, since the application processor no longer performs actual interaction operations with at least some of the peripheral controllers (low-speed peripheral controllers), it is not necessary to install the drivers of these peripheral controllers in the application processor, and there is no operation to upgrade or update these peripheral controller drivers, thereby further reducing the burden on the application processor and reducing resource consumption.

[0047] In design the above Figure 2 Following the microprocessor architecture shown, pre-silicon simulation verification is required before actual production. Only after verifying that its functions meet the design requirements can it be put into formal production.

[0048] To verify the design of the aforementioned microprocessor architecture with integrated input / output processors, the common practice is to synthesize and compile the pre-silicon chip design code of the microprocessor architecture into a logic gate-level netlist and map it onto the simulator. The operating system and other software are then packaged into an image file and loaded when the simulator starts. This one-time system image loading allows the processor in the simulation environment to sequentially complete power-on reset, firmware migration, and various initialization configurations, thus building a complete functional verification environment including the application processor, input / output processor, and peripheral controllers. The main workflow is as follows: First, the server loads the image file containing the bootloader, operating system kernel, root file system, and IOP firmware into the simulator's Flash memory using the simulator's memory loading function. Then, the simulator is started. After system startup, the application processor (AP) migrates the IOP firmware to its designated target storage area (such as the internal SRAM and external DDR memory of the IOP) and completes the IOP's initialization configuration. Finally, the simulator loads the peripheral drivers and performs data read / write tests. After the test is completed, check the simulation log to confirm whether the data is normal and whether the performance is reasonable. If there are errors, locate the problem by analyzing the log and waveform data.

[0049] However, this approach performs poorly when applied to scenarios requiring frequent iterative debugging of firmware code. In its pursuit of complete system simulation, the inherent design of this approach treats each firmware code modification as a completely new system startup process, necessitating a full "stop-modify-reboot" cycle, which inevitably compromises debugging efficiency. For example, when developers discover defects in the IOP firmware or require functional optimization, they must follow these steps: after each modification to the IOP firmware, the image file must be repackaged and loaded into the emulator. Subsequently, they must wait for the AP to complete a series of time-consuming processes, including system initialization, IOP initialization, and operating system startup (typically exceeding 30 minutes), severely impacting simulation verification efficiency.

[0050] Furthermore, the aforementioned simulation verification method requires error and anomaly analysis based on simulation software logs after the simulation to determine whether the microprocessor architecture functions correctly. This simulation verification method has low analysis efficiency, especially when complex problems occur, requiring a considerable amount of time to analyze the problem, and its problem analysis is also relatively lagging.

[0051] To address the aforementioned technical issues, this application proposes a different technical approach. Its core concept is that the server of the simulation verification system assumes the responsibility for determining and deciding on firmware defects. By utilizing the memory data import and signal forcing functions supported by the emulator itself, the firmware code of the IOP is dynamically replaced while the emulator continues to run and the functional verification process is not interrupted. Then, the microprocessor architecture is reset through the encapsulated initialization command sequence, enabling the emulator to continue performing verification based on the new firmware.

[0052] In addition, this technical approach also sets up monitoring processes in the simulator for key locations where problems may occur, so as to facilitate more accurate and direct analysis of the causes of anomalies based on monitoring data.

[0053] By adopting the above technical approach, the efficiency of simulation verification of microprocessor architecture can be improved, especially the ability to quickly analyze functional anomalies and quickly complete firmware updates.

[0054] Figure 3 This is a schematic diagram of the architecture of a simulation verification system provided in an embodiment of this application. The simulation verification system includes a simulator and a server, which are connected by a communication link.

[0055] The simulator (e.g., the Palladium hardware simulation platform) is a large-scale custom processor array that executes chip register-transfer-level (RTL) designs in parallel, enabling cycle-accurate, fully visible, and high-speed pre-silicon verification. Furthermore, the simulator supports functions such as saving and restoring runtime states, forcing signal values, memory loading and dumping, and signal state analysis using a State Description Language (SDL). In this embodiment, the simulator is used to simulate a pre-silicon chip design of a microprocessor architecture, specifically by executing the pre-silicon chip design code for that microprocessor architecture.

[0056] The simulator also runs verification logic code, which is used to perform functional verification of the front-end silicon design code. While running the front-end silicon design code for the microprocessor architecture, the simulator performs functional verification of the microprocessor architecture by calling this verification logic code.

[0057] The microprocessor architecture simulated by the simulator is as follows: Figure 2 As shown, the system includes an application processor, an input / output processor, and at least one peripheral controller, all interconnected via an on-chip network. In this microprocessor architecture, the application processor contains one or more first processor cores, serving as the core for computation and control of the entire system. The application processor is responsible for executing the operating system and upper-level applications, and during the startup phase, it performs initialization configuration of the input / output processor, including moving firmware code to the target memory area associated with the input / output processor and releasing a reset signal.

[0058] The input / output processor comprises a second processor core and a second memory. The second processor core is a lightweight processor core that implements instruction scheduling and processing, focusing on handling input / output transactions for low-speed peripherals. The second memory is static random access memory (SRAM) used to store the firmware code required for the second processor core to run. This firmware code is triggered and executed during functional verification to verify the correctness of the instruction sequence between the application processor, the input / output processor, and the peripheral controller. The peripheral controller corresponds to the low-speed peripheral model or external interface and is used to simulate or implement the control logic of the specific peripheral.

[0059] During functional verification, the application processor sends peripheral operation requests to the input / output processor (I / O processor) via the on-chip network. The second processor core in the I / O processor executes firmware code, parses and processes these requests, and then sends corresponding bus transactions to the peripheral controller via the network interconnect module, thereby driving the peripheral controller to complete the predetermined operation. The peripheral controller's response data is transmitted back to the application processor via the I / O processor along the reverse path. The signals transmitted between modules during this process include bus requests, bus responses, and interrupt signals.

[0060] The simulator also has the ability to monitor and record the simulation process. Internally configured monitoring code is independent of the pre-silicon chip design code being verified and does not alter the original functional logic of the pre-silicon chip design code. During the simulation, the monitoring code acquires specified signal states in real time and sends the acquired monitoring data to the server.

[0061] The server side is responsible for executing the simulation process control scripts, managing the simulator's operating status, and storing and processing the monitoring data sent by the simulator. The data path between the server and the simulator supports both the server issuing control commands and data to the simulator and the simulator uploading monitoring data and operating logs to the server, thus forming a complete simulation verification environment that supports continuous monitoring and dynamic adjustment.

[0062] In the embodiments of this application, "pre-silicon chip design code of microprocessor architecture" refers to hardware description code used to describe the hardware architecture, circuit timing behavior, and interconnection relationship of each functional module of the entire microprocessor architecture. For example, it can be Verilog, SV, or VHDL code, which can simulate and reproduce the operating logic and electrical characteristics of the post-silicon physical microprocessor architecture before the microprocessor architecture is fabricated.

[0063] "Verification logic code" refers to the code of a software program used to apply test stimuli to the front-end chip design code of a microprocessor architecture and check the correctness of the response.

[0064] "Monitoring code" refers to code that operates independently of the verification logic code during functional verification, used for real-time monitoring of target signal status or recording of communication behavior. Examples include, but are not limited to: checkers written in a state description language, monitor modules implemented in a hardware description language, or monitoring logic implemented through assertions. This monitoring code does not consume logic resources of the design being verified and can be dynamically enabled or disabled during simulation.

[0065] In the embodiments of this application, "first firmware code" and "second firmware code" refer to the original firmware and the updated firmware required for the operation of the input / output processor, respectively. "Second firmware code" can be regenerated after fixing defects in "first firmware code".

[0066] In the embodiments of this application, "target storage area" refers to a storage medium area in the emulator used to store the firmware code of the input / output processor. The server can write code to this area through the emulator's memory data import function.

[0067] In the embodiments of this application, "initialization or reset operation" refers to the operation that reloads the configuration of the microprocessor architecture's pre-silicon chip design and puts it into a state where it can run new firmware. For example, this may include, but is not limited to: releasing and reapplying a reset signal, reinitializing configuration registers, executing a boot sequence, or a hardware reset process triggered by a preset instruction. This operation can be completed without restarting the entire simulation environment.

[0068] Figure 4 The diagram shown is a schematic flowchart of the simulation verification method provided in this application embodiment. This method is applied to the above-mentioned simulation verification system and can be implemented by the interaction between the simulator and the server in the simulation verification system. Specifically, it includes the following steps: S101. The simulator performs functional verification on the pre-silicon chip design code of the microprocessor architecture by calling verification logic code, and monitors the functional verification process by calling monitoring code.

[0069] Specifically, when the simulator performs functional verification, it builds the microprocessor architecture internally by running the pre-silicon chip design code. Figure 2 The complete hardware architecture model is shown. During this process, the verification personnel instantiated and synthesized the microprocessor according to its architecture, and after successful compilation, loaded it onto the emulator. Then, the bootloader, kernel, root file system containing software drivers, and IOP firmware were packaged together into an image. Monitoring code was integrated into the corresponding IOP interface. The emulator was then started, and the image file was imported into flash memory using the emulator's memory load function. Next, the application processor (AP) moved the IOP firmware to the first memory (DDR) and the second memory (SRAM), and completed the IOP initialization configuration. After the system booted, the emulator saved the current state, loaded the drivers for each low-speed peripheral, and checked the logs to confirm successful loading. If the drivers were loaded successfully, the specific functional verification process could be executed.

[0070] During the specific functional verification process, the simulator calls the verification logic code to perform functional verification of the microprocessor architecture's front-end chip design code.

[0071] During the execution of the verification logic code in the emulator, the application processor sends peripheral operation requests to the input / output processor via the on-chip network. The second processor core in the input / output processor executes the first firmware code to parse and process these requests, and then issues the corresponding bus transaction to the peripheral controller via the network interconnect module, thereby driving the peripheral controller to complete the predetermined operation. The response data from the peripheral controller is then transmitted back to the application processor via the input / output processor along the reverse path. In this series of interactions, the signals transmitted between the modules include bus requests, bus responses, and interrupt signals.

[0072] Simultaneously, the simulator invokes the monitoring code in parallel to monitor the operational status of the aforementioned functional verification process. The monitoring code can be dynamically enabled or disabled during simulation without recompiling the entire design. As a specific implementation, the monitoring code can be developed using a state description language supported by the hardware simulation platform, and mounted as a lightweight module on the signal node to be monitored, without consuming additional simulation resources.

[0073] S102. The simulator sends the obtained monitoring data to the server.

[0074] During operation, the emulator continuously collects signal states and generates monitoring data through monitoring code. This monitoring data is sent to the server in real time or periodically through the data path between the emulator and the server. In this embodiment, the term "monitoring data" broadly refers to structured or semi-structured data generated by the emulator after sampling, recording, and analyzing specified hardware signals or states during functional verification. Examples include monitoring data of the state of the input / output processor, monitoring data of the interrupt state between the input / output processor and the application processor, and monitoring data of bus signals between the input / output processor and the application processor and / or peripheral controllers. Specifically, it can refer to real-time captured status anomaly reports or encompass bus monitoring logs that record the communication process.

[0075] In other embodiments, the emulator also sends its own runtime logs to the server.

[0076] S103. The server receives monitoring data sent by the simulator.

[0077] Specifically, the server receives monitoring data sent by the simulator in real time or at regular intervals, and also receives operation log data sent by the simulator. The server stores the received monitoring data and operation log data, and can execute subsequent analysis and processing scripts to parse the stored monitoring data and operation log data.

[0078] S104. If the server determines, based on monitoring data, that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process, it generates or obtains the second firmware code.

[0079] After receiving the monitoring data, the server analyzes it to determine if there are defects in the current first firmware code that could prevent functional verification from continuing. For example, the server can determine whether the program counter of the input / output processor has stalled for an extended period, or whether interrupt signals between the application processor and the input / output processor have not been responded to for a long time. When the server determines that the current first firmware code is abnormal, it will activate a new firmware version. The server can obtain pre-compiled second firmware code from a local or remote firmware repository, or it can generate second firmware code in real time based on new code provided by the verification engineer.

[0080] S105. The server imports the second firmware code into the target storage area of ​​the emulator, which is used to store the firmware code of the input / output processor.

[0081] In this embodiment, the target storage region refers to the address space designated for storing the input / output processor firmware code within the hardware memory model simulated by the emulator. This address space can correspond to a specific area within the second memory (e.g., static random access memory) of the input / output processor, a specific area within the first memory of the microprocessor architecture (e.g., double data rate synchronous dynamic random access memory), or a combination of the two. The server can utilize the memory data import function provided by the simulation platform to directly write the data packet of the second firmware code into the corresponding address of the target storage region via a network communication link, while the emulator remains running and the system is not restarted, thereby dynamically replacing the original first firmware code.

[0082] S106. The server control simulator performs initialization or reset operations on the front-end silicon design code of the microprocessor architecture. S107. The emulator is initialized or reset, and functional verification of the pre-silicon chip design code of the microprocessor architecture continues based on the second firmware code.

[0083] Specifically, after the new firmware code is written, the input / output processor needs to be reloaded and executed. The server sends control commands to the emulator, triggering the emulator to perform an initialization or reset operation for the microprocessor architecture. This initialization or reset operation sets the program counter of the second processor core of the input / output processor to the starting address of the new firmware code and reconfigures the relevant registers, allowing the system to load the second firmware code and resume functional verification execution without undergoing a full cold boot process.

[0084] It is understandable that the operation of the server directly writing the second firmware code to the target storage area in step S105 provides the basic conditions for loading the new firmware through initialization or reset operations in step S106. The synergy between these two operations allows the firmware update process to proceed without interrupting and restarting the entire simulation environment, thus skipping the time-consuming step of waiting for the system to restart with each firmware iteration. This significantly shortens the debugging cycle and improves the efficiency of simulating and verifying the microprocessor architecture's pre-silicon chip design code.

[0085] To further optimize the ability to monitor and distinguish abnormal states, another embodiment of this application provides the following preferred solution.

[0086] In this embodiment, the monitoring code in the simulator includes a first monitoring code and a second monitoring code.

[0087] Accordingly, the process by which the simulator monitors the functional verification process by calling monitoring code includes: the simulator monitoring the counting state of the program counter of the input / output processor and / or monitoring the interrupt signal state between the input / output processor and the application processor by calling the first monitoring code; and the simulator monitoring the bus signals between the input / output processor and the application processor and / or the peripheral controller by calling the second monitoring code.

[0088] In this embodiment, the first monitoring code and the second monitoring code are clearly distinguished in terms of function. The first monitoring code focuses on the internal state of the input / output processor and the control signal interface between the input / output processor and the application processor, aiming to capture anomalies from the control flow dimension. As a specific implementation, the first monitoring code can be designed as at least one checker module, such as a program counter checker and an interrupt checker. The program counter checker is connected to the program counter output of the second processor core to monitor the transitions of its program counter. The interrupt checker is connected to the interrupt line between the input / output processor and the application processor to monitor the establishment and clearing status of the interrupt request signal between the input / output processor and the application processor.

[0089] The second monitoring code focuses on the communication bus between the input / output processor and other system components, aiming to record the complete data interaction process from the perspective of communication flow. As a specific implementation, the second monitoring code can be designed as at least one monitor module, such as an AXI monitor and / or an APB monitor. The AXI monitor is deployed at the interface between the input / output processor and the on-chip network to listen for and capture AXI bus requests and responses between them. The APB monitor is deployed at the interface between the peripheral controller and the network interconnect module of the input / output processor to listen for and capture APB bus requests and responses between them.

[0090] By dividing the monitoring code into monitoring the internal state of the processor and monitoring the communication interface according to the monitoring object and function, anomalies can be systematically captured from both control flow and communication flow dimensions. This enables the server to locate the problem more quickly and accurately as to whether it is caused by an internal processor anomaly or a data interaction error, thereby ensuring that the firmware hot replacement mechanism can be accurately triggered.

[0091] As mentioned above, the first monitoring code function can be implemented in various ways. In another embodiment, to further achieve proactive and real-time anomaly monitoring, the first monitoring code is further divided into a first sub-monitoring code and a second sub-monitoring code. The first sub-monitoring code can be designed as a program counter checker, and the second sub-monitoring code can be designed as an interrupt checker. The first and second sub-monitoring codes can run independently and in parallel, thereby simultaneously monitoring the counting status of the program counter of the input / output processor and the status of interrupt signals between the input / output processor and the application processor.

[0092] Figure 5 The diagram shows a deployment schematic of the monitoring code according to an embodiment of this application. The input / output processor and peripheral controller are connected to the AP via an on-chip network. An AXI monitor is deployed at the interface between the input / output processor and the on-chip network. An APB monitor is deployed at the interface between the peripheral controller and the network interconnect module of the input / output processor. An interrupt checker is connected to the outermost side of the input / output processor to monitor its interrupt status with the AP. A program counter checker is connected to the second processor core.

[0093] In this embodiment, the simulator monitors the program counter status of the input / output processor by calling a first sub-monitoring code. If an abnormality is detected in the program counter's count status, the simulator terminates the functional verification process and generates a first termination signal. Optionally, the simulator monitors the interrupt signal status between the input / output processor and the application processor by calling a second sub-monitoring code. If an abnormality is detected in the interrupt signal status, the simulator terminates the functional verification process and generates a second termination signal. Both sub-monitoring codes are active monitoring components, and they have preset trigger conditions representing abnormal states. Once the real-time acquired signal status meets the trigger condition, the functional verification process is immediately terminated, a termination signal is generated, and on-site waveform capture can be selectively triggered.

[0094] This design enables the server to receive explicit hardware anomaly events directly and without delay, thereby eliminating the need for post-event analysis of large amounts of raw signal data, accelerating the response process from anomaly occurrence to firmware update decision, and further improving simulation verification efficiency.

[0095] In another embodiment, the simulator monitors the program counter value of the input / output processor by invoking a first sub-monitoring code. If the program counter value remains unchanged for a first set duration, the simulator invokes the timing code in the first sub-monitoring code to start timing. If the timing reaches a second set duration and the program counter value remains unchanged, the simulator determines that the program counter's counting state is abnormal and terminates the functional verification process, generating a first termination signal.

[0096] Those skilled in the art will understand that during code execution, the processor's program counter is continuously updated as instructions flow. When performing operations such as waiting for interrupt instructions, the program counter may briefly remain at the same address, but this is a normal waiting state. To filter out such normal pauses, this embodiment introduces a two-level timeout mechanism. The first set duration is used to filter out very short pauses caused by normal execution flow. Only when the program counter remains stationary for longer than the first set duration does the system consider that an unexpected stop may have occurred and initiate a second-level precise timing. If the program counter remains unchanged within the additional second set duration, it can be highly certain that the processor has entered an infinite loop or has stopped fetching instructions, i.e., an abnormal counting state has occurred.

[0097] By introducing a two-level timeout mechanism, short pauses during normal processor execution are not mistakenly identified as fatal errors. An exception report is only triggered after the halted state persists for more than a preset threshold, thus ensuring the accuracy of program counter anomaly detection, effectively filtering out invalid exception reports, and ensuring that firmware hot-swap is only triggered when truly needed. Those skilled in the art can adjust the specific values ​​of the first and second preset durations according to the specific processor's operating frequency and code characteristics.

[0098] To effectively identify interruption suspension anomalies, in another embodiment of this application, the simulator, upon detecting a valid interrupt signal between the input / output processor and the application processor by calling the second sub-monitoring code, calls the timing code within the second sub-monitoring code to start timing. If the timing reaches a third preset duration, and the interrupt signal remains valid throughout the timing process, the simulator determines that the interrupt signal state between the input / output processor and the application processor is abnormal, terminates the functional verification process, and generates a second termination signal.

[0099] In this embodiment, an interrupt signal being valid refers to a level or edge state where the interrupt request has been established and maintained by the initiator. In a normal communication process, after the interrupt request signal is set to valid, the receiving processor responds to and processes the interrupt, and then clears the interrupt signal after processing. Therefore, the duration of a valid interrupt signal is finite. If the duration of the valid interrupt signal significantly exceeds the normal processing time, it indicates that an interrupt has been suspended, meaning that the request has been made but has not been properly responded to by the other processor.

[0100] By monitoring the duration of the interruption signal, this solution can accurately identify this hangup state, thereby automatically and quickly discovering handshake failures at the communication protocol level. This avoids the inefficient method of only being able to reverse-engineer the root cause of the problem by checking for errors in the final data result, thus improving the speed of problem localization.

[0101] In order to effectively trace the problem scene after the firmware causes a communication failure, another embodiment of this application discloses that: the emulator samples the bus signal between the input / output processor and the application processor, and / or the bus signal between the input / output processor and the peripheral controller by calling the second monitoring code, and generates bus monitoring data based on the sampled signal data.

[0102] As a specific implementation method, the second monitoring code (e.g.) Figure 5 The AXI monitor and APB monitor shown continuously listen to the bus signal lines. When a valid transaction occurs on the bus (such as a read request, write request, and its corresponding response), the monitor captures all fields of information during the transaction, including address, data, burst length, transaction identifier, and completion status. This sampled information is encapsulated into structured records, which are eventually compiled into a complete and ordered bus monitoring data or log file and sent to the server.

[0103] By continuously sampling and recording bus signals, bus monitoring data is generated for post-event analysis, providing the server with a complete and detailed communication log. When the system reports an error due to a communication failure, the server can analyze this data to reconstruct the data interaction process before the error, thus quickly distinguishing whether the problem stems from a hardware design flaw or a firmware logic error.

[0104] Based on the monitoring of the functional verification process implemented by the monitoring code in the simulator as described in the above embodiments, the simulator sends termination signals and / or bus monitoring data to the server. The server receives the termination signals and / or bus monitoring data and performs path-specific processing.

[0105] For the first termination signal and / or the second termination signal that can directly characterize the abnormal hardware state, after the simulator sends them to the server, the server can determine whether the verification termination is caused by a hardware problem or a software problem by combining the on-site waveform of the simulator's termination operation. If it is caused by a software problem, it can be determined that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process.

[0106] For bus monitoring data that requires analysis in conjunction with the overall system operation status, the emulator sends it to the server. Only upon receiving simulation error data from the emulator (such as call stack errors or timeout alarms printed by the operating system kernel due to peripheral unresponsiveness) does the server perform correlation analysis with the previously received bus monitoring data to determine the first firmware code anomaly. For example, the server can trace back the bus monitoring data before and after the time point of the simulation error to check for incomplete transactions or erroneous data verification, thereby pinpointing whether the root cause of the error is a firmware defect.

[0107] By distinguishing between termination signals and bus monitoring data, precise responses to anomalies are achieved. A high-speed, direct-trigger processing path is used for termination signals, ensuring timely firmware hot-swapping. Communication log data is combined with simulation error events to identify the root cause of problems during testing, avoiding repeated error correction.

[0108] To ensure that the new firmware code can accurately replace the old firmware code and be correctly executed by the processor, another embodiment of this application discloses that: before the server imports the second firmware code into the target storage area of ​​the emulator, the server arranges the data of the second firmware code according to the arrangement of the first firmware code in the target storage area, so that the data arrangement of the second firmware code is consistent with the arrangement of the first firmware code in the target storage area.

[0109] In the emulator's memory model, firmware code is not always stored in a linear, contiguous manner. The arrangement of its internal data may be related to the organization of code segments, data segments, stack segments, and the byte order and alignment within each segment. The first firmware code already occupies a specific, initialized, and linked complete image in the target storage area. If an unprocessed second firmware code, arranged according to the original logical addresses of the file, is directly written into this area, it may result in address misalignment or incomplete overwriting.

[0110] The arrangement of the firmware code in the target storage area can refer to the byte order of the data in big-endian or little-endian order, the padding alignment boundaries between specific data blocks, or the segmentation mapping relationship between code segments and data segments in the address space. The server can rearrange the binary file of the new firmware code according to the design and software manual to ensure that the data layout structure is completely consistent before and after writing.

[0111] By pre-arranging the new firmware code on the server side to make its layout structure completely consistent with that of the original firmware in the storage space, the correctness and atomicity of the memory content replacement operation are guaranteed. This ensures that the input / output processor can retrieve the correct instructions and data from the correct location after initialization, thereby guaranteeing the success rate of firmware hot replacement operation and avoiding unknown verification errors caused by incompatible data storage formats.

[0112] In another embodiment, due to the limited space of the second memory inside the I / O processor, it may not be able to completely store the firmware code of the I / O processor. In this case, the firmware code of the I / O processor is split and stored in both the SRAM inside the I / O processor and the DDR outside the I / O processor. Accordingly, the target storage area in the emulator used to store the I / O processor is also divided into a first target storage area and a second target storage area. For example, the first target storage area may be the address space corresponding to the SRAM inside the I / O processor, and the second target storage area may be the address space corresponding to the DDR outside the I / O processor. Accordingly, the first firmware code is also divided into a first sub-firmware code stored in the first target storage area and a second sub-firmware code stored in the second target storage area.

[0113] In this architecture, the server divides and arranges the acquired second firmware code according to a first arrangement of the first sub-firmware code in the first target storage area and a second arrangement of the second sub-firmware code in the second target storage area, thereby splitting the second firmware code into a third sub-firmware code and a fourth sub-firmware code. The data arrangement of the third sub-firmware code is consistent with the first arrangement, and the data arrangement of the fourth sub-firmware code is consistent with the second arrangement.

[0114] During the firmware import phase, the server imports the third sub-firmware code, arranged in a first arrangement, into the first target storage area, and imports the fourth sub-firmware code, arranged in a second arrangement, into the second target storage area. This process can be completed in one go or in stages.

[0115] By physically partitioning the new firmware code and matching and reorganizing it with the dispersed target storage areas, it ensures that firmware components located in different physical storage can be updated correctly. This solves the problem of incomplete updates or address conflicts caused by dispersed firmware storage, making the firmware hot-swap mechanism applicable to multiprocessor systems with complex storage architectures, and ensuring that the system can start and run normally after the update.

[0116] In order to enable the server to easily and reliably control the emulator to complete the initialization or reset operation after firmware update, another embodiment of this application discloses: the server controls the emulator to perform initialization or reset operation on the pre-silicon chip design code of the microprocessor architecture, specifically: the server sends a preset instruction to the emulator so that the emulator completes the initialization or reset operation by executing the preset instruction.

[0117] In this embodiment, the preset instruction is obtained by integrating and encapsulating a series of initialization or reset instructions supported by the emulator's underlying layer. In related technologies, a complete reset and reinitialization of the input / output processor may involve multiple independent steps, such as releasing the reset signal, reconfiguring the shared memory space size, setting the program counter start address, and re-enabling interrupts, requiring the server to send multiple instructions sequentially. In this embodiment, these complex, multi-step instruction sequences are pre-written and encapsulated into a high-level command or script. The server only needs to send one encapsulated preset instruction to trigger the emulator to automatically execute all underlying operations sequentially.

[0118] By encapsulating the complex sequence of low-level instructions into a single high-level command, the control logic and script complexity on the server side are simplified, reducing the likelihood of operational errors. This makes the firmware update process more automated and reliable; the server only needs to send a single high-level encapsulated command to ensure that the reset and initialization operations within the emulator are executed correctly and completely.

[0119] Based on the simulation verification system and simulation verification method described in the above embodiments, another embodiment of this application provides a simulation verification method executed by a simulator in the simulation verification system described in the above embodiments, the method comprising: The simulator performs a functional verification process on the front-end chip design code of the microprocessor architecture by calling the verification logic code, and monitors the functional verification process by calling the monitoring code; the functional verification process includes triggering the first firmware code to verify the correctness of the execution instruction sequence between the application processor, the input / output processor and the peripheral controller; The simulator sends the obtained monitoring data to the server, so that the server can verify the functionality of the pre-silicon chip design code of the microprocessor architecture based on the monitoring data.

[0120] In some embodiments, the monitoring code includes a first monitoring code and a second monitoring code; The simulator monitors the functional verification process by calling the monitoring code, including: The simulator monitors the program counter status of the input / output processor by calling the first monitoring code, and / or monitors the interrupt signal status between the input / output processor and the application processor; The simulator monitors the bus signals between the input / output processor and the application processor and / or the peripheral controller by calling the second monitoring code.

[0121] In some embodiments, the first monitoring code includes a first sub-monitoring code and a second sub-monitoring code; The simulator monitors the counting status of the input / output processor by calling the first monitoring code, and / or monitors the interrupt signal status between the input / output processor and the application processor, including: The simulator monitors the counting status of the program counter of the input / output processor by calling the first sub-monitoring code, and terminates the functional verification process and generates a first termination signal when it detects that the counting status of the program counter is abnormal. And / or, The simulator monitors the interrupt signal status between the input / output processor and the application processor by calling the second sub-monitoring code, and terminates the functional verification process and generates a second termination signal when it detects an abnormal interrupt signal status between the input / output processor and the application processor.

[0122] In some embodiments, the simulator monitors the counting state of the input / output processor's program counter by calling the first sub-monitoring code, and terminates the functional verification process and generates a first termination signal if an abnormal counting state of the program counter is detected, including: The simulator monitors the program counter value of the input / output processor by calling the first sub-monitoring code; If the program counter value remains unchanged within a first set time period, the simulator calls the timing code in the first sub-monitoring code to start timing. If the timing reaches the second set duration and the program counter value does not change, the simulator determines that the program counter's counting state is abnormal, terminates the function verification process, and generates a first termination signal.

[0123] In some embodiments, the simulator monitors the interrupt signal status between the input / output processor and the application processor by calling the second sub-monitoring code, and terminates the functional verification process and generates a second termination signal when an abnormal interrupt signal status is detected between the input / output processor and the application processor, including: When the simulator detects that the interrupt signal between the input / output processor and the application processor is valid by calling the second sub-monitoring code, it calls the timing code in the second sub-monitoring code to start timing. If the timing reaches the third set duration and the interrupt signal between the input / output processor and the application processor remains valid throughout the timing process, the simulator determines that the interrupt signal state between the input / output processor and the application processor is abnormal, terminates the functional verification process, and generates a second termination signal.

[0124] In some embodiments, the emulator monitors bus signals between the input / output processor and the application processor and / or the peripheral controller by invoking the second monitoring code, including: The simulator samples the bus signals between the input / output processor and the application processor, and / or between the input / output processor and the peripheral controller by calling the second monitoring code, and generates bus monitoring data based on the sampled signal data.

[0125] In some embodiments, the simulator sends the obtained monitoring data to the server, enabling the server to verify the functionality of the pre-silicon chip design code of the microprocessor architecture based on the monitoring data, including: The simulator sends the first termination signal and / or the second termination signal to the server so that the server determines, based on the first termination signal and / or the second termination signal, that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process. And / or, The emulator sends bus monitoring data to the server, so that when the server receives simulation error data sent by the emulator, it can determine, based on the bus monitoring data, that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process; wherein, the bus monitoring data is obtained by the emulator by calling the second monitoring code to monitor the bus signals between the input / output processor and the application processor and / or the peripheral controller.

[0126] In the simulation verification method executed by a simulator provided in this application embodiment, the simulator performs a functional verification process on the front-end silicon design code of the microprocessor architecture by calling verification logic code. During the verification process, monitoring code is also called to monitor the functional verification process and send the monitoring data to the server. The server can directly verify the function of the front-end silicon design code of the microprocessor architecture based on the monitoring data. The above solution monitors the simulation verification process through separate code during the functional verification of the front-end silicon design code of the microprocessor architecture. This allows the server to directly verify the function of the front-end silicon design code of the microprocessor architecture through monitoring data, and enables the server to determine the correctness of the function of the front-end silicon design code of the microprocessor architecture in real time based on the monitoring data during the simulator's simulation verification process. Compared to the prior art, which requires analyzing simulation software logs after completing simulation verification to discover errors or anomalies, the simulation verification method provided in this application is more efficient.

[0127] In the simulation verification method executed by the simulator described above, the specific processing content and beneficial effects of each processing step of the simulator can be found in the description of the corresponding processing steps in the embodiment of the simulation verification method implemented by the interaction between the simulator and the server, and will not be repeated here.

[0128] In another embodiment of this application, a simulation verification method executed by a server in the simulation verification system described in the above embodiments is also provided, the method comprising: If the server determines that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process, it generates or obtains the second firmware code. The server imports the second firmware code into the target storage area of ​​the emulator, the target storage area being used to store the firmware code of the input / output processor; The server controls the simulator to initialize or reset the front-end chip design code of the microprocessor architecture, so that the simulator can continue to perform functional verification of the front-end chip design code of the microprocessor architecture based on the second firmware code.

[0129] In some embodiments, before the server imports the second firmware code into the target storage area of ​​the emulator, the method further includes: The server arranges the second firmware code according to the arrangement of the first firmware code in the target storage area, so that the arrangement of the second firmware code is consistent with the arrangement of the first firmware code in the target storage area.

[0130] In some embodiments, the target storage area includes a first target storage area and a second target storage area, and the first firmware code includes a first sub-firmware code stored in the first target storage area and a second sub-firmware code stored in the second target storage area; The server arranges the second firmware code according to the arrangement of the first firmware code in the target storage area, so that the data arrangement of the second firmware code is consistent with the arrangement of the first firmware code in the target storage area, including: The server divides and arranges the second firmware code according to the first arrangement of the first sub-firmware code in the first target storage area and the second arrangement of the second sub-firmware code in the second target storage area, so as to divide the second firmware code into a third sub-firmware code and a fourth sub-firmware code, and makes the data arrangement of the third sub-firmware code consistent with the first arrangement, and makes the data arrangement of the fourth sub-firmware code consistent with the second arrangement. The server imports the second firmware code into the target storage area of ​​the emulator, including: The server imports the third sub-firmware code arranged in the first arrangement into the first target storage area, and imports the fourth sub-firmware code arranged in the second arrangement into the second target storage area.

[0131] In some embodiments, the server controls the simulator to perform initialization or reset operations on the pre-silicon chip design code of the microprocessor architecture, including: The server sends a preset instruction to the emulator, so that the emulator performs initialization or reset operations on the front-end silicon design code of the microprocessor architecture by executing the preset instruction. The preset instructions are obtained by integrating and encapsulating the initialization or reset instructions supported by the simulator.

[0132] In some embodiments, the simulator also runs monitoring code, and the method further includes: The server receives monitoring data sent by the simulator; The monitoring data is obtained by the simulator through calling the monitoring code to monitor the functional verification process.

[0133] In some embodiments, the monitoring code includes a first monitoring code and a second monitoring code; The server receives monitoring data sent by the simulator, including: The server receives the termination signal and / or bus monitoring data sent by the emulator; The termination signal is generated by the emulator when it detects an abnormal count state of the program counter of the input / output processor by calling the first monitoring code, and / or detects an abnormal interrupt signal state between the input / output processor and the application processor. The bus monitoring data is obtained by the emulator monitoring the bus signals between the input / output processor and the application processor and / or the peripheral controller by calling the second monitoring code.

[0134] In some embodiments, the method further includes: When the server receives a termination signal sent by the simulator, it determines based on the termination signal that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process. And / or, Upon receiving simulation error data from the emulator, the server determines, based on bus monitoring data sent by the emulator, that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process.

[0135] In the server-executed simulation verification method provided in this application embodiment, the server controls the functional verification process of the simulator. When the server determines that the first firmware code in the input / output processor cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current verification task, it directly imports the second firmware code into the target storage area of ​​the simulator used to store the firmware code of the input / output processor. Then, the server controls the simulator to initialize or reset the pre-silicon chip design code of the microprocessor architecture, so that the simulator continues to perform functional verification of the pre-silicon chip design code of the microprocessor architecture based on the second firmware code. In the above method, during the functional verification of the pre-silicon chip design code of the microprocessor architecture by the simulator, the server directly imports the input / output processor firmware code and controls the simulator's initialization or reset without restarting the simulator. This allows for hot replacement of the input / output processor firmware code when an anomaly is detected, without needing to restart the simulator system, thereby improving the efficiency of microprocessor simulation verification.

[0136] In the above-described simulation verification method executed by the server, the specific processing content and beneficial effects of each processing step of the server can be found in the description of the corresponding processing steps in the above-described embodiment of the simulation verification method implemented by the interaction between the simulator and the server, and will not be repeated here.

[0137] Furthermore, another embodiment of this application provides a simulator that can be applied to, for example... Figure 3 The simulation verification system shown also includes a server. The simulator runs front-end silicon design code, verification logic code, and monitoring code based on a microprocessor architecture. This microprocessor architecture includes an application processor, an input / output processor, and at least one peripheral controller. The input / output processor contains the first firmware code.

[0138] This simulator performs functional verification on the pre-silicon chip design code of the microprocessor architecture by calling verification logic code, and monitors the functional verification process by calling monitoring code. The functional verification process includes triggering the first firmware code to verify the correctness of the instruction sequence executed between the application processor, input / output processor, and peripheral controller.

[0139] The simulator sends the obtained monitoring data to the server, so that the server can verify the functionality of the pre-silicon chip design code of the microprocessor architecture based on the monitoring data.

[0140] Specifically, the specific functions of the simulator, the specific processing procedures of each processing step it performs, and the beneficial effects achieved through these processing procedures can be found in the description of the corresponding processing steps performed by the simulator in the above-mentioned embodiment of the simulation verification method implemented by the interaction between the simulator and the server, which will not be repeated here.

[0141] In another embodiment, the simulator includes a processor and a memory. The memory stores program instructions and / or data, and the processor invokes the program instructions stored in the memory to execute any of the simulation verification methods performed by the simulator as described in the foregoing embodiments, or to execute the processing steps performed by the simulator in any of the embodiments of the simulation verification methods implemented by the simulator and the server through interaction.

[0142] Another embodiment of this application also provides a server that can be applied to, for example... Figure 3 The simulation verification system shown includes a simulator. The simulator runs front-end silicon design code for a microprocessor architecture and verification logic code to perform functional verification on the front-end silicon design code by calling the verification logic code. The microprocessor architecture includes an application processor, an input / output processor, and at least one peripheral controller. The input / output processor contains first firmware code. The functional verification process includes triggering the first firmware code to verify the correctness of the instruction sequence executed between the application processor, the input / output processor, and the peripheral controller. If the server determines that the first firmware code cannot correctly execute the current functional verification process of the front-end silicon design code of the microprocessor architecture, it generates or obtains second firmware code. The server imports the second firmware code into the simulator's target storage area, which stores the firmware code of the input / output processor. The server controls the simulator to initialize or reset the front-end silicon design code of the microprocessor architecture, so that the simulator continues to perform functional verification on the front-end silicon design code of the microprocessor architecture based on the second firmware code.

[0143] Specifically, the specific functions of the server, the specific processing procedures of each processing step it performs, and the beneficial effects achieved through these processing procedures can be found in the description of the corresponding processing steps performed by the server in the above-mentioned embodiment of the simulation verification method implemented by the interaction between the simulator and the server, which will not be repeated here.

[0144] In another embodiment, the server includes a processor and a memory. The memory stores program instructions and / or data, and the processor invokes the program instructions stored in the memory to execute any of the simulation verification methods performed by the server as described in the foregoing embodiments, or to execute any of the processing steps performed by the server in any of the embodiments of the simulation verification methods implemented by the interaction between the simulator and the server.

[0145] In the above embodiments of this application, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, GPU, or DSP. In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, or DPU.

[0146] In addition to the methods, simulators, and servers described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the simulation verification methods described in any of the above embodiments of this specification.

[0147] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0148] Furthermore, embodiments of this application may also be storage media storing a computer program, which, when run by a processor, causes the processor to execute the steps of the simulation verification method described in any of the above embodiments of this specification.

[0149] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0150] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0151] The steps in the methods of the various embodiments of this application can be adjusted, merged, or deleted in order according to actual needs, and the technical features described in each embodiment can be replaced or combined.

[0152] The modules and sub-modules in the various embodiments of the present application's devices and terminals can be merged, divided, and deleted according to actual needs.

[0153] It should be understood that the disclosed terminals, devices, and methods can be implemented in other ways, given the several embodiments provided in this application. For example, the terminal embodiments described above are merely illustrative. For instance, the division of modules or sub-modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple sub-modules or modules may be combined or integrated into another module, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0154] The modules or submodules described as separate components may or may not be physically separate. The components that constitute a module or submodule may or may not be physical modules or submodules; that is, they may be located in one place or distributed across multiple network modules or submodules. Some or all of the modules or submodules can be selected to achieve the purpose of this embodiment's solution, depending on actual needs.

[0155] Furthermore, the functional modules or sub-modules in the various embodiments of this application can be integrated into one processing module, or each module or sub-module can exist physically separately, or two or more modules or sub-modules can be integrated into one module. The integrated modules or sub-modules described above can be implemented in hardware or in the form of software functional modules or sub-modules.

[0156] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

[0159] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A simulation verification method, characterized in that, The system is applied to a simulation verification system, which includes a simulator and a server. The simulator runs front-end silicon design code, verification logic code, and monitoring code based on a microprocessor architecture. The microprocessor architecture includes an application processor, an input / output processor, and at least one peripheral controller. The input / output processor contains first firmware code. The method includes: The simulator performs a functional verification process on the front-end chip design code of the microprocessor architecture by calling the verification logic code, and monitors the functional verification process by calling the monitoring code; the functional verification process includes triggering the first firmware code to verify the correctness of the execution instruction sequence between the application processor, the input / output processor and the peripheral controller; The simulator sends the obtained monitoring data to the server, so that the server can verify the functionality of the pre-silicon chip design code of the microprocessor architecture based on the monitoring data.

2. The method according to claim 1, characterized in that, The monitoring code includes a first monitoring code and a second monitoring code; The simulator monitors the functional verification process by calling the monitoring code, including: The simulator monitors the program counter status of the input / output processor by calling the first monitoring code, and / or monitors the interrupt signal status between the input / output processor and the application processor; The simulator monitors the bus signals between the input / output processor and the application processor and / or the peripheral controller by calling the second monitoring code.

3. The method according to claim 2, characterized in that, The first monitoring code includes a first sub-monitoring code and a second sub-monitoring code; The simulator monitors the counting status of the input / output processor by calling the first monitoring code, and / or monitors the interrupt signal status between the input / output processor and the application processor, including: The simulator monitors the counting status of the program counter of the input / output processor by calling the first sub-monitoring code, and terminates the functional verification process and generates a first termination signal when it detects that the counting status of the program counter is abnormal. And / or, The simulator monitors the interrupt signal status between the input / output processor and the application processor by calling the second sub-monitoring code, and terminates the functional verification process and generates a second termination signal when it detects an abnormal interrupt signal status between the input / output processor and the application processor.

4. The method according to claim 3, characterized in that, The simulator monitors the program counter status of the input / output processor by calling the first sub-monitoring code, and terminates the functional verification process and generates a first termination signal when an abnormal program counter status is detected, including: The simulator monitors the program counter value of the input / output processor by calling the first sub-monitoring code; If the program counter value remains unchanged within a first set time period, the simulator calls the timing code in the first sub-monitoring code to start timing. If the timing reaches the second set duration and the program counter value does not change, the simulator determines that the program counter's counting state is abnormal, terminates the function verification process, and generates a first termination signal.

5. The method according to claim 3, characterized in that, The simulator monitors the interrupt signal status between the input / output processor and the application processor by calling the second sub-monitoring code. If an abnormal interrupt signal status is detected between the input / output processor and the application processor, the simulator terminates the functional verification process and generates a second termination signal, including: When the simulator detects that the interrupt signal between the input / output processor and the application processor is valid by calling the second sub-monitoring code, it calls the timing code in the second sub-monitoring code to start timing. If the timing reaches the third set duration and the interrupt signal between the input / output processor and the application processor remains valid throughout the timing process, the simulator determines that the interrupt signal state between the input / output processor and the application processor is abnormal, terminates the functional verification process, and generates a second termination signal.

6. The method according to claim 2, characterized in that, The emulator monitors the bus signals between the input / output processor and the application processor and / or the peripheral controller by calling the second monitoring code, including: The simulator samples the bus signals between the input / output processor and the application processor, and / or between the input / output processor and the peripheral controller by calling the second monitoring code, and generates bus monitoring data based on the sampled signal data.

7. The method according to claim 3, characterized in that, The simulator sends the obtained monitoring data to the server, enabling the server to verify the functionality of the pre-silicon chip design code of the microprocessor architecture based on the monitoring data, including: The simulator sends the first termination signal and / or the second termination signal to the server so that the server determines, based on the first termination signal and / or the second termination signal, that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process. And / or, The emulator sends bus monitoring data to the server, so that when the server receives simulation error data sent by the emulator, it can determine, based on the bus monitoring data, that the first firmware code cannot enable the pre-silicon chip design code of the microprocessor architecture to correctly execute the current functional verification process; wherein, the bus monitoring data is obtained by the emulator by calling the second monitoring code to monitor the bus signals between the input / output processor and the application processor and / or the peripheral controller.

8. A simulator, characterized in that, The simulation verification system further includes a server, in which front-end silicon chip design code, verification logic code, and monitoring code based on a microprocessor architecture are run. The microprocessor architecture includes an application processor, an input / output processor, and at least one peripheral controller. The input / output processor contains first firmware code. The simulator performs a functional verification process on the front-end chip design code of the microprocessor architecture by calling the verification logic code, and monitors the functional verification process by calling the monitoring code; the functional verification process includes triggering the first firmware code to verify the correctness of the execution instruction sequence between the application processor, the input / output processor and the peripheral controller; The simulator sends the obtained monitoring data to the server, so that the server can verify the functionality of the pre-silicon chip design code of the microprocessor architecture based on the monitoring data.

9. A simulator, characterized in that, It includes a processor and a memory, the memory being used to store program instructions and / or data, and the processor being used to invoke the program instructions stored in the memory to execute the simulation verification method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the simulation verification method as described in any one of claims 1-7.

Images