A system-level random verification method and system for a universal MCU verification platform

Abstract

The present invention provides a system-level random verification method and system for a universal MCU verification platform, which relates to the field of simulation verification technology, including: generating random excitations based on random variables and hardware constraints in a hardware environment and storing them in a verified device; the MCU of the verified device retrieves the stored random excitations and adds software constraints, and then uses the random excitations after software constraints for random simulation to obtain simulation results; the hardware environment reads the random excitations after software constraints to produce expected results, and outputs a warning message to complete random verification when the expected results are inconsistent with the simulation results. The beneficial effect is that 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. This greatly enhances the ability of randomization; it is compatible with any existing MCU verification platform, will not affect the existing verification environment, and is only an extension of 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 a variety of fields, including industrial control, medical equipment, and automotive electronics. To ensure system reliability and stability, simulation and verification technology plays a crucial role. During MCU simulation and verification, module-level verification often uses random verification methods based on System Verilog, while system-level verification focuses on targeted verification, primarily to check the accuracy of inter-system connections.

[0003] MCUs are typically designed as systems encompassing multiple clock domains. For example, the clock system of a 32-bit MCU may include five clock types: an external high-speed clock (HSE), an internal high-speed clock (HRC), an internal low-speed clock (LRC), an external low-speed clock (LSE), and a phase-locked loop (PLL) clock, to accommodate both normal and low-power modes. These clocks are not only used by different modules and modes, but also allow users to perform operations such as frequency division and system clock switching at any time during MCU operation, significantly complicating the actual operating timing of the MCU. Furthermore, MCU modules integrate various communication protocols, whose uncertainties in data transmission (such as data length, transmission timing, and clock rate) further complicate timing issues. Verification personnel often face verification challenges related to cross-clock domains, clock phases, and clock division, as well as the numerous verification points for deterministic functionality within each MCU module. This makes it difficult to fully consider these issues during system-level verification and effectively verify them through targeted test cases.

[0004] Currently, randomized verification methods are primarily implemented using the System Verilog language within a simulation environment. As a hardware description language, SystemVerilog supports behavioral, register transfer level (RTL), and gate-level descriptions and is widely used in the design and verification of digital circuits. In System Verilog, randomized test vectors can be generated by defining random environments, and tests are executed through read and write operations with MCU registers. While existing randomized verification methods have improved verification efficiency and coverage to a certain extent, they still face challenges and limitations. While current MCU verification methods can randomize module operating scenarios to a certain extent, their randomization capabilities are still insufficient when dealing with inter-module timing interactions or complex usage scenarios. Summary of the Invention

[0005] In response to 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 software constraints for random simulation to obtain a simulation result; step S3, the hardware environment reads the random stimulus after software constraints to generate an expected result, and outputs a warning message to complete the random verification when the expected result is inconsistent with the simulation result.

[0006] Preferably, the step S1 includes: step S11, generating an initial random excitation based on 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 numerically eliminating the constraints to obtain the random excitation and storing it in the verified device.

[0007] Preferably, 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.

[0008] Preferably, a storage space is provided in the verified device, and the random stimulus is stored in the storage space. After executing step S1, an incentive 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 for 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, is used to receive the configuration sent by the first monitoring module and generate the corresponding expected result; a second monitoring module 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, 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, 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, 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 data in the storage space is lost.

[0015] The above technical solution has the following advantages or beneficial effects:

[0016] 1. By generating random stimuli based on random variables and hardware constraints within the hardware environment, we can more flexibly simulate various complex MCU operating scenarios. We can simulate a variety of possible timing relationships, ensuring that the verification process covers more scenarios and conditions, improving verification comprehensiveness. This significantly enhances randomization capabilities.

[0017] 2. 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 1 is a flow chart of a system-level random verification method for a universal MCU verification platform in a preferred embodiment of the present invention;

[0019] Figure 2 Schematic diagram of the process of step S1 in a preferred embodiment of the present invention;

[0020] Figure 3 The figure is a schematic structural diagram of a system-level random verification system of a universal MCU verification platform in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0021] The present invention is described in detail below with reference to 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.

[0022] 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 universal 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 software constraints for random simulation to obtain simulation results; step S3, the hardware environment reads the random excitation after software constraints to generate an expected result, and outputs a warning message to complete the random verification when the expected result is inconsistent with the simulation result.

[0023] Specifically, in this embodiment, random stimuli in random verification of an MCU refer to random test vectors or data packets generated in a simulation environment to test the functionality and performance of the MCU. These random stimuli are designed to simulate various situations that the MCU may encounter in real applications, thereby verifying the MCU's performance and stability in different scenarios.

[0024] Specifically, random stimuli can include various types of stimulus signals, such as clock signals, reset signals, register configuration signals, and data input signals. These stimulus signals are randomly generated in the simulation environment and applied to the MCU's input terminals according to specific timing and logical relationships. By observing and analyzing the MCU's output responses to these random stimuli, verifiers can assess the MCU's functional correctness, performance stability, and ability to handle complex timing sequences.

[0025] Generating random stimuli is a key step in random verification. To ensure comprehensiveness and effectiveness, random stimuli must cover a wide range of situations the MCU may encounter, including normal operation, abnormal operation, and boundary conditions. Furthermore, random stimuli generation must consider the MCU's characteristics and application scenarios to ensure that the generated stimulus signals meet the MCU's actual operating requirements.

[0026] The randomized verification method in this embodiment generates random stimuli based on random variables and hardware constraints within a hardware environment, enabling more flexible simulation of various complex MCU operating scenarios. This randomized stimuli not only takes into account hardware-level constraints but also allows for further customization and constraints at the software level, significantly enhancing the randomization capability.

[0027] By introducing random excitation, 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.

[0028] For complex usage scenarios, combining random excitation at the hardware and software levels can more accurately simulate actual usage conditions. This helps identify potential problems and defects, and improves the reliability and stability of the MCU.

[0029] Compatible with any existing MCU verification platform, it extends the functionality of existing verification environments without impacting existing verification cases, adding no additional cases, and increasing the workload of verification personnel. It also provides a simple approach for verification points requiring a large number of verification cases, such as protocol and timing verification.

[0030] 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 based on a random variable 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 the values ​​to complete the constraints to obtain the random stimulus and store it in the verified device.

[0031] Specifically, in this embodiment, the clock source selection is taken as a random variable for example:

[0032] Step S11: Generate initial random stimulus (based on clock source selection)

[0033] Core logic: Encode clock configuration parameters in random numbers to generate raw 32-bit values.

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

[0035]

[0036] Clock source selection (4 bits)

[0037] 0x0: HRC (internal 64MHz)

[0038] 0x1: HSE (external 8MHz)

[0039] 0x2: LSE (internal 30KHZ)

[0040] 0x3: LRC (external 32.768KHZ)

[0041] 0x4: PLL (Phase-Locked Loop Output)

[0042] Other values: HRC

[0043] PLL multiplication factor (4 bits):

[0044] AHB frequency division coefficient (4 bits):

[0045] Random values ​​0x0 (no frequency division), 0x1 (frequency division by 2), 0x2 (frequency division by 4), 0x3 (frequency division by 8)

[0046] 2. Generate initial random numbers (example)

[0047] Generate a 32-bit value using the simulation environment random engine (seed=0x5A3D):

[0048] 0x42A30000 (binary: 0100 0010 1010 0011 0000 0000 0000 0000)

[0049] Parsed fields:

[0050] Clock source selection: 0100 (bits 31-28 → value 0x4, corresponding to PLL)

[0051] PLL multiplication factor: 0010 (bits 27-24 → value 0x2, multiplication factor × 2)

[0052] AHB division factor: 1010 (bits 23-20 → value 0xA, illegal)

[0053] Reserved bits: All 0

[0054] Step S12: Apply hardware constraint correction

[0055] Only illegal fields are corrected, and legal random values ​​are retained.

[0056] 1. Clock source selection constraints

[0057] If the Clock Source field value (0x0 / 0x1 / 0x4) indicates a fast clock, the clock is divided normally. If the Clock Source field value (0x2 / 0x3) indicates a slow clock, you can choose not to divide the clock, limit the division rate, or replace it with another clock based on actual needs.

[0058] 2. PLL multiplication factor constraints

[0059] If the multiplication factor is < 0x3 → set to the minimum value 0x3 (×3)

[0060] If the multiplication factor > 0xC → set to the maximum value 0xC (×12)

[0061] In this example, the multiplication factor is 0x2 (×2), which is corrected to 0x3 (×3).

[0062] 3. AHB frequency division coefficient constraints

[0063] Only 0x0 / 0x1 / 0x2 / 0x3 are allowed. Other values ​​are modified according to priority:

[0064] If the value is > 0x3 → take the maximum legal value 0x3 (divide by 8)

[0065] In this example, the frequency division coefficient is 0xA (decimal 10), which is corrected to 0x3 (8 division).

[0066] 4. Recode legal values

[0067] Corrected fields:

[0068] Clock source selection: 0100 (PLL)

[0069] PLL multiplication factor: 0011 (×3)

[0070] AHB frequency division coefficient: 0011 (8 frequency division)

[0071] Reserved bits: unchanged

[0072] Final legal incentive value:

[0073] 0x43330000 (binary: 0100 0011 0011 0011 0000 0000 0000 0000)

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

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

[0076] 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 remains consistent with the current state of the verified device, thereby improving the accuracy of verification.

[0077] By regenerating random stimuli when they are invoked, we can cope with possible state changes of 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.

[0078] In some complex scenarios, the state of the device being verified may change due to multiple factors. Step S13 allows for regeneration each time the random stimulus is called, thereby simulating these complex scenarios and ensuring the comprehensiveness and reliability of the verification.

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

[0080] Specifically, in this embodiment, the state of the data in the storage space is also monitored in real time. If the data in the random stimulus storage module is lost due to power failure or low power mode during simulation, it needs to be written back to the random stimulus storage module in a timely manner. This ensures the integrity of the data in the storage space.

[0081] This is crucial for the accuracy and reliability of the verification process, as any loss of data may lead to biased or failed verification results.

[0082] This ensures that the verification process can continue seamlessly after the device returns to normal. This avoids interruptions to the verification process due to data loss and improves the continuity and efficiency of verification.

[0083] In a preferred embodiment of the present invention, each simulation result is associated with a log message, 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 message.

[0084] 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 as 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, regression testing will be performed. The log information plus the random seed can save complete regression information, making it easier to reproduce the problem.

[0085] 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 the corresponding simulation result.

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

[0087] In a preferred embodiment of the present invention, the MCU requires at least two random stimuli for configuration; in step S1, the hardware environment generates the random stimulus and 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.

[0088] Specifically, in some cases, the MCU requires at least two random stimuli for configuration. Simulation verification cannot be performed solely with a random stimulus generated by the hardware environment. Therefore, an external stimulus is required to complement the random stimulus. The external stimulus serves as an input signal, driving the device under test (DUT) into its intended operating state. This is the starting point for simulation verification. By applying an appropriate stimulus signal, the DUT's internal logic and circuitry can be triggered, causing it to begin operating and generate the appropriate output.

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

[0090] The present invention also provides a random verification system for a universal MCU verification platform, which applies the above random verification method, such as Figure 3As 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, which 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 results generated by the MCU random simulation; a scoreboard module, which is connected to the expectation generation module and the second monitoring module, which is used to compare the simulation results and the expected results, and output a warning message to complete the random verification when the simulation results and the expected results 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, which 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.

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

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

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

[0094] The first step is to build the rand config module (random stimulus generation module). This module generates random numbers based on random variables and sets constraints, tailored to the actual randomness requirements. In simple applications, this configuration is not complex. However, when implementing multiple randomizations, it's important to note that the constraints of the next iteration may reflect the current randomization results, requiring special attention during setup. The rand config module is also driven by the first monitoring module, requiring new random stimulus generation for each drive signal.

[0095] The inspirt module (external stimulus module) controls the external stimulus for the MCU. Its constraints are typically based on the random output of the rand config module. The inspirt module generates external stimulus for the MCU based on the output of the rand config module. When the random output of the rand config module changes, the stimulus controlled by the inspirt module also changes.

[0096] The monitor1 module (the first monitoring module) is primarily responsible for monitoring the random stimulus within the MCU and the configuration process. When it detects the random stimulus being used, it drives the rand config module to re-randomize the configuration. Furthermore, it monitors the status of the memory bank (i.e., storage space) used to store the random stimulus. The memory bank should be selected based on the actual usage context.

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

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

[0099] The monitor2 module (second monitoring module) is used 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.

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

[0101] The restraint module (re-constraint module) is used to impose constraints. This module is required when building a general environment. For example, when the GPIO (GPIO is the input and output interface between the chip and external devices, which can be used for simple status reading and switch control) or PADCFG module (PADCFG module is usually used for GPIO port configuration and management) calls a random environment, and the random environment has stimuli for the MCU. However, during GPIO or PADCFG simulation, it may not be expected to stimulate the MCU. In this case, the restraint module is used to prevent the random environment from stimulating the MCU. Of course, the restraint module has more functions than this. It is important to note that the constraints of the restraint module are only declared once and are valid throughout the simulation.

[0102] The above are only preferred embodiments of the present invention and do not limit the implementation mode and protection scope of the present invention. For those skilled in the art, it 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 stimuli based on random variables and hardware constraints in a hardware environment and storing them in the device to be verified; Step S2, the MCU of the device to be verified retrieves the stored random stimulus and adds software constraints, and then uses the random stimulus after software constraints as a random simulation to obtain a simulation result; Step S3, the hardware environment reads the random stimulus after the software constraints to produce the expected result, and outputs a warning message when the expected result and the simulation result are inconsistent to complete the random verification; The step S1 comprises: Step S11, generating an initial random stimulus according to the random variable in the hardware environment; Step S12: limiting the range of the initial random stimulus according to the hardware constraint condition in the hardware environment, and / or eliminating values ​​to complete the constraint to obtain the random stimulus and storing it in the verified device.

2. The random verification method according to claim 1, characterized in that: After executing step S1, the process further includes an excitation monitoring process, including: The hardware environment monitors the random stimulus stored in the verified device, and when the random stimulus is called, executes step S1 again to regenerate the random stimulus 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 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, writes the generated random stimulus storage 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 message, 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, the hardware environment generates a random stimulus and also obtains an 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: Applying the random verification method according to any one of claims 1 to 6, comprising a stimulus generation environment and a verified device; The hardware environment in the incentive generation environment includes: A random stimulus generation module, configured to generate the random stimulus according to the random variable and the hardware constraint, and store the random stimulus in a storage space of the device to be verified; A first monitoring module, configured to monitor the configuration of the MCU of the verified device during the random simulation process, and to monitor the random stimulus in the storage space; an expectation generating module, connected to the first monitoring module, configured to receive the configuration sent by the first monitoring module and generate the corresponding expected result; A second monitoring module is used to monitor the simulation results generated by the MCU random simulation; a scoreboard module, connected to the expectation generation module and the second monitoring module, configured to compare the simulation result with the expected result, and output a warning message when the simulation result and the expected result are inconsistent to complete random verification; The operating environment in the stimulus generation environment is configured in the MCU of the verified device, including: A software constraint module 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.

8. The random verification system according to claim 7, characterized in that: The hardware environment also includes An external excitation module is connected to the random excitation generation module and the first monitoring module, and is used to obtain an external excitation when the MCU requires at least two random excitations for configuration, 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 further includes: a re-randomization unit, configured 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 The rewriting unit is used to monitor the storage space and rewrite the generated random stimulus storage into the storage space when data in the storage space is lost.

Images