Verification environment construction method, verification method and verification system

Abstract

The invention relates to the field of chip verification, and discloses a construction method of a verification environment, a verification method and a system.The construction method of the verification environment comprises the steps that the connection relation between a to-be-verified component and bus function models is established, and communication connection is established between the matched bus function models and proxy models; initializing each agent model in the software end environment, and completing the initialization process of each agent model after receiving a reset release signal transmitted by the to-be-verified component in the hardware end environment; calling a preset configuration function in the hardware end environment to construct a configuration transaction in the software end environment through the preset configuration function; and driving the configuration transaction through the bus function model in the hardware end environment, and finishing a transaction configuration process of the to-be-verified component in the hardware end environment based on a driving result. According to the technical scheme provided by the invention, the verification process of the to-be-verified component can be accelerated, and the verification efficiency of the to-be-verified component is improved.

Description

Technical Field

[0001] The present application relates to the field of chip verification, and in particular to a verification environment construction method, a verification method, and a system. Background Art

[0002] As the complexity of integrated chip design continues to increase, the workload of chip verification is becoming more and more complex and diverse, requiring a large number of stimulus signals to test the components to be verified. Currently, most of the verification methods used are UVM (Universal Verification Methodology) or EMU (Emulator) to perform functional verification on the components to be verified.

[0003] In practical applications, when the verification scale of a component under verification is large, the UVM environment runs entirely on a software simulator. This time-consuming software simulation makes it difficult to perform long-term tests, resulting in low verification efficiency. While hardware simulation in the EMU environment is faster, it relies on real IP for simulation testing, which consumes a lot of hardware resources and slows the verification process even when the verification scale is large. Therefore, improving the verification efficiency of components under verification has become a current research focus in the chip verification field. Summary of the Invention

[0004] The present application provides a verification environment construction method, a verification method and a system, which can improve the verification efficiency of components to be verified.

[0005] The first aspect of the present application provides a method for constructing a verification environment, wherein the verification environment includes a hardware environment and a software environment, wherein the hardware environment includes a component to be verified and a bus function model, and the software environment includes a proxy model matching the bus function model. The method includes: establishing a connection relationship between the component to be verified and each of the bus function models, and establishing a communication connection between the matching bus function model and the proxy model; initializing each of the proxy models in the software environment, and completing the initialization process of each of the proxy models after receiving a reset release signal from the component to be verified in the hardware environment, wherein the reset release signal is issued when the hardware environment is initialized; calling a preset configuration function in the hardware environment to construct a configuration transaction in the software environment through the preset configuration function; driving the configuration transaction through the bus function model in the hardware environment, and completing the transaction configuration process of the component to be verified in the hardware environment based on the driving result.

[0006] The technical solution provided by this embodiment of the present application accelerates the verification process of the component to be verified through asynchronous collaborative interaction between the hardware end and the software end, thereby improving the verification efficiency of the component to be verified. Specifically, a bus function model is set on the hardware end and a matching proxy model is set on the software end. The two work together through a communication connection, and the hardware end and the software end efficiently configure and drive configuration transactions to ensure that the component to be verified can quickly complete the configuration, accelerate the preparation process of the verification, and thus improve the verification efficiency of the component to be verified. At the same time, the component to be verified in the hardware environment is run on a hardware emulator to accelerate the verification speed by replacing the real IP with a proxy model, and reasonably allocate logical tasks between the hardware end and the software end, saving resource consumption and logic occupancy on the hardware end, and further improving the verification efficiency of the component to be verified. It can be seen that the technical solution provided by this embodiment of the present application, through collaborative verification by the software end and the hardware end, the component to be verified is run in the hardware environment, and the verification speed is improved by thousands of times compared with traditional software simulation, which greatly shortens the verification cycle, and saves resource consumption and logic occupancy on the hardware end compared to traditional hardware simulation, thereby improving the verification efficiency of the component to be verified.

[0007] In a possible implementation, the software-side environment further includes a sampling module and a verification module; the method further includes: sampling transactions transmitted between the bus function model and the proxy model through the sampling module; establishing a communication connection between the sampling module and the verification module so as to pass the sampled transactions to the verification module for verification through the sampling module; initializing the sampling module and the verification module when initializing each of the proxy models in the software-side environment, and completing the initialization process of the sampling module and the verification module after receiving the reset release signal from the component to be verified in the hardware-side environment.

[0008] The technical solution provided by this embodiment of the present application proposes configuring a sampling module and a verification module in the software-side environment. The sampling module and the verification module are used to sample and verify the transaction transmissions between the proxy model and the bus function model, respectively, to ensure timely detection of errors or abnormalities that may occur during the transaction transmission process. At the same time, the sampling module and the verification module are initialized synchronously with the initialization of the proxy model to ensure that all components of the entire verification environment can be correctly started, thereby improving the accuracy and reliability of the verification, ensuring the normal progress of the verification work, and further improving the verification efficiency of the components to be verified.

[0009] In a possible implementation, the bus function model and the proxy model correspond to different protocol types. Accordingly, the sampling module includes at least a first sampling module corresponding to a first protocol type and a second sampling module corresponding to a second protocol type. Sampling transactions transmitted between the bus function model and the proxy model through the sampling module includes: sampling transactions of the first protocol type through the first sampling module, and sampling transactions of the second protocol type through the second sampling module.

[0010] The technical solution provided in this embodiment of the present application refines the composition and corresponding functions of the sampling modules, specifically sampling transactions of different protocol types. By using different sampling modules to simultaneously sample transactions of different protocol types, the sampling process is parallelized, shortening the verification cycle of the component to be verified, thereby improving the verification efficiency of the component to be verified.

[0011] In one possible implementation, the proxy model is instantiated as a transaction initiator and a transaction receiver; establishing a communication connection between a matching bus function model and a proxy model includes: for any bus function model, determining a transaction initiator and a transaction receiver that match the bus function model; establishing a communication connection between the bus function model and the matching transaction initiator, and establishing a communication connection between the bus function model and the matching transaction receiver; wherein the bus function model receives a transaction issued by the transaction initiator, processes the received transaction, and then transfers the processed transaction to the transaction receiver; and receives a response generated by the transaction receiver for the processed transaction, and feeds the response back to the transaction initiator.

[0012] The technical solution provided by this embodiment of the present application instantiates the proxy model as a transaction initiator and receiver, and clearly defines the communication connection between it and the bus function model. Multiple transaction initiators can simultaneously generate different types of transactions, and the matching bus function model can process these transactions in parallel and pass them to the corresponding transaction receivers, thereby meeting the verification requirements of different stages and levels, improving the parallelism and flexibility of verification, and thus improving the verification efficiency of the components to be verified.

[0013] In a possible implementation, the method further includes: when the software-side environment also includes a sampling module and a verification module, sampling transactions transmitted between the bus function model and the transaction initiator, and sampling transactions transmitted between the bus function model and the transaction receiver through the sampling module; passing the sampled transactions to the verification module through the sampling module, so that the received transactions are subjected to cache consistency verification and memory consistency verification through the verification module.

[0014] The technical solution provided by this embodiment of the present application refines the sampling and verification of transactions transmitted between the bus function model and the transaction initiator and transaction receiver. The sampling module samples transactions between the bus function model and the transaction initiator, and between the bus function model and the transaction receiver, respectively, to achieve detection of the entire transaction transmission process. At the same time, the verification module performs cache consistency checks and memory consistency checks on the sampled transactions, thereby improving the comprehensiveness and reliability of verification.

[0015] The second aspect of the present application also provides a verification method, which is applied to a verification environment constructed according to the method described in the first aspect above, and the method includes: calling a preset test function in the hardware-side environment that completes the transaction configuration process, so as to start the corresponding stimulus signal in one or more proxy models in the software-side environment through the preset test function, and generate a stimulus transaction based on the started stimulus signal; through the bus function model in the hardware-side environment, drive the stimulus transaction generated by the matching proxy model to the component to be verified in the hardware environment, so as to perform concurrent verification on the component to be verified.

[0016] The technical solution provided by this embodiment of the present application is that the hardware and software environments perform concurrent verification of the components to be verified through the stimulus signals corresponding to the preset test functions. By calling the preset test functions by the hardware environment, the disadvantage of the slow simulation speed of traditional software is overcome, and the stimulus signals can be quickly started and stimulus transactions can be generated, thereby significantly shortening the verification cycle. In addition, by simultaneously starting the stimulus signals through multiple proxy models to generate multiple stimulus tasks, the stimulus tasks are concurrently driven to the components to be verified, further improving the verification efficiency of the components to be verified.

[0017] In a possible implementation, the preset test function corresponds to test cases of different protocol types. Accordingly, the proxy models of different protocol types concurrently generate stimulus signals for multiple test cases to concurrently verify the components to be verified.

[0018] The technical solution provided in this embodiment of the present application maps pre-set test functions to test cases for different protocol types, ensuring that the verification process covers multiple protocol scenarios. Proxy models for different protocol types concurrently generate stimulus signals, comprehensively covering the concurrent verification of the function and performance of the component under verification under various protocols, thereby improving the comprehensiveness and efficiency of verification of the component under verification.

[0019] In a possible implementation, the verification method further includes: when the software-side environment includes a sampling module and a verification module, if the verification module determines that the transaction between the bus function model and the proxy model does not meet the consistency condition, the verification module initiates an indication information indicating that verification is stopped, and after verification is stopped, the verification module generates transaction offline data, and the transaction offline data is used to analyze consistency.

[0020] The technical solution provided by this embodiment of the present application provides a method for handling errors in verification transactions. When a transaction fails to meet consistency conditions, it can promptly initiate an instruction to stop verification through the verification module, promptly preventing further propagation and accumulation of errors. At the same time, it generates offline transaction data containing detailed information about the transaction during transmission, which can quickly locate the time when the problem occurred, allowing for rapid error troubleshooting and improving the overall verification efficiency of the chip to be verified.

[0021] In a possible implementation, the bus function model and the proxy model communicate with each other through a general first-in-first-out mechanism, and the stimulus transaction generated by the proxy model is driven to the component to be verified in a non-blocking manner.

[0022] The technical solution provided in this embodiment of the present application establishes a first-in, first-out mechanism and a non-blocking communication method. The first-in, first-out mechanism ensures effective and efficient data transmission between the bus function model and the proxy model, reducing waiting time and resource conflicts during data transmission. The non-blocking drive method also enables the component to be verified to receive stimuli and begin responding more quickly, shortening response delays during the verification process and further improving the verification efficiency of the component to be verified.

[0023] According to a third aspect of the present application, a system for constructing a verification environment is provided, wherein the verification environment includes a hardware environment and a software environment, wherein the hardware environment includes a component to be verified and a bus function model, and the software environment includes a proxy model matching the bus function model. The system includes: a connection establishment unit, configured to establish a connection relationship between the component to be verified and each of the bus function models, and to establish a communication connection between the matching bus function model and the proxy model; an initialization unit, configured to initialize each of the proxy models in the software environment, and complete the initialization process of each of the proxy models after receiving a reset release signal from the component to be verified in the hardware environment, wherein the reset release signal is issued when the hardware environment is initialized; a transaction construction unit, configured to call a preset configuration function in the hardware environment to construct a configuration transaction in the software environment through the preset configuration function; and a transaction configuration unit, configured to drive the configuration transaction through the bus function model in the hardware environment, and complete the transaction configuration process of the component to be verified in the hardware environment based on the driving result.

[0024] The fourth aspect of the present application provides a verification system, which includes a verification environment generated according to the method described in the first aspect above, and the verification system includes: a stimulus generation unit, which is used to call a preset test function in the hardware end environment that completes the transaction configuration process, so as to start the corresponding stimulus signal in one or more proxy models in the software end environment through the preset test function, and generate a stimulus transaction based on the started stimulus signal; a transaction driving unit, which is used to drive the stimulus transaction generated by the matching proxy model to the component to be verified in the hardware end environment through the bus function model in the hardware end environment, so as to perform concurrent verification on the component to be verified. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the specific implementation methods or the description of the prior art. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0026] Figure 1 A schematic diagram of the steps of a method for constructing a verification environment provided in one embodiment of the present application;

[0027] Figure 2 A schematic diagram of a verification environment provided for one embodiment of the present application;

[0028] Figure 3 A schematic diagram of a process for configuring transactions in a verification environment provided by one embodiment of the present application;

[0029] Figure 4 A transaction transmission diagram of an instantiated proxy model provided in one embodiment of the present application;

[0030] Figure 5 A schematic diagram of the steps of a verification method provided in one embodiment of the present application;

[0031] Figure 6 A schematic diagram of a process for performing incentive transaction verification on a verification environment provided by one embodiment of the present application;

[0032] Figure 7 A schematic diagram of a verification process for a component to be verified provided in one embodiment of the present application;

[0033] Figure 8 A schematic diagram of a system for constructing a verification environment provided in one embodiment of the present application;

[0034] Figure 9 A schematic structural diagram of a computer device provided in accordance with one embodiment of the present application. DETAILED DESCRIPTION

[0035] To make the purpose, technical solutions, and advantages of the embodiments of the present application more clear, the technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of this application.

[0036] In addition, the descriptions of "first", "second", etc. in this application are for descriptive purposes only and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. Thus, the features defined as "first" and "second" may explicitly or implicitly include at least one of such features. In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more. In addition, the use of "based on" or "according to" means openness and inclusiveness, because the process, steps, calculations or other actions "based on" or "according to" one or more of the conditions or values ​​can be based on additional conditions or values ​​beyond the described values ​​in practice.

[0037] With the rapid development of integrated circuits, the speed of product iteration is accelerated, which makes the development cycle of R&D personnel continuously compressed. In modern chip design, chip verification, as an important part of chip design, usually takes more than half of the project cycle. However, as the complexity demand of integrated chips continues to increase, the verification work of the components to be verified in the integrated chip is also more and more complicated and diverse. The above-mentioned components to be verified are specific components that need to be verified during the chip design process. For example, the above-mentioned components to be verified can be a network on chip, a CPU (Central Processing Unit, central processing unit), a GPU (Graphics Processing Unit, graphics processing unit) or an FPGA (Field Programmable Gate Array, field programmable gate array). In general, the network on chip, as the communication hub in the integrated chip, needs to involve the transmission of multi-party parallel transactions. Therefore, the verification scale when verifying the network on chip is large, and a large amount of random excitation is required to carry out long-term testing to ensure the stability and reliability of the network on chip.

[0038] At present, the UVM verification method is usually adopted to perform functional verification on the component to be verified. First, a UVM verification framework is built to form a verification environment for the component to be verified. The above-mentioned UVM verification framework includes a verification platform, a virtual interface and an instantiated component to be verified. The above-mentioned verification platform includes multiple proxy models for testing various functional points of the component to be verified. Corresponding environment components are developed in the verification platform, such as a component that generates incentives, an incentive conversion component and a signal acquisition component to generate and convert incentives. The above-mentioned verification platform runs in a simulation server to perform software simulation. Instantiating the component to be verified refers to creating an instance of the component to be verified in the verification environment so that it can be driven and verified by the test incentives of the verification platform. The above-mentioned verification platform interacts with the component to be verified through the virtual interface. It should be noted that the above-mentioned simulation server is a high-performance computing device used to run complex simulation software and handle a large number of computing tasks. The above-mentioned simulation server is usually equipped with a CPU, memory and storage system.

[0039] Furthermore, the simulation and stimulus are started to complete the related transaction construction and stimulus test, so that the components to be verified can be subjected to functional and performance tests in different scenarios. The above method can cover most of the design behaviors and scenarios of the components to be verified, but for the simulation of the components to be verified in large-scale design verification and complex scenarios, since the UVM verification method is fully system-operated on the simulation server, the CPU of the simulation server simulates the hardware behavior cycle by cycle, resulting in a slower running speed. The software simulation needs to process a large number of signal changes, which requires a large amount of simulation time to be consumed, making the verification efficiency of the components to be verified lower. Moreover, due to the memory of the simulation server, if the design scale of the components to be verified is large, such as the verification environment of a very large-scale network on chip, it may be impossible to load a complete model and perform comprehensive verification work.

[0040] In related technologies, full-system verification can also be performed using the EMU verification method. The EMU verification environment relies on real IP to run software programs. Although the verification speed of the components to be verified is improved compared to the UVM verification method, the EMU verification environment cannot accurately trigger specific boundary scenarios and it is difficult to generate directional stimuli, resulting in a lack of directional testing in EMU verification, and the verification of the components to be verified cannot be performed more accurately and comprehensively. In addition, the use of real IP consumes a large amount of hardware resources and logic, which reduces the verification efficiency of the components to be verified. It should be noted that the above-mentioned real IP refers to a pre-designed, fully functional hardware module on the integrated chip, which serves as the component to be verified in the verification process, such as a CPU core or a DDR (Double Data Rate) controller.

[0041] In light of this, one or more embodiments of the present application provide a verification environment construction method, verification method, and system that can address the aforementioned issues. This method establishes a communication connection between the hardware and software environments, uses a proxy model instead of the actual IP address to perform transaction configuration for the component to be verified, accelerates the verification process for the component to be verified, and improves verification efficiency for the component to be verified. Furthermore, while ensuring verification efficiency for the component to be verified, it also ensures completeness and accuracy of verification for the component to be verified.

[0042] First, see Figure 1 and Figure 2 One embodiment of the present application provides a method for constructing a verification environment. The verification environment includes a hardware environment and a software environment. The hardware environment includes a component to be verified and a bus function model, and the software environment includes a proxy model that matches the bus function model. Figure 2 The figure shows an example of the verification environment. The hardware environment includes multiple bus function models and components to be verified. The software environment includes a number of proxy models corresponding to the number of bus function models. For example, Figure 2 The three bus function models and the three agent models are one-to-one correspondence. Specifically, the method can include Figure 1 The following steps are shown:

[0043] S11: Establish the connection relationship of the to-be-verified component and each bus function model, and establish a communication connection between the matching bus function model and the agent model.

[0044] The agent model can be understood as a transaction-level model. The agent model can interact with the user end in the software end environment, and is used to generate and control test stimuli in the software end environment. The test stimuli can be understood as a transaction-level instruction. The bus function model can be understood as a synthesizable hardware module. The bus function model can interact with the to-be-verified component in the hardware end environment, and is used to convert the test stimuli into driving signals that can be received by the to-be-verified component, so as to simulate a real bus communication scene. The communication relationship between the agent model in the software end environment and the bus function model in the hardware end environment is established, so as to transmit the test stimuli to the bus function model through the agent model. The hardware end environment is a verification environment running on a hardware simulator, and the software end environment is a verification environment running on a general server. Since the hardware end environment can run simulation at a relatively high speed, usually at a MHz frequency, it has a significant speed improvement compared to traditional software simulation.

[0045] In the embodiment, the to-be-verified component is connected to each bus function model through a hardware interface of the to-be-verified component. The interface protocols of each interface of the to-be-verified component are different, and the bus function model can establish a connection with the to-be-verified component according to the interface protocol type. The interface protocol defines the signal-level communication specification between chip hardware modules, and the bus function model is connected to each hardware interface of the to-be-verified component through a hardware pin. The interface protocol type can be divided into APB (Advanced Peripheral Bus, Advanced Peripheral Bus) protocol, AXI (Advanced eXtensible Interface, Advanced High-Performance Bus) protocol, and CHI (Coherent Hub Interface, Coherent Bus Interface) protocol, for example. The bus function model can include an APB bus function model, an AXI bus function model, and a CHI bus function model, which are connected to the hardware interfaces of the to-be-verified component with corresponding protocol types to realize signal interaction between the bus function model and the to-be-verified component. Moreover, since the bus function model is one-to-one matched with the agent model, a separate communication channel is established between the bus function model and the agent model matched therewith, so as to realize transmission between the software end environment and the hardware end environment.

[0046] In this embodiment, by establishing a communication connection between the component to be verified and the bus function model, and between the bus function model and the proxy model, collaborative work from the hardware end to the software end can be achieved. By establishing a communication connection between the matching bus function model and the proxy model, the real bus communication scenario can be simulated more accurately, thereby improving the accuracy of verification. The component to be verified and the bus function model in the hardware end environment are run on a hardware emulator, which can be simulated at a higher speed, while the software end environment runs on a simulation server, which can flexibly generate and control test stimuli. Compared with traditional software simulation, this software and hardware collaboration method can significantly improve the speed and efficiency of verification. At the same time, compared with traditional hardware simulation, it reduces the dependence on hardware resources to a certain extent, reduces the occupation of hardware resources, and improves the utilization rate of hardware resources.

[0047] S13: Initialize each of the proxy models in the software-side environment, and complete the initialization process of each of the proxy models after receiving a reset release signal from the component to be verified in the hardware-side environment, wherein the reset release signal is sent when the hardware-side environment completes initialization.

[0048] In this embodiment, before starting the simulation, the proxy model in the software-side environment needs to be initialized and configured. Specifically, in the software-side environment, the CPU of the simulation server allocates resources to each proxy model and sets the initial state, including memory allocation, variable initialization, etc., and creates a proxy object for each proxy model, and registers a callback function to respond to hardware events. At the same time, hardware initialization is also performed in the hardware-side environment, such as clock control and hardware reset. Furthermore, after the hardware initialization is completed in the hardware-side environment, the component to be verified transmits a reset release signal to the matching proxy model through the bus function model, indicating that the hardware-side environment is ready to receive the verification stimulus from the software-side environment, thereby avoiding the software side sending the stimulus when the hardware is not ready, thereby causing the state of the component to be verified to be disordered. After the proxy model receives the above-mentioned reset release signal, a configuration test is performed to complete the initialization process of the proxy model.

[0049] In this embodiment, by triggering the completion of software initialization based on a signal after hardware initialization completes, verification activities on the hardware and software sides are synchronized, making the verification process more orderly, avoiding verification errors or anomalies caused by unprepared hardware, and improving the reliability and stability of the verification process. Furthermore, the proxy model does not need to frequently query the status of the hardware side; it only needs to wait for the reset release signal to initiate subsequent operations. Compared to manual intervention to ensure synchronization between the hardware and software sides, this approach simplifies the verification process and reduces the complexity of setting up and running the verification environment, thereby improving the verification efficiency of the components to be verified.

[0050] S15: Calling a preset configuration function in the hardware-side environment to construct a configuration transaction in the software-side environment through the preset configuration function.

[0051] The preset configuration function is a predefined configuration generation function on the software side, which is used to build and call the relevant configuration transaction based on the call parameters on the hardware side. The configuration transaction is a series of operations or data transfers generated during the verification process to configure the component to be verified, such as writing to the register of the component to be verified and setting parameters.

[0052] In this embodiment, by constructing configuration transactions on the software side, users can more flexibly define and modify configuration parameters, so that they can quickly adapt to different verification requirements and realize verification of various configuration scenarios of the components to be verified. Optionally, configuration transactions can also be pre-constructed in the software side environment, and when the configuration generation function is parsed on the software side, the corresponding configuration transactions can be quickly matched, thereby improving the verification efficiency of the components to be verified. At the same time, traditional hardware simulation methods may require the instantiation of a large number of configuration logics and components on the hardware side, resulting in the occupation of a large amount of hardware resources. By constructing configuration transactions on the software side, the resource occupation of the hardware side can be reduced, the utilization rate of hardware resources can be improved, and the verification efficiency of the components to be verified can be further improved.

[0053] S17: driving the configuration transaction through the bus function model in the hardware end environment, and completing the transaction configuration process of the component to be verified in the hardware end environment based on the driving result.

[0054] The above-mentioned drive can be understood as the process in which the bus function model converts the configuration transaction into a signal or operation that can be understood by the component to be verified, and sends it to the component to be verified. The above-mentioned drive process can ensure that the configuration transaction is correctly executed in the hardware environment, thereby completing the initial state configuration and parameter setting of the component to be verified, and then ensuring that the component to be verified is in the correct initial state before the verification begins, so as to carry out subsequent functional verification. By driving the configuration transaction through the bus function model, the high-performance computing capabilities of the hardware emulator can be utilized to quickly complete the configuration of the component to be verified. Compared with traditional software simulation, the configuration time can be significantly reduced, thereby improving the verification efficiency of the component to be verified.

[0055] For example, see Figure 3The hardware side calls the preset configuration function 'CfgFunction()' in the software side environment through a non-blocking call. The above preset configuration function can be set with calling parameters such as target address or target data. The software side parses the called preset configuration function to generate a configuration transaction, stores the configuration transaction in the GFIFO send queue, and returns the configuration transaction as the result of the hardware side call. Subsequently, the bus function model in the hardware side environment can read the configuration transaction from the GFIFO send queue, convert the configuration transaction into a configuration drive signal, and send it to the component to be verified for transaction configuration, and return a response.

[0056] In this embodiment, by driving configuration transactions in the hardware environment through the bus function model, the consistency and accuracy of the configuration process can be ensured, thereby improving the verification efficiency of the component to be verified. By driving configuration transactions in the hardware environment through the bus function model, the configuration task can be transferred to the hardware side, thereby reducing the burden on the software side, allowing it to focus more on generating test stimuli and implementing verification logic. At the same time, by directly interacting with the component to be verified through configuration transactions through the bus function model in the hardware environment, the overhead of signal conversion is reduced, further improving the verification efficiency of the component to be verified.

[0057] In one possible implementation, the software environment also includes a sampling module and a verification module. The sampling module is used to sample transactions transmitted between the bus function model and the proxy model, collecting all transaction data for subsequent analysis and verification. The verification module is used to verify the transaction data passed by the sampling module to verify whether the configuration transactions comply with the expected specifications and protocols, for example, checking the consistency, integrity, and timing of the configuration transactions.

[0058] In this embodiment, when transactions are transmitted between the bus function model and the proxy model, the transmitted transactions are sampled and verified by the sampling module and the verification module, respectively. Specifically, a communication connection is established between the sampling module and the verification module, so that the sampled transactions are passed to the verification module for verification via the sampling module. Based on the verification results, the simulation server's CPU can promptly detect errors and anomalies during the transaction transmission process, helping to improve the accuracy and reliability of verification, ensuring the correctness of the component to be verified in various scenarios. While ensuring verification quality, it significantly reduces verification time and resource consumption, thereby ensuring the verification efficiency of the component to be verified.

[0059] In the embodiment, when initializing each agent model in the software end environment, the sampling module and the checking module also need to be initialized. Specifically, the operation of initializing the sampling module and the checking module can include allocating necessary memory resources, setting initial states, and establishing communication connections with other components, etc. to ensure that the sampling module and the checking module are in the correct initial state before verification starts, and can correctly perform subsequent sampling and checking tasks. And after receiving the reset release signal from the component in the hardware end environment to be verified, the initialization process of the sampling module and the checking module is completed, so as to ensure that the initialization of the sampling module and the checking module in the software end is synchronized with the initialization process of the hardware end, avoiding sampling and checking errors caused by the hardware end not being ready, thereby ensuring the reliability and accuracy of verification.

[0060] In a possible implementation, the bus function model and the agent model correspond to different protocol types, and accordingly, the sampling module includes at least a first sampling module corresponding to a first protocol type and a second sampling module corresponding to a second protocol type. The protocol types can include APB protocol, AXI protocol and CHI protocol. The first protocol type and the second protocol type can be any combination of the above-mentioned protocol types. Since the bus function model and the agent model correspond one by one according to the protocol type, when the bus function model and the agent model perform data transmission, the sampling module needs to extract transaction samples for checking, so different sampling modules are set to distinguish the sampling modules corresponding to the bus function model and the agent model according to the protocol type.

[0061] In the embodiment, the sampling modules of different protocol types sample transactions of different protocol types. The first sampling module samples transactions of the first protocol type, and the second sampling module samples transactions of the second protocol type. For example, the bus function model is an AXI bus function model that transmits AXI protocol type transactions, which is sampled by the sampling module responsible for sampling AXI protocol type when transmitting configuration transactions of AXI protocol type to the AXI agent model of the corresponding protocol type in the software end. By using the sampling module for a specific protocol type, the sampling module can recognize and process data formats and signal characteristics specific to different protocols, so that transaction data can be more accurately captured and analyzed, and the accuracy of sampling and subsequent checking is improved. Further, the verification efficiency of the component to be verified is improved.

[0062] In a possible implementation, please refer to Figure 4In the software environment, the proxy model is instantiated as a transaction initiator and a transaction receiver. The transaction initiator is used to generate and actively initiate configuration transactions according to verification requirements, such as read and write requests, configuration commands, etc., and send them to the component to be verified to simulate hardware behavior. The transaction receiver is used to receive the transaction response generated by the component to be verified after executing the configuration transaction, and return the processed transaction response to the transaction initiator, such as returning the read data or confirming the completion of the write operation. On the hardware environment side, a communication connection is established between the two proxy models of the transaction initiator and the transaction receiver and the component to be verified through the bus proxy model, thereby realizing the transmission and feedback of configuration transactions and response data.

[0063] Specifically, for any bus function model, determine the transaction initiator and transaction receiver that match the bus function model; establish a communication connection between the bus function model and the matching transaction initiator, and establish a communication connection between the bus function model and the matching transaction receiver. The above matching can be understood as the bus function model having the same protocol type as the transaction initiator and the transaction receiver. Among them, the component to be verified receives the transaction issued by the transaction initiator, processes the received transaction, and then passes the processed transaction to the transaction receiver. The above processing process may include operations such as transaction parsing, conversion, and scheduling to ensure that the transaction can be correctly passed to the component to be verified, as well as receiving the response generated by the transaction receiver for the processed transaction, and feeding the response back to the transaction initiator to complete a complete transaction interaction process.

[0064] In this implementation, by instantiating proxy models as transaction initiators and receivers and defining the communication connection between them and the bus functional model, a realistic simulation of actual transaction interaction scenarios can be achieved. Multiple transaction initiators can simultaneously generate different types of transactions, and the matching bus functional model can process these transactions in parallel and pass them to the corresponding transaction receivers. This satisfies verification requirements at different stages and levels, improves verification parallelism and flexibility, and ultimately enhances verification efficiency for the components being verified.

[0065] In one embodiment, on the basis of instantiating the proxy model as a transaction initiator and a transaction receiver, and in the case where a sampling module and a verification module are also included in the software-side environment, the sampling module is used to sample transactions transmitted between the bus function model and the transaction initiator, and the sampling module is used to sample transactions transmitted between the bus function model and the transaction receiver, and the sampled transactions are passed to the verification module through the sampling module, so that the verification module performs cache consistency check and memory consistency check on the received transactions.

[0066] In chip verification, consistency checks include cache consistency and memory consistency. The cache consistency is used to ensure that multiple processors or components maintain consistent access to shared data to avoid errors caused by asynchronous cache data. The memory consistency is used to ensure that data transmission and access between different components follow specific timing and rules to ensure data correctness.

[0067] This implementation refines the sampling and verification of transactions transmitted between the component to be verified and the transaction initiator, as well as the transaction recipient. The sampling module samples transactions between the component to be verified and the transaction initiator, and between the component to be verified and the transaction recipient, respectively, enabling detection of the entire transaction transmission process. The verification module also performs cache and memory consistency checks on the sampled transactions, thereby improving the comprehensiveness and reliability of verification.

[0068] In the second aspect, the present application provides a verification method, which is applied to the verification environment constructed according to the verification environment construction method of the first aspect above. Based on the above verification environment, the component to be verified is activated to verify. Figure 5 , the above verification method can be carried out according to the following steps:

[0069] S61: Calling a preset test function in the hardware-side environment where the transaction configuration process is completed, so as to start corresponding stimulus signals in one or more proxy models in the software-side environment through the preset test function, and generating stimulus transactions based on the started stimulus signals.

[0070] S63: driving the stimulus transaction generated by the matching proxy model to the component to be verified in the hardware environment through the bus function model in the hardware environment, so as to perform concurrent verification on the component to be verified.

[0071] Specifically, in the hardware-side environment, after the transaction configuration process is completed, a preset test function will be called. The preset test function is a generation function predefined by the software side according to a preset scenario. The preset test function contains the various test scenarios and stimulus signal definitions required to verify the component to be verified. Furthermore, the preset test function starts the corresponding stimulus signal in one or more proxy models in the software-side environment. The stimulus signal is a signal pre-designed according to the test scenario requirements and is used to simulate various operations and data transmission requests in actual usage scenarios. Furthermore, based on the started stimulus signal, the proxy model on the software side generates a specific stimulus transaction. The stimulus transaction is used to verify the test data and operation instructions for the function and performance of the component to be verified.

[0072] In this embodiment, multiple stimulus transactions can be sent to the component to be verified at the same time through the bus function model. Figure 6, the hardware end calls the preset test function 'MainTest()', the sampling module and the verification module on the software end start the consistency test, and the agent model in the software end environment starts the stimulus signal, generates the related stimulus transaction, and stores the stimulus transaction in the GFIFO sending queue, and distributes the stimulus transaction to each bus function model through the GFIFO sending queue, and each bus function model drives the stimulus transaction to the component to be verified in the form of a stimulus driving signal in parallel, and returns the response to the bus function model after the component to be verified processes the stimulus transaction, thereby covering more test scenarios in a shorter time, improving the verification comprehensiveness of the component to be verified, and also improving the verification efficiency of the component to be verified.

[0073] The technical scheme provided by the embodiment of the application can perform a large number of tests on the component to be verified in a short time, and is especially suitable for large-scale verification tasks in complex chip design. By calling the preset test function in the hardware end environment, the slow speed of traditional software simulation is overcome, the stimulus signal can be quickly started and the stimulus transaction can be generated, thereby greatly shortening the verification period, and by simultaneously starting the stimulus signal by multiple agent models to generate multiple stimulus tasks, the stimulus tasks are concurrently driven into the component to be verified, thereby further improving the verification efficiency of the component to be verified.

[0074] In a possible implementation, the preset test function corresponds to test cases of different protocol types. Correspondingly, the agent models of different protocol types concurrently generate stimulus signals of multiple test cases to concurrently verify the component to be verified. The test cases include test scenarios for multiple function points of the component to be verified, and by running the stimulus signals of these test cases under different protocol types, it can be verified whether the component to be verified correctly performs the corresponding functions according to the design specification.

[0075] In the embodiment, the preset test function corresponds to test cases of different protocol types, which can ensure that the verification process covers multiple protocol scenarios. The agent models of different protocol types concurrently generate stimulus signals to comprehensively cover the concurrent verification of the function and performance of the component to be verified under various protocols, thereby improving the comprehensiveness and efficiency of the verification of the component to be verified. At the same time, by running test cases of different protocol types, design defects or logical errors in the component to be verified can be found early in the project, so that timely correction can be made to avoid high correction costs caused by late discovery.

[0076] In a possible implementation, in the case where the software end environment includes a sampling module and a verification module, if the transaction between the bus function model and the agent model does not satisfy the consistency condition through the verification module, the verification module initiates indication information representing stopping verification, and after stopping verification, the verification module generates transaction offline data, which is used for analyzing consistency.

[0077] The above consistency conditions include cache consistency conditions and memory consistency conditions. The above cache consistency conditions require that the bus functional model and the proxy model maintain consistency in the cache of transactions. The above memory consistency conditions require that the transaction transmission and access between the bus functional model and the proxy model follow specific timing and rules. The above indication information is the signal or information sent by the verification module when it detects that the transaction does not meet the consistency conditions, indicating that a potential design defect has been found during the verification process. The above indication information can trigger changes in the verification process, such as stopping the verification process to prevent further errors or invalid verifications. The above transaction offline data carries detailed information that characterizes the execution of the transaction, including transaction type, address, data, timing, etc., providing key information for the debugging process, thereby optimizing the verification strategy and test cases.

[0078] This embodiment provides a method for handling errors in verification transactions. When a transaction fails to meet consistency conditions, the verification module can promptly initiate an instruction to stop verification, preventing further transmission of the error. Meanwhile, offline transaction data containing detailed information about the transaction during transmission is generated, allowing for rapid identification of the time when the problem occurred, enabling rapid adjustment of the verification strategy and improving the overall verification efficiency of the chip to be verified.

[0079] In one possible implementation, the bus function model and the proxy model communicate via a general first-in, first-out mechanism (GFIFO). This first-in, first-out mechanism is a data buffering mechanism used to transfer data between the hardware and software ends, ensuring that data is delivered in order and ensuring verification accuracy. Furthermore, stimulus transactions generated by the proxy model are driven to the component to be verified via the GFIFO in a non-blocking manner. This non-blocking approach allows the hardware to continue operating without waiting for software processing to complete, reducing waiting time and thus improving verification efficiency for the component to be verified.

[0080] This implementation utilizes a first-in, first-out (FIFO) mechanism and a non-blocking communication method. This ensures effective and efficient data transmission between the bus function model and the proxy model, reducing latency and resource conflicts during data transmission. Furthermore, the non-blocking driver method allows the component to be verified to receive stimuli and initiate responses more quickly, shortening response delays during verification and further improving verification efficiency.

[0081] Please refer to Figure 7 This application provides an embodiment of the verification process of the component to be verified using the above verification environment. The embodiment is carried out in a collaborative manner in the software end environment and the hardware end environment. The software end environment and the hardware end environment use the GFIFO mechanism to communicate in a non-blocking manner. Figure 7The process is shown:

[0082] Step one: the initialization process of the software end environment and the hardware end environment is performed. Specifically, the initialization of each agent model, sampling module and verification module is performed in the software end environment, and the reset operation of the component to be verified is performed in the hardware end environment. After reset, the reset release signal is transmitted to the software end environment, and the initialization of each component is completed in the software end environment.

[0083] Step two: the configuration process of the software end environment and the hardware end environment is performed. Specifically, in the hardware end environment, a preset configuration function is called, and the preset configuration function is parsed by each bus agent model in the software end environment to construct a configuration transaction, and the configuration transaction is driven to the component to be verified for configuration through the bus function model.

[0084] Step three: the test process of the software end environment and the hardware end environment is performed. Specifically, in the hardware end environment, a preset test function is called, and the preset test function is parsed by each bus agent model in the software end to construct an excitation transaction, and the excitation transaction is driven to the component to be verified for test verification through the bus function model.

[0085] Step four: the verification result of the component to be verified is returned. In addition, if a transaction transmission error occurs in the verification process of step three, transaction offline data is generated by the verification module, and the verification strategy or the optimization and update of the component to be verified are performed according to the transaction offline data.

[0086] After the verification operation of the component to be verified through steps one to four, the verification process of the component to be verified is accelerated through the asynchronous cooperative interaction of the hardware end and the software end, thereby improving the verification efficiency of the component to be verified. Specifically, the bus function model is set in the hardware end and the matching agent model is set in the software end, and the two work cooperatively through communication connection. The configuration transaction is efficiently configured and driven in the hardware end and the software end, ensuring that the component to be verified can quickly complete the configuration, accelerating the preparation process of the verification, and thereby improving the verification efficiency of the component to be verified. At the same time, the component to be verified in the hardware end environment is run on the hardware simulator to accelerate the verification speed by replacing the real IP with the agent model, and the logical tasks are reasonably distributed between the hardware end and the software end, saving the resource consumption and logical occupation of the hardware end, and further improving the verification efficiency of the component to be verified. It can be seen that through the technical solution provided by the embodiment of the application, the software end and the hardware end are cooperatively verified, the component to be verified is run in the hardware environment, the verification speed is thousands of times higher than that of the traditional software simulation, the verification period is greatly shortened, and compared with the traditional hardware simulation, the resource consumption and logical occupation of the hardware end are saved, thereby improving the verification efficiency of the component to be verified.

[0087] Please refer to Figure 8The present application also provides a system for constructing a verification environment, wherein the verification environment includes a hardware environment and a software environment. The hardware environment includes a component to be verified and a bus function model, and the software environment includes a proxy model that matches the bus function model. The system includes:

[0088] The connection establishing unit 100 is used to establish a connection relationship between the component to be verified and each of the bus function models, and to establish a communication connection between the matching bus function models and the proxy model;

[0089] an initialization unit 200 for initializing each of the proxy models in the software-side environment and completing the initialization process of each of the proxy models after receiving a reset release signal from the component to be verified in the hardware-side environment, wherein the reset release signal is issued when the hardware-side environment has completed initialization;

[0090] The transaction construction unit 300 is configured to call a preset configuration function in the hardware-side environment to construct a configuration transaction in the software-side environment through the preset configuration function;

[0091] The transaction configuration unit 400 is configured to drive the configuration transaction through the bus function model in the hardware end environment, and complete the transaction configuration process of the component to be verified in the hardware end environment based on the driving result.

[0092] in,

[0093] In one embodiment, the connection establishment unit 100 is specifically used to establish a communication relationship between the proxy model in the software-side environment and the bus function model in the hardware-side environment, so as to transmit the test stimulus to the bus function model through the proxy model, connect the component to be verified with each bus function model through the hardware interface of the component to be verified, and establish a separate communication channel between the bus function model and the proxy model matching it to achieve lossless transmission from the software-side environment to the hardware-side environment.

[0094] In one embodiment, the initialization unit 200 is specifically used to allocate resources and set the initial state for each proxy model in the software-side environment, and after the hardware initialization is completed in the hardware-side environment, the component to be verified transmits a reset release signal to the matching proxy model through the bus function model. When the proxy model receives the above reset release signal, it performs a configuration test to complete the initialization process of the proxy model.

[0095] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0096] In an embodiment of the present application, a verification environment construction system is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, or other devices that can provide the above functions.

[0097] In one embodiment, the chip verification system is deployed in a computer device, wherein the verification system includes a hybrid verification environment generated according to a hybrid verification environment generation method. The chip verification system is connected to the chip under test via a communication interface of the computer device.

[0098] See also Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 9 As shown, the computer device includes: one or more processors 10, memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in the memory or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Equally, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 9 A processor 10 is taken as an example.

[0099] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0100] The memory 20 stores instructions that can be executed by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0101] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0102] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0103] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0104] The embodiments of the present application also provide a computer-readable storage medium. The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0105] A portion of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium that can be accessed by the computer.

[0106] The systems, devices, modules or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices. For the convenience of description, the above devices are described separately by function into various units. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0107] The present application is described with reference to the flowcharts and / or block diagrams of the methods and systems according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0108] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 Figure 1

[0110] It should also be noted that the term "comprising" or "comprises" when used in this specification is taken to mean the inclusion of one or more steps or elements from any one of the embodiments, or the inclusion of one or more steps or elements from a combination of two or more embodiments.

[0111] Each embodiment in the present specification is described in a progressive manner, and the same or similar parts between each embodiment can be mutually referred to. Each embodiment focuses on the difference from other embodiments. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiments.

[0112] The above only describes the embodiments of the present application and is not intended to limit the present application. Those skilled in the art can make various modifications and changes to the present application. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of the claims of the present application.

[0113] Although the embodiments of the present application are described in conjunction with the drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes shall fall within the scope defined by the appended claims.​​

Claims

1. A method for constructing a verification environment, characterized in that: The verification environment includes a hardware environment and a software environment, wherein the hardware environment includes a component to be verified and a bus function model, and the software environment includes a proxy model that matches the bus function model. The method includes: Establishing a connection relationship between the component to be verified and each of the bus function models, and establishing a communication connection between the matching bus function models and the proxy model; Initializing each of the proxy models in the software-side environment, and completing the initialization process of each of the proxy models after receiving a reset release signal from the component to be verified in the hardware-side environment, wherein the reset release signal is sent when the hardware-side environment has completed initialization; Calling a preset configuration function in the hardware-side environment to construct a configuration transaction in the software-side environment through the preset configuration function; The configuration transaction is driven by a bus function model in the hardware end environment, and a transaction configuration process of the component to be verified in the hardware end environment is completed based on the driving result.

2. The method according to claim 1, characterized in that The software environment further includes a sampling module and a verification module; the method further includes: Sampling transactions transmitted between the bus function model and the proxy model by the sampling module; Establishing a communication connection between the sampling module and the verification module so as to transmit the sampled transactions to the verification module for verification through the sampling module; When initializing each of the proxy models in the software-side environment, the sampling module and the verification module are initialized, and after receiving the reset release signal from the component to be verified in the hardware-side environment, the initialization process of the sampling module and the verification module is completed.

3. The method according to claim 2, characterized in that The bus function model and the proxy model each correspond to a different protocol type. Accordingly, the sampling module at least includes a first sampling module corresponding to a first protocol type and a second sampling module corresponding to a second protocol type. Sampling the transactions transmitted between the bus function model and the proxy model by the sampling module includes: The first sampling module samples transactions of the first protocol type, and the second sampling module samples transactions of the second protocol type.

4. The method according to claim 1, wherein The proxy model is instantiated as a transaction initiator and a transaction receiver; Establishing a communication connection between matching bus function models and agent models includes: For any bus functional model, determining a transaction initiator and a transaction receiver that match the bus functional model; Establishing a communication connection between the bus functional model and a matching transaction initiator, and establishing a communication connection between the bus functional model and a matching transaction recipient; The bus function model receives the transaction issued by the transaction initiator, processes the received transaction, passes the processed transaction to the transaction receiver, receives the response generated by the transaction receiver for the processed transaction, and feeds the response back to the transaction initiator.

5. The method according to claim 4, characterized in that The method further comprises: In a case where the software-side environment further includes a sampling module and a verification module, the sampling module samples transactions transmitted between the bus function model and the transaction initiator, and samples transactions transmitted between the bus function model and the transaction receiver; The sampled transactions are transferred to the verification module through the sampling module, so that the verification module performs cache consistency verification and memory consistency verification on the received transactions.

6. A verification method, characterized in that: The method is applied to a verification environment constructed according to any one of claims 1 to 5, and the method comprises: Calling a preset test function in the hardware-side environment where the transaction configuration process is completed, so as to activate corresponding stimulus signals in one or more proxy models in the software-side environment through the preset test function, and generating stimulus transactions based on the activated stimulus signals; The stimulus transaction generated by the matching agent model is driven to the component to be verified in the hardware environment through the bus function model in the hardware environment, so as to perform concurrent verification on the component to be verified.

7. The method according to claim 6, characterized in that The preset test functions correspond to test cases of different protocol types. Accordingly, the proxy models of different protocol types concurrently generate stimulus signals of multiple test cases to concurrently verify the components to be verified.

8. The method according to claim 6, characterized in that The method further comprises: In the case where the software-side environment includes a sampling module and a verification module, if the verification module determines that the transaction between the bus function model and the proxy model does not meet the consistency condition, the verification module initiates an indication information representing the stop of verification, and after stopping the verification, the verification module generates transaction offline data, and the transaction offline data is used to analyze the consistency.

9. The method according to claim 1, characterized in that The bus function model and the proxy model communicate with each other through a general first-in-first-out mechanism, and the stimulus transaction generated by the proxy model is driven to the component to be verified in a non-blocking manner.

10. A system for constructing a verification environment, characterized in that: The verification environment includes a hardware environment and a software environment. The hardware environment includes components to be verified and a bus function model. The software environment includes a proxy model that matches the bus function model. The construction system includes: a connection establishing unit, configured to establish a connection relationship between the component to be verified and each of the bus function models, and to establish a communication connection between the matching bus function models and the proxy model; an initialization unit, configured to initialize each of the proxy models in the software-side environment and complete the initialization process of each of the proxy models after receiving a reset release signal from the component to be verified in the hardware-side environment, wherein the reset release signal is issued when the hardware-side environment has completed initialization; A transaction construction unit, configured to call a preset configuration function in the hardware-side environment to construct a configuration transaction in the software-side environment through the preset configuration function; The transaction configuration unit is used to drive the configuration transaction through the bus function model in the hardware end environment, and complete the transaction configuration process of the component to be verified in the hardware end environment based on the driving result.

11. A verification system, characterized in that: The verification system includes a verification environment generated by the method according to any one of claims 1 to 5, and the verification system includes: A stimulus generation unit, configured to call a preset test function in the hardware-side environment where the transaction configuration process is completed, so as to activate corresponding stimulus signals in one or more proxy models in the software-side environment through the preset test function, and generate a stimulus transaction based on the activated stimulus signals; The transaction driving unit is used to drive the stimulus transaction generated by the matching proxy model to the component to be verified in the hardware end environment through the bus function model in the hardware end environment, so as to perform concurrent verification on the component to be verified.

Images