A hardware design verification method and device, electronic equipment and storage medium
By automatically generating register models and test sequences, and using state machines and directed acyclic graphs to control the read and write operations of register models, the problem of low efficiency in hardware design verification is solved. Automated register constraints and randomization settings are achieved, thereby improving verification efficiency.
Patent Information
- Application Number
- CN202111445087.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-11-30
- Publication Date
- 2026-01-23
- Estimated Expiration
- 2041-11-30
AI Technical Summary
In existing technologies, hardware design verification is inefficient, especially when DUT functional testing is performed by manually defining test sequences in UVM, it is difficult to maintain and implement the configuration order of registers.
By determining the register specifications and test sequence specifications of the target hardware design, register models and test sequences are automatically generated. The test sequence specifications are represented by a state machine, and the state machine is implemented through a directed acyclic graph. The read and write operations and order of the register model are automatically controlled, and the constraints between registers are configured in the database.
It improves the efficiency of hardware design verification, enables automated register constraints and randomization settings, and simplifies the verification process.
Smart Images
Figure CN114218032B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer, more particularly, to a hardware design verification method and device, an electronic device and a computer readable storage medium. BACKGROUND
[0002] Universal Verification Methodology (UVM) is widely used in verifying hardware design, and hardware behavior is usually controlled by registers. In UVM, a register model is usually used to model registers in a Design Under Test (DUT), and a test sequence generates stimuli of register read, write and other operations. If a certain function of the DUT is implemented, multiple registers need to be configured, and a specific configuration sequence is required. Therefore, it is very troublesome to manually define a test UVM sequence to complete the test of all functions of the DUT, and it is difficult to maintain.
[0003] Therefore, how to improve the efficiency of hardware design verification is a technical problem to be solved by those skilled in the art. SUMMARY
[0004] The present application aims to provide a hardware design verification method and device, an electronic device and a computer readable storage medium, which improves the efficiency of hardware design verification.
[0005] To achieve the above purpose, the present application provides a hardware design verification method, comprising:
[0006] determining a target hardware design, and obtaining a register specification and a test sequence specification of the target hardware design;
[0007] generating a register model of the target hardware design based on the register specification, and generating a test sequence of the target hardware design based on the test sequence specification;
[0008] controlling the register model by using the test sequence to verify the target hardware design.
[0009] The register specification includes any one or combination of register name, register bit width, register legal field value, field access mode, reset value, and whether to support randomization.
[0010] The test sequence specification is represented based on a state machine, each state in the state machine represents a function block in the target hardware design, and the state contains a related register sequence.
[0011] The state machine is implemented by using a directed acyclic graph.
[0012] The controlling the register model by using the test sequence comprises:
[0013] The test sequence and the register model are linked at a test layer to control read and write operations and sequences of registers in the register model by using the test sequence.
[0014] After the test sequence of the target hardware design is generated based on the test sequence specification, the method further comprises:
[0015] Determining a verification level corresponding to a verification environment of the target hardware design;
[0016] Selecting a test sequence at a corresponding level based on the verification level.
[0017] Before the register model is controlled by using the test sequence, the method further comprises:
[0018] Configuring a configuration object corresponding to the target hardware design in a configuration database to configure constraints between different registers in the register model.
[0019] To achieve the above object, the present application provides a hardware design verification device, comprising:
[0020] An acquisition module is configured to determine a target hardware design and acquire register specification and test sequence specification of the target hardware design;
[0021] A generation module is configured to generate a register model of the target hardware design based on the register specification and generate a test sequence of the target hardware design based on the test sequence specification;
[0022] A control module is configured to control the register model by using the test sequence to verify the target hardware design.
[0023] To achieve the above object, the present application provides an electronic device, comprising:
[0024] A memory is configured to store a computer program;
[0025] A processor is configured to implement steps of the above hardware design verification method when the computer program is executed.
[0026] To achieve the above object, the present application provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement steps of the above hardware design verification method.
[0027] As can be seen from the above scheme, the hardware design verification method provided in this application includes: determining a target hardware design and obtaining the register specification and test sequence specification of the target hardware design; generating a register model of the target hardware design based on the register specification and generating a test sequence of the target hardware design based on the test sequence specification; and using the test sequence to control the register model to verify the target hardware design.
[0028] The hardware design verification method provided in this application improves upon traditional verification platforms by adding register specifications and test sequence specifications. This enables the automatic generation of register models and test sequences, and automatically implements register constraints and randomization settings for register models, thereby improving hardware design verification efficiency. This application also discloses a hardware design verification device, an electronic device, and a computer-readable storage medium, which achieve the same technical effects.
[0029] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description
[0030] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. The drawings are used to provide a further understanding of this disclosure and constitute a part of the specification. They are used together with the following detailed description to explain this disclosure, but do not constitute a limitation of this disclosure. In the drawings:
[0031] Figure 1 This is a flowchart illustrating a hardware design verification method according to an exemplary embodiment;
[0032] Figure 2 This is a structural diagram illustrating a verification platform according to an exemplary embodiment;
[0033] Figure 3 This is a structural diagram illustrating a hardware design verification device according to an exemplary embodiment;
[0034] Figure 4 This is a structural diagram of an electronic device according to an exemplary embodiment. Detailed Implementation
[0035] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Furthermore, in the embodiments of this application, "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0036] This application discloses a hardware design verification method, which improves the efficiency of hardware design verification.
[0037] See Figure 1 and Figure 2 , Figure 1 This is a flowchart illustrating a hardware design verification method according to an exemplary embodiment. Figure 2 This is a structural diagram illustrating a verification platform according to an exemplary embodiment. Figure 1 As shown, it includes:
[0038] S101: Determine the target hardware design and obtain the register specification and test sequence specification of the target hardware design;
[0039] The execution entity in this embodiment is a verification platform. In specific implementation, the target hardware design to be verified, i.e., the DUT, is determined, and a main specification is defined, including a register specification and a test sequence specification. The register specification includes register names, register bit widths, valid field values of registers, field access methods, reset values, and whether randomization is supported. The test sequence specification needs to be provided in a machine-readable format, and test sequences for the target hardware design can be automatically generated in subsequent steps. Preferably, the test sequence specification is represented based on a state machine, where each state in the state machine represents a functional block in the target hardware design, and each state contains a sequence of related register programming. In specific implementation, a state machine is used in the test sequence specification, where each state represents a functional block of the minimum programmable hardware, and each state contains a sequence of related register programming. The state machine can be implemented using directed acyclic graphs (DAGs), which simplifies the parsing and automatic generation process and minimizes branching during implementation.
[0040] S102: Generate a register model of the target hardware design based on the register specification, and generate a test sequence of the target hardware design based on the test sequence specification;
[0041] In this step, the parsing script is invoked to automatically generate a compliant register model based on the register specification. The parsing script is also invoked to parse the state machine and automatically generate a compliant test sequence based on the test sequence specification. In other words, the register specification and the test sequence specification must meet the corresponding conditions to ensure automated generation.
[0042] Preferably, this step further includes: determining the verification level corresponding to the verification environment of the target hardware design; and selecting a test sequence of the corresponding level based on the verification level. In specific implementations, different verification environments correspond to different verification levels, and different verification levels correspond to different levels of test sequences. This can be achieved through the connection of hierarchical state machines to distinguish different verification levels and select the corresponding level of test sequences according to the verification environment.
[0043] In a preferred embodiment, this step further includes configuring a configuration object corresponding to the target hardware design in the configuration database to configure constraints between different registers in the register model. It is understood that if the test platform aims for complete randomization, the constraints on the random values of the register model become complex due to the dependencies between multiple registers. Such constraints are difficult to implement within the model itself, and manual constraints are time-consuming and laborious. If the test platform only verifies specific functions, it needs to avoid randomizing the entire register model and control the randomization of local registers. Therefore, a configuration object corresponding to the target hardware design exists in the configuration database. This configuration object contains register models at various levels, and complex constraints that are difficult to generate automatically in the register model are implemented through the configuration object. The randomization level of the register model can also be controlled through the configuration object; that is, complex constraints between different registers in the register model can be configured through this configuration object.
[0044] S103: Use the test sequence to control the register model to verify the target hardware design.
[0045] In this step, a link is established between the test sequence and the register model at the test layer to control the read and write operations and order of registers in the register model using the test sequence. The target hardware design is then verified by controlling the verification environment.
[0046] The verification platform in this embodiment is based on the UVM register model and improves upon traditional verification platforms by adding a master design specification, automatic parsing scripts, and a configuration database to link test sequences and the register model. This platform can automatically generate test sequences and define complex constraints and randomize the register model.
[0047] The hardware design verification method provided in this application improves upon traditional verification platforms by adding register specifications and test sequence specifications, enabling automatic generation of register models and test sequences, and automatically implementing register constraints and randomization settings for register models, thereby improving the efficiency of hardware design verification.
[0048] The following describes a hardware design verification device provided in an embodiment of this application. The hardware design verification device described below and the hardware design verification method described above can be referred to each other.
[0049] See Figure 3 A structural diagram of a hardware design verification apparatus is shown according to an exemplary embodiment, such as... Figure 3 As shown, it includes:
[0050] The acquisition module 301 is used to determine the target hardware design and acquire the register specifications and test sequence specifications of the target hardware design;
[0051] Generation module 302 is used to generate a register model of the target hardware design based on the register specification, and to generate a test sequence of the target hardware design based on the test sequence specification;
[0052] The control module 303 is used to control the register model using the test sequence to verify the target hardware design.
[0053] The hardware design verification device provided in this application improves upon traditional verification platforms by adding register specifications and test sequence specifications, enabling automatic generation of register models and test sequences, and automatically implementing register constraints and randomization settings for register models, thereby improving hardware design verification efficiency.
[0054] Based on the above embodiments, as a preferred implementation, the register specification includes register name, register bit width, valid register field values, field access mode, reset value, and whether randomization is supported, including any one or a combination of these items.
[0055] Based on the above embodiments, as a preferred implementation, the test sequence specification is represented by a state machine, where each state in the state machine represents a functional block in the target hardware design, and the state contains a sequence of related registers.
[0056] Based on the above embodiments, as a preferred implementation, the state machine is implemented using a directed acyclic graph.
[0057] Based on the above embodiments, as a preferred implementation, the control module 303 is specifically a module that establishes a link between the test sequence and the register model in the test layer, so as to use the test sequence to control the read and write operations and order of the registers in the register model, so as to verify the target hardware design.
[0058] Based on the above embodiments, as a preferred embodiment, it further includes:
[0059] The determination module is used to determine the verification level corresponding to the verification environment of the target hardware design.
[0060] The selection module is used to select the test sequence corresponding to the verification level.
[0061] Based on the above embodiments, as a preferred embodiment, it further includes:
[0062] The configuration module is used to configure the configuration object corresponding to the target hardware design in the configuration database, so as to configure the constraints between different registers in the register model.
[0063] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0064] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 4 This is a structural diagram of an electronic device according to an exemplary embodiment, such as... Figure 4 As shown, the electronic device includes:
[0065] Communication interface 1 enables information exchange with other devices, such as network devices;
[0066] Processor 2 is connected to communication interface 1 to enable information interaction with other devices and, when running a computer program, executes the hardware design verification method provided by one or more of the above-mentioned technical solutions. The computer program is stored in memory 3.
[0067] Of course, in practical applications, the various components in an electronic device are coupled together through bus system 4. It can be understood that bus system 4 is used to achieve communication and connection between these components. In addition to the data bus, bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 4 The general will label all buses as Bus System 4.
[0068] The memory 3 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.
[0069] It is understood that memory 3 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 3 described in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.
[0070] The methods disclosed in the embodiments of this application can be applied to processor 2, or implemented by processor 2. Processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 2 or by instructions in the form of software. The processor 2 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 2 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 3. Processor 2 reads the program in memory 3 and completes the steps of the aforementioned method in combination with its hardware.
[0071] When processor 2 executes the program, it implements the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.
[0072] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 3 that stores a computer program, which can be executed by a processor 2 to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.
[0073] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.
[0074] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.
[0075] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A hardware design verification method, characterized in that, include: The target hardware design is determined, and the register specification and test sequence specification of the target hardware design are obtained; wherein, the test sequence specification is represented by a state machine, each state in the state machine represents a functional block in the target hardware design, and the state contains the relevant register programming sequence; A register model for the target hardware design is generated based on the register specification, and a test sequence for the target hardware design is generated based on the test sequence specification. The verification level corresponding to the verification environment of the target hardware design is determined, and a test sequence of the corresponding level is selected based on the verification level; wherein, different verification environments correspond to different verification levels, and different verification levels correspond to different levels of test sequences, and different verification levels are distinguished by connecting hierarchical state machines. Configure the configuration object corresponding to the target hardware design in the configuration database; wherein, the configuration object contains register models at various levels, and the randomization degree of the register model and the constraints between different registers in the register model are controlled by the configuration object; The register model is controlled using the test sequence to verify the target hardware design; The step of controlling the register model using the test sequence includes: A link is established between the test sequence and the register model in the test layer, so as to use the test sequence to control the read and write operations and order of registers in the register model.
2. The hardware design verification method according to claim 1, characterized in that, The register specification includes register name, register bit width, valid register field values, field access mode, reset value, and whether randomization is supported, among other things.
3. The hardware design verification method according to claim 1, characterized in that, The state machine is implemented using a directed acyclic graph.
4. A hardware design verification device, characterized in that, include: An acquisition module is used to determine a target hardware design and acquire the register specifications and test sequence specifications of the target hardware design; wherein, the test sequence specifications are represented based on a state machine, each state in the state machine represents a functional block in the target hardware design, and the state contains a sequence of related register transformations; The generation module is used to generate a register model of the target hardware design based on the register specification, and to generate a test sequence of the target hardware design based on the test sequence specification; The selection module is used to determine the verification level corresponding to the verification environment of the target hardware design, and select the corresponding level of test sequence based on the verification level; wherein, different verification environments correspond to different verification levels, and different verification levels correspond to different levels of test sequences, and different verification levels are distinguished by connecting hierarchical state machines. The configuration module is used to configure the configuration object corresponding to the target hardware design in the configuration database; wherein, the configuration object contains register models at various levels, and the randomization degree of the register model and the constraints between different registers in the register model are controlled by the configuration object; A control module is used to control the register model using the test sequence to verify the target hardware design; Specifically, the control module is used to: establish a link between the test sequence and the register model in the test layer, so as to use the test sequence to control the read and write operations and order of the registers in the register model.
5. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the hardware design verification method as described in any one of claims 1 to 3 when executing the computer program.
6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the hardware design verification method as described in any one of claims 1 to 3.
Citation Information
Patent Citations
Chip test method, system and device and storage medium
CN112131827A