Verification system based on a software storage model

Abstract

The application relates to the chip technical field, in particular to a verification system based on a software storage model, which comprises a driving module, a first conversion interface, an RTL module, a second conversion interface and a storage model; the driving module and the storage model are realized based on a software language; the first conversion interface and the second conversion interface are realized based on the software language and a hardware language; the RTL module is realized based on the hardware language; the RTL module is used for storing RTL codes of a chip design to be tested; the driving module is connected with the first conversion interface; the first conversion interface is connected with the RTL module; the RTL module is connected with the second conversion interface; the storage model comprises a front door access path and a back door access path; the RTL module is connected with the storage model through the front door access path; and the driving module is connected with the storage model through the back door access path. The application reduces chip verification cost, improves chip verification efficiency and verification system performance.

Description

Technical Field

[0001] This invention relates to the field of chip technology, and in particular to a verification system based on a software storage model. Background Technology

[0002] In chip development, different chip verification stages are required. Typically, hardware-level verification begins with the chip's Register Transfer Level (RTL) code. Following hardware-level verification, a hardware accelerator or physical chip is obtained. Then, system-level verification is performed based on the hardware accelerator or physical chip. After successful system-level verification, software-level verification is conducted based on the accelerator or physical chip. Since the hardware accelerator or physical chip is a real, existing entity, discovering problems during the system-level and software verification stages incurs significant update costs, reducing chip development efficiency. If system-level and / or software-level verification can be performed in advance based on the chip's RTL code, resolving issues in the RTL code before the hardware accelerator or physical chip is generated, it can improve chip development efficiency and reduce costs. In current RTL-based verification technologies, the storage model is implemented using a hardware language. During cross-stage verification, frequent interaction with the storage model is required, necessitating frequent software-hardware language conversions, which reduces verification system performance. Therefore, reducing chip verification costs and improving chip verification efficiency and verification system performance are urgent technical problems to be solved. Summary of the Invention

[0003] The purpose of this invention is to provide a verification system based on a software storage model, which reduces chip verification costs and improves chip verification efficiency and verification system performance.

[0004] This invention provides a verification system based on a software storage model, comprising: a driver module, a first conversion interface, an RTL module, a second conversion interface, and a storage model. The driver module and the storage model are implemented based on a software language. The first and second conversion interfaces are implemented based on both a software language and a hardware language. The RTL module is implemented based on a hardware language. The RTL module is used to store the RTL code of the chip under test design.

[0005] The driver module is connected to a first conversion interface, the first conversion interface is connected to an RTL module, the RTL module is connected to a second conversion interface, the storage model includes a front door access path and a back door access path, the RTL module is connected to the storage model through the front door access path, and the driver module is connected to the storage model through the back door access path.

[0006] The driving module is used to access the storage model through the backdoor access path, determine the memory allocation address of the operation parameters, generate a memory address allocation instruction, and send the memory address allocation instruction to the storage model through the backdoor access path.

[0007] The storage model stores the corresponding operation parameters in the allocated memory address based on the received memory address allocation instruction;

[0008] The driving module is also used to generate raw operation instructions based on the operation logic and send the raw operation instructions to the first conversion interface. The raw operation instructions are generated based on the software language, and the operation parameters and operation logic are generated based on test cases. The test cases include software test cases and system test cases.

[0009] The first conversion interface is used to convert the original operation instructions into target operation instructions implemented based on the hardware language, and send the target operation instructions to the RTL module;

[0010] The RTL module is used to generate raw memory operation instructions based on the target operation instructions, and send the raw memory operation instructions to the second conversion interface. The raw memory operation instructions are generated based on a hardware language.

[0011] The second conversion interface is used to convert the original memory operation instructions into target memory operation instructions implemented in a software language;

[0012] The second conversion interface sends the target memory operation instruction to the memory model through the front door access path to execute the corresponding memory operation.

[0013] Compared with existing technologies, this invention has significant advantages and beneficial effects. Through the above technical solution, the verification system based on a software storage model provided by this invention achieves considerable technological advancement and practicality, and has broad industrial application value. It possesses at least the following beneficial effects:

[0014] The system described in this invention can run based on software test cases and system test cases, enabling cross-stage early execution of software and system test cases using RTL code, reducing chip verification costs and improving chip verification efficiency. Furthermore, the system of this invention sets up a software-implemented storage model and implements the frequently interacting memory allocation process directly based on the software language through a backdoor access path, reducing the frequent conversion between software and hardware languages ​​and improving the performance of the verification system. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of a verification system based on a software storage model provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] This invention provides a verification system based on a software storage model, such as... Figure 1 As shown, it includes: a driver module, a first conversion interface, an RTL module, a second conversion interface, and a storage model. The driver module and the storage model are implemented based on a software language, specifically C, C++, etc. The first and second conversion interfaces are implemented based on both software and hardware languages. The RTL module is implemented based on a hardware language, and it stores the RTL code for the design of the chip under test. The hardware language corresponding to the RTL module can be Verilog, SystemVerilog, etc.

[0019] The driver module is connected to a first conversion interface, which in turn is connected to an RTL module. The RTL module is connected to a second conversion interface. The storage model includes a front-door access path and a back-door access path. The RTL module is connected to the storage model via the front-door access path, and the driver module is connected to the storage model via the back-door access path. As one embodiment, the first and second conversion interfaces are implemented using the existing Direct Programming Interface (DPI). DPI is a standard interface that allows SystemVerilog code to directly call C or C++ functions, and vice versa. DPI allows data and control information to be transferred between the two languages; therefore, conversion between software languages ​​and SystemVerilog can be achieved based on DPI, which will not be elaborated further here.

[0020] The driver module accesses the storage model through a backdoor access path, determines the memory allocation address of the operation parameters, generates a memory address allocation instruction, and sends the memory address allocation instruction to the storage model through the backdoor access path. It should be noted that the operation parameters are generated based on test cases. Since the driver module can directly interact with the software language, the test cases include software test cases and system test cases. That is, the system of the invention can realize the execution of software test cases and system test cases on the RTL module, realizing cross-stage test case verification, reducing chip verification costs, and improving chip verification efficiency. The operation parameters can also be original operation parameters and intermediate operation parameters obtained based on the original operation parameters. The number of operation parameters is very large. Therefore, during memory allocation, the driver module and the storage model need to interact frequently. In this embodiment of the invention, both the driver module and the storage model are modules implemented based on a software language, and can directly interact through the backdoor access path without the need for software and hardware language conversion. This greatly improves the efficiency of memory allocation and enhances system performance.

[0021] The storage model stores the corresponding operation parameters in the allocated memory address based on the received memory address allocation instruction.

[0022] The driving module is also used to generate original operation instructions based on the operation logic and send the original operation instructions to the first conversion interface. The original operation instructions are generated based on the software language, and the operation logic is generated based on the test cases. The operation logic can be the original operation logic and the intermediate operation logic obtained based on the original operation logic.

[0023] The first conversion interface is used to convert the original operation instructions into target operation instructions implemented based on the hardware language, and send the target operation instructions to the RTL module.

[0024] The RTL module is used to generate raw memory operation instructions based on the target arithmetic instructions and send the raw memory operation instructions to the second conversion interface. The raw memory operation instructions are generated based on a hardware language.

[0025] The second conversion interface is used to convert the original memory operation instructions into target memory operation instructions implemented in a software language.

[0026] The second conversion interface sends the target memory operation instruction to the memory model through the front door access path to execute the corresponding memory operation.

[0027] like Figure 1As shown in the example, the system also includes a Cmodel module, which is generated based on a software language. The Cmodel module is a software simulation module for the design of the chip under test. At any given time, only one of the Cmodel module and the RTL module can be selected to run. Specifically, different verification branches can be selected by setting environment variables in the driver module. If the environment variable is set to the Cmodel type, the Cmodel verification branch is selected; if the environment variable is set to the RTL type, the RTL verification branch is selected.

[0028] The Cmodel module is connected to the driver module, and the Cmodel module is connected to the storage model through a front-door access path. The driver module is also used to send raw computation instructions to the Cmodel module. It should be noted that since the Cmodel module is also generated based on a software language, it can directly execute the raw computation instructions. The Cmodel module is used to generate target memory operation instructions based on the raw computation instructions, and sends the target memory operation instructions to the storage model through the front-door access path to execute the corresponding memory operations. It should be noted that the Cmodel verification phase precedes hardware-level verification. By setting up the Cmodel module, hardware test cases, software test cases, and system test cases can be verified within the Cmodel module, thereby enabling early detection of problems.

[0029] As one embodiment, the system further includes a Cmodel test case distribution module, a hardware test case distribution module, a software test case distribution module, a system test case distribution module, a third conversion interface, and an application development interface module. The third conversion interface is implemented based on both a software language and a hardware language, and the application development interface module is generated based on a software language. Specifically, the third conversion interface can be implemented using existing direct programming interfaces.

[0030] The Cmodel test case distribution module is used to distribute Cmodel test cases to the application development interface module. The Cmodel test case distribution module only runs when the Cmodel module is selected. It should be noted that Cmodel verification is the earliest verification stage. When performing cross-stage test case verification, the test cases of the later stages are usually verified in advance, that is, the verification is shifted to the left. Generally, it is not necessary to shift to the right. Therefore, the Cmodel test case distribution module usually only needs to run when the Cmodel verification branch is selected. The hardware test case distribution module is used to distribute hardware test cases to the third conversion interface; the third conversion interface is used to convert the hardware test cases into hardware test cases implemented in a software language and send them to the application development interface module; the software test case distribution module is used to distribute software test cases to the application development interface module; the system test case distribution module is used to distribute system test cases to the application development interface module. It should be noted that Cmodel engineers can use the Cmodel test case distribution module to write and generate Cmodel test cases according to the Cmodel test case writing rules for distribution; hardware engineers can use the hardware test case distribution module to write and generate hardware test cases according to the hardware test case writing rules for distribution; software engineers can use the software test case distribution module to write and generate software test cases according to the software test case writing rules for distribution; and system engineers can use the system test case distribution module to write and generate system test cases according to the system test case writing rules for distribution. That is, test cases at each stage can be verified in the Cmodel or RTL module based on the system without modification.

[0031] The application development interface module is used to parse the received test cases, obtain the calculation parameters and calculation logic, and send them to the driver module.

[0032] It should be noted that the system allows for the verification of test cases issued by different users, making the operations performed by the storage model highly complex. If problems arise later and debugging is required, it can be difficult to accurately and quickly pinpoint the problem. To address this issue, as one embodiment, the storage model includes a log recording unit. This unit generates corresponding backdoor access behavior records based on the backdoor access behavior corresponding to the storage model. These backdoor access behavior records include a user identifier and backdoor access behavior information, which may specifically include operation time and operation behavior. The log recording unit also generates corresponding frontdoor access behavior records based on the frontdoor access behavior corresponding to the storage model. These frontdoor access behavior records include a user identifier and frontdoor access behavior information, which may specifically include operation behavior and operation time. Finally, the log recording unit stores the backdoor access behavior records and the frontdoor access behavior records in chronological order of access time.

[0033] By configuring the log recording unit, when a problem occurs, the system can accurately and quickly locate the potential problem location for analysis. As one embodiment, the driver module is also used to generate a target access behavior record retrieval instruction based on the target debug point and send it to the storage model through a backdoor access path. The storage model is used to retrieve target behavior record information from the log recording unit based on the target access behavior record retrieval instruction and send it to the driver module through the backdoor access path.

[0034] As one embodiment, the storage model includes M simulated memory regions {A1, A2, ..., A...} m ,...A M}, A m Let m be the m-th simulated memory region, where m ranges from 1 to M, and M is the total number of simulated memory regions. The driver module is used to access the storage model through a backdoor access path to determine the memory allocation address of the operation parameters, including:

[0035] The driving module obtains the operation parameters {B1,B2,...,B n ,...,B N}, B n Let n be the nth operation parameter, and obtain the number C of simulated memory regions required for each operation parameter. n The driver module accesses the storage model through a backdoor access path, and simulates the usage of the simulated memory region for each B based on the simulated memory region. n Assign C n A simulated memory region is defined, and a memory mapping table is constructed in the storage model. A C++ implementation is then built within this mapping table. n A contiguous virtual memory region, and construct C in the mapping table.n A simulated memory region and C n The mapping relationship between two contiguous virtual memory regions. By setting up a mapping table between simulated memory regions and virtual memory regions, the efficiency of simulated memory allocation and memory utilization can be improved while ensuring that contiguous memory is allocated to operation parameters.

[0036] The system described in this invention can run based on software test cases and system test cases, enabling cross-stage early execution of software and system test cases based on RTL code, reducing chip verification costs and improving chip verification efficiency. Furthermore, the system of this invention sets up a software-implemented storage model and implements the frequently interacting memory allocation process directly based on the software language through a backdoor access path, reducing the frequent conversion between software and hardware languages ​​and improving the performance of the verification system.

[0037] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A verification system based on a software storage model, Its features are, It includes: a driver module, a first conversion interface, an RTL module, a second conversion interface, and a storage model. The driver module and the storage model are implemented based on a software language. The first and second conversion interfaces are implemented based on a software language and a hardware language. The RTL module is implemented based on a hardware language. The RTL module is used to store the RTL code of the chip under test design. The driver module is connected to a first conversion interface, the first conversion interface is connected to an RTL module, the RTL module is connected to a second conversion interface, the storage model includes a front door access path and a back door access path, the RTL module is connected to the storage model through the front door access path, and the driver module is connected to the storage model through the back door access path. The driving module is used to access the storage model through the backdoor access path, determine the memory allocation address of the operation parameters, generate a memory address allocation instruction, and send the memory address allocation instruction to the storage model through the backdoor access path. The storage model stores the corresponding operation parameters in the allocated memory address based on the received memory address allocation instruction; The driving module is also used to generate raw operation instructions based on the operation logic and send the raw operation instructions to the first conversion interface. The raw operation instructions are generated based on the software language, and the operation parameters and operation logic are generated based on test cases. The test cases include software test cases and system test cases. The first conversion interface is used to convert the original operation instructions into target operation instructions implemented based on the hardware language, and send the target operation instructions to the RTL module; The RTL module is used to generate raw memory operation instructions based on the target operation instructions, and send the raw memory operation instructions to the second conversion interface. The raw memory operation instructions are generated based on a hardware language. The second conversion interface is used to convert the original memory operation instructions into target memory operation instructions implemented in a software language; The second conversion interface sends the target memory operation instruction to the memory model through the front door access path to execute the corresponding memory operation.

2. The system according to claim 1, characterized in that, The system also includes a Cmodel module, which is generated based on a software language. The Cmodel module is a software simulation module for the design of the chip under test. Only one of the Cmodel module and the RTL module can be selected to run at the same time. The Cmodel module is connected to the driver module, and the Cmodel module is connected to the storage model through a front door access path; The driver module is also used to send the original calculation instructions to the Cmodel module; The Cmodel module is used to generate target memory operation instructions based on the original operation instructions, and send the target memory operation instructions to the memory model through the front door access path to execute the corresponding memory operation.

3. The system according to claim 2, characterized in that, The system also includes a Cmodel test case distribution module, a hardware test case distribution module, a software test case distribution module, a system test case distribution module, a third conversion interface, and an application development interface module. The third conversion interface is implemented based on software language and hardware language, and the application development interface module is generated based on software language. The Cmodel test case distribution module is used to distribute Cmodel test cases to the application development interface module. The Cmodel test case distribution module only runs when the Cmodel module is selected. The hardware test case distribution module is used to distribute hardware test cases to the third conversion interface; The third conversion interface is used to convert hardware test cases into hardware test cases implemented in software language and send them to the application development interface module. The software test case distribution module is used to distribute software test cases to the application development interface module; The system test case distribution module is used to distribute system test cases to the application development interface module; The application development interface module is used to parse the received test cases, obtain the calculation parameters and calculation logic, and send them to the driver module.

4. The system according to claim 1, characterized in that, The storage model includes a log recording unit; the log recording unit is used to generate corresponding backdoor access behavior records based on the backdoor access behavior corresponding to the storage model, the backdoor access behavior records including user identifiers and backdoor access behavior information; the log recording unit is also used to generate corresponding frontdoor access behavior records based on the frontdoor access behavior corresponding to the storage model, the frontdoor access behavior records including user identifiers and frontdoor access behavior information; the log recording unit is also used to store the backdoor access behavior records and the frontdoor access behavior records in the log recording unit in the order of access time.

5. The system according to claim 4, characterized in that, The driving module is also used to generate a target access behavior record acquisition instruction based on the target debugging point, and send it to the storage model through the backdoor access path; The storage model is used to obtain target behavior record information from the log recording unit based on the target access behavior record acquisition instruction, and send it to the driver module through the backdoor access path.

6. The system according to claim 1, characterized in that, The storage model includes M simulated memory intervals {A1, A2, ..., A...} m ,...A M }, A m Let m be the m-th simulated memory interval, where m ranges from 1 to M, and M is the total number of simulated memory intervals; The driver module is used to access the storage model through a backdoor access path to determine the memory allocation address of the operation parameters, including: The driving module obtains the operation parameters {B1,B2,...,B n ,...,B N }, B n Let n be the nth operation parameter, and obtain the number C of simulated memory regions required for each operation parameter. n The driver module accesses the storage model through a backdoor access path, and simulates the usage of the simulated memory region for each B based on the simulated memory region. n Assign C n A simulated memory region is defined, and a memory mapping table is constructed in the storage model. A C++ implementation is then built within this mapping table. n A contiguous virtual memory region, and construct C in the mapping table. n A simulated memory region and C n The mapping relationship between consecutive virtual memory regions.

7. The system according to claim 3, characterized in that, The first conversion interface, the second conversion interface, and the third conversion interface are all direct programming interfaces, which are used to implement the conversion between software languages ​​and hardware languages.

8. The system according to claim 1, characterized in that, The software languages ​​include C and C++, and the hardware languages ​​include Verilog and SystemVerilog.

Images