System-level random verification method and system for general MCU verification platform

Abstract

The invention provides a system-level random verification method and system for a general MCU verification platform, and relates to the technical field of simulation verification, and the method comprises the steps: generating random excitation in a hardware environment based on a random variable and a hardware constraint condition, and storing the random excitation in a verified device; the MCU of the verified equipment calls the stored random excitation and adds a software constraint condition, and then the random excitation subjected to software constraint is used for random simulation to obtain a simulation result; the hardware environment reads the random excitation after the software constraint to generate an expected result, and when the expected result and the simulation result are compared to be inconsistent, warning information is output to complete random verification. The method has the beneficial effects that various possible sequential relationships can be simulated, so that the verification process can cover more scenes and conditions, and the verification comprehensiveness is improved. Therefore, the randomization capability is greatly enhanced; the method can be compatible with any existing MCU verification platform, does not affect the existing verification environment, and only expands the functions of the existing verification environment.

Description

Technical Field

[0001] The present invention relates to the field of simulation verification technology, and in particular to a system-level random verification method and system for a universal MCU verification platform. Background Art

[0002] A microcontroller unit (MCU) is an integrated circuit that integrates a central processing unit (CPU), memory, and other peripherals. It is widely used in industrial control, medical equipment, automotive electronics, and other fields. In order to ensure the reliability and stability of the system, simulation verification technology plays a vital role. In the simulation verification process of MCU, module-level verification often uses a random verification method based on System Verilog, while system-level verification focuses on directional verification, the main purpose of which is to check the accuracy of the connection relationship between systems.

[0003] MCU is usually designed as a system containing multiple clock domains. Taking the clock system of a 32-bit MCU as an example, it may include five clocks, such as external high-speed clock HSE, internal high-speed clock HRC, internal low-speed clock LRC, external low-speed clock LSE and phase-locked loop clock PLL, to meet the working requirements of normal function and low power mode. These clocks are not only used for different modules and modes, but also allow users to perform operations such as frequency division and switching system clocks at any time when the MCU is running, making the actual working timing of the MCU very complicated. In addition, the modules of the MCU also integrate various communication protocols, and the uncertainty of these protocols during data transmission (such as data length, transmission timing and clock rate, etc.) will produce more complex timing problems. When faced with verification difficulties such as cross-clock domain, clock phase, clock division, etc. brought by complex timing, as well as verification points of many deterministic functions of each module of the MCU, it is often difficult for verification personnel to fully consider them in system-level verification, and it is also difficult to conduct effective verification through targeted test cases.

[0004] At present, random verification methods are mainly implemented through the System Verilog language in the simulation environment. As a hardware description language, SystemVerilog supports behavioral level, register transfer level (RTL) and gate level descriptions, and has been widely used in the design and verification of digital circuits. In System Verilog, random test vectors can be generated by defining random environments, and tests can be performed through read and write operations with MCU registers. Although the existing random verification methods have improved the efficiency and coverage of verification to a certain extent, they still face some challenges and limitations. Although the current MCU verification methods can randomize the working scenarios of modules to a certain extent, their randomization capabilities are still insufficient when dealing with the verification of timing interactions between modules or complex usage scenarios. Summary of the invention

[0005] In view of the problems existing in the prior art, the present invention provides a system-level random verification method for a universal MCU verification platform, comprising: step S1, generating a random stimulus based on random variables and hardware constraints in a hardware environment and storing it in a verified device; step S2, the MCU of the verified device retrieves the stored random stimulus and adds software constraints, and then uses the random stimulus after the software constraints for random simulation to obtain a simulation result; step S3, the hardware environment reads the random stimulus after the software constraints to generate an expected result, and outputs a warning message to complete the random verification when the expected result is compared and the simulation result is inconsistent.

[0006] Preferably, the step S1 includes: step S11, generating an initial random excitation according to the random variable in the hardware environment; step S12, limiting the range of the initial random excitation according to the hardware constraints in the hardware environment, and / or eliminating numerical values ​​to complete the constraints to obtain the random excitation and store it in the verified device.

[0007] Preferably, after executing the step S1, an incentive monitoring process is also included, including: the hardware environment monitors the random incentive stored in the verified device, and when the random incentive is called, the step S1 is executed again to regenerate the random incentive and store it in the verified device.

[0008] Preferably, a storage space is provided in the verified device, and the random stimulus is stored in the storage space. After executing the step S1, a stimulus rewriting process is also included, including: the hardware environment monitors the storage space, and when data in the storage space is lost, the generated random stimulus storage is written into the storage space again.

[0009] Preferably, each simulation result is associated with a log information, and the time in the hardware environment is used as the random variable; each time the simulation result is obtained, the corresponding random variable is recorded in the associated log information.

[0010] Preferably, the random simulation process is that the MCU is configured according to the random stimulus, and after the configuration is completed, a pre-written function is executed in the MCU to obtain a corresponding simulation result.

[0011] Preferably, the MCU requires at least two random stimuli for configuration; then in the step S1, the hardware environment obtains an external stimulus after generating the random stimulus, and stores the random stimulus and the external stimulus in the MCU; during the random simulation process, the MCU is configured according to the random stimulus and the external stimulus.

[0012] The present invention also provides a system-level random verification system of a universal MCU verification platform, which applies the above-mentioned random verification method and includes a stimulus generation environment and a verified device; the hardware environment in the stimulus generation environment includes: a random stimulus generation module, which is used to generate the random stimulus according to the random variable and the hardware constraint condition, and store it in the storage space of the verified device; a first monitoring module, which is used to monitor the configuration of the MCU of the verified device during the random simulation process, and monitor the random stimulus in the storage space; an expectation generation module, which is connected to the first monitoring module, and is used to receive the configuration sent by the first monitoring module and generate the corresponding expected result; a second monitoring module, which is used to monitor the simulation result generated by the random simulation of the MCU; a scoreboard module, which is connected to the expectation generation module and the second monitoring module, and is used to compare the simulation result with the expected result, and output a warning message to complete the random verification when the simulation result and the expected result are inconsistent; the operating environment in the stimulus generation environment is configured in the MCU of the verified device, and includes: a software constraint module, which is connected to the storage space, and is used to call the random stimulus in the storage space and add software constraints, and configure the MCU according to the random stimulus after the software constraints.

[0013] Preferably, the hardware environment also includes an external excitation module, which is connected to the random excitation generation module and the first monitoring module, and is used to obtain external excitation when the MCU requires at least two random excitations for configuration, and constrain the external excitation with the random excitation, and send the constrained external excitation to the MCU.

[0014] Preferably, the first monitoring module also includes: a re-randomization unit, used to drive the random stimulus generation module to regenerate the random stimulus and store it in the storage space when the random stimulus is called; and a re-write unit, used to monitor the storage space and write the generated random stimulus storage into the storage space again when data in the storage space is lost.

[0015] The above technical solution has the following advantages or beneficial effects: 1. By generating random stimuli based on random variables and hardware constraints in the hardware environment, various complex MCU working scenarios can be simulated more flexibly. Various possible timing relationships can be simulated to ensure that the verification process can cover more scenarios and situations, and improve the comprehensiveness of verification. This greatly enhances the ability of randomization.

[0016] 2. It is compatible with any existing MCU verification platform and will not affect the existing verification environment. It is just an expansion of the existing verification environment functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A schematic flow chart of a system-level random verification method for a general MCU verification platform in a preferred embodiment of the present invention; Figure 2 This is a flow chart of step S1 in a preferred embodiment of the present invention; Figure 3 The structure diagram of a system-level random verification system of a universal MCU verification platform in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0018] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment, and other embodiments may also fall within the scope of the present invention as long as they conform to the gist of the present invention.

[0019] In a preferred embodiment of the present invention, based on the above problems existing in the prior art, a system-level random verification method for a general MCU verification platform is provided. Figure 1 As shown, it includes: step S1, generating random excitation based on random variables and hardware constraints in a hardware environment and storing it in a verified device; step S2, the MCU of the verified device calls the stored random excitation and adds software constraints, and then uses the random excitation after the software constraints for random simulation to obtain simulation results; step S3, the hardware environment reads the random excitation after the software constraints to generate expected results, and outputs a warning message to complete the random verification when the expected result is inconsistent with the simulation result.

[0020] Specifically, in this embodiment, in the random verification of the MCU, the random stimulus refers to a random test vector or data packet generated by a simulation environment for testing the functions and performance of the MCU. These random stimuli are intended to simulate various situations that the MCU may encounter in actual applications to verify the performance and stability of the MCU in different scenarios.

[0021] Specifically, random stimulus can include various types of stimulus signals, such as clock signals, reset signals, register configuration signals, data input signals, etc. These stimulus signals are generated randomly in the simulation environment and act on the input of the MCU according to a certain timing and logical relationship. By observing and analyzing the output response of the MCU after receiving these random stimuli, the verification personnel can evaluate the functional correctness, performance stability and ability to handle complex timing of the MCU.

[0022] In the random verification process, the generation of random excitation is one of the key steps. In order to ensure the comprehensiveness and effectiveness of the verification, the random excitation needs to cover various situations that the MCU may encounter, including normal operation, abnormal operation, boundary conditions, etc. At the same time, the generation of random excitation also needs to consider the characteristics and application scenarios of the MCU to ensure that the generated excitation signal meets the actual working requirements of the MCU.

[0023] The random verification method in this embodiment can more flexibly simulate various complex MCU working scenarios by generating random excitations based on random variables and hardware constraints in a hardware environment. This random excitation not only takes into account the constraints at the hardware level, but also can be further customized and constrained at the software level, thereby greatly enhancing the randomization capability.

[0024] By introducing random excitations, various possible timing relationships can be simulated, thereby ensuring that the verification process can cover more scenarios and situations and improving the comprehensiveness of the verification.

[0025] For complex usage scenarios, by combining random excitation at the hardware and software levels, actual usage can be simulated more accurately. This helps to discover potential problems and defects and improve the reliability and stability of the MCU.

[0026] It is compatible with any existing MCU verification platform and will not affect the existing verification environment. It is just an extension of the existing verification environment function. It will not affect the original verification cases, increase the cases, or increase the workload of the verification personnel. It also provides a simple method for verification points such as protocols and timing that require a large number of verification cases.

[0027] Furthermore, in a preferred embodiment of the present invention, the random stimulus is generated by step S1, such as Figure 2 As shown, step S1 includes: step S11, generating an initial random stimulus according to random variables in a hardware environment; step S12, limiting the range of the initial random stimulus according to hardware constraints in the hardware environment, and or eliminating values ​​to complete the constraints to obtain the random stimulus and store it in the verified device.

[0028] Specifically, in this embodiment, the clock source selection is taken as a random variable for example: Step S11: Generate initial random stimulus (based on clock source selection) Core logic: Encode clock configuration parameters in random numbers to generate raw 32-bit values.

[0029] 1. Define the random variable field (32-bit structure)

[0030] Clock source selection (4 bits) 0x0: HRC (internal 64MHz) 0x1: HSE (external 8MHz) 0x2: LSE (internal 30KHZ) 0x3: LRC (external 32.768KHZ) 0x4: PLL (Phase-Locked Loop Output) Other values: HRC PLL multiplication factor (4 bits): AHB frequency division coefficient (4 bits): Random value 0x0 (no frequency division), 0x1 (frequency division by 2), 0x2 (frequency division by 4), 0x3 (frequency division by 8) 2. Generate initial random numbers (example) Generate a 32-bit value using the simulation environment random engine (seed=0x5A3D): 0x42A30000 (binary: 0100 0010 1010 0011 0000 0000 0000 0000) Parsing fields: Clock source selection: 0100 (bits 31-28 → value 0x4, corresponding to PLL) PLL multiplication factor: 0010 (bits 27-24 → value 0x2, multiplication × 2) AHB division factor: 1010 (bits 23-20 → value 0xA, illegal) Reserved bits: All 0 Step S12: Apply hardware constraint correction Only illegal fields are corrected, and legal random values ​​are retained.

[0031] 1. Clock source selection constraints If the clock source field value (0x0 / 0x1 / 0x4) indicates a fast clock, the clock is configured for normal frequency division. If the clock source field value (0x2 / 0x3) indicates a slow clock, you can choose not to divide the frequency, limit the frequency division size, or replace it with another clock according to actual needs.

[0032] 2. PLL frequency multiplication factor constraints If the multiplication factor is <0x3 → set to the minimum value 0x3 (×3) If the multiplication factor is >0xC → set to the maximum value 0xC (×12) In this example, the multiplication factor is 0x2 (×2), which is corrected to 0x3 (×3).

[0033] 3. AHB division coefficient constraints Only 0x0 / 0x1 / 0x2 / 0x3 are allowed, and other values ​​are modified according to priority: If the value > 0x3 → take the maximum legal value 0x3 (divide by 8) In this example, the division factor is 0xA (decimal 10), which is corrected to 0x3 (division by 8).

[0034] 4. Re-encode legal values Corrected fields: Clock source selection: 0100 (PLL) PLL multiplication factor: 0011 (×3) AHB frequency division coefficient: 0011 (8 frequency division) Reserved bits: unchanged Final legal incentive value: 0x43330000 (binary: 0100 0011 0011 0011 0000 0000 0000 0000) The random stimulus after hardware constraints is stored in the storage space of the device to be verified, which usually refers to the storage space inside the MCU.

[0035] In a preferred embodiment of the present invention, after executing step S1, an incentive monitoring process is also included, including: the hardware environment monitors the random incentive stored in the verified device, and when the random incentive is called, executes step S1 again to regenerate the random incentive and store it in the verified device.

[0036] Specifically, in this embodiment, when the random stimulus in the verified device is called, the hardware environment can regenerate the random stimulus and store it in the verified device. This ensures that the random stimulus is updated in real time and is consistent with the current state of the verified device, thereby improving the accuracy of verification.

[0037] By regenerating random stimuli when they are called, it is possible to cope with state changes that may occur in the device under verification during simulation. This enhances the robustness of verification and makes the verification process more reflective of the complexity of actual use cases.

[0038] In some complex scenarios, the state of the verified device may change due to various factors. Step S13 allows regeneration each time the random stimulus is called, so as to simulate these complex scenarios and ensure the comprehensiveness and reliability of the verification.

[0039] In a preferred embodiment of the present invention, for system-level verification of the MCU, the verified device (MCU) has storage space, and the random stimulus is stored in the storage space and taken out when used. After executing the step S1, it also includes a stimulus rewriting process, including: the hardware environment monitors the storage space, and when the data in the storage space is lost, the generated random stimulus storage is written into the storage space again.

[0040] Specifically, in this embodiment, the state of the data in the storage space is also monitored in real time. When the data in the random excitation storage module is lost due to power failure or low power consumption mode in the simulation, it is necessary to rewrite the random excitation storage module in time to ensure the integrity of the data in the storage space.

[0041] This is critical to the accuracy and reliability of the verification process, as any loss of data may lead to bias or failure of the verification results.

[0042] It can ensure that the verification process can continue seamlessly after the device returns to normal. This avoids interrupting the verification process due to data loss and improves the continuity and efficiency of verification.

[0043] In a preferred embodiment of the present invention, each simulation result is associated with a log information, and the time in the hardware environment is used as a random variable; each time a simulation result is obtained, the corresponding random variable is recorded in the associated log information.

[0044] Specifically, before setting up the random stimulus generation environment, the script in the verification environment needs to support passing the random seed (i.e., the random variable in step S1) to the verification environment. Generally speaking, the time is set to the passed random seed, because the time in the simulation environment is constantly changing, which can ensure that the random seed is different each time. At the same time, the seed information should also be added when saving the log information of the simulation results; when the verification case in the random environment is completed, a regression test will be performed. The log information plus the random seed can save the complete regression information, which is convenient for reproducing the problem.

[0045] In a preferred embodiment of the present invention, the random simulation process is that the MCU is configured according to the random stimulus, and after the configuration is completed, a pre-written function is executed in the MCU to obtain a corresponding simulation result.

[0046] Specifically, the random stimulus generation environment is divided into a hardware environment and a software environment. The software environment is configured in the MCU of the device being verified. The software environment is essentially a function program used to read random stimulus. When the program knows the random stimulus, it can perform corresponding configuration.

[0047] In a preferred embodiment of the present invention, the MCU requires at least two random stimuli for configuration; then in step S1, after the hardware environment generates the random stimulus, it also obtains the external stimulus and stores the random stimulus and the external stimulus in the MCU; during the random simulation process, the MCU is configured according to the random stimulus and the external stimulus.

[0048] Specifically, in some cases, the MCU needs at least two random stimuli for configuration. At this time, it is not possible to perform simulation verification by relying solely on a random stimulus generated by the hardware environment. At this time, an external stimulus is required to cooperate with the random stimulus. The external stimulus is used as an input signal to drive the device under test (DUT) into the expected working state. This is the starting point of simulation verification. By applying a suitable stimulus signal, the logic and circuit inside the DUT can be triggered to start running and generate corresponding outputs.

[0049] External stimuli can be designed to cover a variety of possible test scenarios, including normal operation, boundary conditions, abnormal situations, etc. This ensures the comprehensiveness of simulation verification and covers as many potential behaviors of the DUT as possible, thereby improving the confidence of verification.

[0050] The present invention also provides a random verification system for a universal MCU verification platform, which applies the above-mentioned random verification method, such as Figure 3 As shown, it includes a stimulus generation environment ENV and a verified device DUT; the hardware environment in the stimulus generation environment includes: a random stimulus generation module, which is used to generate random stimulus according to random variables and hardware constraints, and store it in the storage space of the verified device; a first monitoring module, which is used to monitor the configuration of the MCU of the verified device during the random simulation process, and monitor the random stimulus in the storage space; an expectation generation module, connected to the first monitoring module, used to receive the configuration sent by the first monitoring module and generate the corresponding expected result; a second monitoring module, which is used to monitor the simulation result generated by the random simulation of the MCU; a scoreboard module, which is connected to the expectation generation module and the second monitoring module, used to compare the simulation result and the expected result, and output a warning message to complete the random verification when the simulation result and the expected result are inconsistent; the operating environment in the stimulus generation environment is configured in the MCU of the verified device, including: a software constraint module, connected to the storage space, used to call the random stimulus in the storage space and add software constraints, and configure the MCU according to the random stimulus after the software constraints.

[0051] In a preferred embodiment of the present invention, Figure 3 As shown, the hardware environment also includes an external excitation module, which is connected to the random excitation generation module and the first monitoring module, and is used to obtain the external excitation when the MCU needs at least two random excitations for configuration, and constrain the external excitation with the random excitation, and send the constrained external excitation to the MCU.

[0052] Preferably, the first monitoring module also includes: a re-randomization unit, which is used to drive the random stimulus generation module to regenerate the random stimulus and store it in the storage space when the random stimulus is called; and a re-write unit, which is used to monitor the storage space and write the generated random stimulus storage into the storage space again when the storage space data is lost.

[0053] Specifically, in this embodiment, the specific structure diagram of the random excitation generation environment is as shown in the attached figure. Figure 3 As shown, you can follow the attached Figure 3 Build the structure shown.

[0054] The first thing to do is to build the rand config module (random stimulus generation module). The construction of this module should generate random numbers based on random variables according to actual random requirements and set constraints. In simple applications, the configuration here is not complicated. When it comes to meeting multiple random requirements, it is necessary to note that the next constraint may be the random result of this time, so special attention should be paid when building it. The rand config module will also be driven by the first monitoring module. Every time a driving signal comes, a new random stimulus needs to be generated.

[0055] The inspirt module (external stimulus module) controls the external stimulus to the MCU. Its constraints usually come from the random results of the rand config module. The inspirt module generates external stimulus to the MCU based on the results of the rand config module. When the random results of the rand config module change, the stimulus controlled by the inspirt module will also change accordingly.

[0056] The monitor1 module (the first monitoring module) is mainly used to monitor the random excitation inside the MCU and monitor the configuration process. When it detects that the random excitation is used, it drives the rand config module to perform randomization again. In addition, it is also necessary to monitor the status of the storage body (i.e. storage space). The storage body is used to store random excitations and needs to be selected according to the actual usage context.

[0057] When the chip simulates low power consumption or power-off behavior, the data in the memory bank may be destroyed. When destroyed, it is necessary to send instructions to let the rand config module put the data back into the memory bank module.

[0058] The reference model module (expected generation module) is a companion model built. Its main function is to accept the configuration passed by the monitor1 module, generate the expected results, and pass the expected results to the scoreboard module.

[0059] The function of the monitor2 module (the second monitoring module) is to monitor the design behavior. When the configuration changes, the MCU will produce different behaviors. The monitor2 module will monitor the behavior and pass the recorded simulation results to the scoreboard module.

[0060] The function of the scoreboard module is to receive the expected results from the reference model module and the simulation results from the monitor2 module in real time, compare the results, and print out a warning message when the expected results conflict with the actual simulation results.

[0061] The role of the restraint module (re-constraint module) is to constrain again. This module is needed when building a general environment. For example, when the GPIO (GPIO is the input and output interface between the chip and the external device, which can be used for simple status reading and control switches) or PADCFG module (PADCFG module is usually used for the configuration and management of GPIO ports) calls the random environment, and there is stimulation for the MCU in the random environment. However, when simulating GPIO or PADCFG, it may not be expected to stimulate the MCU. At this time, the role of the restraint module is to constrain the random environment from stimulating the MCU. Of course, the role of the restraint module is not limited to this. It should be noted that the constraints of the restraint module are only declared once and are valid throughout the simulation process.

[0062] The above are only preferred embodiments of the present invention, and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should be aware that all solutions obtained by equivalent substitutions and obvious changes made using the contents of this specification and illustrations should be included in the protection scope of the present invention.

Claims

1. A system-level random verification method for a general MCU verification platform, characterized in that: include: Step S1, generating random incentives based on random variables and hardware constraints in a hardware environment and storing them in a verified device; In step S2, the MCU of the verified device retrieves the stored random stimulus and adds software constraints, and then uses the random stimulus after the software constraints as a random simulation to obtain a simulation result; in step S3, the hardware environment reads the random stimulus after the software constraints to produce an expected result, and outputs a warning message when the expected result is inconsistent with the simulation result to complete random verification; the step S1 includes: step S11, generating an initial random stimulus according to the random variable in the hardware environment; step S12, in the hardware environment, limiting the range of the initial random stimulus according to the hardware constraints, and / or eliminating the value to complete the constraint to obtain the random stimulus stored in the verified device.

2. The random verification method according to claim 1, characterized in that: After executing the step S1, an incentive monitoring process is also included, including: the hardware environment monitors the random incentive stored in the verified device, and when the random incentive is called, the step S1 is executed again to regenerate the random incentive and store it in the verified device.

3. The random verification method according to claim 1, characterized in that: The verified device is provided with a storage space, and the random stimulus is stored in the storage space. After executing the step S1, it also includes a stimulus rewriting process, including: the hardware environment monitors the storage space, and when the data in the storage space is lost, the generated random stimulus storage is written into the storage space again.

4. The random verification method according to claim 1, characterized in that: Each simulation result is associated with a log information, and the time in the hardware environment is used as the random variable; each time the simulation result is obtained, the corresponding random variable is recorded in the associated log information.

5. The random verification method according to claim 1, characterized in that: The random simulation process in step S2 is that the MCU is configured according to the random stimulus, and after the configuration is completed, a pre-written function is executed in the MCU to obtain a corresponding simulation result.

6. The random verification method according to claim 5, characterized in that: The MCU requires at least two random stimuli for configuration; in the step S1, after the hardware environment generates the random stimulus, it also obtains the external stimulus, and stores the random stimulus and the external stimulus in the verified device; during the random simulation process, the MCU is configured according to the random stimulus and the external stimulus.

7. A system-level random verification system for a general MCU verification platform, characterized in that: The random verification method as described in any one of claims 1 to 6 is applied, comprising a stimulus generation environment and a verified device; the hardware environment in the stimulus generation environment comprises: a random stimulus generation module, used to generate the random stimulus according to the random variable and the hardware constraint condition, and store it in the storage space of the verified device; a first monitoring module, used to monitor the configuration of the MCU of the verified device during the random simulation process, and monitor the random stimulus in the storage space; an expectation generation module, connected to the first monitoring module, used to receive the configuration sent by the first monitoring module and generate the corresponding expected result; a second monitoring module, used to monitor the simulation result generated by the random simulation of the MCU; a scoreboard module, connected to the expectation generation module and the second monitoring module, used to compare the simulation result with the expected result, and output a warning message to complete the random verification when the simulation result and the expected result are inconsistent; the operating environment in the stimulus generation environment is configured in the MCU of the verified device, including: a software constraint module, connected to the storage space, used to call the random stimulus in the storage space and add software constraints, and configure the MCU according to the random stimulus after the software constraints.

8. The random verification system according to claim 7, characterized in that: The hardware environment also includes an external excitation module, which is connected to the random excitation generation module and the first monitoring module, and is used to obtain external excitation when the MCU needs at least two random excitations for configuration, and constrain the external excitation with the random excitation, and send the constrained external excitation to the MCU.

9. The random verification system according to claim 7, characterized in that: The first monitoring module also includes: a re-randomization unit, which is used to drive the random stimulus generation module to regenerate the random stimulus and store it in the storage space when the random stimulus is called; and a re-writing unit, which is used to monitor the storage space and write the generated random stimulus storage into the storage space again when the data in the storage space is lost.

Images