Verification system based on software storage model
By adopting a verification system based on software storage model in the chip verification system, the performance and efficiency problems caused by frequent conversion of software and hardware languages in the prior art are solved, and the effect of cross-stage early verification and cost reduction is achieved.
Patent Information
- Application Number
- CN202510280545.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-11
- Publication Date
- 2025-05-30
- Estimated Expiration
- 2045-03-11
AI Technical Summary
During the chip development process, when the prior art realizes verification based on RTL code, the storage model is implemented based on the hardware language, resulting in frequent conversion of software and hardware languages during the system-level verification and software-level verification stages, which reduces the performance and efficiency of verification system.
It provides a verification system based on software storage model, including driver module, conversion interface and storage model, implements driver module and storage model through software language, and converts hardware languages to reduce the frequent conversion process of software and hardware languages.
It realizes the cross-stage operation of software test cases and system test cases based on RTL code in advance, reducing chip verification costs, improving chip verification efficiency and system verification performance.
Smart Images

Figure CN120068746A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of chip technology, and in particular, to a verification system based on a software storage model. Background Art
[0002] In the process of chip development, different chip verification stages need to be experienced. Usually, hardware-level verification is first performed based on the chip RTL (Register Transfer Level) code. After hardware-level verification, a chip hardware accelerator or a physical chip will be obtained. Then, system-level verification is performed based on the hardware accelerator or the physical chip. After system-level verification passes, software-level verification is performed based on the accelerator or the physical chip. The hardware accelerator or the physical chip is a real entity. If problems are found again during the system-level verification stage and the software verification stage, a large amount of update cost will be consumed, reducing the chip development efficiency. If some system-level verification and / or software-level verification can be performed in advance based on the chip RTL code, and some problems existing in the RTL code are solved before the generation of the hardware accelerator or the physical chip, the chip development efficiency can be improved and the chip development cost can be reduced. In the process of implementing verification based on RTL code in the prior art, the storage model is implemented based on a hardware language. During the implementation of cross-stage verification, it is necessary to interact with the storage model frequently, which requires frequent conversion between software and hardware languages, reducing the performance of the verification system. It can be seen from this that how to reduce the chip verification cost, improve the chip verification efficiency and the performance of the verification system has become a technical problem to be solved urgently. Summary of the Invention
[0003] The purpose of the present invention is to provide a verification system based on a software storage model, which reduces the chip verification cost and improves the chip verification efficiency and the performance of the verification system.
[0004] The present invention provides a verification system based on a software storage model, including: 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 implemented based on a software language. The first conversion interface and the second conversion interface 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 design to be tested.
[0005] Wherein, the driving module is connected to the first conversion interface, the first conversion interface is connected to the RTL module, the RTL module is connected to the 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. The driving 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 an original operation instruction based on the operation logic and send the original operation instruction to the first conversion interface. The original operation instruction is generated based on a software language. The operation parameters and operation logic are generated based on test cases, and the test cases include software test cases and system test cases;
[0009] The first conversion interface is used to convert the original operation instruction into a target operation instruction implemented based on a hardware language and send the target operation instruction to the RTL module;
[0010] The RTL module is used to generate an original memory operation instruction based on the target operation instruction and send the original memory operation instruction to the second conversion interface. The original memory operation instruction is generated based on a hardware language;
[0011] The second conversion interface is used to convert the original memory operation instruction into a target memory operation instruction implemented based on a software language;
[0012] The second conversion module sends the target memory operation instruction to the storage model through the front door access path to perform the corresponding memory operation.
[0013] Compared with the prior art, the present invention has obvious advantages and beneficial effects. By means of the above technical solution, a verification system based on a software storage model provided by the present invention can achieve considerable technical progressiveness and practicality, and has wide industrial utilization value. It has at least the following beneficial effects:
[0014] The system of the present invention can run based on software test cases and system test cases, realizing the cross-stage early running of software test cases and system test cases based on RTL code, reducing the chip verification cost, and improving the chip verification efficiency. In addition, the system of the present invention sets up a storage model implemented by software, and directly implements the memory allocation process with frequent interactions based on a software language through the backdoor access path, reducing the frequent conversion process between software and hardware languages and improving the performance of the verification system. Description of the Drawings
[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.
[0016] Figure 1 Schematic diagram of the verification system based on the software storage model provided by the embodiment of the present invention. Specific embodiments
[0017] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.
[0018] The embodiment of the present invention provides a verification system based on a software storage model, as Figure 1 shown, including: 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, and the software language can specifically be C language, C++ language, etc. The first conversion interface and the second conversion interface are implemented based on a software language and a hardware language. The RTL module is implemented based on a hardware language. The RTL code for storing the design of the chip under test is stored in the RTL module. The hardware language corresponding to the RTL module can specifically be Verilog language, SystemVeriliog language, etc.
[0019] Among them, the driver module is connected to the first conversion interface, the first conversion interface is connected to the RTL module, the RTL module is connected to the 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. As an embodiment, the first conversion interface and the second conversion interface are implemented through an existing Direct Programming Interface (DPI for short). 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, based on DPI, the conversion between the software language and the SystemVerilog language can be realized, which will not be elaborated here.
[0020] 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. It should be noted that the operation parameters are generated based on test cases. Since the driving module can directly interact with software languages, the test cases include software test cases and system test cases, that is, the invented system can implement the operation of software test cases and system test cases on the RTL module, realizing the verification of cross-stage test cases, reducing the chip verification cost, and improving the 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 the memory allocation process, the driving module and the storage model need to interact frequently. In the embodiments of the present invention, both the driving module and the storage model are modules implemented based on software languages, and direct interaction can be achieved through the backdoor access path without the need for software-hardware language conversion. This greatly improves the efficiency of memory allocation and enhances the system performance.
[0021] Based on the received memory address allocation instruction, the storage model stores the corresponding operation parameters at the allocated memory address.
[0022] The driving module is further used to generate an original operation instruction based on the operation logic and send the original operation instruction to the first conversion interface. The original operation instruction is generated based on a software language, and the operation logic is generated based on test cases. The operation logic can be original operation logic and intermediate operation logic obtained based on the original operation logic.
[0023] The first conversion interface is used to convert the original operation instruction into a target operation instruction implemented based on a hardware language and send the target operation instruction to the RTL module.
[0024] The RTL module is used to generate an original memory operation instruction based on the target operation instruction and send the original memory operation instruction to the second conversion interface. The original memory operation instruction is generated based on a hardware language.
[0025] The second conversion interface is used to convert the original memory operation instruction into a target memory operation instruction implemented based on a software language.
[0026] The second conversion module sends the target memory operation instruction to the storage model through the front door access path to perform the corresponding memory operation.
[0027] Such as Figure 1In the shown example, the system further includes a Cmodel module, which is generated based on a software language. The Cmodel module is a software simulation module designed for the chip under test. At the same time, only one of the Cmodel module and the RTL module can be selected and 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 further configured to send the original operation instruction to the Cmodel module. It should be noted that since the Cmodel module is also generated based on a software language, the original operation instruction can be directly executed. The Cmodel module is configured to generate a target memory operation instruction based on the original operation instruction, and send the target memory operation instruction to the storage model through the front-door access path to perform the corresponding memory operation. It should be noted that the Cmodel verification stage is before the hardware-level verification. By setting the Cmodel module, the verification of hardware test cases, software test cases, and system test cases can be realized in the Cmodel module, so that problems can be discovered in advance.
[0029] As an 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 a software language and a hardware language, and the application development interface module is generated based on a software language. Among them, the third conversion interface can be specifically implemented through an existing direct programming interface.
[0030] The Cmodel use case distribution module is used to distribute Cmodel test cases to the application development interface module, and the Cmodel use 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, usually the test cases in the later stage are verified in advance, that is, the verification is shifted to the left. Generally, there is no need to shift to the right. Therefore, the Cmodel use case distribution module usually only needs to run when the Cmodel verification branch is selected. The hardware use 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 software language and send them to the application development interface module; the software use case distribution module is used to distribute software test cases to the application development interface module; the system use case distribution module is used to distribute system test cases to the application development interface module. It should be noted that Cmodel engineers can generate and distribute Cmodel test cases based on the Cmodel use case distribution module according to the writing rules of Cmodel test cases, hardware engineers can generate and distribute hardware test cases based on the hardware use case distribution module according to the writing rules of hardware test cases, software engineers can generate and distribute software test cases based on the software use case distribution module according to the writing rules of software test cases, and system engineers can generate and distribute system test cases based on the system use case distribution module according to the writing rules of system test cases. That is, the test cases in 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 operation parameters and operation logic, and send them to the driver module.
[0032] It should be noted that in the system, the verification of test cases distributed by different users can be realized. Therefore, the operations performed by the storage model are also very complex. If problems occur in the future and need to be debugged, it is very difficult to accurately and quickly locate the problem points. To solve this problem, as an embodiment, the storage model includes a log recording unit; the log unit is used to generate corresponding backdoor access behavior records based on the backdoor access behaviors corresponding to the storage model. The backdoor access behavior records include user identifiers and backdoor access behavior information. The backdoor access behavior information may specifically include operation time and operation behavior, etc. The log unit is also used to generate corresponding front door access behavior records based on the front door access behaviors corresponding to the storage model. The front door access behavior records include user identifiers and front door access behavior information. The front door access behavior information may specifically include operation behavior and operation time, etc. The log unit is also used to store the backdoor access behavior records and the front door access behavior records in the log recording unit in the order of access time.
[0033] When setting up the logging unit, when a problem occurs, it is possible to accurately and quickly locate the possible problem location for analysis. As an embodiment, the driving module is further configured to generate a target access behavior record acquisition instruction based on a target debugging point and send it to the storage module through a backdoor access path. The storage module is configured to obtain target behavior record information from the logging unit based on the target access behavior record acquisition instruction and send it to the driving module through the backdoor access path.
[0034] As an embodiment, the storage model includes M simulated memory intervals {A 1 , A 2 ,..., A m ,... A M}, where A m is the m-th simulated memory interval, the range of m is from 1 to M, and M is the total number of simulated memory intervals; the driving module is configured to access the storage model through the backdoor access path to determine the memory allocation address of the operation parameters, including:
[0035] The driving module obtains operation parameters {B 1 , B 2 ,..., B n ,..., B N}, where B n is the n-th operation parameter, and obtains the number C n of simulated memory intervals required for each operation parameter. The driving module accesses the storage model through the backdoor access path, and based on the usage status of the simulated memory intervals, allocates C n simulated memory intervals for each B n , constructs a memory mapping table in the storage model, constructs C n continuous virtual memory intervals in the mapping table, and constructs a mapping relationship between C n simulated memory intervals and C n continuous virtual memory intervals in the mapping table. By setting up the mapping table of the simulated memory intervals and the virtual memory intervals, it is possible to improve the simulated memory allocation efficiency and memory utilization rate on the basis of satisfying the allocation of continuous memory for the operation parameters.
[0036] The system according to the embodiments of the present invention can run based on software test cases and system test cases, realizing the cross-stage and early running of software test cases and system test cases based on RTL code, reducing the chip verification cost and improving the chip verification efficiency. In addition, the system of the present invention sets up a storage model implemented by software, and directly implements the memory allocation process with frequent interactions based on the software language through the backdoor access path, reducing the frequent conversion process between software and hardware languages and improving the performance of the verification system.
[0037] The above are only the preferred embodiments of the present invention, and do not impose any form of limitation on the present invention. Although the present invention has been disclosed above with the preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some changes or modifications to the equivalent embodiments with equivalent changes within the scope of the technical solution of the present invention. However, as long as the content does not depart from the technical solution of the present invention, any simple modification, equivalent change and modification made to the above embodiments based on the technical essence of the present invention still fall within the scope of the technical solution of the present invention.
Claims
1. A verification system based on software storage model, It is characterized in that It includes: a driver module, a first conversion interface, an RTL module, a second conversion interface and a storage model, wherein the driver module and the storage model are implemented based on a software language, the first conversion interface and the second conversion interface are implemented based on a software language and a hardware language, the RTL module is implemented based on a hardware language, and the RTL module is used to store the RTL code of the chip design to be tested; The driver module is connected to the first conversion interface, the first conversion interface is connected to the RTL module, the RTL module is connected to the 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 driver module is used to access the storage model through the backdoor access path, determine the memory allocation address of the operation parameter, 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 corresponding operation parameters in the allocated memory address based on the received memory address allocation instruction; The driving module is further used to generate original operation instructions based on operation logic, and send the original operation instructions to the first conversion interface, the original operation instructions are generated based on software language, the operation parameters and operation logic are generated based on test cases, and the test cases include software test cases and system test cases; The first conversion interface is used to convert the original operation instruction into a target operation instruction implemented based on the hardware language, and send the target operation instruction to the RTL module; The RTL module is used to generate an original memory operation instruction based on the target operation instruction, and send the original memory operation instruction to the second conversion interface, wherein the original memory operation instruction is generated based on the hardware language; The second conversion interface is used to convert the original memory operation instruction into a target memory operation instruction implemented based on a software language; The second conversion module sends the target memory operation instruction to the storage 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 and is a software simulation module designed for the chip to be tested. At the same time, only one of the Cmodel module and the RTL module can be selected to run; The Cmodel module is connected to the driving module, and the Cmodel module is connected to the storage model through a front door access path; The driving module is also used to send the original operation instruction to the Cmodel module; The Cmodel module is used to generate a target memory operation instruction based on the original operation instruction, and send the target memory operation instruction to the storage model through a front-door access path to execute a corresponding memory operation.
3. The system according to claim 2, characterized in that The system also includes a Cmodel use case sending module, a hardware use case sending module, a software use case sending module, a system use case sending 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 use case sending module is used to send Cmodel test cases to the application development interface module, and the Cmodel use case sending module only runs when the Cmodel module is enabled; The hardware test case sending module is used to send hardware test cases to the third conversion interface; The third conversion interface is used to convert the hardware test case into a hardware test case implemented in a software language and send it to the application development interface module; The software test case sending module is used to send software test cases to the application development interface module; The system test case sending module is used to send system test cases to the application development interface module; The application development interface module is used to parse the received test cases, obtain operation parameters and operation 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 unit is used to generate a corresponding backdoor access behavior record based on the backdoor access behavior corresponding to the storage model, and the backdoor access behavior record includes a user identifier and backdoor access behavior information; the log unit is also used to generate a corresponding frontdoor access behavior record based on the front door access behavior corresponding to the storage model, and the front door access behavior record includes a user identifier and front door access behavior information; the log unit is also used to store the backdoor access behavior record and the front door access behavior record in the log recording unit in order of access time.
5. The system according to claim 4, characterized in that The driver 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 module through the backdoor access path; The storage module 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 driving module through a 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 is the mth 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 parameter, including: The driving module obtains the operation parameters {B1, B2, ..., B n ,...,B N }, B n is the nth operation parameter, and obtains the number of simulated memory intervals C required for each operation parameter n The driver module accesses the storage model through the backdoor access path, and simulates the usage of the memory interval for each B based on the simulated memory interval. n Assign C n A simulated memory interval is constructed, and a memory mapping table is constructed in the storage model, and a C n A continuous virtual memory interval, and constructs C in the mapping table n Simulated memory area and C n The mapping relationship between continuous virtual memory intervals.
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, and the direct programming interfaces are used to realize the conversion between software language and hardware language.
8. The system according to claim 1, characterized in that The software languages include C language and C++ language, and the hardware languages include Veriliog language and SystemVeriliog language.
Citation Information
Patent Citations
Method for building automated co-verification platform on the basis of memory access driving
CN106528364A
Processor verification system based on RISC-V architecture
CN117422026A
Verification system, verification method, electronic device, and storage medium
CN117667655A
Simulation verification system based on DFI interface
CN119201756A
Hardware-software interaction testing using formal verification
US11544436B1