Control method, apparatus, device, medium and product for processor simulation

Abstract

The present disclosure provides a control method, device and related equipment for processor simulation, the method comprising: collecting a first monitoring signal according to a first sampling interval to obtain a plurality of first signal data corresponding to the first monitoring signal; wherein the first monitoring signal is used to represent the simulation progress; in the case of determining that the simulation progress is abnormal according to the first comparison result between the plurality of first signal data, collecting a second monitoring signal according to a second sampling interval to obtain a plurality of second signal data corresponding to the second monitoring signal; wherein the second monitoring signal is used to represent the processor running state; and controlling the processor simulation process according to the second comparison result between the plurality of second signal data. This method detects in two steps, which can ensure that system resources are concentrated for analyzing the period and signal that are more likely to have problems, without being evenly consumed in the entire simulation process, thereby improving the detection efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a control method, apparatus, device, medium and product for processor emulation. Background Technology

[0002] Processor simulation technology is a crucial step in the processor development process for verifying the correctness of the design. By simulating the processor model using a simulator, designers can evaluate the processor's functionality and performance, thereby effectively reducing development costs and risks.

[0003] In related technologies, processor simulation verification methods often rely on global analysis after the simulation is completed, or on engineers manually setting breakpoints and performing single-step tracing. However, these methods struggle to capture anomalies that occur during simulation in real time and automatically. Furthermore, to achieve comprehensive monitoring during simulation, massive amounts of signal data may need to be collected, severely slowing down the simulation and generating huge datasets that are difficult to analyze. Summary of the Invention

[0004] This disclosure provides a control method, apparatus, device, medium, and product for processor emulation.

[0005] In a first aspect, this disclosure provides a control method for processor emulation, the method being executed during processor emulation, and the method comprising:

[0006] During processor simulation, a first monitoring signal is acquired at a first sampling interval to obtain multiple first signal data corresponding to the first monitoring signal; wherein, the first monitoring signal is used to characterize the simulation progress.

[0007] If an abnormality in simulation progress is determined based on a first comparison result among the plurality of first signal data, a second monitoring signal is acquired according to a second sampling interval to obtain a plurality of second signal data corresponding to the second monitoring signal; wherein, the second monitoring signal is used to characterize the processor's operating status;

[0008] The processor simulation process is controlled based on the second comparison result between the plurality of second signal data.

[0009] Secondly, this disclosure provides a control device for processor emulation, the device being suitable for the processor emulation process, the device comprising:

[0010] The first monitoring module is adapted to collect a first monitoring signal according to a first sampling interval to obtain multiple first signal data corresponding to the first monitoring signal; wherein, the first monitoring signal is used to characterize the simulation progress;

[0011] The second monitoring module is adapted to, when determining an abnormality in simulation progress based on a first comparison result among the plurality of first signal data, acquire a second monitoring signal at a second sampling interval to obtain a plurality of second signal data corresponding to the second monitoring signal; wherein, the second monitoring signal is used to characterize the processor's operating status;

[0012] The simulation control module is adapted to control the processor simulation process based on a second comparison result among the plurality of second signal data.

[0013] Thirdly, this disclosure provides an electronic device, including:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The processor is configured to execute the above-described method.

[0017] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described method.

[0018] Fifthly, this disclosure provides a computer program product comprising computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the method described above.

[0019] In the embodiments provided in this disclosure, firstly, a first monitoring signal characterizing the simulation progress is acquired at a first sampling interval. This type of signal mainly characterizes the simulation progress and does not involve specific state information. Therefore, the data volume of this type of signal is usually small, which can effectively reflect whether the simulation is ongoing. Thus, during most normal simulation periods, only a small amount of data needs to be monitored, fundamentally avoiding the huge overhead caused by continuously acquiring massive amounts of internal state signals in traditional solutions, and improving overall verification efficiency. Secondly, if an abnormal simulation progress is determined based on the first monitoring signal, a second round of acquisition is initiated to obtain a second monitoring signal characterizing the processor's operating state. By performing detection in two steps, it is ensured that system resources (computing, storage, I / O) can be concentrated on analyzing periods and signals more likely to cause problems, rather than being evenly consumed throughout the entire simulation process. This approach not only avoids the accumulation of invalid data but also allows subsequent anomaly analysis to focus on critical periods, thereby enabling rapid and accurate identification of the root cause of the progress anomaly. The above two-step monitoring process can be executed automatically during the simulation without waiting for the simulation to end or requiring manual intervention. This changes the traditional lagging mode that relies on post-analysis or manual breakpoint debugging, and realizes real-time, automatic detection, diagnosis and handling of anomalies during simulation, which greatly improves the automation level and response speed of verification.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0021] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0022] Figure 1 A flowchart of a control method for processor emulation provided in this disclosure embodiment;

[0023] Figure 2 A system schematic diagram of a processor simulation system in one example of this disclosure is shown;

[0024] Figure 3 A schematic diagram of the input / output interface of the global control module is shown;

[0025] Figure 4 A schematic diagram of the processor simulation environment is shown.

[0026] Figure 5 A schematic diagram of the file structure of the error detection framework is shown;

[0027] Figure 6 A flowchart illustrating the typical runtime process of an error framework is shown.

[0028] Figure 7 A structural diagram of a control device for processor emulation provided in this disclosure embodiment;

[0029] Figure 8 A block diagram of an electronic device is provided in this disclosure. Detailed Implementation

[0030] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0031] Unless otherwise specified, the various embodiments and features of this disclosure may be combined with each other. As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries.

[0032] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0033] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0034] Figure 1This is a flowchart illustrating a control method for processor emulation, provided as an embodiment of the present disclosure. The method is executed during processor emulation. (Refer to...) Figure 1 The method includes:

[0035] Step S110: Collect the first monitoring signal according to the first sampling interval to obtain multiple first signal data corresponding to the first monitoring signal; wherein, the first monitoring signal is used to characterize the simulation progress.

[0036] Processor simulation refers to the process of functionally simulating a processor design model using a software simulator or hardware simulation platform. Its purpose is to verify the correctness of the processor design, typically without the involvement of the actual physical chip. The first sampling interval refers to the time period unit for acquiring the first monitoring signal, such as simulation time (e.g., microseconds) or processor clock cycles (e.g., 1000 cycles). The setting of the first sampling interval needs to balance monitoring real-time performance and performance overhead: too short an interval will increase the simulation load, while too long an interval may miss transient anomalies. The first monitoring signal refers to the set of signals used to directly or indirectly reflect the simulation progress; its core function is to characterize whether the simulation is active. The first monitoring signal includes, but is not limited to, various types such as the program counter signal, simulation time signal, and pipeline stage valid bit signal. The pipeline stage valid bit signal is a control signal used to indicate whether the data or instructions processed in the current pipeline stage are valid. Additionally, the first monitoring signal can also be a user-defined signal dynamically loaded through a configuration file.

[0037] Simulation progress refers to the advancement status of the processor simulation process. Abnormal simulation progress typically manifests as simulation time stagnation, program counter stalling, or continuous pipeline idleness. The first signal data can be a numerical sequence of the first monitoring signal at consecutive sampling points, such as the set of address values ​​of the program counter signal at multiple intervals. The first sampling interval can be a fixed interval or a dynamic interval. For example, the first sampling interval can be dynamically adjusted based on the simulation load and / or historical error rate.

[0038] Step S120: If the simulation progress is determined to be abnormal based on the first comparison result between multiple first signal data, a second monitoring signal is collected according to the second sampling interval to obtain multiple second signal data corresponding to the second monitoring signal; wherein, the second monitoring signal is used to characterize the processor's operating status.

[0039] Anomalies in simulation progress refer to situations where the processor simulation process deviates from the expected normal progression. Specific manifestations include, but are not limited to: the simulation timestamp remaining stagnant at multiple consecutive sampling points, the program counter remaining unchanged for multiple consecutive cycles, and a persistently zero pipeline commit rate, all indicating that the computation process has stalled or is looping. The pipeline commit rate refers to the number of instructions successfully completed and committed by the instruction submission unit in the processor microarchitecture per unit time (or per simulation cycle). It reflects the throughput rate of the processor core's actual effective work. When the pipeline commit rate is consistently zero, it indicates that the processor core has stopped completing effective instructions. From the perspective of program execution, this confirms that the computation process has stalled, thus constituting a form of anomalies in simulation progress.

[0040] For example, when determining an abnormal simulation progress based on the first comparison result between multiple first signal data, it can be achieved in the following way: sequentially compare the signal data sequence obtained by continuous sampling (such as multiple program counter values ​​or simulation timestamps): focus on checking whether the data of adjacent sampling points have changed. If the program counter values ​​of N consecutive sampling points (N≥2, configurable) are exactly the same, or the difference in simulation timestamps is less than a very small threshold, it indicates that the simulation progress is abnormal.

[0041] The second sampling interval refers to the time interval or period unit used to acquire the second monitoring signal after the depth detection in step S120 is triggered. This second sampling interval is typically smaller than the first sampling interval to achieve higher frequency signal sampling, thereby capturing more subtle state changes. The specific value of the second sampling interval can be dynamically set according to the required diagnostic accuracy and simulation load. For example, it can be set to a fixed value much smaller than the first sampling interval (e.g., 1 microsecond), or it can be dynamically adjusted based on the anomaly type and degree detected in historical data. In other words, the method in this disclosure can also achieve adaptive optimization of the monitoring strategy by learning from historical data.

[0042] The second monitoring signal refers to the signal collected during the deep inspection phase, used to reflect the detailed internal operating status of the processor. Unlike the first monitoring signal, which focuses on progress, the second monitoring signal focuses on status, aiming to reveal the internal causes of progress anomalies. For example, the second monitoring signal may include handshake signals between internal modules of the processor, interrupt request and response signals, control signals of each stage of the pipeline, the current state code of the critical state machine, and the contents of specific memory addresses or registers.

[0043] The processor's operating state characterizes the dynamic configuration, interaction, and behavior of its internal functional units (such as pipelines, cache controllers, and bus interfaces) at specific moments during simulation. It aims to reflect the processor's health and activity level during instruction execution, serving as a basis for locating functional errors. Therefore, the processor's operating state can be considered a collection of dynamic, real-time behaviors and conditions of the target processor's internal hardware logic units during simulation.

[0044] Multiple second signal data can be numerical sequences collected from multiple consecutive second sampling intervals of the second monitoring signal. These data are arranged in chronological order to form a signal snapshot sequence that can be used to analyze the trend of state evolution.

[0045] The first sampling interval can be greater than the second sampling interval; and the second monitoring signal can have more signal types than the first monitoring signal.

[0046] Step S130: Control the processor simulation process based on the second comparison result between multiple second signal data.

[0047] The second comparison result refers to the quantitative or qualitative conclusion drawn after comparing and analyzing multiple consecutive second signal data. Its core is to determine the changes in the second monitoring signal over a period of time. For example, it determines whether a specific handshake signal, program counter, or state machine code remains unchanged across multiple consecutive snapshots, or whether the change pattern deviates from the expected pattern. To control the processor's simulation process, based on the second comparison result, a set of instructions capable of changing its operating state can be triggered to the simulator (such as a software simulator or hardware simulation platform) to terminate the abnormal state and save the debugging context, providing a basis for subsequent analysis.

[0048] In practice, a legal range of change or a threshold for the number of times the second monitoring signal remains unchanged can be predefined, and the anomaly of the second comparison result can be determined based on the legal range of change or the threshold for the number of times the signal remains unchanged. Alternatively, a behavioral model (such as rate of change or correlation) of the second monitoring signal during normal simulation can be established, and an anomaly can be determined when the actual signal sequence deviates significantly from the prediction of the behavioral model.

[0049] Therefore, in this disclosure, firstly, a first monitoring signal characterizing the simulation progress is collected at a first sampling interval. This type of signal mainly characterizes the simulation progress and does not involve specific state information. Therefore, the data volume of this type of signal is usually small, which can effectively reflect whether the simulation is continuing. Thus, during most normal simulation periods, only a small amount of data needs to be monitored, fundamentally avoiding the huge overhead caused by continuously collecting massive amounts of internal state signals in traditional solutions, and improving overall verification efficiency. Secondly, if an anomaly in the simulation progress is determined based on the first monitoring signal, a second round of collection is initiated to obtain a second monitoring signal characterizing the processor's operating state. By performing detection in two steps, it is ensured that system resources (computing, storage, I / O) can be concentrated on analyzing periods and signals more likely to cause problems, rather than being evenly consumed throughout the entire simulation process. This method not only avoids the accumulation of invalid data but also allows subsequent anomaly analysis to focus on critical periods, thereby enabling rapid and accurate identification of the root cause of the progress anomaly. The above two-step monitoring process can be executed automatically during the simulation without waiting for the simulation to end or requiring manual intervention. This changes the traditional lagging mode that relies on post-analysis or manual breakpoint debugging, and realizes real-time, automatic detection, diagnosis and handling of anomalies during simulation, which greatly improves the automation level and response speed of verification.

[0050] In addition, those skilled in the art can make various modifications and variations to the above embodiments:

[0051] In one optional implementation, the first monitoring signal includes: a first program counter signal indicating the progress of processor instruction execution, and / or a simulation time signal. The first program counter signal can be a register signal used by the processor core to store the memory address of the next instruction to be executed during instruction execution; its continuous change directly reflects the normal progress of the instruction flow. In this embodiment, the focus is on the program counter signal of the main core. The simulation time signal refers to the virtual time amount representing the progress of the simulation process in the simulation environment. This simulation time signal is maintained and updated by the emulator kernel; if it stagnates, it usually indicates that the entire simulation process is suspended for some reason (such as waiting for an event or deadlock). Multiple first signal data include: multiple counter signal values ​​of the first program counter signal at multiple consecutive sampling points, and / or multiple simulation time signal values ​​of the simulation time signal at multiple consecutive sampling points. Optionally, the first comparison result can be determined in the following way: determining a first change between every two adjacent counter signal values ​​among multiple counter signal values ​​to obtain multiple first change values; if at least one of the multiple first change values ​​is not greater than a first preset threshold, the result representing the simulation progress anomaly is taken as the first comparison result; based on the first comparison result between multiple first signal data, determining a second change between every two adjacent simulation time signal values ​​among multiple simulation time signal values ​​to obtain multiple second change values; if at least one of the multiple second change values ​​is not greater than a second preset threshold, the result representing the simulation progress anomaly is taken as the first comparison result.

[0052] Therefore, the first comparison result is not a single data value, but a comprehensive logical conclusion obtained after performing a series of specific comparison operations on multiple first signal data, used to determine whether the simulation progress is abnormal. The core of this comparison operation is to calculate the change between signal values ​​at adjacent sampling points and compare this change with a preset threshold. For example, when the first comparison result is represented by multiple changes, it can be implemented as follows: First, in the data preparation stage, a series of values ​​for the first monitoring signal at multiple consecutive sampling points are obtained, i.e., multiple first signal data. Then, in the calculation stage, every two adjacent sample values ​​in the above data sequence are subtracted to calculate the difference between them. For the program counter signal, this difference is the first change; for the simulation time signal, this difference is the second change. Since the calculation is performed on multiple sets of adjacent values, multiple first or second changes will be obtained. Finally, in the result generation stage, each calculated change is compared with the corresponding preset threshold.

[0053] The first and second changes can be the difference between the values ​​of the same monitoring signal at two adjacent sampling points. For the first program counter signal, the change reflects the progress of instruction execution within the time interval; for the simulation time signal, the change reflects the progress of simulation time. The first or second preset threshold can be a very small positive value or zero, pre-set to determine whether the signal has stalled. For example, the first preset threshold can be set to 0, requiring a change in the program counter (PC) value between adjacent sampling points; for the simulation time signal, the second preset threshold can be set to a small value greater than zero to tolerate minor time fluctuations caused by simulator scheduling. This method of determination based on signal changes is intuitive and computationally inexpensive, achieving good monitoring results in large-scale simulation scenarios requiring continuous operation.

[0054] Optionally, the second monitoring signal may include: key signals characterizing the processor's internal operating state, data interaction, and / or control flow. These key signals refer to the set of signals that reflect the dynamic behavior of the processor's internal core modules during processor simulation. For example, internal operating state signals may include current state codes of various state machines, values ​​of important data path registers, cache coherence protocol status, and exception handling status registers. The current state codes of various state machines refer to the fact that the processor has multiple controllers (such as pipeline control, cache controllers, bus arbitrators, etc.), which are typically implemented using finite state machines. The corresponding state codes directly indicate which operating stage the controller is currently in (e.g., idle, arbitration, access, response). Monitoring this signal allows for the determination of whether the controller logic is normal. The values ​​of important data path registers refer to registers that temporarily store, buffer, or record critical operands, addresses, and intermediate results. The cache coherence protocol status refers to the fact that in multi-core processors, each cache line maintains a coherence status label. Monitoring this signal can be used to diagnose problems such as inter-core communication deadlock and data access errors caused by inconsistent cache data. An exception handling status register refers to a set of dedicated registers used to record the cause of the exception, return address, and processing status when a processor encounters an exception (such as a page fault or illegal instruction) or an interrupt. By monitoring these registers, it can be determined whether the processor has entered an exception handling routine and failed to return, or whether the exception handling logic itself has an error. Data interaction signals can include handshake signals between internal processor modules (such as between the arithmetic unit and the memory controller), and between the processor and external interfaces, as well as data bus signals and address bus signals. Control flow signals can include pipeline control signals, branch prediction result signals, interrupt request and acknowledge signals, and exception trigger signals. Among these, control flow signals are used to track the direction of processor instruction execution and the response process to exceptions / interrupts, in order to reflect whether the processor is executing sequentially or has experienced a jump, pause, or interruption by an external event. Multiple second signal data can include multiple signal snapshots of key signals at multiple consecutive sampling points. A signal snapshot is a set of signal values ​​obtained by synchronously acquiring all selected second monitoring signals at a specific sampling time.

[0055] Optionally, the second comparison result can be determined as follows: Determine the degree of difference between every two adjacent signal snapshots in multiple signal snapshots to obtain multiple degree of difference. If at least one of the multiple degree of difference is not greater than a preset degree of difference threshold, the result indicating an anomaly in the simulation process is taken as the second comparison result. Wherein, if the second comparison result indicates an anomaly in the simulation process, control operations corresponding to the anomaly detection result are executed to control the processor simulation process. Here, degree of difference refers to a quantitative measure of the difference between two adjacent signal snapshots. For example, it can be the proportion of signal bits that have changed in all second monitoring signals to the total number of signal bits, or it can be a check of changes in a specific logical state for a specific key signal (such as a handshake signal) (e.g., whether a response is received within the expected time after a request is issued). The preset degree of difference threshold is a preset threshold value used to determine whether the system is stagnant or abnormal. For example, it can be set to 0 or a small value close to 0.

[0056] The determination of anomalies in the simulation process characterizes the system by initially comparing thresholds to identify deviations from expectations, indicating stagnation or malfunction. This judgment is a necessary prerequisite and triggering condition for subsequent refined diagnosis and targeted control operations. Anomaly detection results are the product of in-depth analysis and qualitative classification. For example, after confirming anomalies, the system initiates further intelligent analysis based on the specific signal snapshots identified as anomalies. This analysis identifies which key signals experienced stagnation with what characteristics, thereby classifying and characterizing the anomalies to obtain the anomaly detection results.

[0057] The above methods enable automated and refined monitoring of the processor's internal operating state. By quantitatively analyzing the differences in signal snapshots, various deep-seated errors, including deadlocks and state machine stagnation, can be objectively and efficiently detected. For example, key signals may include: operating status signals and / or interactive control signals; among which, operating status signals include: the second program counter signal and system register signals; interactive control signals include: handshake signals between internal processor modules and / or data interfaces, interrupt signals, pipeline control signals, and state machine signals. Specifically, operating status signals include the second program counter signal and system register signals. The second program counter signal refers to the counter signal used to track or back up instruction fetch addresses, excluding the main program counter. System register signals refer to the values ​​of the register sets used for control and state storage in the processor, which can be used to monitor processor mode switching, interrupt enable changes, and the correctness of loading exception handling entry addresses. Interactive control signals include handshake signals between internal processor modules or data interfaces, interrupt signals, pipeline control signals, and state machine signals. Handshake signals are control signal pairs used to coordinate the timing of data transmission between two modules. They can be used to prevent data loss or overwriting, implement pipeline pauses, and control bus access. Interrupt signals are asynchronous event notification signals initiated by external devices or internal timers. Pipeline control signals are signals that control the flow, pause, or clearing of each stage of the pipeline. State machine signals are coded signals representing the current state of a control module in the processor. They can be used to verify whether state transitions conform to design specifications, monitor whether the state machine is stuck in an illegal state or remains in an intermediate state for an extended period, and, in conjunction with handshake signals, determine whether the protocol has been correctly completed. The first program counter signal and the second program counter signal described in this disclosure are program counter information of different granularities and ranges collected at different stages by the hierarchical monitoring strategy. The main differences between them are as follows:

[0058] (1) Different functions and purposes: The first program counter signal is mainly used for simulation progress monitoring. As a system-level heartbeat signal, its purpose is to quickly detect whether the simulation has a global stall with minimal overhead. The second program counter signal is mainly used for simulation status diagnosis. Its purpose is to provide detailed execution flow context to locate the root cause of the problem when an anomaly is suspected.

[0059] (2) Different signal ranges: The first program counter signal is preferably the program counter signal of the processor's main core to simplify the monitoring logic; the second program counter signal has a more comprehensive range, for example, in a multi-core processor it is the program counter signal of multiple or all cores, and in a single core it is the program counter signal that represents the address of the instruction at different pipeline stages such as commit and retirement, so as to provide the spatiotemporal details required for diagnosis.

[0060] (3) Different acquisition mechanisms: The first program counter signal is acquired throughout the simulation cycle according to the first sampling interval; the second program counter signal is acquired only after the depth detection is triggered, according to the more dense second sampling interval.

[0061] By configuring the second monitoring signal to include critical signals such as running status signals and interactive control signals, detailed progress of the processor instruction execution pipeline and system configuration status can be provided, thus offering complete execution context information for anomaly diagnosis. Furthermore, through fine-grained signal segmentation, the timing of data transmission between modules within the processor, asynchronous event responses, pipeline flow status, and state transitions of control modules can be monitored, enabling precise localization of various anomalies such as handshake failures, interrupt response freezes, pipeline freezes, and system deadlocks.

[0062] By using the above methods, the accuracy of error diagnosis can be significantly improved while ensuring monitoring efficiency.

[0063] In one optional implementation, control operations corresponding to the anomaly detection results can be performed as follows: based on the anomaly type of the anomaly detection results, the simulation process can be stopped, and / or an error report corresponding to the anomaly type can be generated. The anomaly type of the anomaly detection results can be determined based on the signal type of a signal snapshot with a difference not exceeding a preset difference threshold. The signal type refers to the category of the second monitoring signals acquired during the deep detection phase, categorized according to their function and the processor behavior they reflect. For example, signal types include: running state types (such as program counter, system register) and interactive control types (such as handshake signals, interrupt signals, pipeline control signals, state machine signals). Determining the signal type allows for the classification of the core set of signals that caused the anomaly. The anomaly type refers to the classification and characterization of errors occurring in the processor simulation based on the signal type analysis results. For example, if the anomaly is mainly caused by the stagnation of interactive control signals, the anomaly type may be determined as handshake failure, bus deadlock, or interrupt jam; if the anomaly is mainly caused by the stagnation of running state signals, the anomaly type may be determined as pipeline freeze or system deadlock. By stopping the simulation process, the error context can be frozen, preventing the destruction of critical state information at the time of the anomaly due to continued simulation and preserving the complete context for subsequent analysis. By generating error reports, structured documents can be automatically created to record basic information such as the time of the anomaly, relevant signal snapshots, etc.

[0064] By mapping abnormal signals to specific abnormal types and triggering corresponding control operations (such as stopping the simulation) and generating customized error reports, the pertinence of error handling and the effectiveness of debugging information can be improved. It is also easier to obtain key signals and states related to specific abnormal types from the reports, shorten the time for root cause location of errors, and improve the overall efficiency of verification and debugging.

[0065] Therefore, the anomaly type is a classification and qualitative description of the specific nature of the anomaly. Based on the anomaly type, the specific control method for the control operation can be flexibly determined, enabling better control of the processor simulation process. For example, when the anomaly is severe, the processor simulation process can be directly controlled to avoid serious errors; when the anomaly is mild, the simulation process can continue to execute, but an error report corresponding to the anomaly type can be generated for subsequent analysis.

[0066] There can be a definite mapping relationship between the anomaly severity and the anomaly type. The anomaly type is used to qualitatively describe the specific nature of the error (such as pipeline deadlock, bus interface deadlock, state machine timeout, interrupt response failure, processor execution stall, etc.); the anomaly severity is used to quantitatively assess the impact of the anomaly on the simulation process. The two can be associated through a preset anomaly classification table. For example, the anomaly severity can be determined according to the hardware level to which the anomaly type belongs. Generally, anomalies belonging to critical modules inside the processor core (such as pipeline control units, branch prediction units, and anomaly handling units) have a high anomaly severity; anomalies belonging to bus or external interface modules (such as memory controllers and peripheral interfaces) have a medium anomaly severity; and anomalies belonging to non-critical state monitoring modules (such as performance counters and debug trace units) have a low anomaly severity.

[0067] In one alternative implementation, when the signal type is a handshake signal between internal processor modules and / or data interfaces, the exception type is typically a handshake failure or bus deadlock; the error report includes a snapshot of the handshake signal and the associated interface identifier. For example, if a request-response signal pair used to ensure data transmission synchronization is found to be in an invalid state for more than a preset time, it is determined to be this type of exception. The associated interface identifier is used to quickly locate the specific bus or module interface where the problem occurred.

[0068] When the signal type is a pipeline control signal and / or a second program counter signal, the exception type is pipeline freeze; the error report includes the pipeline status and program counter sequence at the time of the freeze. For example, a pipeline freeze can be determined when the control signal reflecting pipeline flow remains active and the second program counter signal sequence reflecting instruction commit / retirement progress stops updating.

[0069] When the signal type is an interrupt signal and / or a system register signal, the exception type is interrupt response stuck; the error report includes the number of the unresponsive interrupt, the interrupt mask status, and / or processor information. For example, if an interrupt request signal is detected as set, but after the expected time, the system register signal reflecting interrupt handling does not change as expected, this type of exception is identified.

[0070] When the signal type is a combination of handshake signals and state machine signals between internal processor modules, and a circular wait relationship exists, the exception type is system deadlock; the error report includes the state signals of the relevant modules and their resource occupancy relationships. For example, the state machine signals (indicating the current operating mode) and the handshake signals between multiple modules can be analyzed to construct a resource dependency graph. When a circular wait relationship is identified (i.e., A waits for a resource held by B, B waits for C, and C waits for A), it is determined to be a system deadlock.

[0071] By subdividing anomalies into various specific types based on different signal types and configuring corresponding error report content for each anomaly type, diagnostic efficiency can be improved. This makes it easier to locate the root cause of the problem directly based on the anomaly type, without having to analyze the original signal data from scratch, thereby significantly shortening the troubleshooting time.

[0072] To facilitate understanding, the specific meanings of the various signals mentioned above will be explained in further detail below:

[0073] Handshake signals: These are one or more pairs of standard signals used to coordinate data transmission timing and control exchange between internal modules of the processor (such as the CPU core and cache) or between the processor and external data interfaces.

[0074] Signal snapshot: refers to the data set obtained by synchronously sampling and recording the logic level values ​​of relevant handshake signals (such as valid, ready) at the abnormal moment when a handshake failure or bus deadlock is determined. It is used to record the exact state of the communication interface when the abnormality occurs.

[0075] Associated interface identifier: refers to a unique logical name or physical address defined for a specific communication link where an anomaly has occurred in the processor design or simulation environment.

[0076] Pipeline state at the moment of pipeline freeze: This refers to the instantaneous set of state information for each pipeline stage (such as instruction fetch, decode, execute, memory access, and write-back) of the processor at the moment when pipeline freeze is determined. It typically includes: the currently latched instruction content or opcode of each stage; the valid bits of each stage, indicating whether the stage is currently processing a valid instruction; and the state of the key control signals that caused the pipeline to stall.

[0077] Program counter sequence at freeze time: refers to multiple program counter values ​​recorded simultaneously at the freeze time, which may include: (1) Horizontal (space): program counter values ​​of all active processor cores, used to determine whether it is a global stagnation of multiple cores or a local stagnation of a single core. (2) Vertical (time): within a single core, the program counter values ​​reflecting the addresses of instructions at different pipeline stages, such as fetch PC, decode PC, commit PC.

[0078] Unresponsive interrupt number: refers to the interrupt source number or interrupt vector number that has been set in the interrupt controller but has not received a response from the processor core.

[0079] Interrupt masking status: refers to the state of the key registers that determine whether an interrupt is masked during an abnormal event.

[0080] Processor information: refers to the core context state related to interrupt handling, mainly including: the current privilege mode, such as user mode or machine mode; the exception return address, such as the program counter value when the interrupt occurs; and the interrupt service routine entry address, such as the address to jump to according to the interrupt number.

[0081] The state signals of the relevant modules refer to the current state codes of the key finite state machines of all modules identified as participating in the circular wait chain that leads to system deadlock.

[0082] Resource occupancy relationships of related modules: This refers to the resource dependency graph automatically generated by analyzing the status signals of the aforementioned modules and the handshake signals between modules. This graph, presented in structured text or chart form, clearly illustrates deadlock loops. For example: Module A is waiting for resource R2 held by Module B; Module B is waiting for resource R3 held by Module C; Module C is requesting resource R1 held by Module A.

[0083] Optionally, the first program counter signal includes: the program counter signal of the processor's main core; the second program counter signal includes: the program counter signals of multiple cores of the processor; and / or, the program counter signal representing the address of an instruction at different pipeline stages within a single core; wherein, the program counter signal representing the address of an instruction at different pipeline stages within a single core includes: a commit program counter signal and / or a retirement program counter signal. By further limiting the first program counter signal used for initial progress monitoring to the program counter signal of the processor's main core, the resource overhead in the first monitoring phase can be minimized. The specific reason is that the main core is usually the starting point and scheduling center of the system execution flow, and its activity best represents whether the overall system is progressing normally. Monitoring only the signal of a single core can effectively monitor the heartbeat status of the entire simulation system with minimal signal acquisition, storage, and comparison overhead, thereby maximizing the saving of computing and storage resources during most normal simulation periods and improving overall verification efficiency.

[0084] In a multi-core processor system, the master core typically refers to the core that starts executing code first during the startup phase, responsible for system initialization and task scheduling. The master core's program counter signal characterizes the progress of the system's most basic execution flow and is a key indicator of whether the overall system is functioning correctly. The program counter signals of multiple processor cores refer to the program counter signals of each active core (including the master core and other slave cores) in a multi-core processor architecture. These signals are used to identify problems such as multi-core deadlock or load imbalance caused by inter-core communication failures, resource contention, etc.

[0085] In a pipelined processor, instruction execution goes through multiple stages (such as fetch, decode, execute, memory access, and write-back). Correspondingly, the program counter signal within a single core, representing the address of an instruction at different pipeline stages, tracks the address value of the instruction at a specific critical stage in the pipeline, providing a more granular view of execution than a single program counter. Specifically, the commit program counter signal refers to the address signal in the processor pipeline that represents an instruction that has passed all checkpoints and whose result will be updated to the processor architecture state (such as registers or memory). If this signal stagnates, it usually indicates a problem in the instruction retirement stage. The retirement program counter signal is related to the commit program counter signal and usually refers to the same event: the program counter value corresponding to the moment when the instruction execution result is finally committed to the architecture state. If the retirement program counter signal remains unchanged, it can be used to determine whether a pipeline freeze or a retirement unit is stuck.

[0086] In one optional implementation, the processor can be a Reduced Instruction Set Computing (RISC) processor. The signal types of the first and / or second monitoring signals can be determined based on a pre-loaded detection configuration file. The detection configuration file includes a signal extension interface for configuring custom-type monitoring signals, which can be determined based on the structural characteristics of the RISC processor. For example, the first and / or second monitoring signals can be configured using the signal extension interface, which can be determined based on the structural characteristics of the RISC processor. Therefore, the detection configuration file defines the list of signals to be monitored during processor simulation and their related attributes. The signal extension interface refers to a programming interface or data pattern reserved in the detection configuration file that allows users to add and define new monitoring signals. It typically includes fields such as signal path, signal type (e.g., input, output, register), bit width, and descriptive information. Custom-type monitoring signals refer to monitoring signals added by the user through the signal extension interface that are not predefined by the framework. Correspondingly, if an update to the monitoring signals configured in the detection configuration file is detected, the first and / or second monitoring signals to be collected can be determined based on the updated detection configuration file.

[0087] The monitoring framework updates its signals by modifying, adding, or deleting monitoring signal definitions in the detection configuration file. This update can occur before simulation begins (static update) or be dynamically triggered during simulation to adapt to different testing phases or debugging needs. This approach achieves configurability and scalability for the monitoring framework. First, by using monitoring signals in the detection configuration file, adjustments to the monitoring strategy do not require modification of the core detection logic, improving code modularity and maintainability. Second, the signal extension interface allows for customized monitoring signals for specific processors to cover their unique functions or potential risks. Finally, dynamic configuration updates are supported, enabling adjustments to monitoring targets during simulation as needed, thereby improving the efficiency and flexibility of processor verification.

[0088] Preferably, to balance operating overhead and accuracy, the first sampling interval is greater than the second sampling interval. Furthermore, the second monitoring signal has more signal types than the first monitoring signal, the signal precision of the second monitoring signal is greater than that of the first monitoring signal, and / or the monitoring granularity of the second monitoring signal is smaller than that of the first monitoring signal. Here, the sampling interval refers to the time interval between two consecutive acquisitions of a monitoring signal. In a simulation environment, the unit of the sampling interval can be simulation time (e.g., microseconds) or processor clock cycles. The first sampling interval is typically used in the routine monitoring phase, aiming to detect system characteristics at a lower frequency; the second sampling interval is typically used in the in-depth analysis phase, aiming to capture subtle trajectories of signal changes at a higher frequency to facilitate the analysis of transient errors. Signal types refer to the type and quantity of monitoring signals: the first monitoring signal typically contains only a small number of core signals that best reflect the overall progress of the system (e.g., global simulation time, main core program counter); the second monitoring signal extends to a broad set of signals covering the internal state of the processor core, inter-module interactions, control flow, etc. (e.g., pipeline control signals, handshake signals, interrupt signals, state machine signals, etc.). Signal precision refers to the resolution or significant bits of the acquired signal value. For example, for the program counter signal, the first monitoring signal might only collect its lower few bits to determine if there has been a change, while the second monitoring signal would collect its full-width, precise address value. Monitoring granularity refers to the smallest unit of system state change that monitoring behavior can observe. A coarser monitoring granularity (the first monitoring signal) might only focus on whether an instruction has retired (focusing on the result), while a finer monitoring granularity (the second monitoring signal) would track the detailed state of the instruction at each stage of the pipeline (focusing on the process).

[0089] The above approach enables on-demand, dynamic, and hierarchical allocation of monitoring resources: the first layer of coarse-grained monitoring ensures efficient simulation operation most of the time, while the second layer of fine-grained monitoring guarantees sufficient diagnostic information at critical moments. This significantly reduces the data storage and processing burden on the simulation system, improving the feasibility of long-term simulations. Simultaneously, by improving signal accuracy and monitoring granularity in the deep diagnostic phase, the ability to capture and analyze complex issues such as transient errors is enhanced, making the debugging process more precise and efficient.

[0090] To facilitate understanding, the following example illustrates the specific implementation details of the control method for processor simulation provided in this disclosure.

[0091] This example relates to a simulation and error correction method for Reduced Instruction Set Computing (RISC) processors based on a tool command language, specifically involving chip verification, RISC processors, and hardware simulation. RISC processors, due to their simple structure, active community, and ease of modification and expansion, have become the mainstream direction for processor design and development in both academia and industry. Simulation verification is an indispensable and extremely time-consuming crucial step in processor development.

[0092] In related technologies, common simulation verification methods include the following:

[0093] (1) Software simulation (simulator)

[0094] Software simulation allows for convenient operations such as downloading complete waveform files, adding processor internal log printing, and locating errors by combining the instruction counters of committed / retired units in the waveform with decompiled code. However, software simulation is extremely slow for complex test scales, making it almost unusable.

[0095] (2) Hardware simulation (Emulator)

[0096] Hardware simulation is much faster than software simulation, but it has at least the following serious limitations: waveform files are extremely large and take a long time to download; once the waveform is lost, only limited information such as registers at a fixed moment can be viewed; if data at multiple moments needs to be observed, the simulation must be paused / resumed manually multiple times, which is extremely inefficient; if an error causes an infinite loop, the simulation will continuously occupy resources, and there is a lack of an effective automated detection mechanism.

[0097] (3) Software + Hardware Joint Verification

[0098] Typically, problems are located as much as possible during the software simulation phase, while errors are inferred during the hardware simulation phase by manually checking registers or pausing step by step. However, this approach lacks a unified, automated error detection framework and cannot automatically locate complex issues such as deadlocks and handshake failures in both types of simulations.

[0099] It is evident that the solutions in related technologies are generally based on waveform or manual analysis, resulting in insufficient automation. In summary, the main defects in related technologies include: (1) Extremely slow software simulation speed: unusable in large-scale testing, leading to extended debugging cycles. (2) Extremely limited hardware simulation debugging information: almost impossible to locate deep-level errors when waveforms cannot be downloaded. (3) Excessive manual intervention: complex error location requires manual pausing of simulation and viewing signals at multiple time points, which is inefficient and prone to errors. (4) Lack of automated error detection mechanism: unable to automatically capture typical problems such as deadlock, pipeline freeze, handshake failure, and interrupt deadlock. (5) Poor scalability: different engineering teams need to manually modify scripts, signals, and sampling methods, and there is no universal framework.

[0100] This example aims to solve all the above problems, providing an automated detection and debugging method applicable to both software and hardware simulations. It seeks to overcome the shortcomings of traditional processor simulations, such as low debugging efficiency, insufficient automation, difficulty in locating complex errors without waveforms, and slow convergence of simulation deadlocks, achieving automatic, fast, and scalable error detection and localization in reduced instruction set processor (RISC) simulations.

[0101] Therefore, the processor simulation error correction method based on tool command language proposed in this example is applicable to both software simulation and hardware simulation. It can automatically detect, locate, collect and analyze simulation deadlock scenarios in the RISC processor core and integration verification without waveforms or human intervention. Its debugging efficiency, scalability and automation capabilities are far superior to the traditional manual debugging method based on waveforms.

[0102] Figure 2 A system diagram of the processor simulation system in this example is shown. Figure 2 As shown, the processor simulation system in this example includes: a global control module, a processor simulation environment, and an error detection framework.

[0103] The specific principles of each module are explained below:

[0104] I. Global Control Module

[0105] The global control module is responsible for performing the following operations: selecting the simulation environment (software / hardware); setting the detection items, detection interval, maximum number of detections, etc.; distributing the program to be tested and starting the simulation environment; and controlling the start and stop of the error detection framework. Figure 3 A schematic diagram of the input / output interfaces of the global control module is shown. (For example...) Figure 3As shown, a simulation configuration parameter table (i.e., the detection configuration file mentioned above) can be pre-configured, in which the following can be configured: (1) Simulation type: used to specify the underlying environment used in this simulation, such as a software simulation with a slower running speed but rich debugging information, or a hardware simulation with a faster running speed but limited debugging. (2) Global sampling parameters: simulation sampling interval, used to define the time period for the monitoring module to periodically check the processor running status (the unit can be microseconds or processor clock cycles). (3) Key signal monitoring path: provides a series of configurable monitoring signal paths to facilitate accurate error detection. The above paths point to key nodes inside the processor design so that users can flexibly specify the signals to be collected. For example, the simulation time path is used to obtain the current timestamp of the simulation engine and determine whether the simulation is progressing; the program counter path is used to monitor the address of the instruction being executed by the CPU core; the retirement counter path and the commit signal path are used to monitor the completion and commit status of instructions in the pipeline. The high-speed interface handshake signal path, interrupt signal path, pipeline pause signal path, and exception handling valid signal path are used to monitor the status of communication between modules inside the processor, asynchronous event response, and pipeline control flow.

[0106] The test cases (usually assembly or high-level language test programs written for processor functionality) need to be compiled into a binary instruction stream that the target processor can execute, i.e., the executable file for the processor simulation shown in the diagram. This file will be loaded into the processor's memory model when the simulation starts. The global control module belongs to the core control unit and is used to receive... Figure 3 The left-hand side handles all input information and coordinates the execution of verification tasks. The global control module handles parameter parsing and distribution, test case loading, and lifecycle control. For example, it can send start, pause, continue, and stop commands to the simulation environment. The simulation environment is a specific instantiated processor runtime platform configured according to the simulation type, used to execute simulation tasks.

[0107] II. Processor Simulation Environment

[0108] The processor simulation environment supports both software and hardware simulations. Different parameters need to be set for different simulation scenarios, and these settings can be implemented in the global control module. Therefore, the processor simulation is controlled simultaneously by the global control module and the error detection framework: the global control module distributes test cases and controls the simulation's start and completion; the error detection framework automatically controls the simulation and completes the sampling process based on the sampling interval settings. When the error detection framework detects a fatal error, it stops the simulation.

[0109] Figure 4 A schematic diagram of the processor simulation environment is shown, such as... Figure 4As shown, the processor simulation environment is used to characterize the object to be verified and the execution engine, specifically including: (1) processor: the processor design model to be verified; (2) data stimulus file: the compiled test program (binary machine code); (3) simulation control module: used to drive the simulation process and receive control commands (start, pause, continue, stop) from the outside; (4) monitor: used to comprehensively collect key signals of the processor's internal and interface interfaces; (5) error detection framework is used to receive the real-time signal stream transmitted by the monitor and automatically analyze the signal stream according to preset rules or learning models to identify anomalies such as deadlock.

[0110] III. Error Detection Framework

[0111] A typical error detection framework consists of a simulation monitoring module, a processor status detection module, a key signal analysis module, and a report generation module. Figure 5 A schematic diagram of the file structure of the error detection framework is shown, such as... Figure 5 As shown, the file structure of the error detection framework includes the following parts:

[0112] (1) monitor_riscv_error.tcl file: This file is used to implement the simulation monitoring module. Specifically, it monitors the simulation progress and collects the following fixed signals from the simulation environment at set intervals (e.g., 100us): the current simulation time, the current main core program counter, and other signals set in the signal_riscv.txt file. The signal_riscv.txt file reserves a signal detection extension interface, through which other signals to be detected can be flexibly defined. The signal_riscv.txt file is a specific form of the detection configuration file mentioned above, and the signal detection extension interface is a specific form of the signal extension interface mentioned above.

[0113] Specifically, if the simulation time remains unchanged multiple times consecutively (default 5 times) or the program counter remains unchanged multiple times consecutively, the monitoring module determines that there is a high probability of entering an error scenario, thus triggering further analysis. The simulation monitoring module will continue to monitor until the simulation ends or further analysis is required.

[0114] (2) The inspect_riscv_state.tcl file: This file is used to implement the functions of the processor state detection module. Specifically, it triggers the corresponding detection operation in this file when the simulation monitoring module detects an anomaly. The purpose of this file is to further collect internal processor signals. By default, it collects the program counter (including retired and committed ones) of each core, as well as all system registers, all high-speed interface handshake signals, interrupt signals, pipeline pause signals, and state machine signals outside the processor cores. These signals are then stored in the file as snapshot signals for further analysis. Once this step is initiated, the collection process continues until the analysis is complete.

[0115] (3) analyze_riscv_freeze.py file: This file is used to implement the function of the critical signal analysis module, which analyzes the acquired snapshot signals. Specifically, it compares and analyzes the current snapshot signal with the previously collected snapshot signal to identify the signals that remain unchanged, such as the handshake signal. By default, if the critical signals (such as the handshake signal, which can be customized) remain unchanged in 5 consecutive snapshots, it is considered to have entered an error state. At this time, the simulation environment will be stopped, and the error-related signals will be output to the corresponding files according to the simulation path from the outside to the inside hierarchy.

[0116] (4) error_report_gen.py file: This file is used to implement the function of the report generation module. It is used to summarize the relevant signals obtained and output them in a formatted markdown file for easy formatting and display. If there is no error-related content, it outputs that the simulation was successful.

[0117] The signals_riscv.txt file is a configuration file used to provide sampling-related configurations, such as the signal path and sampling interval mentioned in the global control module. Users can also configure custom signals to enable the detection of custom signals by modifying the monitoring file.

[0118] In addition, the run_riscv_sim.sh file provides a shortcut command for one-click execution during software simulation, reducing the configuration process.

[0119] Figure 6 This diagram illustrates the runtime flow of a typical error detection framework. Figure 6 As shown, the error framework mainly performs the following steps during runtime:

[0120] Step 1: Start the simulation.

[0121] Once the entire verification task is initialized, the processor simulation environment (whether it is a software simulator or a hardware simulation platform) has been loaded with the test program and officially started running under the instructions of the global control module.

[0122] Step 2: Simulation monitoring.

[0123] After the simulation starts, the system enters the simulation monitoring state. In this state, the error detection framework periodically collects a set of key signals (typically including at least the simulation time signal and / or program counter signal) to characterize the simulation progress according to a preset first sampling interval. The key signals here are the specific forms of the first monitoring signal mentioned above. After each sampling, the framework determines whether the values ​​of these key signals are the same as the previous sampled values, i.e., whether they remain unchanged.

[0124] If, after the current sampling, the condition of maintaining the key signal value continuously for 5 times is not met, the process is marked as "not 5 consecutive times" and returns to the simulation monitoring state to continue the next round of periodic sampling and comparison. The above method constitutes the main monitoring loop, and the system will continue to run in this loop while the simulation is progressing normally.

[0125] If, after the current sampling, the condition that the critical signal remains unchanged for 5 consecutive times is met, the process will determine that a potential stagnation anomaly (such as a deadlock precursor) has been detected, mark it as a critical signal holding condition, trigger an upgrade operation, exit the main monitoring loop, and proceed to the next internal signal acquisition operation.

[0126] Step 3: Internal signal acquisition.

[0127] Once initial monitoring confirms the possibility of an anomaly, the process enters the internal signal acquisition phase. This phase aims to transition from light monitoring to deep detection. The error detection framework comprehensively acquires a predefined second set of monitoring signals at more frequent second sampling intervals. This set of signals is far more detailed than the signals monitored in the first step, aiming to capture the complete internal state of the processor (such as the PC of all cores, pipeline control signals, all handshake signals, interrupt status, system registers, etc.), forming a signal snapshot.

[0128] Step 4: Signal snapshot preservation analysis.

[0129] After obtaining detailed internal signal snapshots, the process enters the signal snapshot persistence analysis phase. The analysis engine compares the signal snapshots collected multiple times in succession to check whether key signals used for error diagnosis (such as specific handshake signal pairs, state machine codes) remain unchanged.

[0130] If the analysis finds that the condition of holding the signal snapshot for 5 consecutive times has not been met, it is marked as not holding it for 5 consecutive times, indicating that the initial anomaly may be a short-term fluctuation. The system determines that the risk has been eliminated, and the process returns to the simulation monitoring state of the second step to restore the normal monitoring cycle.

[0131] If analysis confirms that the key signals in the signal snapshot remain unchanged for five consecutive times, it is marked as five consecutive times, thus determining that the system has entered an abnormal state (such as handshake deadlock or global pipeline freeze). The process then proceeds to the simulation stop step.

[0132] Step 5: Stop the simulation and end the process.

[0133] After confirming the error, the error detection framework sends a forced stop command to the simulator via the control interface, halting the simulation. The simulation process is immediately terminated, computing resources are released, and the system saves complete error context information. The process then terminates, indicating the completion of the automated error detection task.

[0134] In summary, in a complete simulation process, the startup parameters are set before the simulation and sent to the global control module. The global control module controls the startup of the simulation environment and the operation of the error detection framework according to the set parameters. After the simulation starts, the error detection framework periodically obtains specified data from the simulation environment's data signal interface and performs calculations within the framework. If necessary, it uses control signals to pause or resume the simulation. When the error detection framework detects an error, it controls the simulation to end and outputs a relevant report. If no error occurs, the detection module continues to run until the simulation is complete.

[0135] In summary, the entire process can be divided into the following main stages:

[0136] (1) Initialization and configuration phase.

[0137] The main task at this stage is to configure the error detection framework. Specifically, through automated scripts, the goals, rules, and strategies for error detection are preset for this simulation task. This may include the following configurations:

[0138] Select monitoring signals: Define the list of key internal processor signals to be collected and their paths (such as program counter PC, handshake signals, interrupt signals, etc.).

[0139] Set sampling interval: Define the frequency at which the error detection framework polls and checks the processor's running status (e.g., once every 100 microseconds).

[0140] Define trigger conditions: Set the rules for judging "abnormalities" (for example, trigger an alarm if the program counter does not change for 5 consecutive sampling periods).

[0141] Preset response actions: Set the control strategy after detecting different levels of errors (e.g., log only, pause simulation, or stop immediately).

[0142] (2) Simulation startup and branch judgment stage.

[0143] At this stage, depending on the simulation mode, the process is divided into two paths:

[0144] Path A: Software simulation.

[0145] If the problem is determined to be software simulation, the global control module can activate the configured error detection framework and start the software simulator, loading the processor design model and test cases.

[0146] Path B: Hardware simulation.

[0147] If the system is determined to be hardware simulation, an additional hardware configuration step is required: configuring the startup parameters needed for the hardware simulation platform. After configuration, a one-click start command will automatically execute a series of operations by the global control module: downloading the design bitstream to the FPGA, initializing the hardware platform, and establishing a debug connection. Then, once the hardware environment is ready, the error detection framework will be started.

[0148] Phase 3: Perform simulation calculation tasks.

[0149] Phase 4: Operation and Monitoring.

[0150] After simulation starts, the system enters a dynamic simulation running state. The error detection framework periodically performs data acquisition and calculation operations: according to a preset sampling interval, the error detection framework periodically reads specified monitoring signals (such as PC value, bus status) from the running simulation environment through the data signal interface. Subsequently, it performs real-time calculation and analysis within the framework. If the framework determines that the current state does not meet the error detection conditions, the process is marked as no error detected, and it returns to the simulation running state to continue the next round of monitoring loop until the test program executes normally. Once the error detection framework confirms that an error has occurred according to the analysis rules (e.g., a complete deadlock of a critical handshake signal), the process is marked as an error detected, and it exits the monitoring loop.

[0151] Phase 5: Conclusion and Reporting.

[0152] For example, an automated debugging report for a reduced instruction set processor error may include the following information:

[0153] 1. Triggering conditions

[0154] Triggering rule: PC remains unchanged over 2000 cycles;

[0155] Trigger time: Clock cycle is 15000.

[0156] 2. Kernel State Snapshot

[0157] 2.1 Program Counter (PC)

[0158] PC=0x80001234

[0159] 2.2 General Purpose Registers (GPR)

[0160] x1 = 0x00000000

[0161] x2 = 0x80004000

[0162] x3 = 0x00000001

[0163] x4 = 0x00008000 ...

[0165] 2.3 Key Signals in the Production Line

[0166] IF.valid = 1

[0167] IF.ready = 0 (Instruction fetch phase is blocked)

[0168] ID.stall_reason = DEP_WAIT

[0169] EX.exception = 0

[0170] LSU.busy = 1 ...

[0172] 3. Abnormal behavior

[0173] During the pointer fetch phase, valid=1 and ready=0 are continuously maintained, resulting in a handshake pause.

[0174] The PC remains unchanged for a long time;

[0175] The LSU is busy and may be waiting for a memory access request that has not yet returned.

[0176] No abnormalities or interruptions were encountered during the entry process.

[0177] For example, in a specific simulation execution process, it can be achieved in the following way:

[0178] (1) Run a RISC-V program in a hardware simulation environment;

[0179] (2) The monitor module detected that the PC remained unchanged for 5 consecutive times;

[0180] (3) The inspect module begins to continuously collect snapshots;

[0181] (4) The analyze module detected that the handshake signal was continuously frozen;

[0182] (5) The analysis module automatically stops the simulation and outputs key signals;

[0183] (6) The report generation module outputs a Markdown report.

[0184] The entire process is independent of waveforms and does not require manual pausing of the simulation.

[0185] Therefore, compared with related technologies, the solution in this example has at least the following beneficial effects:

[0186] (1) The cause of deadlock and freeze can be automatically located without waveform, greatly reducing simulation resources and time consumption.

[0187] (2) It has a high degree of automation and does not require manual intervention for debugging, which effectively improves the efficiency of simulation verification.

[0188] (3) The software / hardware simulation is universal and highly scalable. Signal detection items can be customized through signals_riscv.txt.

[0189] (4) Quickly output structured error reports, which is beneficial for internal team communication and problem reproduction.

[0190] (5) Significantly improves the verification convergence speed, reduces error localization time, and accelerates iteration.

[0191] Those skilled in the art can implement the monitoring and analysis modules using different languages ​​and scripts; this disclosure does not limit the specific implementation details. The processor state freeze automatic detection method based on periodic snapshot sampling proposed in this example possesses a unified general error detection framework in a software / hardware simulation environment, as well as scalable signal configuration files and automatic sampling interfaces. It automatically locates deadlock signals through snapshot comparison, replacing traditional waveform analysis. It supports hardware simulation and automated debugging, solving the problem of low efficiency in traditional manual pauses. It supports signal expansion, making it flexibly applicable to different RISC processor architectures. The entire process requires no manual intervention, significantly reducing verification time. It can achieve deep error localization even without waveforms or logs.

[0192] It should be noted that the above example is merely an exemplary implementation scheme, and those skilled in the art can make various extensions to the above example. In this example, the first monitoring signal (such as simulation time, main core PC) is used as a preset, static signal for illustration. In practice, a dynamic priority signal list and a dynamic situational awareness mechanism can also be introduced: the set of signals to be monitored can be adaptively determined based on the simulation stage. The first monitoring signal is not fixed, but can be dynamically switched according to different stages of the simulation (such as booting, operating system loading, application running, interrupt handling, shutdown). For example, in the booting stage, the PC and reset signal in the Boot ROM address area can be monitored; in the interrupt handling stage, the PC and interrupt acknowledge signal in the interrupt vector table address are monitored, thus making the monitoring more targeted. Similarly, the types and quantities of the second monitoring signal can also be dynamically and adaptively adjusted according to the detected anomaly type. This disclosure does not limit the specific details.

[0193] This disclosure also provides a control device for processor emulation, which is suitable for the processor emulation process. For example... Figure 7 As shown, the device includes:

[0194] The first monitoring module 71 is adapted to collect a first monitoring signal according to a first sampling interval to obtain multiple first signal data corresponding to the first monitoring signal; wherein, the first monitoring signal is used to characterize the simulation progress.

[0195] The second monitoring module 72 is adapted to, when determining an abnormality in simulation progress based on a first comparison result among the plurality of first signal data, acquire a second monitoring signal at a second sampling interval to obtain a plurality of second signal data corresponding to the second monitoring signal; wherein, the second monitoring signal is used to characterize the processor's operating state;

[0196] The simulation control module 73 is adapted to control the processor simulation process based on a second comparison result between the plurality of second signal data.

[0197] This disclosure also provides an electronic device, including:

[0198] At least one processor; and

[0199] A memory communicatively connected to the at least one processor; wherein,

[0200] The processor is configured as described above.

[0201] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0202] Figure 8 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0203] Reference Figure 8 This disclosure provides an electronic device, which includes: at least one processor 701; at least one memory 702; and one or more I / O interfaces 703 connected between the processor 701 and the memory 702; wherein the memory 702 stores one or more computer programs that can be executed by at least one processor 701, and the one or more computer programs are executed by at least one processor 701 to enable at least one processor 701 to perform the control method for processor emulation described above.

[0204] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the above-described method. The computer-readable storage medium may be volatile or non-volatile.

[0205] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the above-described method.

[0206] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0207] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0208] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0209] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0210] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0211] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0212] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0213] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0214] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0215] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A control method for processor emulation, characterized in that, The method is executed during processor emulation, and the method includes: According to the first sampling interval, a first monitoring signal is collected to obtain multiple first signal data corresponding to the first monitoring signal; wherein, the first monitoring signal is used to characterize the simulation progress; If an abnormality in simulation progress is determined based on a first comparison result among the plurality of first signal data, a second monitoring signal is acquired according to a second sampling interval to obtain a plurality of second signal data corresponding to the second monitoring signal; wherein, the second monitoring signal is used to characterize the processor's operating status; The processor simulation process is controlled based on the second comparison result between the plurality of second signal data.

2. The method according to claim 1, characterized in that, The first monitoring signal includes: a first program counter signal indicating the progress of processor instruction execution, and / or a simulation time signal; the plurality of first signal data includes: multiple counter signal values ​​of the first program counter signal at multiple consecutive sampling points, and / or multiple simulation time signal values ​​of the simulation time signal at multiple consecutive sampling points; the method further includes: Determine the first change between every two adjacent counter signal values ​​among the plurality of counter signal values ​​to obtain a plurality of first changes; if at least one of the plurality of first changes is not greater than a first preset threshold, the result characterizing the simulation progress anomaly is used as the first comparison result; or... Determine the second change between every two adjacent simulation time signal values ​​among the plurality of simulation time signal values ​​to obtain a plurality of second change values; if at least one of the plurality of second change values ​​is not greater than a second preset threshold, the result characterizing the simulation progress abnormality is used as the first comparison result.

3. The method according to claim 2, characterized in that, The second monitoring signal includes: key signals used to characterize the processor's internal operating state, data interaction, and / or control flow; the multiple second signal data includes: multiple signal snapshots of the key signals at multiple consecutive sampling points; The method further includes: determining the degree of difference between every two adjacent signal snapshots in the plurality of signal snapshots to obtain a plurality of degree of difference; if at least one of the plurality of degree of difference is not greater than a preset degree of difference threshold, the result characterizing the simulation process as the second comparison result is used. The step of controlling the processor simulation process based on the second comparison result among the plurality of second signal data includes: when the second comparison result indicates that there is an anomaly in the simulation process, executing a control operation corresponding to the anomaly detection result to achieve control of the processor simulation process.

4. The method according to claim 3, characterized in that, The key signals include: operating status signals and / or interactive control signals; The running status signals include: a second program counter signal and / or a system register signal; the interactive control signals include at least one of the following: handshake signals between internal modules of the processor, handshake signals between data interfaces, interrupt signals, pipeline control signals, and state machine signals.

5. The method according to claim 4, characterized in that, The control operations corresponding to the anomaly detection results include: Based on the anomaly type of the anomaly detection result, control the simulation process to stop, and / or generate an error report corresponding to the anomaly type; The anomaly type of the anomaly detection result is determined based on the signal type of the signal snapshot whose difference is not greater than a preset difference threshold.

6. The method according to claim 5, characterized in that, When the signal type is a handshake signal between modules and / or data interfaces within the processor, the exception type is handshake failure or bus deadlock; the error report includes a signal snapshot of the handshake signal and the associated interface identifier; When the signal type is a pipeline control signal and / or a second program counter signal, the exception type is a pipeline freeze; the error report includes the pipeline status and program counter sequence at the time of the freeze. When the signal type is an interrupt signal and / or a system register signal, the exception type is interrupt response deadlock; the error report includes the number of the unresponsive interrupt, the interrupt masking status, and / or processor information; When the signal type is a combination of handshake signals and state machine signals between internal modules of the processor, and a circular wait relationship exists, the exception type is system deadlock; the error report includes the status signals and resource occupancy relationships of the relevant modules.

7. The method according to any one of claims 4-6, characterized in that, The first program counter signal includes: the program counter signal of the processor's main core; The second program counter signal includes: program counter signals of multiple cores of the processor; and / or, program counter signals within a single core representing the addresses of instructions at different pipeline stages; The program counter signals for the single core characterization instruction at different pipeline stage addresses include: a commit program counter signal and / or a retirement program counter signal.

8. The method according to any one of claims 1-6, characterized in that, The processor includes: a reduced instruction set processor; the first monitoring signal and / or the second monitoring signal are determined according to a signal extension interface in a detection configuration file; wherein, the signal extension interface is used to configure a custom type of monitoring signal, and the monitoring signal configured by the signal extension interface is determined according to the structural characteristics of the reduced instruction set processor; The method further includes: when an update is detected in the monitoring signal configured in the detection configuration file, determining the first monitoring signal and / or the second monitoring signal to be collected according to the updated detection configuration file.

9. The method according to any one of claims 1-6, characterized in that, in, The first sampling interval is greater than the second sampling interval, and the second monitoring signal has more signal types than the first monitoring signal; Furthermore, the signal precision of the second monitoring signal is greater than that of the first monitoring signal, and / or the monitoring granularity of the second monitoring signal is smaller than that of the first monitoring signal.

10. A control device for processor emulation, characterized in that, The control device is suitable for processor simulation processes, and the control device includes: The first monitoring module is adapted to collect a first monitoring signal according to a first sampling interval to obtain multiple first signal data corresponding to the first monitoring signal; wherein, the first monitoring signal is used to characterize the simulation progress; The second monitoring module is adapted to, when determining an abnormality in simulation progress based on a first comparison result among the plurality of first signal data, acquire a second monitoring signal at a second sampling interval to obtain a plurality of second signal data corresponding to the second monitoring signal; wherein, the second monitoring signal is used to characterize the processor's operating status; The simulation control module is adapted to control the processor simulation process based on a second comparison result among the plurality of second signal data.

11. An electronic device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; in, The processor is configured to perform the method of any one of claims 1-9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program, when executed by a processor, implements the method as described in any one of claims 1-9.

13. A computer program product comprising computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, characterized in that, When the computer-readable code is run in an electronic device, the processor in the electronic device performs the method of any one of claims 1-9.

Images