Simulation test method and device, computer equipment and storage medium

Abstract

The invention discloses a simulation test method and device, computer equipment and a storage medium, and relates to the technical field of semiconductors, and the method comprises the steps: carrying out the simulation test of a to-be-tested design, and carrying out the decrement counting of a work clock of the to-be-tested design based on a preset timer; detecting an output result of the to-be-tested design; and if the output result is not detected when the counting is finished, stopping the simulation test of the to-be-tested design. According to the method, whether the to-be-tested design has the abnormal state or not is judged by detecting the output condition of the to-be-tested design in real time, and simulation is automatically stopped if the abnormal condition exists. The overtime detection time does not need to be set, and the management of the test case is simplified, so that the simulation test efficiency is improved, the promotion of the verification task is accelerated, and the problem of easy suspension in the simulation test process is solved.

Description

Technical Field

[0001] The present application relates to the field of semiconductor technology, and in particular to simulation test methods, devices, computer equipment, and storage media. Background Art

[0002] In the field of semiconductor technology, as design complexity increases, the verification process increasingly relies on test cases. Test cases cover functional verification through diverse scenarios and stimulus modes, but simulation hangs are common during debugging. To address this issue, related technologies use timeout thresholds to forcibly terminate timed-out simulations to avoid hangs. However, this method is difficult to reasonably set the timeout threshold. If the threshold is too large, early anomalies cannot be detected in a timely manner; if the threshold is too small, normal test cases may be mistakenly stopped. Summary of the Invention

[0003] The present application provides a simulation test method, apparatus, computer equipment and storage medium to at least solve the problem in related technologies that it is difficult to perform accurate testing.

[0004] The present application provides a simulation test method, comprising: performing a simulation test on a design to be tested, and counting down a working clock of the design to be tested based on a preset timer; detecting an output result of the design to be tested; and stopping the simulation test of the design to be tested if the output result is not detected at the end of counting.

[0005] This application also provides a simulation test device, comprising:

[0006] A counting module, configured to perform a simulation test on the design to be tested and count down the working clock of the design to be tested based on a preset timer;

[0007] A result detection module, used to detect the output result of the design to be tested;

[0008] The test stop module is used to stop the simulation test on the design to be tested if the output result is not detected at the end of counting.

[0009] The present application also provides a computer device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any one of the above-mentioned simulation test methods when executing the computer program.

[0010] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any one of the above-mentioned simulation test methods are implemented.

[0011] The simulation test method provided by an embodiment of the present invention includes performing a simulation test on a design to be tested, and counting down the working clock of the design to be tested based on a preset timer; detecting the output result of the design to be tested; and stopping the simulation test of the design to be tested if no output result is detected at the end of the counting. The present invention determines whether the design to be tested is in an abnormal state by detecting the output of the design to be tested in real time, and automatically stops the simulation if an abnormal state exists. There is no need to set a timeout detection time, which simplifies the management of test cases, thereby improving the efficiency of simulation testing, accelerating the advancement of verification tasks, and solving the problem of hanging up easily during simulation testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0013] Figure 1 A flowchart of a simulation test method provided in an embodiment of the present application;

[0014] Figure 2 A schematic diagram illustrating the association of watchdog timing in a general verification methodology component provided in an embodiment of the present application;

[0015] Figure 3 The verification environment provided for the embodiment of the present application includes an intermediate monitoring node designed to be tested;

[0016] Figure 4 The execution process of the test case provided in the embodiment of the present application;

[0017] Figure 5 A simulation test device provided in an embodiment of the present application;

[0018] Figure 6 A schematic diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0020] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0021] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0022] With the advancement of semiconductor technology, the complexity of integrated circuits is increasing, necessitating a crucial role in verification. The goal of verification is to ensure the functional correctness and performance accuracy of a design under various conditions. This process involves simulation testing using test cases. Test cases are a core tool in the verification process, used to systematically verify functional correctness and performance stability. Test cases include test objectives, test environments, input data, test steps, expected results, test scripts, and other components, ultimately documented. A test case can be considered a set of test inputs, execution conditions, and expected results compiled for a specific objective, used to verify that specific requirements are met. In the semiconductor testing field, test cases define specific verification scenarios and stimulus patterns. Different test cases target different functional points or design features. By configuring different parameters and randomizing the stimulus, a wide range of possible input conditions can be covered to ensure design correctness under diverse conditions.

[0023] In testing, stimulus is an input signal applied to a design through specific test vectors or scenario simulations. Its core goal is to trigger all potential functional paths and abnormal states within the design to verify the correctness and robustness of the design. Stimulus generation typically utilizes constrained random verification techniques, dynamically generating a vast array of test scenarios through parameterized configuration and randomization strategies, covering normal operation, boundary conditions, protocol stress, and anomaly injection. Combined with formal verification and coverage-driven verification, stimulus can systematically traverse the state space, exposing underlying defects such as timing violations, deadlocks, and protocol conflicts.

[0024] As design complexity increases, so does the complexity of test cases. Test cases typically require constructing scenarios that include multi-clock interactions, low-power state machine transitions, and high-speed protocol stack stress testing, resulting in a large amount of code. Consequently, test case debugging can easily lead to hangs, manifested as the simulation process becoming stuck in an event-free loop: clock signals continue to run, but transaction layer activity returns to zero, heartbeat monitoring of the verification IP is interrupted, and no error logs are output. Related art approaches to address this test case hang phenomenon typically provide a simulation timeout exit function by setting a timeout. Specifically, a fixed timeout is set from the start of test case execution until the simulation reaches the timeout. If the test case has not yet completed, a prompt message is displayed and the simulation exits. While this timeout exit method can address the problem of test cases being unable to automatically terminate the simulation due to abnormal hangs, it is difficult to determine a reasonable range for the timeout. The timeout is set to the maximum acceptable time for the simulation, meaning that the test case will not exceed this timeout under normal execution. During the actual debugging process, two common situations will be encountered: one is that the timeout time is estimated to be too small, some test cases are executed normally, and no exceptions occur, so the simulation is stopped by the timeout mechanism; the other is that the test case has an exception at the beginning of the execution, but it needs to wait until the simulation reaches the set timeout time to be stopped. For the first problem, although different test cases can be set separately, it adds a certain amount of workload to the verification personnel, and its reasonable range is difficult to estimate. For the second problem, a solution based on this timeout mechanism has not yet been found. With the advancement of the verification progress, the increase in the number of test cases and the start of large-scale regression, the setting of the timeout time is likely to be adjusted repeatedly. Based on the above content, the present invention provides a simulation testing method.

[0025] The embodiment of the present application provides a simulation test method, Figure 1 Flowchart of a simulation test method according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0026] Step S101 : performing a simulation test on the design to be tested, and counting down the working clock of the design to be tested based on a preset timer.

[0027] In the UVM (Universal Verification Methodology) verification environment, a simulation environment is built that includes the design under test (DUT) and the testbench. Initialize the simulation environment, including setting clock signals, reset signals, input stimuli, etc., and simulate the DUT using test cases. The preset timer is a watchdog timer. When simulating the DUT, the output of the DUT is detected, and the test case starts the preset timer while issuing the stimulus test sequence. Define and create a watchdog timer class, which contains member variables for the counter and the timer initial value. Declare and create a watchdog timer instance in the test case, and set its initial value.

[0028] After the preset timer starts, it counts down based on the main working clock of the design under test. This technical process accompanies the entire execution of the test case. At the end of each clock cycle, the counter is decremented by 1. If the design under test has multiple working clocks, the main working clock of the design under test is selected.

[0029] Step S102: detecting the output result of the design to be tested.

[0030] Set up a monitoring component within the monitoring class. Specifically, you can set a task function to detect the output port of the DUT and collect the output results of the DUT. A preset timer starts counting from the initial value based on the DUT's operation. Feeding the timer is performed in the component that detects the DUT's output. This is triggered when the monitoring component collects the DUT's output results. Determining the initial value requires consideration of the DUT's transaction processing delay, the test case's transaction interval, and the maximum backpressure delay of the verification environment's handshake signal for the DUT.

[0031] Step S103: If no output result is detected at the end of counting, the simulation test of the design to be tested is stopped.

[0032] The end of the preset timer count indicates that the watchdog timer has counted down to 0. If no output result is detected, the watchdog feeding operation cannot be performed. If the watchdog feeding signal is not received when the preset timer counts to 0, it is determined that there is an abnormality and the simulation test ends. Specifically, uvm_fatal can be called to end the simulation test. uvm_fatal is a macro or function call used to report serious errors. When an unrecoverable error occurs in the verification environment, uvm_fatal will be called to stop the simulation and output detailed error information. The error information includes the simulation time of the timeout event, the name of the design to be tested, etc., which facilitates developers to conduct subsequent problem analysis and debugging.

[0033] The timer and the stimulus data transmission sequence are started simultaneously in parallel through fork join_any (used to execute multiple processes in parallel and stop all processes immediately after any one process completes). When one of them is completed, all processes are terminated, and the simulation ends. If the test case executes normally, the watchdog_timer task (watchdog timer) is stopped through disable fork (a key statement used to control concurrent processes, used to forcibly terminate all parallel processes started by the current fork, regardless of whether these processes have completed), and the test case execution ends normally. If the execution reaches the watchdog_timer timeout condition, the simulation is directly terminated through uvm_fatal, and the test case execution fails.

[0034] The simulation test method provided by an embodiment of the present invention includes performing a simulation test on a design to be tested, and counting down the working clock of the design to be tested based on a preset timer; detecting the output result of the design to be tested; and stopping the simulation test of the design to be tested if no output result is detected at the end of the counting. The present invention determines whether the design to be tested is in an abnormal state by detecting the output of the design to be tested in real time, and automatically stops the simulation if an abnormal state exists. There is no need to set a timeout detection time, which simplifies the management of test cases, thereby improving the efficiency of simulation testing, accelerating the advancement of verification tasks, and solving the problem of hanging up easily during simulation testing.

[0035] An embodiment of the present application provides a simulation test method, which includes the following steps:

[0036] Step S201 : performing a simulation test on the design to be tested, and counting down the working clock of the design to be tested based on a preset timer.

[0037] Specifically, step S201 of performing simulation test on the design to be tested includes: sending a stimulus data sequence based on a test case to perform simulation test on the design to be tested, wherein the sending of the stimulus data sequence and the starting of a preset timer are started in parallel.

[0038] In a simulation test environment, test cases are the basis of simulation testing, describing the purpose of the test, input conditions, expected outputs, and test steps. Test cases are implemented in the form of classes and include components such as stimulus generation, DUT monitoring, and result comparison. When designing test cases, the functional requirements, design specifications, and potential error modes of the DUT are fully considered to ensure the comprehensiveness and effectiveness of the test. Stimulus data sequences are generated based on the requirements of the test cases and simulate the input signals that the DUT may receive in actual applications. Stimulus data sequences can include clock signals, reset signals, data input signals, etc., depending on the functions and interfaces of the DUT. When generating stimulus data sequences, factors such as the timing relationship of the signals, the validity and legality of the data need to be considered to ensure that the DUT can correctly receive and process these signals.

[0039] Before simulation testing begins, the verification environment sends stimulus data sequences to the design under test, as described in the test case. This transmission process is accomplished by the verification environment's stimulus generation component, which is responsible for generating and sending stimulus signals according to the predetermined timing and format. Simultaneously, other components in the verification environment begin operating synchronously to monitor the output signals of the design under test in real time and compare them with expected results.

[0040] The preset timer is a watchdog timer used to detect the execution time of test cases. Before the simulation test begins, the timer's initial value must be set. After the timer starts, it counts down based on the working clock of the design under test. Each time a working clock cycle of the design under test ends, the timer counts down once. The preset timer class defines two unsigned integer member variables: one that serves as a counter; the other is the timer's initial value, which serves as the time interval for exception checks. The initial value is assigned to the counter in the new function of the class. The main purpose of defining this class is to implement synchronous operation of the watchdog timer. Because the counting and feeding of the watchdog timer are implemented in different UVM components, the counting operation must be able to promptly receive the reset of the counter by the feeding operation. The class handle reference can achieve real-time synchronization of the member variable values ​​in the class.

[0041] Step S202: detecting the output result of the design to be tested.

[0042] Specifically, step S202 includes: detecting the output result of the design to be tested based on a preset time interval, wherein the preset time interval is determined based on the delay time of the design to be tested processing transactions, the interval time of the test case sending transactions, and the maximum value of the back pressure delay time of the handshake signal of the design to be tested in the verification environment.

[0043] A preset timer is declared and created in a test case, and its initial value is set. The initial value is the preset time interval, which is the time interval for detecting anomalies in the test case. The preset time interval is set as follows:

[0044] (1) The delay is set based on the actual delay of a transaction transmission to be tested. After the design is determined, the delay becomes a fixed value and does not need to be repeatedly adjusted according to different test cases. That is, the delay time of the transaction to be tested is designed to be processed.

[0045] (2) Taking into account the delay between transactions sent in the stimulus sequence, in order to avoid the watchdog timer from erroneously triggering a watchdog timeout event and ending the simulation due to the initial value being set too small, the initial value of the watchdog timer can be set to be larger than the delay, even if it is set to 3 to 5 times the delay. The delay between the two transactions sent for the test case can be known from the verification environment. The maximum value of the delay for sending transactions set in the environment can be added to the initial value of the watchdog.

[0046] (3) When there is a handshake between the interface signal of the design to be tested and the external connection, the impact of backpressure delay needs to be considered. For example, in the handshake process of the valid and ready signals in the AMBA bus (Advanced Microcontroller Bus Architecture, an open standard on-chip interconnect bus protocol), when testing the backpressure of the external signal on the design to be tested, the design to be tested sends a valid signal, but the verification environment needs to wait a certain delay before replying with a ready signal. For this scenario, the initial value setting of the watchdog timer also needs to take into account the handshake delay.

[0047] In some optional implementations, the preset time interval is determined according to the following formula:

[0048] T WDT_init =T DUT_delay +T tr_delay_max +T handshake_delay_max

[0049] Among them, T WDT_init Indicates the preset time interval, T DUt_delay Indicates the delay time of the design to be tested processing transaction, T tr_delay_max Indicates the interval time between sending transactions for the test case. Indicates the maximum backpressure delay time of the verification environment for the handshake signal of the design to be tested. If the test case does not have any handshake signal, this value is 0.

[0050] We comprehensively consider the DUT's processing capabilities, the dynamic behavior of the verification environment, and the characteristics of the protocol handshake to ensure that the initial values ​​cover all possible scenarios. By setting the initial values ​​appropriately, we avoid false triggers caused by normal DUT processing delays, transaction intervals, or handshake backpressure, ensuring that the verification environment only terminates simulation under abnormal circumstances.

[0051] The watchdog timer class only needs to declare a reference handle in the monitoring class, and does not need to be created. Establish a connection between the watchdog timer class in the monitoring class and the watchdog timer class in the test case. In the test case, the watchdog timer class handle is referenced to the watchdog timer class handle of the monitoring class by assignment, which can achieve counter value synchronization. Figure 2 As shown, Figure 2 This is a schematic diagram of the association of watchdog timing in the general verification methodology components. Among them, input_agent is a core component responsible for managing and controlling the stimulus generation, signal driving, and protocol monitoring of the input interface of the design under test (DUT). It is a key module for achieving functional coverage and defect detection in the verification environment, and its design directly determines the flexibility of test cases and verification efficiency. It includes the UVM sequencer class, UVM driver class, and UVM monitoring class. output_agent is a core component in the verification environment specifically used to monitor and analyze the behavior of the output interface of the design under test. Unlike the active input drive of input_agent, the core task of output_agent is to passively capture the output signal of the DUT, verify whether it meets the design specifications, and feed the results back to the verification environment to determine whether the test passes. The scoreboard is used to compare reference data with the output data of the module to be verified.

[0052] Step S203: If the output result is not detected when counting ends, the simulation test of the design to be tested is stopped.

[0053] Specifically, step S203 includes: after each counting operation, determining whether the counting result is 0; if the counting result is 0, stopping the simulation test of the design to be tested.

[0054] The counting process of the preset timer accompanies the entire execution process of the test case, that is, the preset timer starts at the beginning of the test case and stops at the end of the test case. Therefore, the counting logic of the preset timer is encapsulated in an infinite loop to ensure that it can continue to run until the test case is completed normally or terminated due to timeout.

[0055] The preset timer operates based on the DUT's operating clock. Each time a DUT clock cycle ends, the preset timer counts down. If the preset timer has multiple operating clocks, the master clock (the highest frequency or most core clock) is used as the counting reference. This ensures that the preset timer's counting rate matches the DUT's actual operating frequency, improving monitoring accuracy.

[0056] After each counting operation, the preset timer checks whether the current value is 0. If the value of the preset timer becomes 0 after counting, it means that the execution time of the test case has exceeded the timeout limit. At this time, the timer will trigger the timeout processing logic.

[0057] If the timeout logic is triggered, the simulation termination function (such as uvm_fatal) is called to stop the simulation test process. This process prevents the simulation test from running infinitely due to exceptions. It also provides clear error information to facilitate debugging by relevant technicians.

[0058] In some optional implementations, the method further includes: if an output result of the design to be tested is detected, resetting a preset timer to an initial value.

[0059] The initial value represents the timeout value of the preset timer, which is the preset time interval for detecting the design to be tested.

[0060] In the monitoring class's task function for collecting the output data of the design under test, once data output from the design under test is detected during the simulation test, the preset timer is reset to its initial value. The monitoring class references the preset timer object instantiated in the test case through a handle. Because the handle points to the same object, the monitoring class's operations on the timer directly affect the timer instance in the test case, meaning that the timer counter in the test case is also reset to its initial value, thus implementing the dog feeding mechanism.

[0061] Alternatively, as Figure 3 As shown, Figure 3 To verify the existence of intermediate monitoring nodes for the DUT in the verification environment. In a verification environment where there are multiple monitoring points for the DUT, set the preset timer's dog feeding operation in the detection class of the last-level monitoring point (i.e., the final output interface of the DUT) to avoid the situation where the previous-level modules of the DUT link process normally while the subsequent-level modules abnormally hang and cannot be detected.

[0062] In some optional implementations, the method further includes: if the simulation test of the design to be tested on all stimulus data sequences is completed, stopping the simulation test on the design to be tested.

[0063] During the verification process, test cases typically generate a series of stimulus data and apply it to the DUT. The simulation test concludes naturally when all pre-defined stimulus data sequences have been successfully applied and the DUT responds to these stimuli as expected. This conclusion is ideal, indicating that the DUT performed correctly under all test scenarios.

[0064] This ensures that test cases complete normally after completing all pre-set test scenarios. This mechanism not only improves the automation level of the verification environment, but also provides developers with a clear test completion signal, helping to improve verification efficiency and reliability.

[0065] In some optional embodiments, the timer and the sending stimulus data sequence are started in parallel at the same time by fork join_any (for executing multiple processes in parallel, and stopping all processes immediately after any one process is completed), and one of them is executed, then all processes are terminated, and the simulation is terminated. When the test case is normally executed, the watchdog_timer task (watchdog timer) can be stopped by disable fork (a key statement for controlling concurrent processes, for forcibly terminating all parallel processes started by the current fork, regardless of whether these processes have been completed), and the test case is normally executed and ends. If the execution reaches the timeout condition of watchdog_timer, the simulation will be directly stopped by uvm_fatal, and the test case execution fails.

[0066] The present invention incorporates a watchdog timing mechanism into a verification environment to detect abnormalities in a design under test, wherein the working clock of the design under test is a timer count event, and the valid data output of the design under test is a dog-feeding signal. This method addresses the hangup problem encountered during test case development and debugging. By utilizing the watchdog timing mechanism and detecting the output of the design under test in real time, it determines whether the design under test is in an abnormal state, thereby controlling whether to force the simulation to automatically stop. Automatically terminating the simulation upon watchdog timer expiration simplifies test case management, improves test case debugging efficiency, and accelerates verification tasks.

[0067] The embodiment of the present invention provides a simulation test method, such as Figure 4The test case execution process shown in the figure incorporates a watchdog timer. Test cases are a core component of the verification process, defining the input stimuli to be applied to the DUT and the expected output responses. During the stimulus test sequence, the test case generates a series of transactions using a sequencer. These transactions are then converted by a driver into a signal sequence that the DUT can understand and send to the DUT's input ports. While sending stimulus data, the test case also monitors the DUT's output status. This is typically accomplished using a monitor component, which captures the DUT's output signals and converts them into transactions for subsequent comparison with expected results. However, in some cases, the DUT may stop outputting data due to internal faults or abnormal conditions, stalling the verification process. To address this issue, a watchdog timer mechanism is introduced into the test case.

[0068] At the start of a test case, the watchdog timer is initialized to a preset timeout value and begins counting. This timeout value is set based on the expected response time of the DUT and the verification requirements, typically slightly longer than the time required for the DUT to process the longest stimulus sequence. Starting from the initial value, the watchdog timer counts down based on the DUT's operating clock. The timer's counting speed is synchronized with the DUT's processing speed, accurately reflecting the DUT's actual operating status.

[0069] In the component that monitors the DUT output (i.e., the monitoring component), whenever valid DUT output data is collected, a watchdog feeding operation is triggered. This operation is implemented by sending a reset signal to the watchdog timer, which resets the timer count value to the initial value, indicating that the DUT is still operating normally and successfully processing the stimulus data.

[0070] If no feed signal is received when the watchdog timer reaches 0, meaning the monitoring component hasn't collected any output data from the DUT, the DUT is considered abnormal. At this point, the watchdog timer triggers a timeout event, and the test case calls the uvm_fatal task to terminate the simulation. The uvm_fatal task in UVM (Universal Verification Methodology) is used to report serious errors and terminate the simulation. It ensures that the verification process stops immediately upon detecting an anomaly, avoiding wasted simulation time.

[0071] In this method, a test case can be concluded in two ways: normal simulation termination and abnormal simulation termination. Normal simulation termination: When all test sequences have been sent and successfully processed by the DUT, the test case has achieved its intended verification objective. At this point, the test case verifies the functional correctness of the DUT by checking the response status of all stimulus sequences and concludes the simulation normally. This indicates that the DUT performed well under the given test conditions and met the design requirements.

[0072] Abnormal simulation termination: If the monitoring component fails to detect DUT output data within the watchdog timer's timeout period, the DUT is considered abnormal. At this point, the watchdog timer triggers a timeout event, and the test case calls the uvm_fatal task to terminate the simulation. This method promptly identifies potential DUT failures or abnormal conditions, preventing the simulation process from becoming stuck in an infinite loop or stalling for extended periods due to DUT unresponsiveness. This abnormal simulation termination mechanism allows verification personnel to quickly identify the problem and conduct targeted debugging and repairs.

[0073] The present invention incorporates a watchdog timing mechanism into a verification environment to detect abnormalities in a design under test, wherein the working clock of the design under test is a timer count event, and the valid data output of the design under test is a dog-feeding signal. This method addresses the hangup problem encountered during test case development and debugging. By utilizing the watchdog timing mechanism and detecting the output of the design under test in real time, it determines whether the design under test is in an abnormal state, thereby controlling whether to force the simulation to automatically stop. Automatically terminating the simulation upon watchdog timer expiration simplifies test case management, improves test case debugging efficiency, and accelerates verification tasks.

[0074] The dog feeding operation of the watchdog timer during the implementation of the present invention is implemented in the monitoring class, but it is not the only way. In the UVM verification platform, any component that can monitor the output of the design to be tested can be used to implement the dog feeding operation, such as in the function of the TLM (transaction level modeling) that receives the monitoring class output in the scoreboard (scoreboard).

[0075] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0076] The embodiment of the present application also provides a simulation test device, such as Figure 5 As shown, including:

[0077] A counting module, configured to perform a simulation test on the design to be tested and count down the working clock of the design to be tested based on a preset timer;

[0078] A result detection module, used to detect the output result of the design to be tested;

[0079] The test stop module is used to stop the simulation test on the design to be tested if the output result is not detected at the end of counting.

[0080] In some optional embodiments, the result detection module includes:

[0081] An output result detection unit is used to detect the output result of the design to be tested based on a preset time interval, where the preset time interval is determined based on the maximum value of the delay time of the design to be tested in processing transactions, the interval time of the test case sending transactions, and the back pressure delay time of the handshake signal of the design to be tested in the verification environment.

[0082] In some optional implementations, the preset time interval is determined according to the following formula:

[0083] T WDT_init =T DUT_delay +T tr_delay_max +T handshake_delay_max

[0084] Among them, T WDT_init Indicates the preset time interval, T DUT_delay Indicates the delay time of the design to be tested processing transaction, T tr_delay_max Indicates the interval time between sending transactions for the test case. Indicates the maximum backpressure delay time of the handshake signal of the design under test in the verification environment.

[0085] In some optional implementations, stopping the test module includes:

[0086] A counting result judging unit, used to judge whether the counting result is 0 after each counting operation;

[0087] The test stop unit is used to stop the simulation test on the design to be tested if the counting result is 0.

[0088] In some optional embodiments, the device comprises:

[0089] The reset module is used to reset the preset timer to an initial value if the output result of the design to be tested is detected.

[0090] In some optional embodiments, the counting module includes:

[0091] A test unit, configured to send a stimulus data sequence based on a test case to perform a simulation test on the design to be tested;

[0092] The sending excitation data sequence and the preset timer are started in parallel.

[0093] In some optional embodiments, the device further comprises:

[0094] The second stopping module is configured to stop the simulation test on the design to be tested if the simulation test on all the stimulus data sequences of the design to be tested is completed.

[0095] For the description of the features in the embodiment corresponding to the simulation test device, please refer to the relevant description of the embodiment corresponding to the simulation test method, and no further details will be given here.

[0096] The embodiment of the present application also provides a computer device, such as Figure 6 As shown, it includes a memory 10 and a processor 20, the memory 10 stores a computer program, and the processor 20 is configured to run the computer program to execute the steps in any one of the above simulation test method embodiments.

[0097] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned simulation test method embodiments when running.

[0098] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0099] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above-mentioned simulation test method embodiments are implemented.

[0100] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned simulation test method embodiments are implemented.

[0101] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0102] The above is a detailed introduction to a simulation test method, device, computer equipment and storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A simulation test method, characterized in that: include: Performing a simulation test on the design to be tested, and counting down the working clock of the design to be tested based on a preset timer; detecting an output result of the design to be tested; If the output result is not detected at the end of counting, the simulation test on the design to be tested is stopped.

2. The simulation test method according to claim 1, wherein: The detecting the output result of the design to be tested includes: The output result of the design to be tested is detected based on a preset time interval, and the preset time interval is determined based on the delay time of the design to be tested processing transactions, the interval time of the test case sending transactions, and the maximum value of the back pressure delay time of the handshake signal of the design to be tested in the verification environment.

3. The simulation test method according to claim 2, wherein: The preset time interval is determined according to the following formula: T WDT_init =T DUT_delay +T tr_delay_max +T handshake_delay_max Among them, T WDT_init Indicates the preset time interval, T DUT_delay Indicates the delay time of the design to be tested processing transaction, T tr_delay_max Indicates the interval time between sending transactions for the test case, T handshakedelay _ max Indicates the maximum backpressure delay time of the handshake signal of the design under test in the verification environment.

4. The simulation test method according to claim 1, wherein: If the output result is not detected at the end of counting, stopping the simulation test on the design to be tested includes: After each counting operation, determine whether the counting result is 0; If the counting result is 0, the simulation test on the design to be tested is stopped.

5. The simulation test method according to claim 1, wherein: The method further comprises: If the output result of the design to be tested is detected, the preset timer is reset to an initial value.

6. The simulation test method according to claim 1, wherein: The simulation test of the design to be tested includes: Sending a stimulus data sequence based on a test case to perform a simulation test on the design to be tested; The sending excitation data sequence and the preset timer are started in parallel.

7. The simulation test method according to claim 6, wherein: The method further comprises: If the simulation test of the design to be tested on all the stimulus data sequences is completed, the simulation test of the design to be tested is stopped.

8. A simulation test device, characterized in that: include: A counting module, configured to perform a simulation test on the design to be tested and count down the working clock of the design to be tested based on a preset timer; A result detection module, used to detect the output result of the design to be tested; The test stop module is used to stop the simulation test on the design to be tested if the output result is not detected at the end of counting.

9. A computer device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the simulation test method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the simulation test method according to any one of claims 1 to 7.

Images