CN113076227A - MCU verification method, system and terminal equipment - Google Patents
MCU verification method, system and terminal equipment Download PDFInfo
- Publication number
- CN113076227A CN113076227A CN202110469341.3A CN202110469341A CN113076227A CN 113076227 A CN113076227 A CN 113076227A CN 202110469341 A CN202110469341 A CN 202110469341A CN 113076227 A CN113076227 A CN 113076227A
- Authority
- CN
- China
- Prior art keywords
- mcu
- register
- read
- verification
- value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012795 verification Methods 0.000 title claims abstract description 137
- 238000000034 method Methods 0.000 title claims abstract description 57
- 230000006870 function Effects 0.000 claims abstract description 80
- 230000004044 response Effects 0.000 claims abstract description 45
- 238000012360 testing method Methods 0.000 claims abstract description 27
- 230000005284 excitation Effects 0.000 claims abstract description 11
- 238000013461 design Methods 0.000 claims description 13
- 238000004590 computer program Methods 0.000 claims description 10
- 230000001360 synchronised effect Effects 0.000 claims description 9
- 230000002159 abnormal effect Effects 0.000 claims description 5
- 238000013507 mapping Methods 0.000 claims description 4
- 238000012544 monitoring process Methods 0.000 claims description 3
- 238000004088 simulation Methods 0.000 abstract description 9
- 238000010586 diagram Methods 0.000 description 9
- 230000002093 peripheral effect Effects 0.000 description 6
- 230000006399 behavior Effects 0.000 description 5
- 238000013508 migration Methods 0.000 description 5
- 230000005012 migration Effects 0.000 description 5
- 230000003993 interaction Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000002829 reductive effect Effects 0.000 description 4
- 239000003795 chemical substances by application Substances 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/26—Functional testing
- G06F11/263—Generation of test inputs, e.g. test vectors, patterns or sequences ; with adaptation of the tested hardware for testability with external testers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/26—Functional testing
- G06F11/273—Tester hardware, i.e. output processing circuits
Abstract
The embodiment of the application provides a method, a system and a terminal device for MCU verification, wherein the method comprises the following steps: generating a corresponding register configuration message according to the test excitation of the target register, and writing an address index and a pre-configuration value contained in the register configuration message into a storage unit of the MCU so that the MCU operates the target register in the corresponding module; and meanwhile, sending the configuration message to a reference model corresponding to the MCU, and comparing an expected response output by the reference model with an actual response output by the MCU to verify the system function of the MCU and/or the function of a corresponding module. According to the method, most functions are verified at a module level, only one unified module level simulation platform needs to be built, compared with the existing verification method, the fact that a large number of instruction programs need to be developed is avoided, the fact that many verification platforms are built for specific modules is also avoided, not only can MCU be effectively verified, but also the utilization rate of the general verification platform is improved.
Description
Technical Field
The present application relates to the field of chip verification technologies, and in particular, to a method, a system, and a terminal device for MCU verification.
Background
With the development of IC (integrated circuit) process technology and EDA (electronic design automation) design level, the capability and technology of MCU (micro controller Unit) design using IP (intellectual property) core has been greatly improved. The application of the unified bus specification can ignore the difference of ports among IP cores, so that the interconnection of various IP cores becomes simple, the whole system including a microprocessor, an on-chip bus, a memory module, an I/O peripheral device and the like can be integrated into one chip, the area of a PCB (printed circuit board) is reduced while various functions are realized, the reliability of the whole system is improved, and the power consumption of the device can be reduced. However, the more functions of the chip, the higher the complexity of the chip, and the greater the difficulty of the verification work. One of the important research directions in IC design today is how to perform functional verification quickly and efficiently. For example, for a series of MCU products, a verification platform corresponding to the MCU product can be constructed according to its functional characteristics, so that the verification platform can be applied to different products of the same series, which is also one of the methods to improve verification efficiency, shorten verification time, and speed up the time to market.
Disclosure of Invention
The embodiment of the application provides a method, a system and a terminal device for verifying an MCU (microprogrammed control unit), which can realize effective verification of the MCU, avoid the need of developing a large number of instruction programs and the establishment of a plurality of verification platforms aiming at specific modules compared with the existing verification mode, greatly reduce the workload, fully utilize the inherent components of the general verification platform, and facilitate platform migration among different projects.
The embodiment of the application provides an MCU verification method, which is applied to a general verification platform, wherein the general verification platform is constructed with a reference model with the same function as an MCU to be verified, and the method comprises the following steps:
generating a corresponding register configuration message according to the obtained test excitation of the target register, wherein the register configuration message comprises an address index, a pre-configuration value and a read-write control value of the target register;
writing the address index, the pre-configuration value and the read-write control value into a storage unit of the MCU, and triggering the MCU to operate the target register in the corresponding module according to the read-write control value;
sending the register configuration message to the reference model so that the reference model performs response output according to the register configuration message;
comparing the expected response output by the reference model with the monitored actual response output by the MCU and outputting a comparison result, wherein the comparison result is used for verifying the system function of the MCU and/or the function of the corresponding module.
In some embodiments, the generating of the test stimulus for the target register comprises:
obtaining related information of a target register corresponding to the function of the module to be verified according to the register unified addressing information of the MCU;
and generating test excitation of the target register according to the relevant information of the target register.
In some embodiments, before writing the address index, the preconfigured value, and the read-write control value into the storage unit of the MCU, the method further includes:
performing function distribution on storage spaces corresponding to three addresses in the storage unit of the MCU through a firmware program, wherein the storage space corresponding to a first address is used for storing the address index, the storage space corresponding to a second address is used for storing the pre-configuration value, and the storage space corresponding to a third address is used for storing a synchronization signal value and the read-write control value;
performing path mapping on the target register based on a top-level design mode, wherein the path is used for performing back-door access of the register;
the writing the address index and the preconfigured value into a storage unit of the MCU includes:
and respectively writing the address index and the pre-configuration value into storage spaces corresponding to the first address and the second address in the MCU in a back door access mode.
In some embodiments, the MCU includes a CPU and a storage unit connected to the CPU, and the triggering of the MCU to operate the register in the corresponding module according to the read-write control value includes:
setting the synchronous signal value to be in a set state, wherein the synchronous signal value in the set state is used for triggering the CPU to read the read-write control value and carrying out register operation on a corresponding module according to the read-write control value and the address index in the storage unit;
and if the synchronous signal value is detected to be changed from the setting state to the zero clearing state, determining to finish the register configuration operation.
In some embodiments, the performing, according to the read-write control value, a register operation on the corresponding module according to the address index in the storage unit includes:
if the read-write control value indicates write operation, the CPU sends the pre-configuration value in the storage unit to a target register designated by the address index;
and if the read-write control value indicates read operation, the CPU transmits the data stored in the target register appointed by the address index in the storage unit to the pre-configuration value.
In some embodiments, verifying whether the system function of the MCU and/or the function of the corresponding module are normal using the comparison result includes:
if the expected response is consistent with the actual response, determining that the system function of the MCU and/or the function of the corresponding module are correct;
and if the expected response is inconsistent with the actual response, further judging the abnormal condition of the system function of the MCU and/or the function of the corresponding module.
An embodiment of the present application further provides an MCU verification system, including: the system comprises an MCU to be verified and a general verification platform, wherein the general verification platform is connected with the MCU to be verified and is also constructed with a reference model with the same function as the MCU; the general verification platform is used for executing the method to verify the MCU.
In some embodiments, the universal verification platform includes a sequencer, a driver, a monitor, and a score board, wherein the driver and the monitor are respectively connected to the MCU through a physical interface, the sequencer is connected to the driver, the reference model, and the score board are respectively connected in sequence through a first-in first-out data buffer, and the monitor is connected to the score board through a first-in first-out data buffer;
the sequencer is used for generating a corresponding register configuration message according to the obtained test excitation of the target register, wherein the register configuration message comprises an address index, a pre-configuration value and a read-write control value of the target register;
the driver is used for writing the address index, the pre-configuration value and the read-write control value into a storage unit of the MCU and triggering the MCU to operate the target register in the corresponding module according to the read-write control value;
the driver is further used for sending the register configuration message to the reference model so that the reference model performs response output according to the register configuration message;
the monitor is used for monitoring the actual response output by the MCU;
the scoring board is used for recording an expected response output by the reference model, comparing the expected response with the actual response and outputting a comparison result, wherein the comparison result is used for verifying the system function of the MCU and/or the function of the corresponding module.
An embodiment of the present application further provides a terminal device, where the terminal device includes a processor and a memory, where the memory stores a computer program, and the processor is configured to execute the computer program to implement the MCU verification method.
An embodiment of the present application further provides a readable storage medium, which stores a computer program, and when the computer program runs on a processor, the MCU verification method described above is implemented.
The embodiment of the application has the following beneficial effects:
according to the MCU verification method, the corresponding register configuration message is generated according to the test excitation of the target register, and after the address index and the pre-configuration value contained in the register configuration message are written into the storage unit of the MCU, the MCU operates the target register in the corresponding module; and meanwhile, the register configuration message is sent to a reference model corresponding to the MCU, and the expected response output by the reference model and the actual response output by the MCU are compared for verifying whether the system function of the MCU and/or the function of the corresponding module are correct or not. This application puts down most functions module level and verifies, not only can effectively verify MCU's system level and/or module level function, owing to only need set up a unified module level simulation platform, compare current verification mode, avoided needing to develop a large amount of instruction programs (such as assembly and C program etc.), also avoided setting up respective verification platform respectively to specific module, so work load that can significantly reduce, in addition, still improved the rate of utilization to general verification platform, easily realize the platform migration between the different projects.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.
Fig. 1 is a schematic workflow diagram illustrating a UVM verification platform according to an embodiment of the present application;
fig. 2 is a schematic structural diagram of a UVM verification platform according to an embodiment of the present application;
FIG. 3 shows a first flowchart of an MCU verification method according to an embodiment of the present application;
FIG. 4 shows a second flowchart of the MCU verification method according to the embodiment of the present application;
FIG. 5 is a diagram illustrating address allocation in a memory unit of an MCU according to an embodiment of the present application;
FIG. 6 is a coverage rate indication diagram of an MCU verification result of the MCU verification method according to the embodiment of the present application;
fig. 7 shows a schematic structural diagram of an MCU verification system according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments.
The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.
Hereinafter, the terms "including", "having", and their derivatives, which may be used in various embodiments of the present application, are intended to indicate only specific features, numbers, steps, operations, elements, components, or combinations of the foregoing, and should not be construed as first excluding the existence of, or adding to, one or more other features, numbers, steps, operations, elements, components, or combinations of the foregoing.
Furthermore, the terms "first," "second," "third," and the like are used solely to distinguish one from another and are not to be construed as indicating or implying relative importance.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of the present application belong. The terms (such as those defined in commonly used dictionaries) should be interpreted as having a meaning that is consistent with their contextual meaning in the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein in various embodiments.
Practice of the present applicationIn the example, the MCU is a short term micro controller Unit (Microcontroller Unit), sometimes called a microcomputer or a single chip microcomputer, and generally includes a Central Processing Unit (CPU), a memory (memory), a counter (Timer), a serial communication interface (USB), an analog-to-digital (a/D) module, a UART interface, and an I interface2One or more of the C bus, the SPI bus and the like can be designed in different combinations according to different application occasions.
Currently, there are two main methods for MCU verification: 1. the whole system is taken as a verification target, a verification platform is built, a system level firmware program is compiled, and the purpose of verification is achieved through interaction between the system level firmware program and the verification platform. 2. The whole system is divided into individual modules, and a corresponding verification platform is set up for each module, so that functional behavior verification of the individual modules is completed, and then integrated verification is performed. Both the two methods can adopt Universal Verification Methodology (UVM) to build a Verification platform, and Verification is carried out by utilizing a UVM platform framework.
For the first method, the whole system is taken as a verification target, and since the MCU system includes a CPU, a global firmware program considering the CPU needs to be written for each use case during verification, which may cause the following problems: 1) the workload is large; 2) each verifier is required to have the ability to design a global firmware program; 3) the interaction between the global firmware program and the verification platform is tight, so that the platform migration between different projects is difficult; 4) because the function of the CPU cannot be simulated in the reference model of the UVM platform, a system-level firmware program cannot be used, and further, the automatic comparison between the reference model and the MCU cannot be realized. In other words, although the verification platform is built based on the UVM verification methodology, the utilization rate of available components provided in the UVM framework is not high, for example, the automatic comparison function of reference model and monitor is not used; 5) because the use of a system level firmware program of a CPU function needs to be considered, randomization is difficult to achieve, complex use cases and abnormal use cases are difficult to construct, and further the code coverage rate is low.
For the second method, the whole system is divided into modules for individual verification, a verification platform is set up for each module, cases are compiled, and verification is completed, so that the requirements on manpower and time are high. For example, if a system includes 20 modules, this means that 20 verification platforms are built, which is a heavy task. In addition, the coverage data can only be provided separately in individual modules, and cannot form a complete coverage data.
Therefore, the embodiment of the application provides a new MCU verification method to solve at least one of the defects in the two existing schemes, the MCU verification method can realize effective verification of the MCU, in addition, inherent components of a general verification platform are fully utilized, on one hand, the workload can be greatly reduced, and on the other hand, platform migration between different projects and the like can be easily realized.
In the embodiment of the application, a UVM verification method is also used for building a verification platform, and as shown in fig. 1, in the verification process of a built UVM verification platform, peripheral elements of an MCU during actual operation are simulated mainly by developing corresponding verification components, and then the verification components are integrated with virtual prototypes (which can be designed as gate-level circuits with delays and the like) of the MCU. And simultaneously, developing a test program, and loading a memory mapping file generated by compiling and connecting into a corresponding memory model so that the memory model can be fetched from the memory model for execution, thereby simulating the internal processing flow of the MCU to carry out various verification works. The MCU verification method is described below with reference to specific embodiments.
Example 1
Referring to fig. 2, the present embodiment provides an MCU verification method, which can be applied to a general verification platform, and when the MCU needs to be verified, the MCU to be verified can be connected to the general verification platform, so as to verify whether the function of the MCU is normal through the interaction between the general verification platform and the MCU. The embodiment performs simulation verification based on the UVM verification platform.
Referring to a UVM verification platform architecture shown in fig. 2, exemplarily, the UVM verification platform architecture may include components such as a sequencer (sequence), a driver (driver), a monitor (monitor), a score board (scoreboard), an agent (agent), and a reference model (reference model), and specifically, an actually required verification platform is built through a transaction level. As shown in fig. 2, the sequencer is connected to the driver, the reference model and the score board are respectively connected in sequence through a first-in first-out data buffer (FIFO), and the monitor is also connected to the score board through a first-in first-out data buffer (FIFO), and finally the score board prints out a verification report.
The agent can be used for instantiating the sequencer, the driver and the monitor, connecting the driver and the sequencer through an interface, and also used for preparing data obtained by the monitor to be sent to a score board and the like by using a TLM mechanism, and a user can define configuration according to actual needs, wherein the TLM (transaction level modifying) mechanism is a transaction (transaction) based communication mode. The sequencer can be used for receiving an input test case or test stimulus, generating a test data packet meeting format requirements through transaction, and sending the test data packet to a driver and the like. The driver establishes a connection with a Device Under Test (DUT) through a physical interface, requests a Test sequence from the sequencer, and sends the resulting data packet to the DUT, a reference model, and the like. The reference model is a model having the same function as the DUT, is developed based on a hardware description language according to the requirements of each module, and can also be understood as a mirror image of the DUT. Unlike an actual DUT, the reference model focuses on the functionality and behavior of the input and output of the DUT, while not paying much attention to its internal logic.
Generally, one MCU may include a CPU and various modules connected to the CPU through a bus, such as a memory module including an SRAM chip, an AD conversion module, and a UART interface, a USB interface module, etc. Before the MCU verification is performed, when a corresponding reference model is constructed, for example, a reference submodel of each module in the MCU may be constructed according to a gate-level circuit design with delay provided by the MCU, and then each reference submodel is packaged into a reference model having the same function as the MCU.
In the existing verification method, a UVM verification platform mainly builds a UVM module-level simulation platform and/or a UVM system-level simulation platform according to an object to be verified, and the difference between the UVM and the UVM is mainly in different concerned angles, namely the system-level simulation platform mainly concerns the behavior above the modules, namely whether the interconnection interaction among the modules is normal under the participation of a CPU; and the module-level simulation platform is deeply inserted into the corresponding module and pays attention to whether the functions and behaviors in the specific module are normal or not. For example, for system level verification of the MCU, it may be verified whether the responses between the respective modules are normal with the participation of the CPU, and for a certain module, such as the UART interface, it may be verified whether it can read data from the outside or send data to the outside, etc.
However, in the embodiment of the application, a unified module-level platform is built, most functions are transferred to the module level for verification, and the system level only does little work, so that the system-level functions are verified when the module-level functions are verified, and the workload of writing a global firmware program for each use case is greatly reduced.
Exemplarily, a module-level platform as shown in fig. 2 is built for verification, and a system TOP layer (TOP) mode is adopted for code verification design, so that configuration is issued to a certain module by means of a uniform channel of an MCU system through the system TOP layer, and when a certain module needs to be operated, the operation can be performed at the system TOP layer and conducted to a target module by means of conduction between modules inside the MCU.
In one embodiment, the unified addressing information of the MCU registers can be used as the basis for the top-level design of the system. The above-mentioned unified addressing information of the register can be obtained by the design scheme of the MCU, which is mainly used to describe the condition that the input/output ports (i.e. I/O ports) of each module in the MCU are mapped into the physical address space of the CPU. Typically, most peripherals operate by reading and writing registers on the device, also referred to as I/O ports. And the physical addresses of all peripheral I/O ports can be mapped into one physical address space of the CPU and uniformly addressed in the physical address space. Thus, the CPU can access the peripheral I/O port as a memory unit without setting up a special peripheral I/O instruction. It can be understood that the function verification of each module requires the corresponding I/O port to respond, so that the configuration operation of the specific register in the corresponding module can be used to verify whether the corresponding function of the corresponding module is normal.
When the MCU is verified, most functions can be downloaded to the module level for verification, and it should be noted that, while the functions of the corresponding modules are verified through register configuration operation, since the existing channels in the MCU system are used for downloading configuration, if the configuration operation is successful or the associated modules respond, the interactive interconnection between the modules is normal, i.e., the system level functions are verified.
The following describes a general verification process performed by using one of the module functions of an MCU to be verified. The MCU to be verified comprises a CPU and a plurality of modules connected with the CPU, wherein the modules comprise a memory (storage unit), a plurality of interface modules and the like; and constructing a UVM module-level verification platform based on the MCU to be verified, wherein the UVM verification platform is pre-constructed with a reference model with the same function as the MCU to be verified. Exemplarily, as shown in fig. 3, the MCU verification method includes the following steps:
step S110, generating a corresponding register configuration message according to the obtained test excitation of the target register, wherein the register configuration message comprises an address index, a pre-configuration value and a read-write control value of the target register.
Exemplarily, a sequence generator component in the verification platform receives a test stimulus testcase of a target register corresponding to a function of a module to be verified in the MCU, which is input by a user or generated by the platform, and further generates a corresponding register configuration message by using the test stimulus, where the register configuration message may include a plurality of parameters related to the target register configuration, for example, an address index of the register, a preconfigured value, and the like.
In one embodiment, the register configuration message may include definition parameters sfr _ addr, sfr _ data, and sfr _ wrd, where sfr _ addr is used to store an address index of a register to be accessed; for sfr _ data, if it is a write operation, data ready to be written into the corresponding register stored in sfr _ addr can be stored; if the operation is a read operation, the data read from the corresponding register stored in sfr _ addr can be stored; sfr _ wrd is a read/write control bit that is used in conjunction with sfr _ addr and sfr _ data, e.g., 0, to indicate a read register operation; at 1, a write register operation is indicated.
In the above description, as shown in fig. 4, the obtaining of the test stimulus of the target register may include the following steps:
step S201, obtaining the relevant information of the target register corresponding to the function of the module to be verified according to the register unified addressing information of the MCU.
Step S202, generating the test excitation of the target register according to the relevant information of the target register.
Exemplarily, since the register unified addressing information of the MCU reflects the unified addressing condition of accessible registers in each module, for the function of a certain module, the corresponding register may be determined, and then the register unified addressing information may be queried to obtain the relevant information of the target register, which may include, but is not limited to, register address, register bit number, definition of each bit, and the like.
Furthermore, the corresponding test stimulus can be designed according to the related information of the target register, for example, when a certain bit is in a set state, other modules can be triggered to respond, and then when the test stimulus is generated, the corresponding bit can be set to a value corresponding to the set state to monitor the response condition of other modules and the like. It will be appreciated that test stimuli are typically designed according to specific functional requirements.
For the step S110, after the register configuration message is generated, the driver inputs the register configuration message into the MCU, and simultaneously sends the register configuration message to the reference module, that is, the steps S120 and S130 are respectively executed, and since the reference module corresponds to the actual module in the MCU, it can be verified whether the corresponding function is expected by comparing whether the output responses of the MCU and the reference module are consistent. It can be understood that the present embodiment will fully use the components supported by the verification platform for verification, which can reduce the workload of verification, etc.
And step S120, writing the address index, the pre-configuration value and the read-write control value into a storage unit of the MCU, and triggering the MCU to operate the target register in the corresponding module according to the read-write control value.
Exemplarily, after the driver establishes a connection with the MCU through the physical interface, the address index and the pre-configuration value in the register configuration message are written into a storage unit, typically a memory, of the MCU. And then, the driver is matched with the minimum firmware program running in the MCU, and the pre-configuration value is written into the corresponding register in the corresponding module in the MCU, namely, the register configuration operation is realized.
Before the MCU operates, a minimum firmware program will be designed. Exemplarily, the main workflow of the minimal firmware program is as follows: allocating functions to memory spaces corresponding to three addresses in a memory unit of the MCU, wherein the memory space corresponding to the first address is used for storing the address index, namely corresponding to sfr _ addr; the storage space corresponding to the second address is used for storing the pre-configuration value sfr _ data, and the storage space corresponding to the third address is used for storing the synchronization signal value and the read-write control value.
For example, as shown in fig. 5, storage spaces corresponding to 2045, 2046, 2047 addresses of 2K × 32bit SARM (static random access memory) in the MCU may be used, wherein the 2047 address is used for storing a 32-bit register address; the 2046 address is used to store a 32-bit register configuration value; the 2045 addresses take the lower 2 bits, bit1 and bit0, to store the sync signal value and the read/write control value, respectively. Wherein bit1 represents the synchronous signal of driver and the CPU, set by the driver, and cleared by the minimum firmware program; bit0 represents the read-write control mark, which is set and cleared by the driver, when it is 1, it represents the current write operation to the register; when the value is 0, it indicates that the register is read this time.
In addition, in order to realize direct writing of the address index and the pre-configured value, before verification, mapping paths of accessible registers in the MCU are set based on the top-level design, and the paths are used for realizing back-gate access of the registers. The back door access is an access mode which can directly read or modify register variables through a signal path of an associated register. Because the bus protocol passes through the MCU, the bus error can be effectively captured, and then the access path of the bus is verified.
For the step S120, the driver will exemplarily write the address index and the pre-configured value into the memory space corresponding to the first address and the second address in the MCU by a back-door access manner. Then, the driver sets the value of the synchronization signal to a set state (i.e. 1' b1), which triggers the CPU to read the read-write control value and perform register operation on the corresponding module according to the read-write control value and the address index in the storage unit; and if the synchronous signal value is detected to be changed from the setting state to the zero clearing state, determining to finish the register configuration operation.
In one embodiment, if the read-write control value is a write operation, the CPU sends the preconfigured value in the storage unit to a target register specified by the address index; if the read-write control value is read operation, the data stored in the target register appointed by the address index is transmitted to the pre-configuration value.
Taking the SARM shown in fig. 5 as an example, sfr _ addr is written into the storage space corresponding to the 2047 address; sfr _ data is written into the storage space corresponding to the 2046 address. In addition, the driver will set bit0 to either 0 (read) or 1 (write) depending on whether the present register configuration message is a read or write register operation. Further, the driver sets the above-mentioned synchronizing signal value bit1 to a set state (i.e., 1' b1), after which the CPU can start to perform the corresponding register operation. After this is done, the driver starts to detect the value of bit1 until it detects bit1 changes from the set state to the clear state.
For the minimum firmware program operated by the CPU, the value of the synchronous signal is continuously detected, if bit1 is equal to 1, the value of bit0 is judged, and if bit0 is equal to 1, the minimum firmware program directly sends sfr _ data to the address specified by sfr _ addr in the MCU; if bit0 is equal to 0, the minimum firmware program will transfer the data stored at the address designated by sfr _ addr to sfr _ data. When this is done, the minimum firmware program sets bit1 to 0 (i.e., a clear state). Thus, the driver determines that this register configuration operation is completed after detecting bit1 changing from 1 to 0. Optionally, a next register configuration message may be sent.
Step S130, the register configuration message is sent to a reference model, so that the reference model performs response output according to the register configuration message.
The reference module has a function corresponding to that of the MCU, and can obtain a correct expected response signal when test stimulus is input for simulation. Illustratively, the driver also reports the send register configuration to the reference model at the same time so that the reference model makes the correct actions or outputs as functionally required. It is understood that the result output by the reference model is the expected result.
And step S140, comparing the expected response output by the reference model with the monitored actual response output by the MCU and outputting a comparison result, wherein the comparison result is used for verifying whether the system function of the MCU and/or the function of the corresponding module are normal.
Exemplarily, a monitor in the verification platform may be connected to the MCU through a physical interface to monitor and obtain an actual response of the MCU after the register configuration operation is performed, and then, the two responses are automatically compared to obtain a verification result. For example, if the expected response and the actual response are consistent, it is determined that the corresponding module of the MCU functions normally, i.e., the output and behavior are correct, which is expected. For the system function, it can be specifically verified whether the currently verified function relates to interactive interconnection with other modules, and if so, the corresponding system-level function can also be verified to be normal. On the contrary, if the expected response is not consistent with the actual response, the abnormal conditions of the system function of the MCU and/or the functions of the corresponding modules need to be further determined. It is understood that after one function is verified, the verification of the next function can be continued, also using the above steps S110-S140.
Compared with the existing first method, the MCU verification method of the embodiment only does little work at the system level by putting most functions down to the module level for verification, thereby greatly reducing the workload of writing firmware programs for each use case; platform migration between different projects is easy to realize because of no need of participation of a global firmware program; in addition, because the module level does not need excessive participation of a CPU, register configuration operation is mainly carried out by running a minimum firmware program, so that complex use cases and abnormal use cases are convenient and easy, and the code coverage rate is high; it will be appreciated that the CPU in the present method is primarily responsible for assisting in the register configuration. In addition, the method can also make full use of the inherent components of the verification platform, such as FIFO, TLM mechanism, transaction, reference model, monitor, and the like, and can improve the resource utilization rate of the verification platform, thereby reducing the verification workload.
Compared with the second method in the prior art, the MCU verification method of the embodiment adopts the top-level design of the system, and can naturally form rich interfaces and channels between the internal modules of the DUT and the modules, so that a verification platform is not required to be independently built for each module when each module is verified, and only a unified module-level simulation platform is built, thereby greatly reducing the workload; in addition, as only one uniform verification platform is provided, a complete coverage rate data can be generated. For example, fig. 6 shows a verification test result of coverage data of a certain MCU, and it can be seen that the verification results of the functions of each module of the whole MCU can be presented on the same verification platform.
Example 2
Referring to fig. 7, based on the method of embodiment 1, this embodiment provides an MCU verification system, exemplarily, the MCU verification system includes an MCU to be verified and a universal verification platform, the universal verification platform is connected to the MCU to be verified, and the universal verification platform further constructs a reference model with the same function as the MCU to be verified. In this embodiment, the universal verification platform may adopt the UVM verification platform in embodiment 1.
Exemplarily, as shown in fig. 2, the UVM verification platform mainly includes a sequencer, a driver, a monitor, a score board, and other components, where the driver and the monitor are respectively connected to the MCU to be verified through a physical interface, the sequencer is connected to the driver, the reference model, and the score board are respectively connected in sequence through an FIFO, and the monitor is connected to the score board through the FIFO.
In the MCU verification process, the sequencer is used for generating a corresponding register configuration message according to the obtained test excitation of the target register, wherein the register configuration message comprises an address index and a pre-configuration value of the target register and a read-write control value.
The driver is used for writing the address index, the pre-configuration value and the read-write control value into a storage unit of the MCU, and triggering the MCU to operate the target register in the corresponding module according to the read-write control value. The driver is also used for sending the register configuration message to the reference model so that the reference model responds and outputs according to the register configuration message.
The monitor is used for monitoring the actual response output by the MCU. And the scoring board is used for recording an expected response output by the reference model, comparing the expected response with the actual response and outputting a comparison result report. And the comparison result is used for verifying whether the system function of the MCU and/or the function of the corresponding module are normal or not. It is to be understood that the alternatives described above in relation to the UVM verification platform in embodiment 1 are equally applicable to this embodiment and therefore will not be described again here.
The application further provides a terminal device, exemplarily comprising a processor and a memory, where the memory stores a computer program, and the processor enables the terminal device to execute the functions of each module in the MCU verification method or the MCU verification apparatus.
The application also provides a readable storage medium for storing the computer program used in the terminal device.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative and, for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, each functional module or unit in each embodiment of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a smart phone, a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application.
Claims (10)
1. An MCU verification method is characterized by being applied to a general verification platform, wherein the general verification platform is constructed with a reference model with the same function as an MCU to be verified, and the method comprises the following steps:
generating a corresponding register configuration message according to the obtained test excitation of the target register, wherein the register configuration message comprises an address index, a pre-configuration value and a read-write control value of the target register;
writing the address index, the pre-configuration value and the read-write control value into a storage unit of the MCU, and triggering the MCU to operate the target register in the corresponding module according to the read-write control value;
sending the register configuration message to the reference model so that the reference model performs response output according to the register configuration message;
comparing the expected response output by the reference model with the monitored actual response output by the MCU and outputting a comparison result, wherein the comparison result is used for verifying the system function of the MCU and/or the function of the corresponding module.
2. The MCU verification method of claim 1, wherein the generation of the test stimulus of the target register comprises:
obtaining related information of a target register corresponding to the function of the module to be verified according to the register unified addressing information of the MCU;
and generating test excitation of the target register according to the relevant information of the target register.
3. The MCU verification method of claim 2, wherein before writing the address index, the preconfigured value, and the read-write control value into a memory unit of the MCU, further comprising:
performing function distribution on storage spaces corresponding to three addresses in the storage unit of the MCU through a firmware program, wherein the storage space corresponding to a first address is used for storing the address index, the storage space corresponding to a second address is used for storing the pre-configuration value, and the storage space corresponding to a third address is used for storing a synchronization signal value and the read-write control value;
performing path mapping on the target register based on a top-level design mode, wherein the path is used for performing back-door access of the register;
the writing the address index and the preconfigured value into a storage unit of the MCU includes:
and respectively writing the address index and the pre-configuration value into storage spaces corresponding to the first address and the second address in the MCU in a back door access mode.
4. The MCU authentication method according to claim 3, wherein the MCU comprises a CPU and a storage unit connected with the CPU, and the triggering of the MCU to operate the target register in the corresponding module according to the read-write control value comprises:
setting the synchronous signal value to be in a set state, wherein the synchronous signal value in the set state is used for triggering the CPU to read the read-write control value and carrying out register operation on a corresponding module according to the read-write control value and the address index in the storage unit;
and if the synchronous signal value is detected to be changed from the setting state to the zero clearing state, determining to finish the register configuration operation.
5. The MCU authentication method according to claim 4, wherein the performing a register operation on the corresponding module according to the read-write control value and the address index in the storage unit comprises:
if the read-write control value indicates write operation, the CPU sends the pre-configuration value in the storage unit to a target register designated by the address index;
and if the read-write control value indicates read operation, the CPU transmits the data stored in the target register appointed by the address index in the storage unit to the pre-configuration value.
6. The MCU verification method according to claim 1, wherein verifying the system function of the MCU and/or the function of the corresponding module using the comparison result comprises:
if the expected response is consistent with the actual response, determining that the system function of the MCU and/or the function of the corresponding module are correct;
and if the expected response is inconsistent with the actual response, further judging the abnormal condition of the system function of the MCU and/or the function of the corresponding module.
7. An MCU verification system, comprising: the system comprises an MCU to be verified and a general verification platform, wherein the general verification platform is connected with the MCU to be verified and also constructs a reference model with the same function as the MCU; wherein the universal verification platform is configured to perform the method of any one of claims 1-6 to verify the MCU.
8. The system according to claim 7, wherein the universal verification platform comprises a sequencer, a driver, a monitor and a score board, wherein the driver and the monitor are respectively connected to the MCU through physical interfaces, the sequencer is connected to the driver, the reference model and the score board are respectively connected sequentially through a first-in first-out data buffer, and the monitor is connected to the score board through a first-in first-out data buffer;
the sequencer is used for generating a corresponding register configuration message according to the obtained test excitation of the target register, wherein the register configuration message comprises an address index, a pre-configuration value and a read-write control value of the target register;
the driver is used for writing the address index, the pre-configuration value and the read-write control value into a storage unit of the MCU and triggering the MCU to operate the target register in the corresponding module according to the read-write control value;
the driver is further used for sending the register configuration message to the reference model so that the reference model performs response output according to the register configuration message;
the monitor is used for monitoring the actual response output by the MCU;
the scoring board is used for recording an expected response output by the reference model, comparing the expected response with the actual response and outputting a comparison result, wherein the comparison result is used for verifying the system function of the MCU and/or the function of the corresponding module.
9. A terminal device, characterized in that the terminal device comprises a processor and a memory, the memory storing a computer program, the processor being configured to execute the computer program to implement the MCU authentication method of any one of claims 1-7.
10. Readable storage medium, characterized in that it stores a computer program which, when run on a processor, implements the MCU verification method according to any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110469341.3A CN113076227A (en) | 2021-04-28 | 2021-04-28 | MCU verification method, system and terminal equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110469341.3A CN113076227A (en) | 2021-04-28 | 2021-04-28 | MCU verification method, system and terminal equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113076227A true CN113076227A (en) | 2021-07-06 |
Family
ID=76619038
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110469341.3A Pending CN113076227A (en) | 2021-04-28 | 2021-04-28 | MCU verification method, system and terminal equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113076227A (en) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113835757A (en) * | 2021-09-29 | 2021-12-24 | 深圳大普微电子科技有限公司 | Method and device for sharing register model by multiple hosts and electronic equipment |
| CN113901754A (en) * | 2021-09-26 | 2022-01-07 | 清华大学 | FPGA-based Ethernet MACIP board-level verification structure and method |
| CN114301812A (en) * | 2021-12-29 | 2022-04-08 | 北京物芯科技有限责任公司 | Method, device, equipment and storage medium for monitoring message processing result |
| CN114417780A (en) * | 2021-12-16 | 2022-04-29 | 北京百度网讯科技有限公司 | State synchronization method and device, electronic equipment and storage medium |
| CN115146568A (en) * | 2022-09-01 | 2022-10-04 | 南京芯驰半导体科技有限公司 | Chip verification system and verification method based on UVM |
| CN115599618A (en) * | 2022-11-17 | 2023-01-13 | 深圳市楠菲微电子有限公司（Cn） | Register dynamic relocation verification method and device, storage medium and processor |
| CN115632856A (en) * | 2022-10-20 | 2023-01-20 | 西安爱芯元智科技有限公司 | Verification system and verification method |
| CN116627496A (en) * | 2023-03-08 | 2023-08-22 | 南京金阵微电子技术有限公司 | UVM-based register model construction and verification method, system and electronic equipment |
| CN116661859A (en) * | 2023-07-27 | 2023-08-29 | 灵动集成电路南京有限公司 | Driving method and device of MCU peripheral circuit module and terminal equipment |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20060018644A (en) * | 2004-08-25 | 2006-03-02 | 삼성전자주식회사 | Rom testing method for micro controller unit by check-sum |
| CN102096628A (en) * | 2009-12-15 | 2011-06-15 | 上海华虹集成电路有限责任公司 | Method for realizing microprogrammed control unit (MCU) verification platform based on verification methodology of verification methodology manual (VMM) |
| US20180300431A1 (en) * | 2017-04-18 | 2018-10-18 | Raytheon Company | Universal verification methodology (uvm) register abstraction layer (ral) traffic predictor |
| CN110618929A (en) * | 2019-08-01 | 2019-12-27 | 广东工业大学 | Verification platform and verification method of symmetric encryption algorithm based on UVM |
| CN112559264A (en) * | 2020-12-08 | 2021-03-26 | 北京京航计算通讯研究所 | Simulation test method for realizing FPGA (field programmable Gate array) universal serial port by verification platform based on UVM (Universal verification Module) |
| CN112579381A (en) * | 2020-12-28 | 2021-03-30 | 杭州德旺信息技术有限公司 | UVM-based UART bus UVM verification system and method |
-
2021
- 2021-04-28 CN CN202110469341.3A patent/CN113076227A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20060018644A (en) * | 2004-08-25 | 2006-03-02 | 삼성전자주식회사 | Rom testing method for micro controller unit by check-sum |
| CN102096628A (en) * | 2009-12-15 | 2011-06-15 | 上海华虹集成电路有限责任公司 | Method for realizing microprogrammed control unit (MCU) verification platform based on verification methodology of verification methodology manual (VMM) |
| US20180300431A1 (en) * | 2017-04-18 | 2018-10-18 | Raytheon Company | Universal verification methodology (uvm) register abstraction layer (ral) traffic predictor |
| CN110618929A (en) * | 2019-08-01 | 2019-12-27 | 广东工业大学 | Verification platform and verification method of symmetric encryption algorithm based on UVM |
| CN112559264A (en) * | 2020-12-08 | 2021-03-26 | 北京京航计算通讯研究所 | Simulation test method for realizing FPGA (field programmable Gate array) universal serial port by verification platform based on UVM (Universal verification Module) |
| CN112579381A (en) * | 2020-12-28 | 2021-03-30 | 杭州德旺信息技术有限公司 | UVM-based UART bus UVM verification system and method |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113901754B (en) * | 2021-09-26 | 2022-11-01 | 清华大学 | FPGA-based Ethernet MACIP board-level verification structure and method |
| CN113901754A (en) * | 2021-09-26 | 2022-01-07 | 清华大学 | FPGA-based Ethernet MACIP board-level verification structure and method |
| CN113835757B (en) * | 2021-09-29 | 2023-08-15 | 深圳大普微电子科技有限公司 | Method and device for sharing register model by multiple hosts and electronic equipment |
| CN113835757A (en) * | 2021-09-29 | 2021-12-24 | 深圳大普微电子科技有限公司 | Method and device for sharing register model by multiple hosts and electronic equipment |
| CN114417780A (en) * | 2021-12-16 | 2022-04-29 | 北京百度网讯科技有限公司 | State synchronization method and device, electronic equipment and storage medium |
| CN114417780B (en) * | 2021-12-16 | 2022-11-01 | 北京百度网讯科技有限公司 | State synchronization method and device, electronic equipment and storage medium |
| CN114301812A (en) * | 2021-12-29 | 2022-04-08 | 北京物芯科技有限责任公司 | Method, device, equipment and storage medium for monitoring message processing result |
| CN115146568A (en) * | 2022-09-01 | 2022-10-04 | 南京芯驰半导体科技有限公司 | Chip verification system and verification method based on UVM |
| CN115632856A (en) * | 2022-10-20 | 2023-01-20 | 西安爱芯元智科技有限公司 | Verification system and verification method |
| CN115599618A (en) * | 2022-11-17 | 2023-01-13 | 深圳市楠菲微电子有限公司（Cn） | Register dynamic relocation verification method and device, storage medium and processor |
| CN115599618B (en) * | 2022-11-17 | 2023-03-31 | 深圳市楠菲微电子有限公司 | Register dynamic change-allocation verification method and device, storage medium and processor |
| CN116627496A (en) * | 2023-03-08 | 2023-08-22 | 南京金阵微电子技术有限公司 | UVM-based register model construction and verification method, system and electronic equipment |
| CN116627496B (en) * | 2023-03-08 | 2023-12-29 | 南京金阵微电子技术有限公司 | UVM-based register model construction and verification method, system and electronic equipment |
| CN116661859A (en) * | 2023-07-27 | 2023-08-29 | 灵动集成电路南京有限公司 | Driving method and device of MCU peripheral circuit module and terminal equipment |
| CN116661859B (en) * | 2023-07-27 | 2023-10-10 | 灵动集成电路南京有限公司 | Driving method and device of MCU peripheral circuit module and terminal equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113076227A (en) | MCU verification method, system and terminal equipment | |
| CN115841089B (en) | System-level chip verification platform and verification method based on UVM | |
| US20110078350A1 (en) | Method for generating multiple serial bus chip selects using single chip select signal and modulation of clock signal frequency | |
| WO2018018978A1 (en) | Universal serial bus controller verification method, system and device | |
| CN101251819A (en) | Debug method suitable for multi-processor core system chip | |
| CN111859834B (en) | UVM-based verification platform development method, system, terminal and storage medium | |
| CN113486625B (en) | Chip verification method and verification system | |
| CN115184764A (en) | Chip testing method and device, electronic equipment and storage medium | |
| CN115496018A (en) | Multi-version verification method, device and equipment for SoC (System on chip) | |
| CN113868987A (en) | System-level chip verification platform and verification method thereof | |
| CN113849433A (en) | Bus controller execution method and device, bus controller, computer equipment and storage medium | |
| CN103793263B (en) | DMA transaction-level modeling method based on Power PC processor | |
| CN103713977B (en) | Microprocessor IP (internet protocol) kernel comparison and verification implementation method | |
| US20050144436A1 (en) | Multitasking system level platform for HW/SW co-verification | |
| JP4187470B2 (en) | Semiconductor device development support cooperation device and development support method | |
| CN114548027A (en) | Method for tracking signal in verification system, electronic device and storage medium | |
| CN108228965B (en) | Simulation verification method, device and equipment for memory cell | |
| US7228513B2 (en) | Circuit operation verification device and method | |
| CN110261758B (en) | Device under test verification device and related product | |
| US20080281576A1 (en) | Interface board, simulator, synchronization method, and synchronization program | |
| JP2001209556A (en) | Verification supporting system | |
| CN113760751B (en) | Method for generating test case, electronic device and storage medium | |
| CN112885403B (en) | Function test method, device and equipment of Flash controller | |
| JP2011039781A (en) | Cooperative simulator and simulation method | |
| CN117131821B (en) | Chip verification method, device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |