Interrupt monitoring module verification system and method based on uvm verification methodology

Abstract

The application relates to an interrupt monitoring module verification system and method based on a UVM verification methodology, an advanced verification platform integrating error injection, collection and checking of an interrupt monitoring module is built through a SystemVerilog language, the verification platform comprises a basic test component and an instantiated peripheral, a Cortex-M microcontroller, a storage unit and the interrupt monitoring module to be verified, a real interrupt service program processing process is simulated through interaction between the peripheral and the Cortex-M microcontroller, the verification process of the interrupt monitoring module is more in line with a real use scene, meanwhile, a high randomness of a test case and error injection and a plurality of scene combinations ensure the accuracy and completeness of the verification of the interrupt monitoring module, the synchronization of the interrupt monitoring module to be tested and a verification environment is realized with low configuration cost, and the verification efficiency of the interrupt monitoring module is greatly improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of chip verification, and relates to an interrupt monitoring module verification system and method based on UVM verification methodology. Background Art

[0002] In the early days of computers, the CPU could only access and process various hardware peripherals in the order in which they were programmed. This mode of operation was called polling. Since the status of input and output devices had to wait until each task was completed before checking, this led to delayed response times, the inability of devices to count and process requests, and inefficient resource utilization. Subsequently, interrupt technology was first used on computers. When a hardware peripheral has a transaction that requires CPU processing, it can send an interrupt request signal (IRQ). When the CPU receives an interrupt request signal from the hardware peripheral, it temporarily interrupts the execution of the current task and instead executes the new transaction corresponding to the interrupt request signal. It waits for the new transaction to complete before continuing with the interrupted task. The existence of interrupts significantly improves the system's responsiveness and computer resource utilization, making multitasking more efficient and improving overall performance.

[0003] With the proliferation of hardware peripherals and the continuous advancement of computers, the CPU needs to handle an increasing number of interrupts in a short period of time. To ensure that critical tasks are handled promptly, the concept of interrupt priority has emerged. The Cortex-M series microcontrollers support up to 240 interrupt sources and utilize a nested vectored interrupt controller (NVIC), allowing users to configure multiple interrupt priorities and implement nested interrupt processing. Priorities within the NVIC are divided into preemption priority and response priority. Preemption priority means that if an interrupt has a higher preemption priority than the currently executing interrupt, it can interrupt the currently executing interrupt and be executed first. The lower the preemption priority value, the higher the priority. Response priority means that if two interrupts arrive simultaneously and have the same preemption priority, the interrupt with the higher response priority will be processed first. The lower the response priority value, the higher the priority. The response and preemption priorities of each interrupt can be determined by configuring the NVIC.

[0004] To ensure that the processor handles interrupts according to the required priority, the Interrupt Monitor module is designed to detect errors in the interrupt handling process. If the Cortex-M microcontroller handles interrupts in an abnormal order due to incorrect NVIC configuration or random hardware failure, that is, the interrupt handling priority is inconsistent with the preset priority, the Interrupt Monitor module will generate an alarm, record it, and report it to the Cortex-M microcontroller to prevent the error from escalating.

[0005] To ensure the correctness of the interrupt monitoring module, it needs to be fully tested and verified. Since the current testing of the interrupt monitoring module through FPGA (Field-Programmable Gate Array) has problems such as difficult to construct incentives and incomplete scenario coverage, how to build a complete verification platform for the interrupt monitoring module, accurately simulate real interrupt priority processing scenarios based on Cortex-M microcontrollers, and use a large number of random incentives to ensure the completeness of its functions is a technical problem that verification personnel urgently need to solve. Summary of the Invention

[0006] In response to the problems existing in the above-mentioned traditional technologies, the present invention proposes an interrupt monitoring module verification system based on UVM verification methodology and an interrupt monitoring module verification method based on UVM verification methodology, which can construct a real and complete interrupt priority processing scenario and fully verify the basic functions of the interrupt monitoring module.

[0007] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0008] On the one hand, an interrupt monitoring module verification system based on UVM verification methodology is provided, including a verification platform built using SystemVerilog language, a basic test component is created based on the verification platform, and an instantiation design integration is performed; the basic test component is used to create a verification environment and construct various test cases for implementing peripherals to send interrupts according to various verification scenarios, and each test case includes a non-error injection case and an error injection case;

[0009] The design integration includes peripherals, a Cortex-M microcontroller, memory units, and an interrupt monitoring module to be verified. The verification environment communicates with the design integration code by modifying the contents of the flag address in the memory unit. The Cortex-M microcontroller uses instruction fetching to read and write peripherals, read and write registers of the interrupt monitoring module, and exit the interrupt service routine. The peripheral configuration generates an interrupt, which is then sent to the interrupt monitoring module and the Cortex-M microcontroller.

[0010] When selecting the test function, if the test case is a non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to the same interrupt processing priority, and the same interrupt request is selected. The interrupt is configured to be set externally. After all interrupts are set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemptive priority. The interrupt monitoring module monitors the highest priority interrupt and is expected to generate no abnormal alarm. The non-error injection case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior.

[0011] If the test case is selected as an error injection case, the interrupt processing priorities of the Cortex-M microcontroller and the interrupt monitoring module are configured to be inconsistent, and the interrupt monitoring module generates an exception alarm and records it in the error log; by comparing the expected exception alarm result in the error log with the actual exception alarm result, if the results are inconsistent, the simulation is stopped, otherwise the simulation ends.

[0012] On the other hand, a UVM-based interrupt monitoring module verification method is provided, which is applied to an interrupt monitoring module verification system based on the UVM-based verification methodology. The interrupt monitoring module verification system includes a verification platform built using the SystemVerilog language, and a basic test component is created based on the verification platform and instantiated for design integration. The basic test component is used to create a verification environment and construct test cases for implementing peripherals sending interrupts according to various verification scenarios, and each test case includes a non-error injection case and an error injection case.

[0013] The design integration includes peripherals, a Cortex-M microcontroller, memory units, and an interrupt monitoring module to be verified. The verification environment communicates with the design integration code by modifying the contents of the flag address in the memory unit. The Cortex-M microcontroller uses instruction fetching to read and write peripherals, read and write registers of the interrupt monitoring module, and exit the interrupt service routine. The peripheral configuration generates an interrupt, which is then sent to the interrupt monitoring module and the Cortex-M microcontroller.

[0014] The interrupt monitoring module verification method based on UVM verification methodology includes the following steps:

[0015] When selecting the test function, if the test case is not an error injection case, configure the Cortex-M microcontroller and the interrupt monitoring module to the same interrupt processing priority and select the same interrupt request;

[0016] The interrupt is set outside the configuration. After all interrupts are set, the Cortex-M microcontroller enters the interrupt service routine with the highest priority. The interrupt monitoring module monitors the highest priority interrupt and is expected not to generate an abnormal alarm. The non-fault injection use case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior.

[0017] If the test case is selected as an error injection case, the interrupt processing priorities of the Cortex-M microcontroller and the interrupt monitoring module are configured to be inconsistent; the interrupt monitoring module generates an abnormal alarm and records it in the error log;

[0018] By comparing the expected abnormal alarm results in the error record with the actual abnormal alarm results, if the results are inconsistent, the simulation is stopped, otherwise the simulation is ended.

[0019] One of the above technical solutions has the following advantages and beneficial effects:

[0020] The above-mentioned interrupt monitoring module verification system and method based on UVM verification methodology adopts the UVM verification environment and builds an advanced verification platform for error injection, collection and inspection of the interrupt monitoring module through the SystemVerilog language, which includes basic test components and instantiates design integration. The design integration includes peripherals, Cortex-M microcontrollers, storage units and the interrupt monitoring module to be verified. The real interrupt service program processing process is simulated through the interaction between the peripherals and the Cortex-M microcontroller, so that the verification process of the interrupt monitoring module is more in line with the real usage scenario. At the same time, the high randomness of the test case and the combination of multiple scenarios such as error injection ensure the accuracy and completeness of the verification of the interrupt monitoring module, so as to achieve the synchronization of the interrupt monitoring module to be tested and the verification environment with low configuration cost, and greatly improve the verification efficiency of the interrupt monitoring module. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the conventional technology, the following briefly introduces the drawings required for use in the embodiments or the conventional technology descriptions. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 A block diagram of an interrupt monitoring module verification system based on UVM verification methodology in one embodiment is provided;

[0023] Figure 2 A schematic diagram of an interrupt handling process of an interrupt monitoring module verification system based on UVM verification methodology in one embodiment;

[0024] Figure 3 1 is a flow chart of an interrupt monitoring module verification method based on UVM verification methodology in one embodiment. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and Examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the description of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0026] It should be noted that the reference to "embodiment" in this document means that the specific features, structures or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The presentation of this phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It will be understood by those skilled in the art that the embodiments described herein may be combined with other embodiments. The term "and / or" used in the present specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0027] The following describes the embodiments of the present invention in detail with reference to the accompanying drawings.

[0028] In one embodiment, Figure 1 As shown, an interrupt monitoring module verification system based on the UVM verification methodology is provided, including a verification platform testbench (TB) built in the SystemVerilog language. A basic test component base_test (test case base class) is created based on the verification platform testbench and instantiated for design integration; the basic test component base_test is used to create a verification environment env and construct various test cases for implementing peripherals to send interrupts according to various verification scenarios, and is used to declare environment variables, environment configuration information, and create various functions for test cases to call; the test cases include non-error injection cases and error injection cases.

[0029] The design integration includes peripherals, a Cortex-M microcontroller, memory cells, and an interrupt monitoring module to be verified. The verification environment communicates with the design integration code by modifying the contents of the flag address within the memory cell. The Cortex-M microcontroller uses instruction fetches to read and write peripherals, read and write registers of the interrupt monitoring module, and exit the interrupt service routine. Peripheral configuration generates interrupts that are sent to the interrupt monitoring module and the Cortex-M microcontroller.

[0030] When selecting the test function, if the test case is a non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to the same interrupt processing priority, and the same interrupt request is selected. The interrupt is configured to be set externally. After all interrupts are set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemptive priority. The interrupt monitoring module monitors the highest priority interrupt and is expected to generate no abnormal alarm. The non-error injection case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior.

[0031] If the test case is selected as an error injection case, the interrupt processing priorities of the Cortex-M microcontroller and the interrupt monitoring module are configured to be inconsistent. The interrupt monitoring module generates an abnormal alarm and records it in the error log; by comparing the expected result with the actual result in the error log, if the expected result is inconsistent with the actual result, the simulation is stopped, otherwise the simulation ends.

[0032] It can be understood that the design of each component in the above-mentioned verification platform testbench follows the existing UVM verification methodology. According to the functional verification requirements of the interrupt monitoring module to be verified, the components of the corresponding functions are configured based on the verification platform testbench and basic operations such as connection and connectivity testing between components are completed to ensure normal data flow between components during the verification process.

[0033] The top-level simulation file created is used to initialize the testbench (top-level file) and start test cases and other basic operations. Based on the testbench, a design integration containing the module to be verified (i.e., the interrupt monitoring module) is instantiated. The design integration includes a Cortex-M microcontroller, a storage unit, optional peripherals, and the interrupt monitoring module to be tested, such as Figure 1As shown. Based on the verification platform testbench, a backdoor write function is created for the storage space where the flag address, register address, and data address for accessing the Cortex-M microcontroller are located. This function is used to access the registers of peripherals or registers within the Cortex-M microcontroller. Based on the verification platform testbench, a backdoor read and backdoor write function for the interrupt flag address accessed by the Cortex-M microcontroller is also created. This function is used to enable the verification environment env to sense whether the Cortex-M microcontroller has entered the interrupt service routine, and to control the Cortex-M microcontroller to exit the interrupt service routine. In order to simulate a real interrupt service routine, after sensing that the Cortex-M microcontroller has entered the interrupt service routine, the verification environment env will wait for a random time to clear the interrupt, and then wait for another random time before clearing the data in the interrupt flag address, causing the Cortex-M microcontroller to exit the interrupt service routine.

[0034] The verification environment communicates with the design code by modifying the contents of the flag address in the storage unit. Figure 1 The double arrows in the figure indicate that the Cortex-M microcontroller uses instruction fetching to implement operations such as reading and writing peripherals, reading and writing registers of the interrupt monitoring module, and exiting the interrupt service program. After the peripheral configuration generates an interrupt, it is sent to the interrupt monitoring module and the Cortex-M microcontroller. The basic test component base_test (test case base class) is used to create the platform environment env, declare environment variables, configuration information, and create various functions for test case calls. These environment variables, configuration information, and various functions can be selected on the verification platform according to the verification requirements of the interrupt monitoring module to be tested. Among them, the environment variables can be used to control the clock frequency of the peripherals, Cortex-M microcontroller, and interrupt monitoring module. The created initialization function can initialize the verification platform environment, Cortex-M microcontroller, and peripherals.

[0035] To correctly cover the preemption and response priority functions in the Cortex-M microcontroller, different test cases can be created based on the base_test test case base class to ensure that the peripherals can send interrupts according to the required functional verification scenarios, such as all interrupts being generated simultaneously or the same interrupt being generated randomly in different orders. To ensure that the interrupt monitoring module can correctly output interrupt exception alarms, fault injection cases that violate the expected interrupt handling priority are also constructed. When the interrupt handling priority of the Cortex-M microcontroller and the interrupt monitoring module are consistent, the interrupt monitoring module is checked to ensure that the interrupt exception alarm is not issued. When the interrupt handling priority of the Cortex-M microcontroller and the interrupt monitoring module are inconsistent, the interrupt monitoring module is checked to ensure that the interrupt exception alarm is issued.

[0036] Specifically, when selecting a test function, you can implement different functions by changing the corresponding register configuration. For example, you can configure the interrupt handling priorities of the Cortex-M microcontroller and the interrupt monitoring module to be consistent, or configure interrupt generation at random times. When developing a fault injection test case, you can configure the interrupt monitoring module to have different interrupt handling priorities than the Cortex-M microcontroller, or when the Cortex-M microcontroller enters the interrupt service routine, clear the interrupt that does not match the current interrupt service routine.

[0037] If the current test case is not a fault injection test case, the Cortex-M microcontroller and the interrupt monitoring module are configured with the same interrupt handling priority and the same interrupt request is selected. After the interrupt is enabled, the Cortex-M microcontroller enters the interrupt service routine with the highest priority, and the interrupt monitoring module monitors the highest-priority interrupt. After simulating the software behavior, the test case clears the corresponding interrupt based on the current state of the Cortex-M microcontroller. At this point, the interrupt monitoring module is expected to generate no exception alarms. If the current test case is a fault injection test case, the interrupt monitoring module is expected to generate an exception alarm and record it in the error log.

[0038] Since the error log records both the expected and actual exception alarms generated by the interrupt monitoring module, the corresponding simulation results can be obtained by comparing the results in the error log. For example, if the comparison fails, meaning the expected and actual exception alarms generated by the interrupt monitoring module are inconsistent, a comparison failure log is output and the simulation terminates. If the comparison succeeds, meaning the expected and actual exception alarms generated by the interrupt monitoring module are consistent, a comparison pass log is output and the simulation terminates.

[0039] The above-mentioned interrupt monitoring module verification system based on UVM verification methodology adopts UVM verification environment and builds an advanced verification platform for error injection, collection and inspection of the interrupt monitoring module through SystemVerilog language, which includes basic test components and instantiates design integration. The design integration includes peripherals, Cortex-M microcontrollers, storage units and the interrupt monitoring module to be verified. The real interrupt service program processing process is simulated through the interaction between the peripherals and the Cortex-M microcontroller, so that the verification process of the interrupt monitoring module is more in line with the real usage scenario. At the same time, the high randomness of the test cases and the combination of multiple scenarios such as error injection ensure the accuracy and completeness of the verification of the interrupt monitoring module, so as to achieve the synchronization of the interrupt monitoring module to be tested and the verification environment with low configuration cost, and greatly improve the verification efficiency of the interrupt monitoring module.

[0040] In one embodiment, if all interrupts are set at the same time, the Cortex-M microcontroller enters the interrupt service routine that responds to the highest priority interrupt.

[0041] It can be understood that if all interrupts are set at the same time, the Cortex-M microcontroller will enter the interrupt service routine with the highest response priority, and the interrupt processing priority of the configured interrupt monitoring module will be consistent with the response priority of the Cortex-M microcontroller. At this time, the interrupt monitoring module is expected not to generate an abnormal alarm. Otherwise, the interrupt monitoring module is expected to generate an abnormal alarm and it will be recorded in the error log.

[0042] In one embodiment, the verification platform further creates a coverage collection component and uses a makefile file to connect the flielist of the design code of the design integration and the filelist of the verification environment. The coverage collection component is used to collect functional coverage for verification of the interrupt monitoring module.

[0043] It can be understood that a makefile can be written on the verification platform, and after selecting the compilation tool to compile, the flielist of the code and the filelist of the verification environment can be connected. Compilation macros and coverage collection items can also be added. Through the makefile, the test case can also be automatically run a specified number of times, such as Figure 2 As shown in the figure: configure the NVIC register of the Cortex-M microcontroller, select the interrupt request to be tested, randomly configure the priority of the interrupt to be tested, and randomly configure the ratio of the response priority and the preemption priority; enable the interrupt monitoring module to enter the working state and pass the interrupt request to be tested, and configure the priority of the corresponding channel of the interrupt monitoring module according to the priority of the interrupt to be tested; configure the peripheral corresponding to the interrupt to be tested to enable and generate an interrupt; wait for a certain time after the Cortex-M microcontroller enters the interrupt state, wait for a certain time after clearing the interrupt and check whether the interrupt monitoring module issues an abnormal alarm at the same time; exit the interrupt service program and handle the next interrupt.

[0044] Each component in the interrupt monitoring module verification system based on the UVM verification methodology can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the components can be embedded in or independent of a device with data processing capabilities in hardware form, or can be stored in a memory of the aforementioned device in software form, so that a processor can call and execute operations corresponding to each of the above modules. The aforementioned device can be, but is not limited to, various types of chip verification computers available in the art.

[0045] In one embodiment, a UVM-based interrupt monitoring module verification method is provided, which is applied to an interrupt monitoring module verification system based on the UVM-based verification methodology. The interrupt monitoring module verification system includes a verification platform built using the SystemVerilog language, a basic test component is created based on the verification platform, and an instantiation design integration is performed; the basic test component is used to create a verification environment and construct test cases for implementing peripherals sending interrupts according to various verification scenarios, and each test case includes a non-error injection case and an error injection case;

[0046] The design integration includes peripherals, a Cortex-M microcontroller, memory units, and an interrupt monitoring module to be verified. The verification environment communicates with the design integration code by modifying the contents of the flag address in the memory unit. The Cortex-M microcontroller uses instruction fetching to read and write peripherals, read and write registers of the interrupt monitoring module, and exit the interrupt service routine. The peripheral configuration generates an interrupt, which is then sent to the interrupt monitoring module and the Cortex-M microcontroller.

[0047] like Figure 3 As shown, the above interrupt monitoring module verification method based on UVM verification methodology may include the following processing steps S10 to S16:

[0048] S10, when selecting the test function, if the test case is selected as a non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to have the same interrupt processing priority and the same interrupt request is selected;

[0049] S12, configure the external interrupt settings, wait for all interrupts to be set, and then the Cortex-M microcontroller enters the interrupt service routine with the highest priority. The interrupt monitoring module monitors the highest priority interrupt and does not generate an abnormal alarm. The non-fault injection use case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior.

[0050] S14, if the test case is selected as an error injection case, the interrupt processing priorities of the Cortex-M microcontroller and the interrupt monitoring module are configured to be inconsistent; the interrupt monitoring module generates an abnormal alarm and records it in the error log;

[0051] S16, by comparing the expected abnormal alarm result in the error record with the actual abnormal alarm result, if the results are inconsistent, the simulation is stopped, otherwise the simulation is ended.

[0052] The above-mentioned interrupt monitoring module verification method based on UVM verification methodology adopts UVM verification environment and builds an advanced verification platform for error injection, collection and inspection of the interrupt monitoring module through SystemVerilog language, which includes basic test components and instantiates design integration. The design integration includes peripherals, Cortex-M microcontrollers, storage units and the interrupt monitoring module to be verified. The real interrupt service program processing process is simulated through the interaction between the peripherals and the Cortex-M microcontroller, so that the verification process of the interrupt monitoring module is more in line with the real usage scenario. At the same time, the combination of high randomness of test cases and multiple scenarios such as error injection ensures the accuracy and completeness of the verification of the interrupt monitoring module, so as to achieve the synchronization of the interrupt monitoring module to be tested and the verification environment with low configuration cost, and greatly improve the verification efficiency of the interrupt monitoring module.

[0053] In one embodiment, if all interrupts are set at the same time, the Cortex-M microcontroller enters the interrupt service routine that responds to the highest priority interrupt.

[0054] In one embodiment, before selecting the test function, the above-mentioned interrupt monitoring module verification method based on UVM verification methodology further includes the steps of:

[0055] The instruction fetch address and behavior of the Cortex-M microcontroller are constrained according to the set instruction fetch configuration; the set instruction fetch configuration includes that when the data in the flag address used by the Cortex-M microcontroller to indicate whether an operation currently exists in the memory unit is 0, the Cortex-M microcontroller will repeatedly access the flag address; when the data in the flag address is not 0, the Cortex-M microcontroller determines the behavior of the next operation according to the data in the flag address;

[0056] The interrupt handling behavior of the Cortex-M microcontroller is constrained according to the set behavior configuration; the set behavior configuration includes that the Cortex-M microcontroller enters the interrupt service routine after receiving the interrupt sent by the peripheral, and in the interrupt service routine, the Cortex-M microcontroller sends the interrupt sequence number corresponding to the currently processed interrupt to the interrupt flag address and cyclically reads the interrupt flag address. When the Cortex-M microcontroller reads the interrupt flag address and finds that the data is cleared, it exits the interrupt service routine.

[0057] It can be understood that the establishment of the verification platform also needs to constrain the instruction fetch address and behavior of the Cortex-M microcontroller: Specifically, the Cortex-M microcontroller will access the flag address in the storage unit to indicate whether there is an operation currently. When the data in the flag address is 0, the Cortex-M microcontroller will repeatedly access the flag address; when the data in the flag address is not 0, the next behavior of the Cortex-M microcontroller, such as read or write, is determined based on the data read from the flag address. After reading the data in the flag address, the Cortex-M microcontroller will access the register address used to indicate the register to be accessed for the next operation. After the Cortex-M microcontroller obtains the register address, if the flag indicates that the current behavior of the Cortex-M microcontroller is read, the Cortex-M microcontroller will read the data of the register corresponding to the register address; if the flag indicates that the current behavior of the Cortex-M microcontroller is write, the Cortex-M microcontroller will access the data address used to indicate write data, and write the data read from the flag address to the register corresponding to the register address.

[0058] Constrain the interrupt handling behavior of the Cortex-M microcontroller: Specifically, when the Cortex-M microcontroller receives an interrupt from a peripheral, the Cortex-M microcontroller will enter the interrupt service routine. Under this interrupt service routine, the Cortex-M microcontroller sends the interrupt sequence number corresponding to the currently processed interrupt to the interrupt flag address and cyclically reads the interrupt flag address. When the Cortex-M microcontroller reads the interrupt flag address and finds that the data is cleared, the Cortex-M microcontroller will exit the interrupt service routine. This process is regarded as the Cortex-M microcontroller handling an interrupt.

[0059] The above constraints allow the verification platform to be initialized and used directly when it is delivered for verification, making it easier to ensure the accuracy and completeness of the interrupt monitoring module verification without the need for additional separate Cortex-M microcontroller behavior configuration.

[0060] In one embodiment, the above-mentioned interrupt monitoring module verification method based on UVM verification methodology further includes the steps of:

[0061] The coverage collection component created by the verification platform is used to collect functional coverage for the verification of the interrupt monitoring module.

[0062] It can be understood that since the interrupt monitoring module can support interrupt monitoring of multiple (for example, 8) channels at the same time, the interrupt monitoring module can cover all peripheral interrupts and various possible priority nesting situations, such as Figure 1As shown, a coverage collection component cov is also set. Complete coverage collection requires ensuring that all peripheral interrupts can correctly enter the interrupt monitoring module. The interrupt monitoring module can arbitrarily select the interrupt channel enable, all interrupt priority combinations, and the waiting time and clearing time of each interrupt, etc., so that various scenarios such as high randomness and error injection of test cases can be combined with coverage collection to make verification more complete.

[0063] For the specific limitations of the interrupt monitoring module verification method based on the UVM verification methodology, please refer to the corresponding limitations of the interrupt monitoring module verification system based on the UVM verification methodology above, which will not be repeated here.

[0064] It should be understood that although Figure 2 and Figure 3 The steps in the diagram are shown in the order indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Figure 2 and Figure 3 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0065] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the above-described method embodiments. Any reference to memory, storage, database, or other media used in the various embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus DRAM (RDRAM), and DDR DRAM.

[0066] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0067] The above embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that a person skilled in the art would be able to make numerous modifications and improvements without departing from the spirit of the present invention, all of which fall within the scope of the present invention. Therefore, the scope of the present invention shall be determined by the appended claims.

Claims

1. An interrupt monitoring module verification system based on UVM verification methodology, characterized in that, The system comprises a verification platform built using the SystemVerilog language, a basic test component is created based on the verification platform, and an instantiation design integration is performed; the basic test component is used to create a verification environment and construct test cases for implementing peripherals to send interrupts according to various verification scenarios, and each of the test cases includes a non-error injection case and an error injection case; The design integration includes peripherals, a Cortex-M microcontroller, a storage unit, and an interrupt monitoring module to be verified, and the verification environment communicates with the design code of the design integration by modifying the content of the flag address in the storage unit; The Cortex-M microcontroller reads and writes the peripherals, reads and writes the registers of the interrupt monitoring module and exits the interrupt service routine by fetching instructions. After the peripheral configuration generates an interrupt, it is sent to the interrupt monitoring module and the Cortex-M microcontroller; When selecting a test function, if the test case is selected as the non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to have the same interrupt processing priority, and the same interrupt request is selected, the peripheral is configured to initiate an interrupt, and after all interrupts are set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemptive priority, and the interrupt monitoring module monitors the highest priority interrupt and expects no abnormal alarm to be generated; the non-error injection case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating software behavior; If the test case is selected as the error injection case, the interrupt processing priorities of the Cortex-M microcontroller and the interrupt monitoring module are configured to be inconsistent, and the interrupt monitoring module generates an abnormal alarm and records it in the error record; by comparing the expected abnormal alarm result in the error record with the actual abnormal alarm result, if the results are inconsistent, the simulation is stopped, otherwise the simulation is ended.

2. the interruption monitoring module verification system based on UVM verification methodology according to claim 1, is characterized in that, If all interrupts are set at the same time, the Cortex-M microcontroller enters the interrupt service routine with the highest response priority.

3. the interruption monitoring module verification system based on UVM verification methodology according to claim 1 or 2, is characterized in that, The verification platform also creates a coverage collection component and uses a makefile file to connect the flielist of the design code of the design integration and the filelist of the verification environment. The coverage collection component is used to collect functional coverage for verification of the interrupt monitoring module.

4. A UVM-based verification method for an interrupt monitoring module, characterized in that: The invention is applied to an interrupt monitoring module verification system based on UVM verification methodology, the interrupt monitoring module verification system including a verification platform built in SystemVerilog language, a basic test component is created based on the verification platform and an instantiation design integration is performed; the basic test component is used to create a verification environment and construct test cases for realizing peripherals sending interrupts according to various verification scenarios, and each of the test cases includes a non-error injection case and an error injection case; The design integration includes peripherals, a Cortex-M microcontroller, a storage unit, and an interrupt monitoring module to be verified, and the verification environment communicates with the design code of the design integration by modifying the content of the flag address in the storage unit; The Cortex-M microcontroller reads and writes the peripherals, reads and writes the registers of the interrupt monitoring module and exits the interrupt service routine by fetching instructions. After the peripheral configuration generates an interrupt, it is sent to the interrupt monitoring module and the Cortex-M microcontroller; The interrupt monitoring module verification method based on UVM verification methodology includes the following steps: When selecting a test function, if the test case is selected as the non-error injection case, configuring the Cortex-M microcontroller and the interrupt monitoring module to have the same interrupt processing priority and enabling the same interrupt request; The peripheral is configured to initiate an interrupt, and after all interrupts are asserted, the Cortex-M microcontroller enters an interrupt service routine with the highest priority; the interrupt monitoring module monitors the highest priority interrupt and anticipates that no abnormal alarm will be generated; and the non-error injection use case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating software behavior; If the test case is selected as the error injection case, the interrupt processing priorities of the Cortex-M microcontroller and the interrupt monitoring module are configured to be inconsistent; the interrupt monitoring module generates an abnormal alarm and records it in the error log; By comparing the expected abnormal alarm result in the error record with the actual abnormal alarm result, if the results are inconsistent, the simulation is stopped, otherwise the simulation is ended.

5. the interruption monitoring module verification method based on UVM verification methodology according to claim 4, is characterized in that, If all interrupts are set at the same time, the Cortex-M microcontroller enters the interrupt service routine with the highest response priority.

6. according to the interruption monitoring module verification method based on UVM verification methodology according to claim 4 or 5, it is characterized in that, Also includes the steps: The coverage collection component created by the verification platform is used to collect functional coverage of the interrupt monitoring module verification.

7. the interruption monitoring module verification method based on UVM verification methodology according to claim 6, is characterized in that, Before selecting the test function, the following steps are also included: constraining the instruction fetch address and behavior of the Cortex-M microcontroller according to a set instruction fetch configuration; the set instruction fetch configuration includes that when the data in the flag address used by the Cortex-M microcontroller to indicate whether an operation currently exists in the storage unit is 0, the Cortex-M microcontroller will repeatedly access the flag address; when the data in the flag address is not 0, the Cortex-M microcontroller determines the behavior of the next operation according to the data in the flag address; The interrupt handling behavior of the Cortex-M microcontroller is constrained according to a set behavior configuration; the set behavior configuration includes the Cortex-M microcontroller entering an interrupt service routine after receiving an interrupt issued by the peripheral device, the Cortex-M microcontroller sending an interrupt sequence number corresponding to the currently processed interrupt to an interrupt flag address and cyclically reading the interrupt flag address, and exiting the interrupt service routine when the Cortex-M microcontroller reads the interrupt flag address and finds that the data is cleared.

Images