Chip bus verification method, device and equipment and storage medium

Abstract

A chip bus verification method, apparatus, device, and storage medium are disclosed. First, the chip design file of the chip to be verified is obtained. Then, based on the device address configuration file and device path configuration file in the chip design file, a reference model and verification test cases for bus verification are generated. Furthermore, based on the device configuration file in the chip design file, verification environment components and interface connection files between the device under test (DUT) and the DUT are generated. The DUT includes the bus design code of the chip to be verified. The chip bus of the chip to be verified can then be verified based on the reference model, verification test cases, the DUT, and the verification environment components. By automatically generating the verification environment components, reference model, verification test cases, and interface connection files for chip bus verification based on the chip design file, a verification platform can be automatically generated based on the chip design file, eliminating the need for verification personnel to build the verification platform and significantly reducing labor costs.

Description

Technical Field

[0001] This disclosure relates to the field of chip verification technology, and in particular to a chip bus verification method, apparatus, device and storage medium. Background Technology

[0002] With the rapid development of digital integrated circuit technology, the number of devices integrated within a chip (also known as functional modules, such as central processing units, memory, and controllers) is constantly increasing, significantly enhancing the complexity of communication between these devices. The internal bus of a chip has also gradually evolved into interconnection structures such as bus matrices, multi-layer buses, and on-chip networks. Master-slave device access on the bus now includes not only read and write operations but also various transaction-level operations, posing greater challenges to the workload and completeness of chip bus verification.

[0003] In chip bus verification, a technique based on UVM (Universal Verification Methodology) to build a verification platform and write verification test cases is proposed to achieve chip bus verification. In related technologies, verification personnel, based on the UVM verification methodology, write drivers, monitors, interfaces, sequencers, and verification test cases to complete the verification platform construction and verification test case building. The interface is then used to connect to the DUT (Device Under Test) to ultimately complete the simulation testing of the DUT. This approach requires verification personnel to spend a significant amount of time building verification test cases and the verification platform, resulting in low verification efficiency. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this disclosure provide a chip bus verification method, apparatus, device, and storage medium.

[0005] According to one aspect of the present disclosure, a chip bus verification method is provided, comprising: Obtain the chip design files of the chip to be verified; Based on the device address configuration file and device path configuration file in the chip design file, a reference model and verification test cases for bus verification are generated; and based on the device configuration file in the chip design file, verification environment components and interface connection files between the device under test and the device under test are generated, wherein the device under test includes the bus design code of the chip to be verified. Based on the reference model, verification test cases, the device under test, and the verification environment components, the chip bus of the chip to be verified is verified.

[0006] In some optional implementations, the generation of a reference model and verification test cases for bus verification based on the device address configuration file and device path configuration file in the chip design file includes: Based on the device address configuration file, an array including device address data is generated; Based on the array and the device path configuration file, a device communication routing table is generated; Based on the master device's access permissions to the slave device in the device communication routing table, and the slave device's device address data, the verification test case and the reference model are generated.

[0007] In some optional implementations, generating an array including device address data based on the device address configuration file includes: The device address configuration file is parsed to obtain the address information of the device in the chip to be verified; The array is generated based on the address information of the device.

[0008] In some optional implementations, generating the verification environment components and interface connection files with the device under test based on the device configuration file in the chip design file includes: Based on the device configuration file, generate the verification environment components corresponding to the device; Based on the verification environment components corresponding to the device, an interface connection file is generated between the device under test and the device.

[0009] In some alternative implementations, it also includes: Based on the interface connection file, a connection is established between the verification environment component and the device under test.

[0010] In some alternative implementations, it also includes: Based on the device address configuration file and device path configuration file in the chip design file, a functional coverage model is generated.

[0011] In some optional implementations, after verifying the chip bus of the chip to be verified, the process further includes: Collect chip verification data; Using the aforementioned functional coverage model, the coverage of chip bus verification is determined based on the chip verification data.

[0012] In some optional implementations, the verification of the chip bus of the chip to be verified based on the reference model, verification test cases, the device under test, and the verification environment components includes: Based on the aforementioned verification test cases, the driver stimulus generator generates stimulus signals; The excitation signal is driven to the device under test, and the device under test is controlled to perform device communication operations to obtain a first execution result. The excitation signal is also controlled to be collected by the monitor in the verification environment component and input into the reference model, and the reference model is controlled to perform corresponding device communication operations to obtain a second execution result. Based on the first execution result and the second execution result, the chip bus verification result is determined.

[0013] According to another aspect of the present disclosure, a chip bus verification apparatus is provided, comprising: The acquisition module is used to acquire the chip design files of the chip to be verified. The generation module is used to generate a reference model and verification test cases for bus verification based on the device address configuration file and device path configuration file in the chip design file; and to generate verification environment components and interface connection files between the device and the device under test based on the device configuration file in the chip design file, wherein the device under test includes the bus design code of the chip to be verified. The verification module is used to verify the chip bus of the chip to be verified based on the reference model, verification test cases, the device under test, and the verification environment components.

[0014] In some alternative implementations, the generation module may include: The first generation submodule is used to generate an array including device address data based on the device address configuration file; The second generation submodule is used to generate a device communication routing table based on the array and the device path configuration file; The third generation submodule is used to generate the verification test case and the reference model based on the master device's access permission to the slave device in the device communication routing table and the slave device's device address data.

[0015] In some optional implementations, the first generation submodule is used to: parse the device address configuration file to obtain the address information of the device in the chip to be verified; and generate the array based on the address information of the device.

[0016] In some alternative implementations, the generation module may include: The fourth generation submodule is used to generate the verification environment components corresponding to the device based on the device configuration file; The fifth generation submodule is used to generate an interface connection file between the device under test and the verification environment component corresponding to the device.

[0017] In some alternative implementations, the chip bus verification apparatus may include: The connection module is used to establish a connection between the verification environment component and the device under test based on the interface connection file.

[0018] In some alternative implementations, the generation module is also used to generate a functional coverage model based on the device address configuration file and device path configuration file in the chip design file.

[0019] In some alternative implementations, the chip bus verification apparatus may include: The data acquisition module is used to collect chip verification data; The coverage determination module is used to determine the coverage of chip bus verification based on the chip verification data using the functional coverage model.

[0020] In some alternative implementations, the verification module may include: The signal generation submodule is used to drive the stimulus generator to generate a stimulus signal based on the verification test case. The driving submodule is used to drive the excitation signal to the device under test, control the device under test to perform device communication operations to obtain a first execution result, and control the monitor in the verification environment component to collect the excitation signal and input the excitation signal into the reference model, control the reference model to perform corresponding device communication operations to obtain a second execution result; The result determination submodule is used to determine the chip bus verification result based on the first execution result and the second execution result.

[0021] According to another aspect of the present disclosure, a computer-readable storage medium is provided, which stores computer program instructions that, when executed, implement the above-described method.

[0022] According to another aspect of the present disclosure, an electronic device is provided, the electronic device comprising: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in memory, and when the computer program product is executed, to implement the above method.

[0023] According to another aspect of the present disclosure, a computer program product is provided, including computer program instructions that, when executed by a processor, implement the above-described method.

[0024] Based on the embodiments of this disclosure, for scenarios requiring chip bus verification, the chip design file of the chip to be verified can be obtained first. Then, based on the device address configuration file and device path configuration file in the chip design file, a reference model and verification test cases for bus verification can be generated. Furthermore, based on the device configuration file in the chip design file, verification environment components and interface connection files between the chip and the device under test (DUT) can be generated. The DUT includes the bus design code of the chip to be verified. Thus, the chip bus of the chip to be verified can be verified based on the reference model, verification test cases, DUT, and verification environment components. By automatically generating the verification environment components, reference model, verification test cases, and interface connection files for chip bus verification based on the chip design file, a verification platform can be automatically generated based on the chip design file. This eliminates the need for verification personnel to build the verification platform, greatly reducing labor costs and effectively improving the efficiency of chip bus verification.

[0025] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0026] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0027] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 This is a schematic diagram of a verification platform used for chip bus verification. Figure 2 This is a flowchart illustrating one embodiment of the chip bus verification method disclosed herein; Figure 3 This is a flowchart illustrating step 202 in the chip bus verification method disclosed herein; Figure 4 This is a schematic diagram of the device address data generated in the chip bus verification method of this disclosure; Figure 5 This is another flowchart illustrating step 202 in the chip bus verification method disclosed herein; Figure 6 This is a flowchart illustrating step 203 in the chip bus verification method disclosed herein; Figure 7 This is a schematic diagram of the structure of one embodiment of the chip bus verification device disclosed herein; Figure 8This is a schematic diagram of another embodiment of the chip bus verification device disclosed herein; Figure 9 This is a structural diagram of an electronic device provided as an illustrative embodiment of the present disclosure. Detailed Implementation

[0028] Hereinafter, exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present disclosure, and not all embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0029] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0030] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0031] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0032] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0033] Furthermore, in this embodiment, the term "and / or" merely describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this embodiment, the character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0034] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0035] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0036] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0037] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0038] In order to accurately describe the technical content in this disclosure, and to accurately understand the embodiments of this disclosure, the terms used in the embodiments of this disclosure are explained or defined as follows: The verification platform built on UVM is primarily a verification environment architecture written in SystemVerilog (a hardware description and verification language for hardware design and verification, also known as SV). It is used to verify the functional correctness of the DUT (Device Under Test). In this disclosure, the DUT mainly performs chip bus functions. See also... Figure 1 The verification platform can include tb top (testbench top, the top layer of the verification platform), uvm_test (verification test cases), uvm_env (a container for the verification environment), uvm_sequence (an stimulus generator, a sequence), uvm_in_agent (an input agent that inputs stimulus signals to the input interface of the DUT), and uvm_out_agent (an output agent that captures data from the output interface of the DUT).

[0039] The `tb top` module is the top-level module of the simulation environment, used to instantiate the device under test (DUT), generate interface connection files between the verification environment components and the DUT, and verify the correctness of the interfaces between modules. `uvm_test` is responsible for creating and configuring the entire verification environment (`uvm_env`), and defining specific test scenarios, including calling `uvm_sequence` to generate stimulus signals based on the verification test case scenarios. `uvm_env` contains all the verification environment components that constitute the verification environment, organizing and managing them in a structured way. `uvm_in_agent` includes a driver (`uvm_driver`), a monitor (`uvm_monitor`), and a sequence generator (`uvm_sequencer`), used to transmit the stimulus signals generated by `uvm_sequence` from the sequence generator to the DUT's input interface. `uvm_out_agent` is responsible for capturing data from the DUT's output interface and transmitting it to the scoreboard (`uvm_scoreboard`) for verification.

[0040] The `uvm_driver` is used to convert received sequence items into interface signals and drive the DUT's input interface, serving as the interface driver layer between the verification environment and the DUT. The `uvm_monitor` monitors the DUT's interface signals, converts them into transactions, and sends them to other components (such as `uvm_scoreboard` or `uvm_reference_model`). The `uvm_reference_model` simulates the DUT's expected behavior, receiving the same input stimulus signals as the DUT from the `uvm_monitor` and generating the expected output results for comparison by the scoreboard. The `uvm_scoreboard` compares the expected results from the `uvm_reference_model` with the actual output results from the `uvm_out_agent`. If a mismatch is found, it reports an error to help locate functional defects in the DUT. The `uvm_reporter` collects and reports information, warnings, and errors during the verification process.

[0041] In this disclosure, the verification platform may also include a function coverage model (…). Figure 1 (Not illustrated in the image), this functional coverage model can be connected to uvm_out_agent and uvm_reference_model to track the functional verifications completed for the DUT during simulation, as well as the functional verifications that have not yet been completed, to ensure the completeness of chip bus verification; or it can obtain the functional verifications that have been completed from uvm_reporter.

[0042] As can be seen from the above description, for different chip bus verifications, the reference model, functional coverage model, verification environment components, verification test cases, etc. in the verification platform are all different. If a corresponding verification platform is designed for each type of chip bus verification, the workload is large, the time is long, and the verification efficiency is low.

[0043] Exemplary methods Figure 2 This is a flowchart illustrating an embodiment of the chip bus verification method disclosed herein; this chip bus verification method can be applied to terminal devices (such as computer devices, servers), such as... Figure 2 As shown, the chip bus verification method includes the following steps 201 to 203. Each step is explained below.

[0044] Step 201: Obtain the chip design file of the chip to be verified.

[0045] In this embodiment, the chip design file may include a device address configuration file, a device path configuration file, and a device configuration file. The device address configuration file, device path configuration file, and device configuration file can be written by the designer using natural language.

[0046] The device configuration file can record device-related information such as the device (functional module) and device interface bandwidth contained in the chip to be verified.

[0047] The device address configuration file can record the address allocation information of each device in the chip to be verified, including the start address and end address of each device. For example, the start address of the slave0 device is h00000000, and the end address is h0000FFFF. The address allocation information of each device is uniformly addressed across the entire chip and can be used as device identification information, that is, the address allocation information can identify the device to which the address belongs.

[0048] The device path configuration file can record the bus communication relationships between the devices in the chip to be verified. For example, the master0 device can access devices slave0, slave1, and slave2. The device configuration file can also include access permission information between devices, such as the master0 device being able to write data to slave0, but only being able to read data from slave1 and not be able to write data to slave1.

[0049] The aforementioned device address configuration file, device path configuration file, and device configuration file can be organized into one large chip design file, or into three separate files, or combined and split in different ways. This disclosure does not limit the scope of these files.

[0050] Step 202: Based on the device address configuration file and device path configuration file in the chip design file, generate a reference model and verification test cases for bus verification; and based on the device configuration file in the chip design file, generate verification environment components and interface connection files between the device under test and the device under test, wherein the device under test includes the bus design code of the chip to be verified.

[0051] In this embodiment, the reference model is used to simulate the expected behavior of the DUT. It receives the same input stimulus signal as the DUT from the uvm_monitor and generates the expected output result. This model can be generated based on the device address configuration file and device path configuration file, and can simulate the behavior of devices communicating via the bus. The verification use case is used to drive the stimulus generator to generate stimulus signals and to verify the behavior of devices communicating via the bus using the generated stimulus signals.

[0052] For example, if the device path configuration file indicates that the master0 device can write data to the slave0 device, and the start address of the slave0 device is h00000000 and the end address is h0000FFFF, then three verification test cases can be generated based on the start address, end address, and a random address between the start and end addresses of the slave0 device, respectively, to test the bus behavior of writing data from the master0 device to the start address, end address, and a random address between the start and end addresses of the slave0 device.

[0053] The verification environment components include uvm_driver, uvm_monitor, uvm_scoreboard, and uvm_reporter. The interface connection file contains the interface files that connect the verification environment components to the DUT and reference model.

[0054] The process of generating the reference model and implementing verification test cases for bus verification based on the device address configuration file and device path configuration file in the chip design file can be found in [reference needed]. Figure 3 The illustrated embodiment; the specific process of generating verification environment components and interface connection files between the device and the device under test based on the device configuration file in the chip design file can be found in [reference needed]. Figure 5 The embodiments shown are not described in detail here.

[0055] Step 203: Verify the chip bus of the chip to be verified based on the reference model, verification test cases, device under test, and verification environment components.

[0056] The specific process for verifying the chip bus of the chip to be verified can be found in [link to relevant documentation]. Figure 6 The embodiments shown are not described in detail here.

[0057] Based on the embodiments of this disclosure, verification environment components, reference models, verification test cases, and interface connection files for chip bus verification can be automatically generated based on chip design files. This realizes the automatic generation of a verification platform based on chip design files, eliminating the need for verification personnel to build the verification platform, greatly reducing labor costs, and effectively improving the efficiency of chip bus verification.

[0058] Figure 3 This is a flowchart illustrating step 202 of the chip bus verification method disclosed herein. Figure 3 As shown above, in the above Figure 2 Based on the illustrated embodiment, the process of generating a reference model and implementing verification test cases for bus verification based on the device address configuration file and device path configuration file in the chip design file may include steps 221 to 223. Each step is described below.

[0059] Step 221: Generate an array containing device address data based on the device address configuration file.

[0060] In this embodiment, a script file can be used to open the device address configuration file, read the address data of each device in the configuration file, and then generate an address array based on the address data of each device. This address array includes the start address and end address of each device. Figure 4 As shown, the address data of devices slave0 and slave1 are illustrated.

[0061] The script file can be written using the interpreted scripting language Python.

[0062] In this embodiment, after generating an array including device address data, the array can be stored in a file.

[0063] Step 222: Generate a device communication routing table based on the array and the device path configuration file.

[0064] In this embodiment, the device communication routing table includes the slave devices that each master device can access, the permissions to access the slave devices, and the slave devices corresponding to the access addresses. For example, using... Figure 3 For example, assuming the master device master1 can access slave0 and slave1, if master1 accesses address h00000004, the route can be determined to the slave0 port according to the device communication routing table, while if it accesses address h00010004, the route can be determined to the slave1 port.

[0065] In this embodiment, the aforementioned script file can be used to open and read the bus communication relationship between each device in the device path configuration file, and a device communication routing table can be generated based on the bus communication relationship.

[0066] Step 223: Based on the master device's access permissions to the slave device in the device communication routing table, and the slave device's device address data, generate verification test cases and reference models.

[0067] In this embodiment, the reference model is the implementation of the device communication routing table on the UVM platform, used for use case comparison during simulation.

[0068] In some alternative implementations, a functional coverage model can also be generated based on the device address configuration file and device path configuration file in the chip design file. This model can be used to track the functional verifications completed by the DUT during simulation, as well as the functional verifications that have not yet been completed, to ensure the completeness of the chip bus verification.

[0069] In some alternative implementations, at the end of the use case simulation verification, chip verification data can be collected, and the coverage of chip bus verification can be determined based on the chip verification data using a functional coverage model to check whether each master device has accessed its accessible slave devices.

[0070] In practice, the functional coverage model can periodically or in real time obtain completed functional verifications from uvm_out_agent and uvm_reference_model to track the functional verifications completed for the DUT during the simulation process, as well as the functional verifications that have not yet been completed, thereby generating functional coverage; or it can obtain completed functional verifications from uvm_reporter to generate functional coverage.

[0071] Furthermore, based on the generated device communication routing table, verification test cases can be generated to drive uvm_sequence to generate stimulus signals and complete chip bus verification.

[0072] Based on the embodiments of this disclosure, a method for automatically generating a reference model and verification cases for bus verification is disclosed according to the device address configuration file and the device path configuration file. By automatically generating the reference model and verification cases, the computational resources for generating the verification cases and reference model can be effectively reduced, and the efficiency of generating the verification cases and reference model can be improved. Moreover, the accuracy of generating the reference model and verification cases according to the device address configuration file and the device path configuration file is higher, the bus verification is more comprehensive, omissions can be avoided, and the design quality of the verification cases can be improved.

[0073] Figure 5 This is another flowchart illustrating step 202 of the chip bus verification method disclosed herein. (See diagram below.) Figure 5 As shown above, in the above Figure 2 Based on the illustrated embodiment, the specific process of generating the verification environment components and the interface connection files between them and the device under test, based on the device configuration file in the chip design file, may include steps 224 to 225. Each step is described below.

[0074] Step 224: Generate the verification environment components corresponding to the device based on the device configuration file.

[0075] In this embodiment, a verification environment component can be generated for each device based on the devices (functional modules) contained in the chip to be verified as recorded in the device configuration file.

[0076] The verification environment components may include uvm_driver, uvm_monitor, uvm_scoreboard, and uvm_reporter.

[0077] Step 225: Based on the verification environment components corresponding to the device, generate the interface connection file between the device under test and the device.

[0078] The interface connection file contains the interface files that connect the verification environment components to the DUT and the reference model. Through the interface connection file, connections can be established between the verification environment components and the DUT, as well as between the verification environment components and the reference model.

[0079] A standard UVM validation platform can be generated by validating the environment components and interface connection files.

[0080] In this embodiment, by instantiating the DUT and including the interface connection file, the driver and monitor in the verification environment component of the verification platform are connected to the DUT through the interface, so as to realize the acquisition of stimulus input and output results, and data comparison can be realized in the scoreboard.

[0081] Based on the embodiments of this disclosure, a standard UVM verification platform for chip bus verification is generated by generating verification environment components corresponding to master and slave devices according to device configuration files through a script, and then generating interface connection files between the verification environment components and the DUT. By automatically generating interface connection files between the verification environment components and the DUT, manual connection code is eliminated, and interface changes during the development process can be flexibly responded to, eliminating the need to manually modify the code connection every time the code interface changes.

[0082] In some optional implementations, based on the UVM verification platform, after verifying the bus function through simulation tools, the code coverage and the previously generated functional coverage are analyzed. If 100% coverage is achieved, the verification is complete. If not, targeted verification test cases are generated to eventually achieve 100% coverage.

[0083] Figure 6 This is a flowchart illustrating step 203 of the chip bus verification method disclosed herein. Figure 6 As shown above, in the above Figure 2 Based on the illustrated embodiment, the specific process of verifying the chip bus of the chip to be verified, based on the reference model, verification use cases, device under test, and verification environment components, may include steps 231 to 233. Each step is described below.

[0084] Step 231: Based on the verification test cases, drive the stimulus generator to generate stimulus signals.

[0085] In this embodiment, by running verification test cases, the stimulus generator can be driven, and the stimulus generator can be used to generate stimulus signals. The stimulus signals can include input data from the DUT and the reference model. For example, the master device 1 writes the data "aaabbbbb" to the address of the slave device 2. Then, the generated stimulus signals and register configurations can be used to drive the DUT and the reference model.

[0086] Step 232: Drive the excitation signal to the device under test, control the device under test to perform device communication operation to obtain the first execution result, and control the monitor in the verification environment component to collect the excitation signal and input the excitation signal into the reference model, control the reference model to perform the corresponding device communication operation to obtain the second execution result.

[0087] The first execution result is the bus communication result executed by the device under test according to the excitation signal, and the second execution result is the bus communication result executed by the reference model according to the excitation signal. The second execution result output by the reference model can be used as a reference result to verify the first execution result.

[0088] Step 233: Based on the first execution result and the second execution result, determine the chip bus verification result.

[0089] Based on the embodiments of this disclosure, a process for verifying a chip bus by running test cases is disclosed. By completing the chip bus verification according to automatically generated test cases, the manpower and time required for the debugging platform are reduced.

[0090] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as ROM, RAM, magnetic disk, or optical disk.

[0091] Corresponding to the embodiments of the aforementioned chip bus verification method, this disclosure also provides embodiments of a chip bus verification device.

[0092] Exemplary device Figure 7 This is a schematic diagram of one embodiment of the chip bus verification device disclosed herein. This device is applied to electronic devices (such as computer equipment, servers, etc.). Figure 7 As shown, the chip bus verification device may include: The acquisition module 71 is used to acquire the chip design file of the chip to be verified; The generation module 72 is used to generate a reference model and verification test cases for bus verification based on the device address configuration file and device path configuration file in the chip design file; and to generate verification environment components and interface connection files between the device and the device under test based on the device configuration file in the chip design file, wherein the device under test includes the bus design code of the chip to be verified. Verification module 73 is used to verify the chip bus of the chip to be verified based on the reference model, verification test cases, device under test, and verification environment components.

[0093] Figure 8 This is a schematic diagram of another embodiment of the chip bus verification device disclosed herein. Figure 8 As shown above, in the above Figure 7 Based on the illustrated embodiment, in some optional implementations, the generation module 72 may include: The first generation submodule 721 is used to generate an array including device address data based on the device address configuration file; The second generation submodule 722 is used to generate a device communication routing table based on an array and a device path configuration file; The third generation submodule 723 is used to generate verification test cases and reference models based on the master device's access permissions to the slave device in the device communication routing table and the slave device's device address data.

[0094] In some optional implementations, the first generation submodule 721 is used to: parse the device address configuration file to obtain the address information of the device in the chip to be verified; and generate an array based on the device address information.

[0095] In some alternative implementations, generation module 72 may include: The fourth generation submodule 724 is used to generate the verification environment components corresponding to the device based on the device configuration file; The fifth generation submodule 725 is used to generate interface connection files between the device under test and the device based on the verification environment components corresponding to the device.

[0096] In some alternative implementations, the chip bus verification apparatus may include: Connection module 74 is used to establish a connection between the verification environment components and the device under test based on the interface connection file.

[0097] In some alternative implementations, generation module 72 is also used to generate a functional coverage model based on the device address configuration file and device path configuration file in the chip design file.

[0098] In some alternative implementations, the chip bus verification apparatus may include: Data acquisition module 75 is used to acquire chip verification data; The coverage determination module 76 is used to determine the coverage of chip bus verification based on chip verification data using a functional coverage model.

[0099] In some alternative implementations, the verification module 73 may include: The signal generation submodule 731 is used to drive the stimulus generator to generate stimulus signals based on the verification test cases; The driving submodule 732 is used to drive the excitation signal to the device under test, control the device under test to perform device communication operations to obtain a first execution result, and control the monitor in the verification environment component to collect the excitation signal and input the excitation signal into the reference model, control the reference model to perform corresponding device communication operations to obtain a second execution result; The result determination submodule 733 is used to determine the chip bus verification result based on the first execution result and the second execution result.

[0100] The modules and units in this disclosed device can be further divided into finer-grained units according to actual needs, and the specific configuration can be set according to actual needs.

[0101] The apparatus of this disclosure embodiment can be used to implement the methods of the above embodiments of this disclosure. The two correspond to each other in specific implementation, and the specific implementation of related parts can be referred to each other, which will not be repeated here.

[0102] Exemplary electronic devices, computer program products, and computer-readable storage media This disclosure also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, it implements the chip bus verification method of any of the above embodiments of this disclosure.

[0103] Below, for reference Figure 9 This describes an electronic device according to embodiments of the present disclosure, wherein apparatus for implementing methods according to embodiments of the present disclosure may be integrated. Figure 9 This is a structural diagram of an electronic device provided in an illustrative embodiment of the present disclosure, such as... Figure 9 As shown, the electronic device includes one or more processors 91, one or more memory 92s of computer-readable storage media, and a computer program stored in the memory and executable on the processor. When the program in the memory 92 is executed, the aforementioned chip bus verification method can be implemented.

[0104] Specifically, in practical applications, the electronic device may also include components such as an input device 93 and an output device 94, which are interconnected via a bus system and / or other forms of connection mechanisms (not shown). Those skilled in the art will understand that... Figure 9The structure of the electronic device shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or certain components, or different component arrangements. Wherein: The processor 91 may be a central processing unit (CPU) or other form of processing unit with chip bus verification capability and / or instruction execution capability. It performs various functions and processes data by running or executing software programs and / or modules stored in memory 92 and calling data stored in memory 92, thereby performing overall monitoring of the electronic device.

[0105] The memory 92 can store one or more computer program products. The memory can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program products can be stored on the computer-readable storage medium, and the processor 91 can run the computer program products to implement the chip bus verification methods of the various embodiments of this disclosure described above, and / or other desired functions.

[0106] The input device 93 can be used to receive input numeric or character information. The input device 93 may include a keyboard, mouse, joystick, etc., related to user settings and function control.

[0107] The output device 94 can output various information to the outside, including determined distance information, direction information, etc. The output device 94 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0108] Electronic devices may also include a power supply for powering various components, which can be logically connected to the processor 91 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply may also include one or more DC or AC power sources, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and any other components.

[0109] Of course, for the sake of simplicity, Figure 9 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0110] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products, including computer program instructions that, when executed by a processor, cause the processor to perform the steps in the chip bus verification methods according to various embodiments of this disclosure as described in the "Exemplary Methods" section of this specification.

[0111] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0112] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the chip bus verification methods according to various embodiments of this disclosure as described in the "Exemplary Methods" section above.

[0113] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0114] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in these embodiments are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0115] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0116] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as ROM, RAM, magnetic disk, or optical disk.

[0117] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the method is for illustrative purposes only, and the steps of the method of this disclosure are not limited to the order specifically described above, unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program acquired on an acquisition medium, the program including machine-readable instructions for implementing the method according to this disclosure. Thus, this disclosure also covers acquisition media storing programs for executing the method according to this disclosure.

[0118] The description in this disclosure is provided for illustrative and descriptive purposes only and is not intended to be exhaustive or to limit the disclosure to its forms. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to better illustrate the principles and practical application of this disclosure and to enable those skilled in the art to understand this disclosure and to design various embodiments with various modifications suitable for a particular purpose.

Claims

1. A chip bus verification method, characterized in that, include: Obtain the chip design files of the chip to be verified; Based on the device address configuration file and device path configuration file in the chip design file, a reference model and verification test cases for bus verification are generated. In addition, based on the device configuration file in the chip design file, a verification environment component and an interface connection file between the device under test and the device under test are generated, wherein the device under test includes the bus design code of the chip to be verified; Based on the reference model, verification test cases, the device under test, and the verification environment components, the chip bus of the chip to be verified is verified.

2. The method according to claim 1, characterized in that, The process of generating a reference model and verification test cases for bus verification based on the device address configuration file and device path configuration file in the chip design file includes: Based on the device address configuration file, an array including device address data is generated; Based on the array and the device path configuration file, a device communication routing table is generated; Based on the master device's access permissions to the slave device in the device communication routing table, and the slave device's device address data, the verification test case and the reference model are generated.

3. The method according to claim 2, characterized in that, The step of generating an array including device address data based on the device address configuration file includes: The device address configuration file is parsed to obtain the address information of the device in the chip to be verified; The array is generated based on the address information of the device.

4. The method according to any one of claims 1-3, characterized in that, The process of generating verification environment components and interface connection files between the device and the device under test based on the device configuration file in the chip design file includes: Based on the device configuration file, generate the verification environment components corresponding to the device; Based on the verification environment components corresponding to the device, an interface connection file is generated between the device under test and the device.

5. The method according to claim 4, characterized in that, Also includes: Based on the interface connection file, a connection is established between the verification environment component and the device under test.

6. The method according to any one of claims 1-3, characterized in that, Also includes: Based on the device address configuration file and device path configuration file in the chip design file, a functional coverage model is generated.

7. The method according to claim 6, characterized in that, After verifying the chip bus of the chip to be verified, the process further includes: Collect chip verification data; Using the aforementioned functional coverage model, the coverage of chip bus verification is determined based on the chip verification data.

8. The method according to any one of claims 1-3, characterized in that, The verification of the chip bus of the chip to be verified based on the reference model, verification test cases, the device under test, and the verification environment components includes: Based on the aforementioned verification test cases, the driver stimulus generator generates stimulus signals; The excitation signal is driven to the device under test, and the device under test is controlled to perform device communication operations to obtain a first execution result. The excitation signal is also controlled to be collected by the monitor in the verification environment component and input into the reference model, and the reference model is controlled to perform corresponding device communication operations to obtain a second execution result. Based on the first execution result and the second execution result, the chip bus verification result is determined.

9. A chip bus verification device, characterized in that, include: The acquisition module is used to acquire the chip design files of the chip to be verified. The generation module is used to generate a reference model and verification test cases for bus verification based on the device address configuration file and device path configuration file in the chip design file. In addition, based on the device configuration file in the chip design file, a verification environment component and an interface connection file between the device under test and the device under test are generated, wherein the device under test includes the bus design code of the chip to be verified; The verification module is used to verify the chip bus of the chip to be verified based on the reference model, verification test cases, the device under test, and the verification environment components.

10. An electronic device, characterized in that, include: Memory, used to store computer program products; A processor for executing a computer program product stored in the memory, wherein when the computer program product is executed, it implements the method described in any one of claims 1-8.

11. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-8.

12. A computer program product comprising computer program instructions, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-8.

Images