SRAM connectivity verification method, device, equipment and readable storage medium

Abstract

An SRAM connectivity verification method, device, equipment and readable storage medium. The method comprises: extracting valid information from a design document of a SoC and recording in a standardized intermediate file; before RTL simulation, detecting whether the standardized intermediate file is incorrect; if the standardized intermediate file is correct, generating a test case of each subsystem based on the standardized intermediate file for connectivity verification of SRAM in each subsystem. Through the present application, the correctness of the standardized intermediate file is ensured before RTL simulation, that is, the correctness of the design document is ensured, avoiding problems found after later simulation, leading to verification lag and increasing verification time; the test case is automatically generated based on the correct standardized intermediate file, reducing manual operation; in summary, the SRAM connectivity verification efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of chip technology, and in particular to an SRAM connectivity verification method, apparatus, device, and computer-readable storage medium. Background Art

[0002] SRAM (static random access memory) is a key component in SoC (System on Chip) design, responsible for storing temporary data and instructions. SRAM connectivity directly impacts chip performance and reliability. Flaws in the connection between SRAM and its control logic can lead to data corruption, system crashes, and even security vulnerabilities. Therefore, ensuring the correctness and integrity of SRAM connections is a crucial step in SoC design and verification. Existing SRAM connectivity verification suffers from the following issues:

[0003] 1. Relying on manual analysis of design documents and manual writing of test cases. When the SoC design documents are updated, the test cases still need to be manually updated, which makes it difficult to adapt to the rapid iteration of SoC design.

[0004] 2. The accuracy and completeness of design document information can usually only be verified after test case simulation, which results in problems being discovered only after late simulation, increasing rework costs and verification cycles. Summary of the Invention

[0005] To solve at least one of the above technical problems, the present application provides an SRAM connectivity verification method, apparatus, device, and computer-readable storage medium.

[0006] In a first aspect, an embodiment of the present application provides an SRAM connectivity verification method, the SRAM connectivity verification method comprising:

[0007] Extracting valid information from the design document of the system-on-chip (SoC) and recording the valid information in a standardized intermediate file, wherein the valid information includes type information of the SRAM in each subsystem on the SoC and hierarchical structure information of each SRAM on the entire SoC;

[0008] Before performing RTL simulation, checking whether the standardized intermediate file is correct;

[0009] If the standardized intermediate file is correct, generating a test case for each subsystem based on the standardized intermediate file;

[0010] Connectivity verification of the SRAM in each subsystem is performed based on the test cases for each subsystem.

[0011] In conjunction with the first aspect, in one embodiment, detecting whether the standardized intermediate file has errors includes:

[0012] Determine first information according to valid information recorded in the standardized intermediate file, wherein the first information includes the number of each type of SRAM in each hierarchical structure;

[0013] determining second information according to the design document, the second information including the number of each type of SRAM in each hierarchy;

[0014] If the first information is consistent with the second information, each piece of hierarchical structure information recorded in the standardized intermediate file is concatenated with the SoC top-level hierarchical information to obtain each new piece of hierarchical structure information;

[0015] Check whether each new hierarchical structure information exists in the RTL code;

[0016] If so, it is determined that the standardized intermediate file is correct.

[0017] In conjunction with the first aspect, in one embodiment, generating a test case for each subsystem based on the standardized intermediate file includes:

[0018] For each subsystem, the type information and hierarchical structure information of the SRAM in the subsystem are written into the test case template to obtain a test case for each subsystem.

[0019] In conjunction with the first aspect, in one embodiment, verifying connectivity of the SRAM in each subsystem based on the test case of each subsystem includes:

[0020] For each SRAM in the subsystem, write a random number into a register corresponding to the type information of the SRAM;

[0021] Reading data from the SRAM end according to the hierarchical structure information of the SRAM;

[0022] Detecting whether the read data is consistent with the random number;

[0023] If they are consistent, it is determined that the connectivity verification for the SRAM has passed;

[0024] If they are inconsistent, it is determined that the connectivity verification for the SRAM fails.

[0025] In conjunction with the first aspect, in one embodiment, after performing connectivity verification on the SRAM in each subsystem based on the test case of each subsystem, the method further includes:

[0026] When the connectivity verification for all SRAMs passes and the simulation coverage is 100%, it is determined that the SRAM connectivity function verification for the SoC passes.

[0027] In combination with the first aspect, in one embodiment, after determining that the SRAM connectivity function verification for the SoC passes, the method further includes:

[0028] Perform testability design for the SoC.

[0029] In combination with the first aspect, in one implementation, the standardized intermediate file is in txt format.

[0030] In a second aspect, an embodiment of the present application provides an SRAM connectivity verification device, the SRAM connectivity verification device comprising:

[0031] An extraction module is configured to extract valid information from the design document of the system-on-chip (SoC) and record the valid information in a standardized intermediate file. The valid information includes the type information of the SRAM in each subsystem on the SoC and the hierarchical structure information of each SRAM in the entire SoC.

[0032] A detection module, used to detect whether the standardized intermediate file has errors before performing RTL simulation;

[0033] A generating module, configured to generate a test case for each subsystem based on the standardized intermediate file if the standardized intermediate file is correct;

[0034] A verification module is used to verify the connectivity of the SRAM in each subsystem based on the test cases of each subsystem.

[0035] In a third aspect, an embodiment of the present application provides an SRAM connectivity verification device, which includes a processor, a memory, and an SRAM connectivity verification program stored on the memory and executable by the processor, wherein when the SRAM connectivity verification program is executed by the processor, the steps of the SRAM connectivity verification method described in the first aspect are implemented.

[0036] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which an SRAM connectivity verification program is stored, wherein when the SRAM connectivity verification program is executed by a processor, the steps of the SRAM connectivity verification method described in the first aspect are implemented.

[0037] The beneficial effects of the technical solutions provided in the embodiments of the present application include:

[0038] In an embodiment of the present application, valid information is extracted from the design document of the system-on-chip (SoC), and the valid information is recorded in a standardized intermediate file. The valid information includes the type information of the SRAM in each subsystem on the SoC and the hierarchical structure information of each SRAM on the entire SoC; before performing RTL simulation, the standardized intermediate file is checked for errors; if the standardized intermediate file is correct, a test case for each subsystem is generated based on the standardized intermediate file; and connectivity verification is performed on the SRAM in each subsystem based on the test case of each subsystem. Through the embodiment of the present application, the correctness of the standardized intermediate file is ensured before performing RTL simulation, that is, the correctness of the design document is ensured, avoiding problems discovered after the later simulation, resulting in verification delays and increased verification time; test cases are automatically generated based on correct standardized intermediate files, reducing manual operations; in general, the efficiency of SRAM connectivity verification is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 This is a flow chart of an embodiment of the SRAM connectivity verification method of the present application;

[0040] Figure 2 This is a flow chart of another embodiment of the SRAM connectivity verification method of the present application;

[0041] Figure 3 This is a functional module diagram of an embodiment of the SRAM connectivity verification device of the present application;

[0042] Figure 4 This is a schematic diagram of the hardware structure of the SRAM connectivity verification device involved in the embodiment of the present application. DETAILED DESCRIPTION

[0043] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0044] First, some technical terms in this application are explained to facilitate those skilled in the art to understand this application.

[0045] SRAM: Static Random-Access Memory. A type of semiconductor memory based on a flip-flop structure that retains data without refreshing and is commonly used in high-speed caching scenarios.

[0046] RTL: Register Transfer Level, which uses a hardware description language (such as Verilog or VHDL) to describe the behavior of a circuit, rather than its physical implementation. It is often used for functional simulation and verification.

[0047] DFT stands for Design for Testability. This improves test coverage and quality after chip manufacturing by inserting specific logic (such as scan chains and built-in self-test) into chip design.

[0048] SoC: system on chip.

[0049] CSV file: A file format whose contents consist of plain text separated by commas.

[0050] Subsystem: A complex system-on-chip (SoC) usually consists of multiple subsystems.

[0051] Hierarchy: Hierarchical structure, the hierarchical organizational relationship of modules in chip design.

[0052] Regarding SRAM connectivity verification, existing solutions have the following problems:

[0053] 1. Inefficiency of manual operation

[0054] Existing technical solutions rely heavily on manual operations during SRAM connectivity verification, including manual analysis of design documents, manual writing and updating of test cases, etc. This approach is not only time-consuming but also prone to human error, especially when dealing with complex and large SoC chips.

[0055] 2. Difficulty adapting to design iterations

[0056] With the rapid iteration of SoC designs, the existing manual test case creation and update methods are unable to adapt to design changes in a timely manner. This causes the verification process to frequently lag behind the design schedule, increasing the risk of project delays.

[0057] 3. Lack of pre-check mechanism

[0058] In existing technologies, the accuracy and completeness of design document information can only be obtained after simulation. The lack of a pre-check mechanism before RTL simulation means that potential design problems may only be discovered at a later stage, increasing rework costs and verification cycles.

[0059] 4. Lack of Automation

[0060] When calling a script with existing technology, it is usually necessary to execute it manually in the command line. This method lacks flexibility and makes it difficult to automate the entire process, which limits the improvement of verification efficiency.

[0061] 5. The existing technology does not verify the SRAM in the DFT test phase at the functional stage, resulting in high-cost rework and long verification cycle in the later stage.

[0062] 6. Low reusability: The scripts and templates in existing technical solutions are difficult to reuse. Different projects may require different scripts and templates, which increases the cost of development and maintenance.

[0063] Based on the above process, the embodiment of the present application provides a SRAM connectivity verification method. Figure 1 , Figure 1 This is a flow chart of an embodiment of the SRAM connectivity verification method of this application. Figure 1 As shown, the SRAM connectivity verification method includes:

[0064] 1. Input SoC design documents: for example, the SoC.csv file, which stores the type of SRAM in each subsystem of the entire SoC and the hierarchical structure of SRAM in the entire SoC;

[0065] 2. File parsing: Parse the SoC.csv file, extract valid information (such as signal name, hierarchical path, etc.), generate a standardized intermediate file output.txt, remove redundant information and format it for storage;

[0066] 3. Pre-check mechanism: Before RTL simulation, check whether the signal and hierarchy in the output.txt file are consistent with the current RTL, check whether all SRAM is covered without omission, and output error reports to ensure the completeness of the RTL design;

[0067] 4. Test case generation module: Generates test cases that verify all SRAM connectivity functions based on the output.txt file that has undergone the pre-check mechanism;

[0068] 5. Verification environment: Load the generated test cases into the existing simulation environment, perform automated simulation, inject test stimuli, and capture responses;

[0069] 6. Result Analysis and Reporting: The simulation outputs visual reports, waveform files, coverage information, and other information to confirm connectivity functionality. If correct, the entire SRAM connectivity verification for subsequent DFT verification is complete during the functional phase, mitigating DFT verification risks and reducing verification costs. If errors are detected, the visual report can be used to locate the problematic SRAM and its subsystem, and the waveform files can be used to identify the cause of the error.

[0070] like Figure 1 As shown, the processes within the dotted boxes are integrated into the existing verification environment, achieving full automation without the need to manually call scripts and other related commands in the command line.

[0071] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0072] In a first aspect, an embodiment of the present application provides an SRAM connectivity verification method.

[0073] In one embodiment, referring to Figure 2 , Figure 2 This is a flow chart of another embodiment of the SRAM connectivity verification method of this application. Figure 2 As shown, the SRAM connectivity verification method includes:

[0074] Step S10, extracting valid information from the design document of the system-on-chip (SoC) and recording the valid information in a standardized intermediate file, wherein the valid information includes type information of the SRAM in each subsystem on the SoC and hierarchical structure information of each SRAM in the entire SoC;

[0075] In this embodiment, the SoC design document takes the SoC.csv file as an example. In the SoC.csv file, the content of each line is separated by a comma, forming two parts. When extracting valid information, each line needs to be read line by line. The following information can be extracted:

[0076] Content after the comma:

[0077] The type information of SRAM is extracted. The type information involved here includes: dul / dcl / rel / srl / ssl / cul / drl / sul / dsl / dvd / crl / l1. The type information of SRAM extracted here is recorded in the standardized intermediate file output.txt. The prefix mem_ctrl_ is added when recording, such as mem_ctrl_dul, mem_ctrl_dcl, mem_ctrl_rel, etc.

[0078] Content before the comma:

[0079] Extract the subsystem of the SRAM in the SoC, such as ap_ss / ddr_ss, etc.

[0080] Extract the specific location of SRAM in the subsystem, that is, its hierarchical structure, for example: u_ap_ss.u_ap_istc_apb.u_istc_apb_ram.u_mem_0.

[0081] The format in which the extracted valid information is stored in the standardized intermediate file output.txt is similar to a "dictionary" format, that is, the first line stores the SRAM type information, followed by a line break, and each subsequent line stores the hierarchical structure of the same type of SRAM, and each line stores a hierarchical structure information. When the current type of SRAM hierarchy is completely retrieved and stored, the line breaks and the next SRAM type is stored, and so on.

[0082] Furthermore, in one embodiment, the standardized intermediate file is in txt format.

[0083] In this embodiment, the standardized intermediate file is plain text, and each line is not separated by commas. Subsequently, a Python script reads the file content to perform pre-checks, generate test cases, and other operations. Therefore, only built-in functions such as read() or readline() are required to process the file line by line. Therefore, using the txt format is the most common and simplest. Other formats, such as csv, are also acceptable.

[0084] Step S20, before performing RTL simulation, checking whether the standardized intermediate file has any errors;

[0085] In this embodiment, the standardized intermediate file, as described above, records valid information from the SoC design documentation. Checking for errors in the standardized intermediate file is actually checking for errors in the SoC design documentation. This is because the SoC.csv file provided by the designer is based on the published SoC RTL, which uses a hardware description language to describe circuit behavior. The SoC RTL is published first, and then, based on the specific circuit description in the SoC RTL, the SRAM and hierarchical structure information used by the entire SoC are extracted. However, this extraction process can include omissions or errors, meaning that the SoC.csv file is not completely accurate, necessitating a check.

[0086] As mentioned above, the SoC.csv file provided by the chip designer isn't always completely accurate. The hierarchical structure information in the provided SoC.csv file might not exist in the current SoC RTL version, or it might exist but contain errors in the middle of the hierarchy information. Preemptive checking can identify errors and provide direct feedback to the designer, allowing them to correct the SoC.csv file or update the SoC RTL. Without preemptive checking, whether the hierarchical structure information or SoC RTL is incorrect can only be determined after simulation is complete. Simulation is performed on the entire SoC, which is time-consuming. Therefore, discovering errors after simulation is complete reduces verification efficiency.

[0087] Furthermore, in one embodiment, the detecting whether the standardized intermediate file has errors includes:

[0088] Determine first information according to valid information recorded in the standardized intermediate file, wherein the first information includes the number of each type of SRAM in each hierarchical structure;

[0089] determining second information according to the design document, the second information including the number of each type of SRAM in each hierarchy;

[0090] If the first information is consistent with the second information, each piece of hierarchical structure information recorded in the standardized intermediate file is concatenated with the SoC top-level hierarchical information to obtain each new piece of hierarchical structure information;

[0091] Check whether each new hierarchical structure information exists in the RTL code;

[0092] If so, it is determined that the standardized intermediate file is correct.

[0093] In this embodiment, a python script is used for checking, as follows:

[0094] Parse the SoC.csv file and record the number of all hierarchical structure information for each type of SRAM, storing it in the corresponding array; parse output.txt and store the number of all hierarchical structure information for each type of SRAM in an array; compare the values ​​of the two arrays. If they are equal, confirm that the number of output.txt contents is correct, and then further check whether its content is correct. The inspection plan is as follows:

[0095] Each piece of hierarchical information in output.txt is concatenated with the top level of the SoC to obtain the hierarchical information of the SRAM in the SoC (i.e., the new hierarchical information). After processing all paths, all new hierarchical information is stored in a log file. Before RTL simulation, compilation is required (compilation time is relatively short). During compilation, each new piece of hierarchical information in the log is read and compared with the RTL code compiled at that time. If it cannot be found in the RTL code or is incorrect, it will be printed out and an error report will be generated. If there is an error, it needs to be fed back to the designer. If each piece of new hierarchical information can be found in the RTL code, that is, each piece of new hierarchical information exists in the RTL code, then the standardized intermediate file is confirmed to be correct.

[0096] Step S30: if the standardized intermediate file is correct, generating a test case for each subsystem based on the standardized intermediate file;

[0097] In this embodiment, a test case template is preset, and the type information of the SRAM in each subsystem and the hierarchical structure information of each SRAM in the entire SoC recorded in the standardized intermediate file are filled in it, thereby generating a test case for each subsystem.

[0098] Furthermore, in one embodiment, generating a test case for each subsystem based on the standardized intermediate file includes:

[0099] For each subsystem, the type information and hierarchical structure information of the SRAM in the subsystem are written into the test case template to obtain a test case for each subsystem.

[0100] In this embodiment, the test case generation process is completed using a Python script, as follows:

[0101] After the pre-check is completed, confirm that the content of output.txt is correct. In the target directory, create a folder for each subsystem to store the corresponding test cases, such as: pcie_mem, usb_mem;

[0102] Create multiple lists, such as mem_ctrl_crl_values[], to store all hierarchical structure information corresponding to SRAM:crl;

[0103] Read the output.txt file line by line and retrieve all the hierarchical structure information corresponding to each SRAM in each subsystem. For example, we retrieve SRAM:crl and subsystem pcie. The specific process is as follows:

[0104] a) Read line by line. When the line content is mem_ctrl_crl, the flag is true and the next line is processed. When the line content contains pcie, the current line is added to the mem_ctrl_crl_values[] list.

[0105] b) Then output each line of the list as a string format, wrap it, and enclose it in {}, and store it in result_crl, such as {"u_pcie_ss.u_pcie_top.u_sram.u_mem_0", "u_pcie_ss.u_pcie_top.u_smmu.u_mem0"}, and repeat this process until all SRAMs of all subsystems are retrieved;

[0106] c) In the created folder, such as pcie_mem, create a test case named test_sv_mem_reset_rand_pcie.sv and fill it with specific content. The test case framework for all subsystems is the same, but the SRAM hierarchy information for different subsystems is different (the test case framework is based on SystemVerilog syntax). Therefore, the entire test case framework is a predefined template, which is then filled with the required content. The result_crl obtained in the previous step is written to the array m_crl_path[$] defined in the test case. Then, m_crl_path is assigned to the two-dimensional array m_mem_name_path["mem_ctrl_crl"] defined in the test case. This will obtain the entire hierarchy of the SRAM:crl in the subsystem pcie.

[0107] By repeating this process, you can successfully create test cases for all subsystems.

[0108] Step S40 : performing connectivity verification on the SRAM in each subsystem based on the test case of each subsystem.

[0109] In this embodiment, for each subsystem, the corresponding test case is run to implement connectivity verification of the SRAM in each subsystem.

[0110] Furthermore, in one embodiment, step S40 includes:

[0111] For the SRAM in each subsystem, a random number is written to a register corresponding to the type information of the SRAM; data is read from the SRAM end according to the hierarchical structure information of the SRAM; whether the read data is consistent with the random number is detected; if they are consistent, it is determined that the connectivity verification for the SRAM has passed; if they are inconsistent, it is determined that the connectivity verification for the SRAM has failed.

[0112] In this embodiment, each type of SRAM will be controlled by a register. When the register is assigned a value, the corresponding value will be written into the SRAM. Then, data is read from the SRAM end according to the hierarchical structure information and compared with the pre-written number. If they are equal, the connectivity is correct.

[0113] In an embodiment of the present application, valid information is extracted from the design document of the system-on-chip (SoC), and the valid information is recorded in a standardized intermediate file. The valid information includes the type information of the SRAM in each subsystem on the SoC and the hierarchical structure information of each SRAM on the entire SoC; before performing RTL simulation, the standardized intermediate file is checked for errors; if the standardized intermediate file is correct, a test case for each subsystem is generated based on the standardized intermediate file; and connectivity verification is performed on the SRAM in each subsystem based on the test case of each subsystem. Through the embodiment of the present application, the correctness of the standardized intermediate file is ensured before performing RTL simulation, that is, the correctness of the design document is ensured, avoiding problems discovered after the later simulation, resulting in verification delays and increased verification time; test cases are automatically generated based on correct standardized intermediate files, reducing manual operations; in general, the efficiency of SRAM connectivity verification is improved.

[0114] Furthermore, in one embodiment, after step S40, the method further includes:

[0115] Step S50 : When the connectivity verification for all SRAMs passes and the simulation coverage is 100%, it is determined that the SRAM connectivity function verification for the SoC passes.

[0116] In this embodiment, each test case directory corresponds to a simulation log file. In the verification environment, the data read from the SRAM end is compared with the pre-configured data. If the comparison fails, an error will be reported and printed in the log file. The SRAM and its hierarchical structure will also be printed. Based on this information, the waveform file generated by the simulation is opened, and the SRAM signals and register signals of the corresponding hierarchical structure are pulled to check the cause of the problem. After all test cases are simulated, a coverage file on the SoC will be obtained. In this file, by checking the code coverage, it is confirmed whether the registers controlling each type of SRAM are configured. Then, through the hierarchy, the SRAM end is found to determine whether its internal signals are configured. If they are all configured, the code coverage will be displayed as 100%. If it is less than 100%, it can be checked which signal is not covered, and then analyzed to confirm whether the signal can be excluded or whether additional test cases are needed. Through this series of checks, the connectivity function is confirmed to be correct and the verification is completed.

[0117] Furthermore, in one embodiment, after step S50, the method further includes:

[0118] Perform testability design for the SoC.

[0119] In this embodiment, the testability design is performed after the SRAM connectivity function verification of the SoC is passed, thereby avoiding rework caused by SRAM connectivity defects in the testability design DFT test phase, thereby significantly shortening the verification cycle.

[0120] In a second aspect, an embodiment of the present application further provides an SRAM connectivity verification device.

[0121] In one embodiment, referring to Figure 3 , Figure 3 This is a functional module diagram of an embodiment of the SRAM connectivity verification device of this application. Figure 3 As shown, the SRAM connectivity verification device includes:

[0122] An extraction module 10 is configured to extract valid information from a design document of a system-on-chip (SoC) and record the valid information in a standardized intermediate file. The valid information includes type information of the SRAM in each subsystem on the SoC and hierarchical structure information of each SRAM in the entire SoC.

[0123] A detection module 20 is used to detect whether the standardized intermediate file has errors before performing RTL simulation;

[0124] A generating module 30 is configured to generate a test case for each subsystem based on the standardized intermediate file if the standardized intermediate file is correct;

[0125] The verification module 40 is configured to perform connectivity verification on the SRAM in each subsystem based on the test case of each subsystem.

[0126] Furthermore, in one embodiment, the detection module 20 is configured to:

[0127] Determine first information according to valid information recorded in the standardized intermediate file, wherein the first information includes the number of each type of SRAM in each hierarchical structure;

[0128] determining second information according to the design document, the second information including the number of each type of SRAM in each hierarchy;

[0129] If the first information is consistent with the second information, each piece of hierarchical structure information recorded in the standardized intermediate file is concatenated with the SoC top-level hierarchical information to obtain each new piece of hierarchical structure information;

[0130] Check whether each new hierarchical structure information exists in the RTL code;

[0131] If so, it is determined that the standardized intermediate file is correct.

[0132] Furthermore, in one embodiment, the generating module 30 is configured to:

[0133] For each subsystem, the type information and hierarchical structure information of the SRAM in the subsystem are written into the test case template to obtain a test case for each subsystem.

[0134] Furthermore, in one embodiment, the verification module 40 is configured to:

[0135] For each SRAM in the subsystem, write a random number into a register corresponding to the type information of the SRAM;

[0136] Reading data from the SRAM end according to the hierarchical structure information of the SRAM;

[0137] Detecting whether the read data is consistent with the random number;

[0138] If they are consistent, it is determined that the connectivity verification for the SRAM has passed;

[0139] If they are inconsistent, it is determined that the connectivity verification for the SRAM fails.

[0140] Furthermore, in one embodiment, the verification module 40 is further configured to:

[0141] When the connectivity verification for all SRAMs passes and the simulation coverage is 100%, it is determined that the SRAM connectivity function verification for the SoC passes.

[0142] Furthermore, in one embodiment, the SRAM connectivity verification apparatus further includes a design module for:

[0143] Perform testability design for the SoC.

[0144] Furthermore, in one embodiment, the standardized intermediate file is in txt format.

[0145] Among them, the functional implementation of each module in the above-mentioned SRAM connectivity verification device corresponds to each step in the above-mentioned SRAM connectivity verification method embodiment, and its functions and implementation processes are no longer repeated here.

[0146] In a third aspect, an embodiment of the present application provides an SRAM connectivity verification device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0147] Reference Figure 4 , Figure 4 FIG. 1 is a schematic diagram of the hardware structure of the SRAM connectivity verification device involved in the embodiment of the present application. In the embodiment of the present application, the SRAM connectivity verification device may include a processor, a memory, a communication interface, and a communication bus.

[0148] The communication bus may be of any type and is used to interconnect the processor, memory, and communication interface.

[0149] Communication interfaces include input / output (I / O), physical, and logical interfaces, which interconnect components within the SRAM connectivity verification device and connect the SRAM connectivity verification device to other devices (such as other computing devices or user devices). Physical interfaces can include Ethernet, fiber, or ATM interfaces; user devices can include displays and keyboards.

[0150] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0151] The processor may be a general-purpose processor that can call an SRAM connectivity verification program stored in a memory and execute the SRAM connectivity verification method provided in the embodiments of the present application. For example, the general-purpose processor may be a central processing unit (CPU). The method executed when the SRAM connectivity verification program is called may refer to the various embodiments of the SRAM connectivity verification method of the present application and will not be further described here.

[0152] Those skilled in the art will understand that Figure 4 The hardware structure shown in the figure does not constitute a limitation to the present application and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0153] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium.

[0154] The computer-readable storage medium of the present application stores an SRAM connectivity verification program, wherein when the SRAM connectivity verification program is executed by a processor, the steps of the above-mentioned SRAM connectivity verification method are implemented.

[0155] Among them, the method implemented when the SRAM connectivity verification program is executed can refer to the various embodiments of the SRAM connectivity verification method of the present application, and will not be repeated here.

[0156] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0157] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit the "first", "second" and "third" to different types.

[0158] In the description of the embodiments of this application, the words "exemplary," "for example," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary," "for example," or "for example" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0159] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0160] In some processes described in the embodiments of the present application, multiple operations or steps are included that appear in a specific order. However, it should be understood that these operations or steps may not be performed in the order in which they appear in the embodiments of the present application or may be performed in parallel. The sequence numbers of the operations are only used to distinguish between different operations, and the sequence numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations or steps may be performed in sequence or in parallel, and these operations or steps may be combined.

[0161] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, or the part that contributes to the existing technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above and includes a number of instructions for enabling a terminal device to execute the methods described in each embodiment of this application.

[0162] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A SRAM connectivity verification method, characterized in that: The SRAM connectivity verification method includes: Extracting valid information from the design document of the system-on-chip (SoC) and recording the valid information in a standardized intermediate file, wherein the valid information includes type information of the SRAM in each subsystem on the SoC and hierarchical structure information of each SRAM on the entire SoC; Before performing RTL simulation, checking whether the standardized intermediate file is correct; If the standardized intermediate file is correct, generating a test case for each subsystem based on the standardized intermediate file; Verify the connectivity of the SRAM in each subsystem based on the test cases of each subsystem; The detecting whether the standardized intermediate file is incorrect includes: Determine first information according to valid information recorded in the standardized intermediate file, wherein the first information includes the number of each type of SRAM in each hierarchical structure; determining second information according to the design document, the second information including the number of each type of SRAM in each hierarchy; If the first information is consistent with the second information, each piece of hierarchical structure information recorded in the standardized intermediate file is concatenated with the SoC top-level hierarchical information to obtain each new piece of hierarchical structure information; Check whether each new hierarchical structure information exists in the RTL code; If so, it is determined that the standardized intermediate file is correct.

2. The SRAM connectivity verification method according to claim 1, wherein: Generating a test case for each subsystem based on the standardized intermediate file includes: For each subsystem, the type information and hierarchical structure information of the SRAM in the subsystem are written into the test case template to obtain a test case for each subsystem.

3. The SRAM connectivity verification method according to claim 2, wherein: The connectivity verification of the SRAM in each subsystem based on the test case of each subsystem includes: For each SRAM in the subsystem, write a random number into a register corresponding to the type information of the SRAM; Reading data from the SRAM end according to the hierarchical structure information of the SRAM; Detecting whether the read data is consistent with the random number; If they are consistent, it is determined that the connectivity verification for the SRAM has passed; If they are inconsistent, it is determined that the connectivity verification for the SRAM fails.

4. The SRAM connectivity verification method according to claim 3, wherein: After verifying the connectivity of the SRAM in each subsystem based on the test case of each subsystem, the method further includes: When the connectivity verification for all SRAMs passes and the simulation coverage is 100%, it is determined that the SRAM connectivity function verification for the SoC passes.

5. The SRAM connectivity verification method according to claim 4, wherein: After determining that the SRAM connectivity function verification for the SoC passes, the method further includes: Perform testability design for the SoC.

6. The SRAM connectivity verification method according to claim 1, wherein: The standardized intermediate file is in txt format.

7. A SRAM connectivity verification device, characterized in that: The SRAM connectivity verification device comprises: An extraction module is configured to extract valid information from the design document of the system-on-chip (SoC) and record the valid information in a standardized intermediate file. The valid information includes the type information of the SRAM in each subsystem on the SoC and the hierarchical structure information of each SRAM in the entire SoC. A detection module is used to determine, before performing RTL simulation, first information based on valid information recorded in the standardized intermediate file, the first information including the number of each type of SRAM in each hierarchical structure; determine second information based on the design document, the second information including the number of each type of SRAM in each hierarchical structure; if the first information is consistent with the second information, then splice each hierarchical structure information recorded in the standardized intermediate file with the SoC top-level hierarchical information to obtain each new hierarchical structure information; detect whether each new hierarchical structure information exists in the RTL code; if so, determine that the standardized intermediate file is correct; A generating module, configured to generate a test case for each subsystem based on the standardized intermediate file if the standardized intermediate file is correct; A verification module is used to verify the connectivity of the SRAM in each subsystem based on the test cases of each subsystem.

8. An SRAM connectivity verification device, characterized in that: The SRAM connectivity verification device includes a processor, a memory, and an SRAM connectivity verification program stored in the memory and executable by the processor, wherein when the SRAM connectivity verification program is executed by the processor, the steps of the SRAM connectivity verification method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores an SRAM connectivity verification program, wherein when the SRAM connectivity verification program is executed by a processor, the steps of the SRAM connectivity verification method according to any one of claims 1 to 6 are implemented.

Images