Function verification method and device for hardware design, equipment, medium and product

Abstract

The invention provides a function verification method and device for hardware design, electronic equipment, a computer readable storage medium and a computer program product, which can be applied to the field of hardware verification, and the method comprises the following steps: building a test platform corresponding to the to-be-verified hardware design by using a meta-model; continuously sending the current excitation data packets to a test platform through a client socket; wherein the current excitation data packet is generated by performing behavior selection based on coverage rate data fed back by an emulator through an intelligent agent in an RL environment; the excitation data packet received by the test platform is utilized to continuously drive the hardware design to be tested; continuously collecting coverage rate data after the to-be-tested hardware is designed and driven by adopting a simulator, and continuously feeding back the current coverage rate data to the RL environment; and when the current coverage rate data meets the verification target condition, stopping driving the to-be-verified hardware design, and completing the function verification target. Therefore, the verification efficiency is improved, and the hardware design period is shortened.

Description

Technical Field

[0001] The present disclosure relates to the field of circuit testing, specifically to the field of hardware verification, and more specifically to a method, device, electronic device, computer-readable storage medium, and computer program product for functional verification of hardware design. Background Art

[0002] ‌Hardware design is not only the basis for realizing product functions, but also can significantly affect the cost, performance and market competitiveness of products, and plays a vital role in product development. At present, in the complete chip development cycle, 70% of the design development time and resources are used for functional verification. However, with the increasing complexity of hardware design, traditional functional verification methods face many challenges when dealing with large-scale designs. Different types of hardware designs such as processor IP, controller modules, and complex system chips need to be verified using different functional verification methods, which leads to an extension of the verification cycle, thereby affecting the time to market of the product, and the efficiency of achieving the design time to market goal is gradually reduced. Therefore, the necessity of speeding up the functional verification process is obvious, and functional verification is widely regarded as a bottleneck in the hardware design cycle.

[0003] In addition, the increasing complexity of system-on-chip (SOC) designs has brought great challenges to verification, especially in meeting coverage fast convergence targets. Currently, coverage convergence relies heavily on random constraints and coverage-driven verification methods, where random stimuli are limited to verify certain scenarios and meet coverage targets. This process is cumbersome and consumes a lot of project time, resulting in long hardware design cycles and low verification efficiency. Summary of the invention

[0004] In order to solve at least one of the above-mentioned technical problems caused by the long functional verification cycle of hardware design in the prior art, the present disclosure provides a functional verification method, device, electronic device, computer-readable storage medium and computer program product for hardware design.

[0005] According to the first aspect of the present disclosure, a method for functional verification of a hardware design is provided, comprising: using a metamodel to build a test platform corresponding to a hardware design to be tested; continuously sending a current stimulus data packet to the test platform through a client socket; wherein the current stimulus data packet is generated by an agent in an RL environment making behavior selections based on coverage data fed back by a simulator; using the test platform to continuously drive the hardware design to be tested based on the current stimulus data packet; using the simulator to continuously collect coverage data after driving the hardware design to be tested to obtain current coverage data, and continuously feeding back the current coverage data to the RL environment; and when the current coverage data meets the verification target condition, stopping driving the hardware design to be tested to complete the functional verification target.

[0006] In the embodiment of the present disclosure, a test platform is created through a metamodel, the RL environment and the test platform are connected through a client socket, and stimulus data packets are continuously sent to the test platform to drive the hardware design. The RL agent is used to generate effective incentives based on the feedback coverage data, which can achieve coverage convergence of the hardware design to be verified more quickly. In addition, an automated framework is created using the metamodel to generate a test platform and RL environment for any given design. This method can be applied to various hardware designs. Compared with traditional constrained random verification, the RL agent provides effective incentives for behavior selection, which can achieve coverage convergence more quickly.

[0007] According to an embodiment of the present disclosure, the current stimulus data packet is generated by an agent in an RL environment performing behavior selection based on coverage data fed back by a simulator, including: reading the coverage data fed back by the simulator through the RL environment; based on a learning feedback strategy and a feedback update strategy, selecting a next new behavior through the agent, and using the new behavior as the current new stimulus; and using the agent to package the current new stimulus and the corresponding port name to generate the current stimulus data packet.

[0008] According to an embodiment of the present disclosure, the feedback update strategy includes: if the coverage data of the feedback is greater than the previous coverage data in the RL environment, the feedback value is updated to 1; and if the coverage data of the feedback is not greater than the previous coverage data in the RL environment, the feedback value is updated according to a preset reward and punishment feedback scheme.

[0009] According to an embodiment of the present disclosure, the learning feedback strategy includes: any one of the reinforcement learning algorithms of Q-learning, SARSA, DDPG, AC, A2C, PPO, DQN and TRPO.

[0010] According to an embodiment of the present disclosure, the method of continuously sending the current stimulus data packet to the test platform through the client socket includes: the test platform continuously sending the current stimulus request to the RL environment through the client socket; and the RL environment continuously receiving the current stimulus request and continuously sending the current stimulus data packet to the test platform through the client socket.

[0011] According to an embodiment of the present disclosure, the use of a metamodel to build a test platform corresponding to the hardware design to be tested includes: parsing the hardware design to be tested to obtain port parameter information of standard specifications; and creating the test platform based on the port parameter information and a predefined template using the metamodel.

[0012] According to an embodiment of the present disclosure, parsing the hardware design to be tested to obtain port parameter information of standard specifications includes: using a preset code parsing method to parse the register transfer level code of the hardware design to be tested to extract port parameter information; and creating a standardized format specification based on the port parameter information to obtain parameter interface information of the standard specifications.

[0013] According to an embodiment of the present disclosure, the method also includes: reading the port parameter information through the RL environment, and determining the behavior space based on the port parameter information; and using the agent to randomly select an initial behavior in the behavior space, use the initial behavior as an initial stimulus, and package the initial stimulus and the corresponding port name to generate an initial stimulus data packet.

[0014] According to an embodiment of the present disclosure, the types of coverage data include: one or more of line coverage, condition coverage, state machine coverage, flip coverage, path coverage, branch coverage and assertion coverage.

[0015] According to an embodiment of the present disclosure, the hardware design to be tested includes: any one of: DUT, processor IP, controller module, system-level chip and IP core.

[0016] The second aspect of the present disclosure provides a functional verification device for a hardware design, including: a creation module, used to use a metamodel to build a test platform corresponding to a hardware design to be tested; a stimulus module, used to send a current stimulus data packet to the test platform through a client socket; wherein the current stimulus data packet is generated by an agent in an RL environment making behavior selections based on coverage data fed back by a simulator; a drive module, used to use the test platform to continuously drive the hardware design to be tested based on the current stimulus data packet; a feedback module, used to use the simulator to continuously collect coverage data after the hardware design to be tested is driven, obtain current coverage data, and continuously feed back the current coverage data to the RL environment; and a target module, used to stop driving the hardware design to be tested and complete the functional verification target when the current coverage data meets the verification target condition.

[0017] According to an embodiment of the present disclosure, according to an embodiment of the present disclosure, the stimulus module includes: a reading unit, used to read the coverage data fed back by the simulator through the RL environment; an intelligent selection unit, used to select the next new behavior through the agent based on the learning feedback strategy and the feedback update strategy, and use the new behavior as the current new stimulus; and a packaging unit, used to use the agent to package the current new stimulus and the corresponding port name to generate the current stimulus data packet.

[0018] According to an embodiment of the present disclosure, the feedback update strategy includes: if the coverage data of the feedback is greater than the previous coverage data in the RL environment, the feedback value is updated to 1; and if the coverage data of the feedback is not greater than the previous coverage data in the RL environment, the feedback value is updated according to a preset reward and punishment feedback scheme.

[0019] According to an embodiment of the present disclosure, the learning feedback strategy includes: any one of the reinforcement learning algorithms of Q-learning, SARSA, DDPG, AC, A2C, PPO, DQN and TRPO.

[0020] According to an embodiment of the present disclosure, the stimulus module includes: a request unit, used for the test platform to continuously send the current stimulus request to the RL environment through the client socket; and a sending unit, used for the RL environment to continuously receive the current stimulus request through the client socket, and continuously send the current stimulus data packet to the test platform.

[0021] According to an embodiment of the present disclosure, the creation module includes: a parsing unit, used to parse the hardware design to be tested to obtain port parameter information in a standard format; and a creation unit, used to create the test platform based on the port parameter information of the standard specification and the predefined template using the metamodel.

[0022] According to an embodiment of the present disclosure, the parsing unit includes: an information extraction unit, which is used to parse the register transfer level code of the hardware design to be tested using a preset code parsing method to extract port parameter information; and a format specification unit, which is used to create a standardized format specification based on the port parameter information to obtain parameter interface information of the standard specification.

[0023] According to an embodiment of the present disclosure, the device also includes: an initial module, used to read the port parameter information through the RL environment, and determine the behavior space based on the port parameter information; and using the intelligent agent to randomly select an initial behavior in the behavior space, use the initial behavior as an initial stimulus, and package the initial stimulus and the corresponding port name to generate an initial stimulus data packet.

[0024] According to an embodiment of the present disclosure, the types of coverage data include: one or more of line coverage, condition coverage, state machine coverage, flip coverage, path coverage, branch coverage and assertion coverage.

[0025] According to an embodiment of the present disclosure, the hardware design to be tested includes: any one of: DUT, processor IP, controller module, system-level chip and IP core.

[0026] A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0027] The fourth aspect of the present disclosure further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the steps of the above method when the above computer program or instructions are executed by a processor.

[0028] The fifth aspect of the present disclosure further provides a computer program product, including a computer program or instructions, which implement the steps of the above method when the above computer program or instructions are executed by a processor.

[0029] The functional verification method, device, electronic device, computer-readable storage medium, and computer program product of the hardware design provided by the embodiments of the present disclosure have one of the following beneficial effects:

[0030] (1) The functional verification method of the present invention belongs to a design-independent verification framework, which is not only applicable to specific designs, but also widely applicable to various types of design verification requirements. Traditional verification methods usually require a customized verification platform for each design, which increases development time and verification complexity. The design-independent framework of the present invention can be flexibly adjusted to adapt to different types of designs such as processor IP, controller modules, DUT, IP cores, complex system-level chips, etc. This adaptability makes the verification process more universal and modular, thereby reusing the verification platform between different projects, greatly improving verification efficiency and saving development costs.

[0031] (2) Traditional verification methods rely on constrained random verification, which requires engineers to manually adjust constraints to optimize stimulus generation. The reinforcement learning (RL) algorithm is used to generate verification stimuli. By introducing the reinforcement learning algorithm, the generation of hardware random test cases is innovatively driven, and the RL agent is used to generate verification stimuli, making the generation process of the test platform more automated. Compared with traditional random stimulus generation, the RL agent can select efficient stimulus sequences under the optimization strategy.

[0032] (3) The RL agent can automatically generate effective verification incentives by intelligently exploring the designed state space. Unlike random incentive generation, the RL agent can adaptively adjust the incentive strategy based on the designed feedback and reward signals, and gradually optimize the generated incentive sequence. This means that the RL agent can specifically select incentives that can achieve the coverage target faster, rather than ineffectively wasting computing resources on redundant paths. In this way, the RL agent can achieve the same or even higher coverage with fewer incentives. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The above contents and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0034] Figure 1 A diagram schematically illustrates an application scenario of a method, apparatus, electronic device, computer-readable storage medium, and computer program product for functional verification of hardware design according to an embodiment of the present disclosure;

[0035] Figure 2 A flowchart of a reinforcement learning algorithm for a functional verification method of a hardware design according to an embodiment of the present disclosure is schematically shown;

[0036] Figure 3 A flowchart of a method for functional verification of hardware design according to an embodiment of the present disclosure is schematically shown;

[0037] Figure 4 A metamodel execution flow chart of a functional verification method for hardware design according to an embodiment of the present disclosure is schematically shown;

[0038] Figure 5 A verification framework diagram of a functional verification method for hardware design according to an embodiment of the present disclosure is schematically shown;

[0039] Figure 6 A flowchart of creating a test platform for a method for functional verification of hardware design according to an embodiment of the present disclosure is schematically shown;

[0040] Figure 7 The following schematically shows a flowchart of a method for functional verification of hardware design according to an embodiment of the present disclosure;

[0041] Figure 8 The flowchart of generating incentives of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown;

[0042] Fig. 9 The AC algorithm diagram of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown;

[0043] Fig.10 The sending stimulus flow chart of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown;

[0044] Fig.11 The initial stimulus flow chart of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown;

[0045] Fig.12 A block diagram schematically shows a structure of a functional verification device for hardware design according to an embodiment of the present disclosure; and

[0046] Fig.13 A block diagram of an electronic device suitable for implementing a function verification method of hardware design according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0047] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0048] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise", "include", etc. used herein indicate the existence of features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0049] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0050] When using expressions such as "at least one of A, B, and C, etc.", they should generally be interpreted according to the meaning of the expression commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0051] In the functional verification of hardware design, simulation is often used. Functional verification based on simulation is a mature and powerful technology that utilizes the methods of constrained random verification (CRV) and coverage driven verification (CDV). Although simulation verification strengthens the verification process, it is still a big challenge to achieve the coverage target, which is also necessary to end the functional verification. This is because simulation verification requires engineers to manually participate in adjusting the constraints in the testbench according to previous random tests to drive more effective incentives to achieve the final coverage target.

[0052] In the CRV method, random test stimuli can be generated to cover more functional scenarios by imposing constraints on the input signals in the test platform. However, randomness does not always automatically achieve high coverage, and verification engineers are required to intervene manually to perform the following tasks: First, adjust the constraints according to the simulation results to ensure that the generated test data is closer to the uncovered functional points. Second, guide the randomness by purposefully adding or modifying specific stimuli so that verification can specifically cover edge cases or complex scenarios. This manual adjustment and guidance process is not only time-consuming, but also highly dependent on the experience of verification engineers.

[0053] The core goal of the CDV method is to help the verification team identify insufficiently tested functional areas by tracking coverage metrics. Although CDV is a powerful technique, the following challenges still exist: (1) Insufficient automation: In complex systems, random testing may not be able to efficiently cover all functions, especially some edge cases. (2) Excessive manual intervention: Verification engineers need to manually analyze and adjust constraints based on coverage data to promote coverage improvement.

[0054] Although simulation-based functional verification is the core technology in the current verification process, the need to manually adjust constraints to achieve coverage targets is still a major pain point for verification engineers. In order to further overcome the problem, further reduce manual participation in verification, and improve verification efficiency, the current simulation verification method can be improved by introducing reinforcement learning algorithms for functional verification, generating more effective stimuli, reducing manual intervention, and improving verification efficiency and accuracy. Therefore, the following improvements are made in combination with CRV and CDV: Automatic constraint adjustment based on machine learning: Introduce intelligent algorithms to automatically analyze uncovered functional points and adjust the constraints of random stimuli, thereby reducing human intervention. For example, reinforcement learning technology is used to automatically explore the test stimulus space; adaptive test platform: Design an adaptive test platform that can dynamically adjust the stimulus generation strategy, and automatically adjust it according to real-time coverage data, rather than relying entirely on manual modifications by engineers, thereby proposing a functional verification method for the hardware design of this application.

[0055] Specifically, an embodiment of the present disclosure provides a functional verification method for a hardware design, the method comprising: using a metamodel to build a test platform corresponding to a hardware design to be tested; continuously sending a current stimulus data packet to the test platform through a client socket; wherein the current stimulus data packet is generated by an agent in an RL environment performing behavior selection based on coverage data fed back by a simulator; using the test platform to continuously drive the hardware design to be tested based on the current stimulus data packet; using a simulator to continuously collect coverage data after the hardware design to be tested is driven to obtain current coverage data, and continuously feeding back the current coverage data to the RL environment; and when the current coverage data meets the verification target condition, stopping driving the hardware design to be tested to complete the functional verification target.

[0056] Due to the functional verification method of hardware design provided by the embodiment of the present disclosure, in order to improve the efficiency of functional verification, machine learning and automation technology are introduced to accelerate test case generation, improve coverage, optimize test processes and provide better debugging and error location support. By combining reinforcement learning methods and automation technology, the design time-to-market goals can be better met, thereby improving the efficiency of the overall verification process. A test platform is created through a metamodel, the RL environment and the test platform are connected through a client socket, and stimulus data packets are continuously sent to the test platform to drive the hardware design. The RL agent is used to generate effective incentives based on the feedback coverage data, which can achieve coverage convergence of the hardware design to be verified faster. In addition, an automated framework is created using a metamodel to generate a test platform and RL environment for any given design. This method can be applied to various hardware designs. Compared with traditional constrained random verification, the RL agent provides effective incentives for behavior selection, which can achieve coverage convergence faster.

[0057] It should be noted that the functional verification method and device for hardware design provided in the embodiments of the present disclosure can be applied to the field of circuit testing technology, the field of hardware verification, or any technical field other than the above-mentioned technical fields. The application field of the functional verification method and device for hardware design provided in the embodiments of the present disclosure is not specifically limited.

[0058] An embodiment of the present disclosure provides a method for functional verification of hardware design.

[0059] Figure 1 The application scenario diagram of the functional verification method, apparatus, electronic device, computer-readable storage medium and computer program product of the hardware design according to the embodiments of the present disclosure is schematically shown.

[0060] like Figure 1 As shown, the application scenario 100 according to this embodiment may include functional verification of a circuit design. A network 104 is used to provide a medium for a communication link between terminal devices 101, 102, 103 and a server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0061] Users can use terminal devices 101, 102, 103 to interact with server 105 through network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only examples).

[0062] The terminal devices 101 , 102 , and 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0063] The server 105 may be a server that provides various services, such as a background management server (only as an example) that provides support for websites browsed by users using the terminal devices 101, 102, and 103. The background management server may analyze and process the received data such as user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal device.

[0064] It should be noted that the functional verification method of the hardware design provided in the embodiment of the present disclosure can generally be executed by the server 105. Accordingly, the functional verification device of the hardware design provided in the embodiment of the present disclosure can generally be set in the server 105. The functional verification method of the hardware design provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105. Accordingly, the functional verification device of the hardware design provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105.

[0065] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0066] The following will be based on Figure 1 The scene described by Figure 2~Figure 11 The functional verification method of the hardware design of the disclosed embodiment is described in detail.

[0067] The functional verification method of the hardware design disclosed in the present invention is implemented based on the reinforcement learning algorithm. Figure 2 The flowchart of the reinforcement learning algorithm of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown.

[0068] Reinforcement Learning algorithm (RL algorithm) is a special type of Machine Learning algorithm (ML), such as Figure 2As shown in the figure, in the process of reinforcement learning, the agent and the environment are constantly interacting. Policy is a method of determining action based on state. The agent obtains the state of the environment and makes an action based on the state and strategy. This action will cause the state of the environment in which the agent is located to change, and the agent will get certain feedback from the change of the environment. This feedback is used by the agent to judge whether its previous action is reasonable.

[0069] Exemplarily, the steps of a typical RL algorithm are as follows:

[0070] 1. First, the agent interacts with the environment by performing actions;

[0071] 2. The agent performs actions and moves from one state to another;

[0072] 3. The agent will then receive feedback based on the actions it performed;

[0073] 4. Based on the feedback, the agent will know whether the behavior is good or bad;

[0074] 5. If the behavior is good, it means that the agent has received positive feedback, i.e. reward, then the agent will prefer to perform that behavior, otherwise the agent will try to perform other behaviors that lead to rewards.

[0075] The RL algorithm is a trial-and-error learning process, where the agent can gain insight into which actions will bring rewards and which actions will bring negative feedback or punishment. Obviously, the higher the feedback the agent gets from the actions it takes, the more successful the agent is. The purpose of reinforcement learning is to allow an agent to maximize the feedback it can get in a complex and uncertain environment.

[0076] The core components of the RL algorithm are shown in Table 1 below, which contains the definitions of these core components and their representation in a given coverage convergence problem.

[0077] Table 1 Core components of RL algorithms

[0078]

[0079] Figure 3 The flowchart of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown.

[0080] like Figure 3 As shown, the functional verification method of the hardware design of this embodiment includes operations S310 to S350, and the functional verification method can be automatically executed.

[0081] In operation S310, a test platform corresponding to the hardware design to be tested is constructed using the metamodel.

[0082] In an embodiment of the present disclosure, the hardware design to be tested includes: any one of: DUT, processor IP, controller module, system-level chip and IP core.

[0083] It is worth mentioning that DUT (Device Under Test) is the design under test, which refers to the circuit or system verified during the test process, that is, the test unit on the chip under test in chip testing. DUT is usually the functional unit of the chip, such as memory, on-chip microcontroller, etc. During chip testing, a series of tests will be performed on DUT to verify whether its functions are normal.

[0084] Processor IP is the design of a circuit module with independent functions, which can be applied to other chip design projects to reduce design workload and shorten the design cycle.

[0085] The controller module is responsible for coordinating and controlling various operations in a device or system.

[0086] System on Chip (SoC) is a design that integrates multiple processors, controllers and other functional modules into a single chip.

[0087] IP core (Intellectual Property Core) is an intellectual property core, that is, a pre-designed circuit function module that can improve design efficiency and success rate.

[0088] Figure 4 The metamodel execution flow chart of the functional verification method of hardware design according to an embodiment of the present disclosure is schematically shown.

[0089] like Figure 4 As shown in the figure, the metamodel uses port parameter information (Specification) in a standard format and a predefined template (Template) to build a test platform. In the metamodel, each model (design) has a corresponding metamodel to define its structure, constraints, and properties. These metamodels are usually represented as structured data sources, such as XML files. The metamodel environment facilitates interaction with these models by providing access, creation, and conversion functions based on metamodel descriptions. The environment (Autogenerated APIs) usually includes an automatically generated API that allows users to interact with model instances and their properties. Mako-based templates (Template) and template engines (Template engine) use this API to generate the required code (code).

[0090] It is worth mentioning that code generation is essential to improve chip design efficiency. However, adopting Python-based code generators may lead to inconsistent data structures. Modeling with metamodels helps ensure data interoperability between various generators and promotes code reusability. Metamodels are necessary to resolve inconsistencies between different systems that need to generate consistent automatic code from a common source.

[0091] In operation S320, the current stimulus data packet is continuously sent to the test platform through the client socket; wherein the current stimulus data packet is generated by the agent in the RL environment performing behavior selection based on the coverage data fed back by the simulator.

[0092] Socket is a system API interface that encapsulates the TCP / IP protocol cluster, so that there is no need to pay attention to the protocol itself, and you can directly use the interface provided by the socket to interconnect and communicate with processes on different hosts. A socket is one end of process communication on the network, and provides a mechanism for application layer processes to exchange data using network protocols.

[0093] Continuously means that the operation is performed again after each test clock cycle, that is, in the current clock cycle, the current stimulus data packet generated by the agent is sent to the test platform through the client socket, and after entering the next test cycle, the new current stimulus data generated by the agent is continued to be sent to the test platform in the next clock cycle.

[0094] In each clock cycle, the client socket connects the test platform and the RL environment. The test platform sends stimulus requests to the RL environment through the client socket. The RL environment receives the stimulus requests through the client socket. The agent generates stimulus data and sends the stimulus data to the test platform through the client socket, so that the test platform drives the hardware design to be tested based on the stimulus data, obtains coverage data, and feeds back the coverage data to the RL environment to continue to enter the next test cycle.

[0095] It is worth noting that RL environment represents reinforcement learning environment, which is configured by providing design details in the configuration file. The design details include top-level modules, coverage types, learning feedback strategies, ports, and feedback mechanisms.

[0096] Top-level module: the design IP to be verified, that is, the hardware design to be verified.

[0097] Coverage type: The type of coverage data collected. The configuration file contains coverage options. The coverage option (-cm) specifies the type of coverage that the hardware design to be tested can achieve. For example, if the coverage type is configured as: -cm line+cond+fsm+tgl+branch+assert, it means that the types of coverage data include line coverage, condition coverage, state machine coverage, flip coverage, path coverage, branch coverage, and assertion coverage.

[0098] In an embodiment of the present disclosure, the types of coverage data include: one or more of line coverage, condition coverage, state machine coverage, flip coverage, path coverage, branch coverage and assertion coverage.

[0099] Learning feedback strategy: RL algorithms (such as PPO, A2C, or DQN) guide the learning process of the RL agent.

[0100] Ports: Ports in the hardware design IP that help increase the coverage range, such as control ports, data input / output ports, status indication ports, clock and reset ports, debug ports, etc. By properly configuring and utilizing these ports, the behavior of the hardware design IP can be more comprehensively verified and the overall coverage can be improved. Among them, the control port allows the configuration and control of the hardware design IP, usually including reset and enable signals, etc. Through these control ports, different states and configurations can be tested to improve coverage. Data input / output ports are used for data transmission and can be tested through a variety of data patterns (for example, boundary values, random values, etc.) to increase functional coverage. Status indication ports are ports used to indicate the internal state or behavior of the hardware design IP, which can help test the functional behavior under specific conditions and improve state coverage. The clock and reset ports can ensure the verification of the function of the hardware design IP under a variety of timing conditions by testing different clock frequencies and reset conditions. Debug ports are usually used to access the internal signals and states of the hardware design IP, which facilitates more detailed verification and troubleshooting, thereby increasing code coverage and functional coverage.

[0101] Feedback Mechanism: Reward or Penalty Reward Scheme, if the behavior is good and the agent gets positive feedback i.e. reward, the agent will prefer to perform that behavior, otherwise the agent will try to perform other behaviors that lead to reward.

[0102] In operation S330, the hardware design under test is driven successively based on the current stimulus data packet using the test platform.

[0103] Continuously means that the operation is performed again after each test clock cycle, that is, in the current clock cycle, the test platform drives the hardware design to be tested based on the current stimulus data packet, and continues to enter the next test cycle. In the next clock cycle, the test platform continues to drive the hardware design to be tested based on the new current stimulus data packet.

[0104] In operation S340, the simulator is used to continuously collect coverage data after the hardware design to be tested is driven, to obtain current coverage data, and the current coverage data is continuously fed back to the RL environment.

[0105] Continuously means that the operation is performed again after each clock cycle of the test, that is, in the current clock cycle, the simulator collects the coverage data after the hardware design to be tested is driven, and feeds back the current coverage data to the RL environment, and then continues to enter the next test cycle. In the next clock cycle, the simulator collects the coverage data after the hardware design to be tested is driven, and feeds back the new current coverage data to the RL environment.

[0106] The simulator is configured to collect coverage data after each test clock cycle. The coverage type of the specific coverage data, such as line coverage, finite state machine coverage, toggle coverage, and condition coverage, is determined by the settings in the configuration file. The RL environment reads and saves the coverage value after each test clock cycle.

[0107] In operation S350 , when the current coverage data meets the verification target condition, driving the hardware design to be verified is stopped to complete the functional verification target.

[0108] After obtaining the current coverage data in each clock cycle, determine whether the coverage data meets the verification target conditions. If it does, it means that the functional verification target is completed, and the test process needs to be stopped, and the test platform stops driving the hardware design to be tested. If it does not meet the requirements, it means that the functional verification target has not been completed, and the test process of operation S320-S340 needs to be repeated until the current coverage data meets the verification target conditions. Among them, the verification target conditions are that the coverage reaches 100% or a predetermined number of reinforcement learning operations are reached.

[0109] Figure 5 A verification framework diagram of a functional verification method for hardware design according to an embodiment of the present disclosure is schematically shown.

[0110] Figure 5In the above, Design IP indicates the hardware design to be tested, Parser indicates the parser, Specification indicates the parameter interface information of the standard specification, Metamodel indicates the metamodel, Template indicates the template, SystemVerilog Testbench indicates the test platform (SystemVerilog is the hardware description and verification language (HDVL)), Client indicates the client, Response indicates the response, Message indicates the message, Socket indicates the socket, Simulator indicates the simulator, Stimuli indicates the stimulus, Action indicates the behavior, RL Agent indicates the reinforcement learning agent, Reward indicates the feedback, Coverage indicates the coverage, and server (RL environment) indicates the reinforcement learning environment, i.e., the RL environment. Figure 5 As shown in the figure, a reinforcement learning-based verification framework is proposed. Under this framework, the hardware design to be tested is first parsed to extract all data information of the relevant main ports. The metamodel uses this data information to generate a SystemVerilog test platform, which interacts with the RL environment implemented in Python. Starting from the RL environment, the initial zero values ​​of all ports are sent to the test platform. Subsequently, the hardware design to be tested is simulated using the stimulus values ​​of the RL environment, and the coverage of the current time step is collected using the simulator, which is then passed back to the RL environment to calculate the feedback value. Based on the feedback value and the coverage value, the agent selects a new behavior, that is, a new stimulus, which will be used to drive the hardware design to be tested to the next step. This process is repeated until the coverage reaches 100% or the expected coverage target is achieved.

[0111] The present disclosure proposes a design-independent verification framework, which is not only applicable to specific designs, but also widely applicable to various types of design verification requirements. Traditional verification methods usually require a customized verification platform for each design, which increases development time and verification complexity. The design-independent framework of the present invention can be flexibly adjusted to adapt to different types of hardware designs (whether processor IP, controller module or complex system chip). This adaptability makes the verification process more universal and modular, so that the verification platform can be reused between different projects, greatly improving verification efficiency and saving development costs.

[0112] Figure 6 A flowchart of creating a test platform for a method for functional verification of hardware design according to an embodiment of the present disclosure is schematically shown.

[0113] like Figure 6As shown, according to an embodiment of the present disclosure, in operation S310, a test platform corresponding to the hardware design to be tested is built by using a metamodel, including operations S610-S620.

[0114] In operation S610, the hardware design to be tested is parsed to obtain parameter interface information of standard specifications.

[0115] The parser uses a preset code parsing method to parse the hardware design to be tested, and obtains parameter interface information of the standard specification corresponding to the hardware design to be tested, so that the meta-model can build a test platform according to the parameter interface information of the standard specification.

[0116] In operation S620 , a test platform is created using a metamodel based on parameter interface information of a standard specification and a predefined template.

[0117] The metamodel uses standard parameter interface information and a predefined template to build a test platform written in SystemVerilog language. The predefined template is a template library based on Python. Preferably, the mako template library can be used, which has simple syntax, high performance, flexible layout and convenient integration. As a comprehensive verification system, the test platform is implemented by the code created by the metamodel. The code defines the specific details of the test platform, including test cases, test environment configuration, signal generation and monitoring, etc.

[0118] Figure 7 The following schematically shows a parsing flow chart of a method for functional verification of hardware design according to an embodiment of the present disclosure.

[0119] like Figure 7 As shown, according to an embodiment of the present disclosure, in operation S610 of parsing the hardware design to be tested to obtain port parameter information of standard specifications, operations S710-S720 are included.

[0120] In operation S710, a preset code parsing method is used to parse the register transfer level code of the hardware design to be verified to extract port parameter information.

[0121] The register transfer level (RTL) code of the hardware design to be tested is parsed to extract the main port parameter information, which includes the name, type, size and direction of the port, etc., wherein the RTL code is usually written in VHDL, Verilog or SystemVerilog language.

[0122] In an embodiment of the present disclosure, the preset code parsing method includes one or more of a lexical analysis method and a grammatical analysis method.

[0123] Lexical Analysis: The lexical analyzer (lexer) scans the RTL code character by character and breaks the code into the smallest lexical units (tokens), such as keywords, operators, identifiers, constants, etc.

[0124] The parsing process of lexical analysis is:

[0125] (1) Identify keywords (such as input, output, wire, reg) and symbols in RTL.

[0126] (2) Identify the identifiers (port name, type, size) in the port declaration part as independent tags.

[0127] (3) Generate a token stream for subsequent grammatical analysis.

[0128] Syntax Analysis: Use context-free grammar (CFG) rules to parse the token stream and verify whether the code conforms to the syntax specifications of Verilog, VHDL, and SystemVerilog.

[0129] The parsing process of the syntax analysis method is:

[0130] (1) Structural processing of the token stream to identify the grammatical structure in the code, such as modules, port declarations, signal definitions, assignment operations, etc.

[0131] (2) Construct a syntax tree (or abstract syntax tree, AST) to express the structural hierarchy of the code.

[0132] (3) Extract key information from the syntax tree, such as port name, port type, data bit width and direction.

[0133] In operation S720, based on the port parameter information, a standardized format specification is created to obtain port parameter information of a standard specification.

[0134] For the port parameter information extracted from the hardware design to be tested, a standardized specification in the Extensible Markup Language (XML) format is created to obtain the parameter interface information of the standard specification corresponding to the hardware design to be tested.

[0135] Figure 8 The flowchart of generating stimulus of the functional verification method of hardware design according to the embodiment of the present disclosure is schematically shown.

[0136] like Figure 8As shown, according to an embodiment of the present disclosure, in operation S320, the agent in the RL environment performs behavior selection based on coverage data fed back by the simulator to generate the current stimulus data packet, including operations S810-S830.

[0137] In operation S810 , coverage data fed back by the simulator is read through the RL environment.

[0138] After each clock cycle of the simulation, the RL environment reads the coverage data fed back by the simulator so that the agent can generate the stimulus for the next clock cycle based on the coverage data.

[0139] In operation S820, based on the learning feedback strategy and the feedback update strategy, the next new behavior is selected by the agent, and the new behavior is used as the current new incentive.

[0140] The behavior selected by the agent serves as a new stimulus to drive the hardware design to be tested, and the behavior space is defined by the specified ports. The RL agent selects an action based on the specified learning feedback policy and feedback update policy. Reinforcement learning is a family of algorithms that finds strategies that can maximize the benefits in sequential decision making. Reinforcement learning policies represent the rules for the agent to decide which action to take.

[0141] In an embodiment of the present disclosure, the learning feedback strategy includes any one of the reinforcement learning algorithms of Q-learning, SARSA, DDPG, AC, A2C, PPO, DQN and TRPO.

[0142] Take the AC (Actor-Critic) algorithm as an example: Fig. 9 The AC algorithm diagram of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown. Fig. 9 In the example, two networks are defined as Actor and Critic. The input state S is: one output strategy, defined as Actor, responsible for selecting actions; one responsible for calculating the score of each action, defined as Critic. Perform N updates, and perform the following actions for each update:

[0143] (1) Starting from state St, perform action a, get reward R, and enter state St+1;

[0144] (2) recorded data;

[0145] (3) Input the data into the Critic network according to the formula:

[0146] TD-error = gamma * V(St+1) + R - V(St)

[0147] Calculate the error TD-error and reduce the TD-error;

[0148] (4) Input TD-error into the Actor network and calculate the strategy distribution.

[0149] The reinforcement learning algorithm is used to generate verification incentives, which is another major breakthrough of the verification framework disclosed in the present invention. The traditional verification method relies on constrained random verification, which requires engineers to constantly manually adjust the constraints to optimize the incentive generation. However, through the introduction of the RL algorithm, intelligent incentive generation can be achieved. By introducing the reinforcement learning algorithm, the generation of hardware random test cases is innovatively driven. The use of RL agents to generate verification incentives makes the generation process of the test platform more automated. Compared with traditional random incentive generation, RL agents can select efficient incentive sequences under the optimization strategy.

[0150] In an embodiment of the present disclosure, the feedback update strategy includes: if the feedback coverage data is greater than the previous coverage data in the RL environment, the feedback value is updated to 1; and if the feedback coverage data is not greater than the previous coverage data in the RL environment, the feedback value is updated according to a preset reward and punishment feedback scheme.

[0151] After each clock cycle of the simulation, the simulator exports coverage data and feeds it back to the RL environment, which reads the coverage data fed back by the simulator. The feedback update strategy is: if the coverage of the current step (the feedback coverage data) exceeds the coverage of the previous step, that is, the coverage has increased, the feedback is assigned a value of 1. If the coverage of the current step (the feedback coverage data) is lower than the coverage of the previous step, that is, the coverage has not increased, the feedback value is determined according to the preset reward and punishment feedback scheme.

[0152] For example, the calculation process of the reward and punishment feedback scheme based on rewards and punishments is:

[0153] if current_coverage > previous_coverage then reward←1

[0154] else if reward_scheme == penalty then reward←-1

[0155] else if reward_scheme == optimistic then reward←0

[0156] end if

[0157] The calculation process shows that when the coverage rate increases, the feedback is assigned a value of 1; when the coverage rate decreases, the feedback is assigned a value of -1; when the coverage rate remains unchanged, the feedback is assigned a value of 0.

[0158] In operation S830, the agent is used to package the current new stimulus and the corresponding port name to generate a current stimulus data packet.

[0159] The agent executes the selected stimulus by packaging the stimulus and port name into a message data packet (stimulus data packet) and sending the data packet to the client (SystemVerilog test platform) when receiving the stimulus request. Subsequently, the agent will receive the corresponding feedback. The feedback evaluates the effectiveness of the stimulus. The agent uses the feedback to update the strategy and select the next behavior based on the received feedback stimulus data. The selected behavior will continue to be executed in the next step. This process continues until the verification target conditions are met.

[0160] The agent can automatically generate effective verification incentives by intelligently exploring the designed state space. Unlike random incentive generation, the agent can adaptively adjust the incentive strategy based on the designed feedback and reward signals, and gradually optimize the generated incentive sequence. This means that the agent can specifically select incentives that can achieve the coverage target faster, rather than ineffectively wasting computing resources on redundant paths. In this way, the agent can achieve the same or even higher coverage with fewer incentives.

[0161] Fig.10 The flowchart of sending stimulus of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown.

[0162] like Fig.10 As shown, according to an embodiment of the present disclosure, in operation S320, the current stimulus data packets are successively sent to the test platform through the client socket, including operations S1010-S1020.

[0163] In operation S1010 , the test platform successively sends current stimulus requests to the RL environment through the client socket.

[0164] Continuously means that the operation is performed again after each test clock cycle, that is, in the current clock cycle, the test platform sends the current stimulus request to the RL environment, and after entering the next test cycle, in the next clock cycle, the test platform continues to send a new current stimulus request to the RL environment.

[0165] Based on the predefined template, the metamodel creates a SystemVerilog testbench that requests stimulus from the RL environment and uses the received stimulus data to drive the hardware design under test.

[0166] It should be noted that when the testbench drives the hardware design to be tested, the hardware design to be tested must be driven by the stimulus from the RL environment. Since the RL environment is implemented in Python and the testbench is implemented in SystemVerilog, it is not feasible for the metamodel to communicate directly with the SystemVerilog testbench. Therefore, the communication between the RL environment and the SystemVerilog testbench can be achieved by using a client-server application. The direct programming interface (DPI) can call functions written in C language in the SystemVerilog testbench. Therefore, the RL environment responsible for creating the client socket, managing the handshake, and sending the response from the server is implemented in C language.

[0167] In operation S1020 , the RL environment successively receives current stimulus requests through the client socket, and successively sends current stimulus data packets to the test platform.

[0168] Continuously means that the operation is performed again after each test clock cycle, that is, in the current clock cycle, the RL environment receives the current stimulus request through the client socket, and sends the current stimulus data packet to the test platform, and then continues to enter the next test cycle. In the next clock cycle, the RL environment continues to receive the new current stimulus request through the client socket, and sends the new current stimulus data packet to the test platform.

[0169] Fig.11 The initial stimulation flow chart of the functional verification method of the hardware design according to the embodiment of the present disclosure is schematically shown.

[0170] After the test platform is created, in the initial state, there is no feedback coverage data in the simulator, so the initial stimulus data packet is used as the current stimulus data packet, and the initial stimulus data packet is sent to the test platform through the client socket. The test platform drives the hardware design to be tested for the first time, wherein the initial stimulus data packet is generated by the random selection behavior of the intelligent agent in the RL environment. The generation process of the initial stimulus data packet is as follows: Fig.11 As shown, operations S1110-S1120 are included.

[0171] In operation S1110 , port parameter information is read through the RL environment, and a behavior space is determined based on the port parameter information.

[0172] The RL environment reads the sizes of these ports from the output of the parser and configures the action space so that it contains all possible combinations of values ​​the ports can assume.

[0173] For example, for an arithmetic logic unit (ALU) with 3-bit opcodes, the behavior space ranges from 0 to 23 −1, row 6 will drive the opcode port of the ALU with its binary value 110.

[0174] In operation S1120, an initial behavior is randomly selected in the behavior space using an intelligent agent, the initial behavior is used as an initial stimulus, and the initial stimulus and the corresponding port name are packaged to generate an initial stimulus data packet.

[0175] After the test platform is created, in the initial state, the initial behavior is random, and the initial behavior has its behavior space, which is defined by the port. The initial behavior is randomly selected in the behavior space. After receiving the stimulus request from the test platform, the agent generates an initial stimulus data packet, takes the initial stimulus data packet as the current stimulus data packet, and enters the test cycle of operations S320-S350 until the functional verification goal of the hardware design to be tested is completed.

[0176] Based on the above hardware design function verification method, the present disclosure also provides a hardware design function verification device. Fig.12 The device is described in detail.

[0177] Fig.12 The structural block diagram of the functional verification device of the hardware design according to the embodiment of the present disclosure is schematically shown.

[0178] like Fig.12 As shown, the functional verification device 1200 of the hardware design of this embodiment includes a creation module 1210 , a stimulus module 1220 , a drive module 1230 , a feedback module 1240 and a target module 1250 .

[0179] The creation module 1210 is used to build a test platform corresponding to the hardware design to be tested by using the metamodel. In one embodiment, the creation module 1210 can be used to perform the operation S310 described above, which will not be repeated here.

[0180] The incentive module 1220 is used to send the current incentive data packet to the test platform through the client socket; wherein the current incentive data packet is generated by the agent in the RL environment performing behavior selection based on the coverage data fed back by the simulator. In one embodiment, the incentive module 1220 can be used to perform the operation S320 described above, which will not be repeated here.

[0181] The driving module 1230 is used to use the test platform to continuously drive the hardware design to be tested based on the current stimulus data packet. In one embodiment, the driving module 1230 can be used to perform the operation S330 described above, which will not be described in detail here.

[0182] The feedback module 1240 is used to collect the coverage data of the hardware design to be tested after driving by the simulator, obtain the current coverage data, and continuously feed back the current coverage data to the RL environment. In one embodiment, the feedback module 1240 can be used to perform the operation S340 described above, which will not be repeated here.

[0183] The target module 1250 is used to stop driving the hardware design to be tested and complete the functional verification target when the current coverage data meets the verification target condition. In one embodiment, the target module 1250 can be used to perform the operation S350 described above, which will not be repeated here.

[0184] According to an embodiment of the present disclosure, the incentive module 1220 includes: a reading unit for reading the coverage data fed back by the simulator through the RL environment; an intelligent selection unit for selecting the next new behavior through the agent based on the learning feedback strategy and the feedback update strategy, and using the new behavior as the current new incentive; and a packaging unit for using the agent to package the current new incentive and the corresponding port name to generate a current incentive data packet.

[0185] According to an embodiment of the present disclosure, the feedback update strategy includes: if the feedback coverage data is greater than the previous coverage data in the RL environment, the feedback value is updated to 1; and if the feedback coverage data is not greater than the previous coverage data in the RL environment, the feedback value is updated according to a preset reward and punishment feedback scheme.

[0186] According to an embodiment of the present disclosure, the learning feedback strategy includes any one of the reinforcement learning algorithms of Q-learning, SARSA, DDPG, AC, A2C, PPO, DQN and TRPO.

[0187] According to an embodiment of the present disclosure, the stimulus module 1220 includes: a request unit, which is used for the test platform to continuously send the current stimulus request to the RL environment through the client socket; and a sending unit, which is used for the RL environment to continuously receive the current stimulus request through the client socket and continuously send the current stimulus data packet to the test platform.

[0188] According to an embodiment of the present disclosure, the creation module 1210 includes: a parsing unit for parsing the hardware design to be tested to obtain parameter interface information of standard specifications; and a creation unit for creating a test platform based on the parameter interface information of standard specifications and predefined templates using a metamodel.

[0189] According to an embodiment of the present disclosure, a parsing unit includes: an information extraction unit, used to parse the register transfer level code of the hardware design to be tested using a preset code parsing method to extract port parameter information; and a format specification unit, used to create a standardized format specification based on the port parameter information to obtain the port parameter information in a standard format.

[0190] According to an embodiment of the present disclosure, the device further includes: an initial module 1260, which is used to read the port parameter information through the RL environment, determine the behavior space based on the port parameter information; and use the agent to randomly select an initial behavior in the behavior space, use the initial behavior as an initial stimulus, and package the initial stimulus and the corresponding port name to generate an initial stimulus data packet. In one embodiment, the initial module 1260 can be used to perform the operations S1110-S1120 described above, which will not be repeated here.

[0191] According to an embodiment of the present disclosure, the types of coverage data include: one or more of line coverage, condition coverage, state machine coverage, flip coverage, path coverage, branch coverage and assertion coverage.

[0192] According to an embodiment of the present disclosure, any multiple modules of the creation module 1210, the excitation module 1220, the drive module 1230, the feedback module 1240, the target module 1250 and the initial module 1260 can be combined into one module for implementation, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules can be combined with at least part of the functions of other modules and implemented in one module. According to an embodiment of the present disclosure, at least one of the creation module 1210, the excitation module 1220, the drive module 1230, the feedback module 1240, the target module 1250 and the initial module 1260 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application specific integrated circuit (ASIC), or can be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or implemented in any one of the three implementation methods of software, hardware and firmware or in a suitable combination of any of them. Alternatively, at least one of the creation module 1210, the stimulation module 1220, the drive module 1230, the feedback module 1240, the target module 1250 and the initial module 1260 may be at least partially implemented as a computer program module, which may perform a corresponding function when executed.

[0193] Fig.13 A block diagram of an electronic device suitable for implementing a function verification method of hardware design according to an embodiment of the present disclosure is schematically shown.

[0194] like Fig.13 As shown, the electronic device 1300 according to an embodiment of the present disclosure includes a processor 1301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1302 or a program loaded from a storage part 1308 to a random access memory (RAM) 1303. The processor 1301 may include, for example, a general-purpose microprocessor (such as a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (for example, an application-specific integrated circuit (ASIC)), etc. The processor 1301 may also include an onboard memory for caching purposes. The processor 1301 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0195] In RAM 1303, various programs and data required for the operation of electronic device 1300 are stored. Processor 1301, ROM 1302 and RAM 1303 are connected to each other via bus 1304. Processor 1301 performs various operations of the method flow according to the embodiment of the present disclosure by executing the program in ROM 1302 and / or RAM 1303. It should be noted that the program can also be stored in one or more memories other than ROM 1302 and RAM 1303. Processor 1301 can also perform various operations of the method flow according to the embodiment of the present disclosure by executing the program stored in one or more memories.

[0196] According to an embodiment of the present disclosure, the electronic device 1300 may further include an input / output (I / O) interface 1305, which is also connected to the bus 1304. The electronic device 1300 may further include one or more of the following components connected to the I / O interface 1305: an input portion 1306 including a keyboard, a mouse, etc.; an output portion 1307 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage portion 1308 including a hard disk, etc.; and a communication portion 1309 including a network interface card such as a LAN card, a modem, etc. The communication portion 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to the I / O interface 1305 as needed. A removable medium 1311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1310 as needed, so that a computer program read therefrom is installed into the storage portion 1308 as needed.

[0197] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present disclosure is implemented.

[0198] According to an embodiment of the present disclosure, a computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, may include but is not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, an apparatus, or a device. For example, according to an embodiment of the present disclosure, a computer-readable storage medium may include the ROM 1302 and / or RAM 1303 described above and / or one or more memories other than ROM 1302 and RAM 1303.

[0199] The embodiment of the present disclosure also includes a computer program product, which includes a computer program, and the computer program contains program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the functional verification method of the hardware design provided by the embodiment of the present disclosure.

[0200] The above functions defined in the system / device of the embodiment of the present disclosure are performed when the computer program is executed by the processor 1301. According to the embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0201] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices, magnetic storage devices, etc. In another embodiment, the computer program may also be transmitted and distributed in the form of signals on a network medium, and downloaded and installed through the communication part 1309, and / or installed from the removable medium 1311. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0202] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1309, and / or installed from the removable medium 1311. When the computer program is executed by the processor 1301, the above functions defined in the system of the embodiment of the present disclosure are performed. According to the embodiment of the present disclosure, the system, device, apparatus, module, unit, etc. described above can be implemented by a computer program module.

[0203] According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level process and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, Java, C++, python, "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on the remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect through the Internet).

[0204] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0205] It will be appreciated by those skilled in the art that the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations and / or combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways without departing from the spirit and teachings of the present disclosure. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0206] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A functional verification method for hardware design, characterized in that: The method comprises: Use the metamodel to build a test platform corresponding to the hardware design to be tested; Sending the current stimulus data packet to the test platform in succession through the client socket; wherein the current stimulus data packet is generated by the behavior selection of the agent in the RL environment based on the coverage data fed back by the simulator; Using the test platform, based on the current stimulus data packet, successively driving the hardware design to be tested; Using the simulator to continuously collect coverage data after the hardware design to be tested is driven, obtain current coverage data, and continuously feed back the current coverage data to the RL environment; and When the current coverage data meets the verification target condition, the driving of the hardware design to be verified is stopped to complete the functional verification target.

2. The method according to claim 1, characterized in that The current stimulus data packet is generated by an agent in the RL environment performing behavior selection based on coverage data fed back by the simulator, including: Reading coverage data fed back by the simulator through the RL environment; Based on the learning feedback strategy and the feedback update strategy, the next new behavior selected by the agent is used as the current new incentive; and The agent is used to package the current new stimulus and the corresponding port name to generate the current stimulus data packet.

3. The method according to claim 2, characterized in that The feedback update strategy includes: If the coverage data of the feedback is greater than the previous coverage data in the RL environment, the feedback value is updated to 1; and If the coverage data of the feedback is not greater than the previous coverage data in the RL environment, the feedback value is updated according to a preset reward and punishment feedback scheme.

4. The method according to claim 2, characterized in that: The learning feedback strategy includes: any one of the reinforcement learning algorithms among Q-learning, SARSA, DDPG, AC, A2C, PPO, DQN and TRPO.

5. The method according to claim 1, characterized in that The step of continuously sending the current stimulus data packets to the test platform through the client socket comprises: The test platform continuously sends current stimulus requests to the RL environment through the client socket; and Through the client socket, the RL environment continuously receives the current stimulus request and continuously sends the current stimulus data packet to the test platform.

6. The method according to claim 1, characterized in that The use of the metamodel to build a test platform corresponding to the hardware design to be tested includes: Analyzing the hardware design to be tested to obtain parameter interface information of standard specifications; and The test platform is created based on the parameter interface information of the standard specification and the predefined template using the meta model.

7. The method according to claim 6, characterized in that The step of analyzing the hardware design to be tested to obtain parameter interface information of standard specifications includes: Parsing the register transfer level code of the hardware design to be tested by using a preset code parsing method to extract port parameter information; and Based on the port parameter information, a standardized format specification is created to obtain parameter interface information of the standard specification.

8. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: Reading the port parameter information through the RL environment, and determining a behavior space based on the port parameter information; and The agent is used to randomly select an initial behavior in the behavior space, the initial behavior is used as an initial stimulus, and the initial stimulus and the corresponding port name are packaged to generate an initial stimulus data packet.

9. The method according to any one of claims 1 to 7, characterized in that: The types of the coverage data include: one or more of line coverage, condition coverage, state machine coverage, flip coverage, path coverage, branch coverage and assertion coverage.

10. The method according to any one of claims 1 to 7, characterized in that: The hardware design to be tested includes: any one of DUT, processor IP, controller module, system-level chip and IP core.

11. A functional verification device for hardware design, characterized in that: The device comprises: Create a module to build a test platform corresponding to the hardware design to be tested using the metamodel; A stimulus module, used to send the current stimulus data packet to the test platform through the client socket; wherein the current stimulus data packet is generated by the intelligent agent in the RL environment performing behavior selection based on the coverage data fed back by the simulator; A driving module, used to use the test platform to continuously drive the hardware design to be tested based on the current stimulus data packet; A feedback module, used to continuously collect coverage data of the hardware design to be tested after being driven by the simulator to obtain current coverage data, and continuously feed back the current coverage data to the RL environment; and The target module is used to stop driving the hardware design to be tested and complete the functional verification target when the current coverage data meets the verification target condition.

12. An electronic device comprising: one or more processors; a memory for storing one or more computer programs, It is characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

14. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images