Code checking method and device, equipment and storage medium

Abstract

The invention discloses a code checking method and device, equipment and a storage medium, and relates to the technical field of code development. According to the method, the random number suffixes are added to the serial numbers of the corresponding violation codes in the violation exemption statements in the low-level static exemption files corresponding to the low-level codes, and the file paths corresponding to the violation codes are replaced with the file paths of the high-level codes; the hierarchical structure of the module where the corresponding violation code is located is matched and updated on the basis of the high-level code hierarchical table, and then an updated low-level static exemption file is obtained; according to the method, each violation exemption statement in the updated low-level static exemption file can be effectively identified, cross-level multiplexing of the violation exemption statements is realized, repeated work caused by failure of the violation exemption statements during different-level check is avoided, human intervention is reduced, and the accuracy and efficiency of code check are improved.

Description

Technical Field

[0001] The present application relates to the field of code development technology, and in particular to a code checking method, apparatus, device, and storage medium. Background Art

[0002] During hardware development, code review is a crucial step in ensuring code quality. Static code review tools can automatically detect potential code issues, such as syntax errors. To improve the flexibility and efficiency of code review, exemption rules are often set to exempt specific code snippets or modules from certain code review items.

[0003] In complex hardware development projects, the code often has a multi-layered structure. Static checks are usually performed on the lower-level code first, reporting violation codes that do not comply with the static check rules. Because some violation codes are actually ignorable, it is necessary to manually filter out the ignorable violation codes and set corresponding exemptions. However, when static checks are subsequently performed on higher-level code, due to changes in the development environment, the exemption settings set during the lower-level checks become invalid, and the same violation codes will still be reported. The more layers there are, the more repeated violation codes will be reported, resulting in a large amount of duplication of work, wasted human resources, and reduced development efficiency. Summary of the Invention

[0004] The present application provides a code checking method, apparatus, device and storage medium to at least solve the problems of low efficiency and low accuracy when performing code checking.

[0005] The present application provides a code checking method, which includes:

[0006] Obtaining a high-level code hierarchy table, a file path of the high-level code, a preset target inspection level, and a low-level static exemption file corresponding to the low-level code; the low-level static exemption file includes multiple violation exemption statements; the violation exemption statement includes the number of the corresponding violation code, the file path of the corresponding violation code, and the hierarchical structure of the module where the corresponding violation code is located;

[0007] Add a random number suffix to the number of the corresponding violation code in each violation exemption statement;

[0008] Replace the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code;

[0009] According to the high-level code hierarchy table, the hierarchical structure of the module where the corresponding violation code in each violation exemption statement is located is matched and updated until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with the preset target inspection level;

[0010] Based on the updated violation exemption statement, an updated low-level static exemption file is obtained for use in statically checking the high-level code at a preset target inspection level.

[0011] The present application also provides a code checking device, comprising:

[0012] An acquisition module is used to obtain a high-level code hierarchy table, a file path of the high-level code, a preset target inspection level, and a low-level static exemption file corresponding to the low-level code; the low-level static exemption file includes multiple violation exemption statements; the violation exemption statement includes the number of the corresponding violation code, the file path of the corresponding violation code, and the hierarchical structure of the module where the corresponding violation code is located;

[0013] A number update module, used for adding a random number suffix to the number of the corresponding violation code in each violation exemption statement;

[0014] A path update module, used for replacing the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code;

[0015] A hierarchical structure updating module is used to match and update the hierarchical structure of the module where the corresponding violation code in each violation exemption statement is located according to the high-level code hierarchy table, until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with the preset target inspection level;

[0016] The static exemption file update module is used to obtain an updated low-level static exemption file based on the updated violation exemption statement, so as to be used for static inspection of the high-level code at a preset target inspection level.

[0017] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned code checking methods when executing the computer program.

[0018] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned code checking methods are implemented.

[0019] Through this application, by adding a random number suffix to the number of the corresponding violation code in each violation exemption statement in the low-level static exemption file corresponding to the low-level code, replacing the file path of the corresponding violation code with the file path of the high-level code, and matching and updating the hierarchical structure of the module where the corresponding violation code is located based on the high-level code hierarchy table, the updated violation exemption statements are obtained, and then the updated low-level static exemption file is obtained, so that when the high-level code is subsequently statically inspected at the preset target inspection level, the violation exemption statements in the updated low-level static exemption file can be effectively identified, and the cross-level reuse of the violation exemption statements is realized, avoiding repetitive work caused by the failure of the violation exemption statements when performing inspections at different levels, reducing human intervention, and improving the accuracy and efficiency of code inspection. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0021] Figure 1 A flowchart of a code checking method provided by an embodiment of the present invention;

[0022] Figure 2 A schematic flow chart of another code checking method provided by an embodiment of the present invention;

[0023] Figure 3 A schematic diagram of a high-level code hierarchy table provided in an embodiment of the present invention;

[0024] Figure 4 A schematic diagram of a process for updating the hierarchical structure of low-level code according to an embodiment of the present invention;

[0025] Figure 5 A schematic diagram of a code checking process in related art is shown;

[0026] Figure 6 A schematic diagram of a code checking process according to an embodiment of the present invention;

[0027] Figure 7 This is a structural block diagram of a code checking device according to an embodiment of the present application;

[0028] Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0030] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0031] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0032] Lint is a static code checking tool that analyzes code without running it, detecting possible syntax errors, potential logic problems, and statements that do not conform to coding standards. During the code development process, static checking helps to identify and resolve problems in advance, improving code quality.

[0033] During hardware development, code review is a crucial step in ensuring code quality. Static code review tools can automatically detect potential issues within the code. To improve the flexibility and efficiency of code review, static lint waivers are often used to exempt specific code snippets or modules from certain code review constraints.

[0034] In complex hardware development projects, the code often has a multi-layered structure, containing multiple levels of modules and sub-modules. Static checking is performed on the code from the bottom up, reporting violations that do not conform to static checking rules. Specifically, static checking tools are usually used to perform static checking on lower-level code first. For example, the spyglass tool or the vc_spyglass tool can be used. The spyglass tool follows the default static checking rules, while the vc_spyglass tool needs to follow the checking rules in the static checking rule file set by the user to check the written hardware code.

[0035] Since some violation codes are actually ignorable (or meet design requirements), it is necessary to manually filter out the ignorable violation codes and make corresponding exemption settings. There are two ways to generate static exemption files. First, you can set the exemption rules through the waive_lint statement before establishing the static inspection project. Second, after generating the static inspection project, the user opens the graphical processing interface and filters out the static inspection violation codes that are considered ignorable based on the reported static inspection rule violation results. Generate the corresponding static exemption file, read it in when re-establishing the static inspection project, and regenerate the static inspection report.

[0036] Based on the above approach, when statically checking code at each level, it is necessary to manually filter out violations deemed negligible, resulting in a lot of repetitive work. Furthermore, when statically checking code at higher levels, changes in the development environment can invalidate the exemptions set during lower-level checks, causing the same violation code to be reported again. The more levels there are, the more repeated violation codes are reported. For complex hardware development projects, this number can reach thousands or more, leading to a large amount of repetitive work, wasted human resources, and reduced code checking efficiency. Manual processing is also likely to result in omissions, affecting code checking accuracy.

[0037] It should be noted that higher-level code and lower-level code are relative concepts, and lower-level code may be reused multiple times in different modules of higher-level code. In this application, higher-level code and lower-level code are used to indicate code that has changed in the development environment and is in different hierarchical structures. Specifically, the process from writing to submitting code at a certain level is generally as follows: first, the person responsible for the development of the lower-level code writes the lower-level code locally in its code development environment (such as a computer device), and uses a static checking tool locally to perform a static check on the lower-level code to obtain various violation codes, and clean up the ignorable violation codes, perform violation exemption settings, generate violation exemption statements, and then output them as violation exemption files. Next, the lower-level code that has completed the static check is submitted to the public library (the code development environment has changed), and the higher-level code will call the lower-level code in the public library for integration (which may cause the hierarchical structure to change), and then perform a static check. Because the code inspection file has changed, the hierarchical structure of the integrated lower-level code may also change, causing the violation exemption statements in the original violation exemption file when inspecting the lower-level code to be unable to be correctly identified during the subsequent inspection of the higher-level code, and thus become invalid. In addition, when inspecting each preset target inspection level, the violation exemption statements in the lower-level static exemption file need to be updated according to the preset target inspection level, so that the violation exemption statements in the lower-level static exemption file can be correctly identified and reused during the inspection.

[0038] The embodiment of the present application provides a code checking method, which is applied to a high-level code development environment and can be executed by a computer device where the high-level code development environment is located. Figure 1 This is a flow chart of a code checking method provided by an embodiment of the present invention. Figure 1 As shown, the process includes the following steps.

[0039] The specific steps are as follows:

[0040] Step S101 , obtaining a high-level code hierarchy table, a high-level code file path, a preset target inspection level, and a low-level static exemption file corresponding to the low-level code.

[0041] The high-level code is the higher-level code whose development environment has changed, that is, the code to be checked that needs to be statically checked in the high-level code development environment. The high-level code hierarchy table is used to indicate the hierarchical structure of the high-level code. The file path of the high-level code is used to indicate the storage path where the high-level code is located. When performing a static check on the high-level code, the high-level code needs to be called through the file path of the high-level code. The preset target check level is used to indicate the target level for the static check of the high-level code.

[0042] The low-level static exemption file corresponding to the low-level code is the static exemption file obtained after statically checking the low-level code and setting violation exemptions in the low-level code development environment. This low-level static exemption file includes multiple violation exemption statements; each violation exemption statement includes the number of the corresponding violation code, the file path of the corresponding violation code, and the hierarchical structure of the module where the violation code is located.

[0043] After static checking of low-level code, each violation code will be assigned a number according to the static checking rule violated. For example, the 10 violation codes that violate static checking rule W162 are numbered as W162_1, W162_2, W162_3, ..., W162_10. If the developer believes that one of the violation codes, such as W162_3, is ignorable, then a violation exemption statement is added to W162_3, such as adding "-add<W162_3> Therefore, if the high-level code contains two low-level codes of the same level, and both of the low-level codes of the same level have violation codes that violate the static check rule W162 and have the same number, for example, both have W162_3 and both have added violation exemption statements, then when the high-level code is integrated and the violation exemption statements of the two low-level codes of the same level are read in, the "-add<W162_3> "Duplicate error. Therefore, it is necessary to improve the number of the corresponding violation code in the violation exemption statement, see step S102 for details.

[0044] Since the development environment has changed, the file path of the corresponding violation code in the violation exemption statement is invalid and cannot be identified in the high-level code inspection. Therefore, the file path of the corresponding violation code in the violation exemption statement needs to be improved, see step S103 for details.

[0045] Since low-level code may be reused multiple times in different modules of high-level code, the hierarchical structure of the low-level code in the high-level code may change, causing the hierarchical structure of the module where the corresponding violation code in the violation exemption statement is located to become invalid. Therefore, it is necessary to improve the hierarchical structure of the module where the corresponding violation code in the violation exemption statement is located, see step S104 for details.

[0046] Step S102: Add a random number suffix to the number of the corresponding violation code in each violation exemption statement.

[0047] Since the numbers of the corresponding violation codes in the violation exemption statements may be repeated, resulting in duplicate violation exemption statements, a random number suffix is ​​added to the numbers of the corresponding violation codes in each violation exemption statement. Each random number suffix is ​​different, so that the numbers of the corresponding violation codes in each violation exemption statement after adding the random number suffix are different to avoid duplication.

[0048] Step S103: replacing the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code.

[0049] After replacing the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code, when performing static inspection on the high-level code, the corresponding violation exemption can be read through the file path of the corresponding violation code in each violation exemption statement after replacement.

[0050] Step S104 , matching and updating the hierarchical structure of the module where the corresponding violation code in each violation exemption statement is located according to the high-level code hierarchy table, until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with the preset target inspection level.

[0051] The high-level code hierarchy table indicates the hierarchical structure of the high-level code, that is, the level at which the low-level code is located in the high-level code during integration, and thus the hierarchical structure of the module where the corresponding violation code is located in the violation exemption statement generated based on the low-level code can be obtained. When matching and updating, for each violation exemption statement, the highest level of the hierarchical structure of the module where the corresponding violation code is located is matched to its level in the high-level code, and then according to the preset target inspection level, the higher levels to which the module where the corresponding violation code is located are continuously searched and recorded in the hierarchical structure of the module where the corresponding violation code is located, until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with the preset target inspection level, and the updated hierarchical structure of the module where the corresponding violation code is located is obtained.

[0052] Step S105 : Based on the updated violation exemption statement, an updated low-level static exemption file is obtained for performing static inspection of a preset target inspection level on the high-level code.

[0053] After updating the number of the corresponding violation code in the violation exemption statement, the file path of the corresponding violation code in the violation exemption statement, and the hierarchical structure of the module where the corresponding violation code in the violation exemption statement is located, an updated low-level static exemption file can be obtained. When performing static inspection of high-level code, the updated low-level static exemption file can provide valid and identifiable violation exemption statements, realize cross-level reuse of low-level static exemption files by high-level code, and enable violation exemption statements in low-level static exemption files to be shared and reused in high-level code static inspection, reducing the workload of repeated searches and repeated violation exemption settings, and improving the accuracy and efficiency of code inspection.

[0054] The code checking method provided in this embodiment adds a random number suffix to the number of the corresponding violation code in each violation exemption statement in the low-level static exemption file corresponding to the low-level code, replaces the file path of the corresponding violation code with the file path of the high-level code, and matches and updates the hierarchical structure of the module where the corresponding violation code is located based on the high-level code hierarchy table, thereby obtaining updated violation exemption statements and then obtaining an updated low-level static exemption file, so that when the high-level code is subsequently statically checked at a preset target inspection level, the violation exemption statements in the updated low-level static exemption file can be effectively identified, thereby realizing cross-level reuse of violation exemption statements, avoiding repetitive work caused by the failure of violation exemption statements when performing inspections at different levels, reducing human intervention, and improving the accuracy and efficiency of code checking.

[0055] In this embodiment, a code checking method is provided. Figure 2 This is a flow chart of another code checking method provided by an embodiment of the present invention. Figure 2 As shown, the process includes the following steps.

[0056] The specific steps are as follows:

[0057] Step S201 , obtaining a high-level code hierarchy table, a file path of the high-level code, a preset target inspection level, and a low-level static exemption file corresponding to the low-level code.

[0058] Since the purpose of this application is to implement cross-level application of violation exemption statements of low-level code to high-level code, reducing the workload of repeated filtering and repeated violation exemption settings, this embodiment first introduces the general format of a static exemption file, as shown below (the content after # indicates a comment):

[0059] waive_violation#Main command, indicating that violation exemption settings are to be executed

[0060] -status{Waived}#Indicates that the violation has been filtered and the tool does not need to check

[0061] -add<rulename_number> #Add exemption (add mode), used to create a new exemption, requires a unique name, allows the use of comments, tags, ID, stage, category, severity and filter regular expressions

[0062] -tag <rulename>

[0063] -comment{<comment_string>}#Append a comment string to the exemption to describe the reason for the exemption. The comment option can only be used in add mode

[0064] -filter{#Filter option, when used in conjunction with the -regexp Boolean option, the filter option can be used to select specific data fields from the violation. The ID option is only valid in add or append mode

[0065] (Goal == "custom_lint") # indicates the target of the exemption statement

[0066] AND(Module=="<module_name> ")#Indicates the module where the violation code corresponding to the exemption statement is located

[0067] AND(FileName=="<file path> ")#Indicates the file path where the violation code corresponding to the exemption statement is located

[0068] AND(LineNumber=="<line number> ")#Indicates the line number of the violation code corresponding to the exemption statement

[0069] AND(Statement==" <code content>")#Indicates the violation code content corresponding to the exemption statement

[0070] AND<……>

[0071] AND(HIERARCHY==" <hierarchy>")#Indicates the hierarchical structure of the module where the violation code corresponding to the exemption statement is located

[0072] }

[0073] -msg{ <xxx>}'in assignment[Hierarchy:'hierarchy']}

[0074] -app{lint}

[0075] -tag{ <rulename>}#One or more static check rules to which the added exemption applies. The tag option is only valid in add or append mode

[0076] In addition, there are some less commonly used parameters, such as:

[0077] -append <name>#Append exemptions (append mode) is used to add additional selection conditions to existing exemptions. The name is required and must have been previously declared in the add mode. Labels, IDs, phases, categories, severity and filter regular expressions are allowed, but comment options are not allowed

[0078] -stage<stage / list_of_stages> #The phase or phases to which this exemption applies. The phase option is only valid in add or append mode

[0079] For the static exemption file format above, the following parameters will change accordingly after changing the static checking level:

[0080] (1)-add<rulename_number> After each static checking project (lint project) is established, each violation code will be assigned a unique number according to the static checking rule violated. For example, in the static checking project with modulea (module a) as the top-level file, the number of violations of static checking rule W162 reported in the inspection report is 10. The spyglass or vc_spyglass tool will mark the 10 violations as W162_1, W162_2, W162_3, ..., W162_10 respectively. If the user believes that a violation such as W162_3 reported meets the design requirements, the violation will be displayed as -add when it is filtered.<W162_3> Therefore, if a higher-level code contains two lower-level codes of the same level and both lower-level codes have W162_3 violations, when the higher-level code is integrated, if the violation exemption settings of the two lower levels are read, -add will be reported.<rulename_number> Repeated mistakes.

[0081] (2) Filename = "<file path> ", this parameter specifies the file path where the code to be checked is located.

[0082] (3)HIERARCHY==" <hierarchy>", because the hierarchical structure of the low-level code in the high-level code is different, for example, a certain violation code is in the lower level (the highest level name of the code top_name = modulea) HIERARCHY == " <hierarchy>"Displayed as:

[0083] HIERARCHY==":modulea:U_MODULEB@moduleb:U_MODULEC@modulec:U_MODULED@moduled"

[0084] At a higher level (the top level code name is top_name=modules), HIERARCHY==" <hierarchy>"Displayed as:

[0085] HIERARCHY=="modules:U_MODULES@modulea:U_MODULEB@moduleb:U_MODULEC@modulec:U_MODULED@moduled"(added level modules:U_MODULES@)

[0086] Therefore, in order to ensure that the violation exemption statements of low-level code can be correctly read and recognized and take effect during high-level code inspection, it is necessary to correctly process the above parameters to form violation exemption statements that meet the preset target inspection level and the corresponding static exemption files.

[0087] First, set the parameters for code inspection, that is, obtain the high-level code hierarchy table input by the user, the file path of the high-level code, the preset target inspection level, and the low-level static exemption file corresponding to the low-level code.

[0088] Optionally, when obtaining the high-level code hierarchy table, first obtain the high-level code, then filter out the highest-level module name in the high-level code and the instance name (Instance Name) and module name (Module Name) of each level except the highest level, that is, except for the highest level which only has the module name, other levels have corresponding instance names and module names. The module name is the name of the design template, similar to the concept of a class, and the instance name is the instance name when the module is actually used. Then, fill the highest-level module name in the high-level code and the instance name and module name of each level except the highest level into the high-level code hierarchy table to be filled, and obtain the high-level code hierarchy table. Among them, the column headers of the high-level code hierarchy table are used to indicate the highest-level module name and the instance name and module name of each level except the highest level in turn, and the same module name / instance name is only filled in once. The high-level code hierarchy table to be filled is the high-level code hierarchy table before filling. By setting up a high-level code hierarchy table, you can intuitively and clearly obtain the hierarchical structure of the high-level code, thereby improving the efficiency and accuracy of code checking.

[0089] Exemplarily, the high-level code hierarchy table is an Excel spreadsheet file, and the contents include:

[0090] The first line contains the level numbers:

[0091] 0: top-level module name;

[0092] 1_0: first level instance name;

[0093] 1_1: first-level module name;

[0094] 2_0: second level instance alias;

[0095] 2_1: second-level module name;

[0096] 3_0: third level instance alias;

[0097] 3_1: the name of the third-level module;

[0098] …

[0099] N_0: the Nth level instance alias;

[0100] N_1: Nth level module name;

[0101] Starting from the second line, fill in the module name and instance name of the corresponding level. To avoid complexity, if the next level under level N contains multiple levels N-1, level N only needs to be filled in once. Figure 3 A schematic diagram of a high-level code hierarchy table provided in an embodiment of the present invention, Figure 3 Taking the high-level code hierarchy table in Excel format as an example, the highest-level module is named<module0_name> , the rest will not be elaborated.

[0102] The low-level static exemption file includes a plurality of violation exemption statements; the violation exemption statement includes a number corresponding to the violation code, a file path corresponding to the violation code, and a hierarchical structure of a module where the violation code is located.

[0103] For example, the user inputs various parameters to the computer device, and the computer device parses and stores the parameters input by the user through the argparse module (a module for parsing command line parameters) for subsequent use. The sample code is as follows:

[0104] parser=argparse.ArgumentParser(description="this is a help info forlint_waive.py")#ArgumentParser creates an argument parser object. description is used to define the program's help information.

[0105] parser.add_argument("hierarchy_excel",help=":the path of hierachyexcel")#Parse the path of high-level code hierarchy table hierarchy_excel

[0106] parser.add_argument("target_level",help=":the level of target youwant match")#Parse preset target check level target_level

[0107] parser.add_argument("input_waive_tcl",help=":the path of input lintwaive tcl")#Parse the file path of the low-level static exemption file corresponding to the low-level code input_waive_tcl

[0108] parser.add_argument("output_waive_tcl",help=":the path of outputprocessed lint waive tcl")#Parse the output file path of the updated low-level static exemption file output_waive_tcl

[0109] parser.add_argument("rtl_path",help=":the path of self_designed codelike <xxx / xxx / xxx / <filename.v> ")#Parse the file path rtl_path of the high-level code to be checked

[0110] args = parser.parse_args() # parameter parsing and output, converting command line input into a namespace object

[0111] print(f"the path of hierachy excel:{args.hierarchy_excel}")#print means printing out the corresponding content

[0112] print(f"the level of target you want match:{args.target_level}")

[0113] print(f"the path of lint waive tcl:{args.input_waive_tcl}")

[0114] print(f"the name of processed lint waive tcl:{args.output_waive_tcl}")

[0115] print(f"the path of self_designed code:{args.rtl_path}")

[0116] Among them, the user needs to enter five parameters, namely the path hierarchy_excel of the high-level code hierarchy table, the preset target inspection level target_level, the file path input_waive_tcl of the low-level static exemption file corresponding to the low-level code, the output file path output_waive_tcl of the updated low-level static exemption file, and the file path rtl_path of the high-level code to be checked.

[0117] Optionally, check whether the directory for outputting the updated low-level static exemption files exists. If not, create the directory. Specifically, first obtain the file path of the low-level static exemption files input by the user, then extract the pure directory path from the file path of the low-level static exemption files, and then check whether the pure directory path exists in the high-level code development environment. If not, create a new file path for the low-level static files. The sample code is as follows:

[0118] import os#Standard statement for importing operating system interaction modules

[0119] output_dir = os.path.dirname (args.output_waive_tcl) # Strip the file name from the file path and extract the pure directory path

[0120] if not os.path.exists(output_dir):#If the pure directory path does not exist

[0121] os.makedirs(output_dir)#Recursively create multi-level directories

[0122] Step S202: Add a random number suffix to the number of the corresponding violation code in each violation exemption statement.

[0123] Specifically, for each violation code number in the violation exemption statement, a random number generation function is called to generate a random integer. This random integer is then converted to a string type to obtain a random string. This random string is then added as a suffix to the corresponding number to avoid errors caused by duplicate numbers. The sample code is as follows:

[0124] import random#Import random number module

[0125] def add_randnum():#Define random number generation function

[0126] return str(random.randint(1,1000000))#Generate an integer between 1 and 1000000 and convert it to a string type

[0127] Step S203: Replace the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code.

[0128] Specifically, first read the low-level static exemption file, then filter out the file path of the corresponding violation code in each violation exemption statement in the low-level static exemption file, and then replace the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code, and obtain the updated file path of the corresponding violation code in each violation exemption statement. The sample code is as follows:

[0129] def process_fname(line,rtl_path):#Define the process_fname(processfile name) function

[0130] if "FileName==\"" in line:#Filter the target line and only process the exemption statement containing FileName==\"

[0131] pattern=r'FileName==".*? <filenamex>'#.*? indicates non-greedy matching of any character (avoid matching to the end of the line)

[0132] processed_line = re.sub(pattern, f'FileName == "{rtl_path}', line) #rtl_path represents the base path of the new level, re.sub means retaining the original line format (such as indentation / comment) and only replacing the path part

[0133] return processed_line

[0134] return line

[0135] Step S204 , matching and updating the hierarchical structure of the module where the corresponding violation code in each violation exemption statement is located according to the high-level code hierarchy table, until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with the preset target inspection level.

[0136] Specifically, the above step S204 includes:

[0137] Step S2041 , obtaining the hierarchical structure of the module where the corresponding violation code in each violation exemption statement in the low-level static exemption file is located.

[0138] Obtained by reading the low-level static exemption file.

[0139] Step S2042: Search for the highest-level module name in the hierarchical structure of the module where the corresponding violation code is located.

[0140] In the violation exemption statement, filter out the highest-level module name in the hierarchy of the module where the corresponding violation code is located.

[0141] Step S2043, match the highest-level module name in the hierarchical structure of the module where the corresponding violation code is located with the high-level code hierarchy table to obtain the matching module name and matching level of the highest-level module name in the hierarchical structure of the module where the corresponding violation code is located in the high-level code hierarchy table.

[0142] By matching, the level (matching level) of the highest-level module name in the hierarchical structure of the module where the corresponding violation code is located in the high-level code and the corresponding module name (matching module name) are determined.

[0143] Step S2044: compare the matching level with the preset target inspection level to determine whether they are consistent.

[0144] If they are consistent, it means that the highest-level module name in the hierarchical structure of the module where the corresponding violation code is located is at the same level in the high-level code as the target level (preset target inspection level) targeted by this code check. In this case, there is no problem that the hierarchical structure of the violation code targeted by the violation exemption statement is different from its hierarchical structure in the high-level code. There is no need to modify the hierarchical structure of the module where the corresponding violation code is located in the violation exemption statement.

[0145] Step S2045: If there is any inconsistency, start with the matching module name, search to the left and upward in sequence until a non-empty cell is found, and record the module name / instance name in the non-empty cell in the hierarchical structure of the module where the corresponding violation code is located, until the matching level is consistent with the preset target inspection level, and obtain the updated hierarchical structure of the module where the corresponding violation code is located.

[0146] Specifically, the row number of the cell corresponding to the matching module name is used as the first coordinate starting point value, and the column number of the cell corresponding to the matching module name is used as the second coordinate starting point value; the second coordinate starting point value is subtracted by 1 to determine whether the corresponding cell is empty; if it is empty, the first coordinate starting point value is decremented by 1 in descending order to determine whether the corresponding cell is empty, until a non-empty cell is found, and the module name / instance name corresponding to the non-empty cell is recorded in the hierarchical structure of the module where the corresponding violation code is located; return to the step of subtracting 1 from the second coordinate starting point value, and repeat the step until the hierarchy of the module name corresponding to the non-empty cell found is consistent with the preset target inspection hierarchy, and the updated hierarchical structure of the module where the corresponding violation code is located is obtained.

[0147] Figure 4 A schematic diagram of a process for updating the hierarchical structure of low-level codes provided by an embodiment of the present invention is shown in FIG. Figure 4 As shown, first find the violation exemption setting statement in the low-level static exemption file (corresponding to Figure 4 The highest-level module name indicated by the original waive_violation setting in the code is matched with the high-level code hierarchy table. If the level corresponding to the highest-level module name in the high-level code hierarchy table is consistent with the preset target inspection level, the parameter HIERARCHY==" of the violation exemption setting statement is set. <hierarchy>"Remain unchanged. If inconsistent, search according to the high-level code hierarchy table. First, record the position of the highest-level module name in the high-level code hierarchy table as the origin Q (A0, B0), where A0 indicates the row number and B0 indicates the column number. Then perform the first search to check whether the Q1 (A0, B0-1) point to the left of Q point is a non-empty cell. If it is a non-empty cell, record the content of Q1 point and add it to the new hierarchy structure according to the format; if it is an empty cell, it means that there are multiple modules of the same level as the current level, then search upward for Q2 (A0-1 , B0-1) and determine whether it is non-empty. If it is not empty, record the content of Q2 and add it to the new hierarchical structure according to the format. If Q2 is an empty cell, continue to search upward to see if the Q3 (A0-2, B0-1) cell is empty, until a non-empty cell is found and the content is recorded to the new hierarchical structure, and the instantiation name corresponding to the module name indicated by the non-empty cell is added as a prefix. At this point, the first-level structure is supplemented forward on the original basis to obtain a new hierarchical structure. And so on, until the module name of the preset target inspection level is found, the updated hierarchical structure of the low-level code is obtained.

[0148] For example, the code for the function to find non-empty cells is as follows:

[0149]

[0150] The row function code to find non-empty cells is as follows:

[0151]

[0152] The following is an example of the function code for building a hierarchical path:

[0153] def build_hierarchy_path(sheet, keyword, start_col, start_row, target_level): #Generate a new path based on the comprehensive backtracking results. sheetexcel represents a worksheet used to read hierarchical configuration data. keyword represents a string used to indicate the module name in the original exemption file. start_col represents the column coordinates of the original module in the table. start_row represents the row coordinates of the original module in the table. target_level represents the preset target check level.

[0154] hiered_ln=[]#Storage hierarchical path fragment

[0155] current_col=start_col#Initialize the current column number to the starting column number, which is the starting point setting of the hierarchical path backtracking algorithm

[0156] current_row=start_row#Initialize the current row number to the starting row number

[0157] target_col=2*target_level+1# The mapping formula between column number and level. The instance name and module name occupy two columns.

[0158] while current_col>target_col:#Level backtracking loop, scanning the Excel column from right to left until reaching the target level

[0159] func_col=current_col-1#Move one column to the left

[0160] current_value=find_non_empty_cell(sheet,func_col,current_row) #find_non_empty_cell means getting the non-empty cell value (module name or instance name)

[0161] if current_value is not None:#path segment splicing

[0162] if func_col%2==0: #Judge whether func_col is an even number, % is the modulo operator

[0163] hiered_ln.insert(0,current_value+"@")#Even columns are given aliases with the suffix @

[0164] else:

[0165] hiered_ln.insert(0,current_value+":")#Odd-numbered columns are module names, with suffix:

[0166] current_col-=1#Decrement operator, indicating that the current column number is moved one column to the left

[0167] else:

[0168] break

[0169] hiered_ln.append(keyword)#Append the variable keyword to the end of the hierarchical path list hiered_ln to complete the last segment of the hierarchical path splicing

[0170] final_path = "".join(hiered_ln) #Seamlessly concatenate all string elements in the list hiered_ln into a complete hierarchical path string and assign it to the variable final_path

[0171] return f"HIERARCHY==\":{final_path}"#Format the concatenated hierarchical path final_path into the HIERARCHY syntax string required by EDA tools (such as SpyGlass, VC_Lint) through f-string, and output it as the function return value

[0172] Step S205 : Based on the updated violation exemption statement, an updated low-level static exemption file is obtained for performing static inspection of a preset target inspection level on the high-level code.

[0173] Optionally, write the updated violation exemption statements to the output file to obtain the updated low-level static exemption file. The code example is as follows:

[0174] hiered_lns.append(ln)#hiered_lns is a list that stores all processed rules. Append the currently processed single-line waive rule (ln) to the list hiered_lns

[0175] with open(args.output_waive_tcl,'w')as file:#Open the output file in write mode ('w'). The with statement ensures that the file is automatically closed after the operation. args.output_waive_tcl is the output file path specified by the user. 'w' means overwrite (if the file already exists, it will be cleared)

[0176] file.writelines(hiered_lns)#Write all the rules in the list hiered_lns to the file at once

[0177] As one or more specific application examples of the embodiments of the present invention, the optimal implementation scheme or the solution that the inventor most wants to embody is described below in combination with specific application scenarios.

[0178] This embodiment provides a code checking method, the steps are as follows:

[0179] Step 1: Configure layer parameters. Users enter parameters through the command line, which are parsed using the argparse module. These parameters include the path to an Excel layer configuration file (a high-level code layer table), the target layer number (preset target layer) of the target code to be checked (the high-level code to be checked), the path to a lint waive file (a static exemption file) with the waive_violation setting (violation exemption setting) at a lower level, the path to the processed lint waive file, and the path to the target code to be checked.

[0180] Step 2: Output directory check. Use the os.path.exists() and os.makedirs() functions to check whether the directory for outputting lint waive files exists, and create the directory if it does not exist.

[0181] Step 3: Read the input lint waive file. Open the lower-level lint waive file with the waive_violation setting and read its contents line by line.

[0182] Step 4: Process each waive_violation statement in the lint waive file, including:

[0183] (1)-add<rulename_number> For randomization, define a function and add random numbers in the parameter "-add<>" to avoid duplicate numbers that may cause errors when the tool runs the project.

[0184] (2) Filename = "<file path> "Processing, define a function to process the file path in the original waive_violation setting and replace it with the path of the target inspection code.

[0185] (3)HIERARCHY==" <hierarchy>Parameter processing: Find the original highest-level module name indicated by waive_violation in the original lint waive file and match it with the Excel hierarchy configuration file. Based on the matching results, use predefined functions to find non-empty cells, find rows with non-empty cells, and build a hierarchical path.

[0186] Step 5: Output the results. Write the contents of each processed waive_violation statement to the output file to generate the output_waive_tcl file.

[0187] Figure 5 The following is a schematic diagram of the code checking process in the related art. Figure 6 This is a schematic diagram of the code inspection process provided by an embodiment of the present invention. As can be seen, this embodiment, by reusing the lint waive settings of low-level code modules across multiple layers, avoids repeated violation filtering operations at different layers, reduces a large amount of repetitive work, and reduces manual intervention, thereby significantly improving the efficiency and accuracy of code inspection.

[0188] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0189] The embodiment of the present application also provides a code checking device, such as Figure 7 As shown, the code checking device includes an acquisition module 701, a number update module 702, a path update module 703, a hierarchical structure update module 704 and a static exemption file update module 705.

[0190] An acquisition module 701 is configured to acquire a high-level code hierarchy table, a file path of the high-level code, a preset target inspection level, and a low-level static exemption file corresponding to the low-level code; the low-level static exemption file includes multiple violation exemption statements; the violation exemption statement includes the number of the corresponding violation code, the file path of the corresponding violation code, and the hierarchical structure of the module where the corresponding violation code is located;

[0191] a number updating module 702, configured to add a random number suffix to the number of the corresponding violation code in each violation exemption statement;

[0192] A path updating module 703 is configured to replace the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code;

[0193] A hierarchical structure updating module 704 is configured to match and update the hierarchical structure of the module where the corresponding violation code is located in each violation exemption statement according to the high-level code hierarchy table, until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with a preset target inspection level;

[0194] The static exemption file updating module 705 is configured to obtain an updated low-level static exemption file based on the updated violation exemption statement, so as to be used for static checking of a preset target checking level on the high-level code.

[0195] For the description of the features in the embodiment corresponding to the code checking device, please refer to the relevant description of the embodiment corresponding to the code checking method, and no further details will be given here.

[0196] The embodiment of the present application also provides an electronic device, such as Figure 8 As shown, it includes a memory 10 and a processor 20, the memory 10 stores a computer program, and the processor 20 is configured to run the computer program to execute the steps in any of the above code checking method embodiments.

[0197] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned code checking method embodiments when running.

[0198] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0199] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above code checking method embodiments are implemented.

[0200] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned code checking method embodiments are implemented.

[0201] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0202] The code checking method, apparatus, device and storage medium provided by the present application are introduced in detail above. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the present application.< / hierarchy> < / hierarchy> < / filenamex> < / hierarchy> < / hierarchy> < / hierarchy> < / name> < / rulename> < / xxx> < / hierarchy> < / code> < / rulename>

Claims

1. A code checking method, characterized in that: The code checking method comprises: Obtaining a high-level code hierarchy table, a file path of the high-level code, a preset target inspection level, and a low-level static exemption file corresponding to the low-level code; the low-level static exemption file includes multiple violation exemption statements; the violation exemption statement includes the number of the corresponding violation code, the file path of the corresponding violation code, and the hierarchical structure of the module where the corresponding violation code is located; Add a random number suffix to the number of the corresponding violation code in each violation exemption statement; Replace the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code; According to the high-level code hierarchy table, the hierarchical structure of the module where the corresponding violation code in each violation exemption statement is located is matched and updated until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with the preset target inspection level; Based on the updated violation exemption statement, an updated low-level static exemption file is obtained for use in statically checking the high-level code at a preset target inspection level.

2. The code checking method according to claim 1, characterized in that: The obtaining of the high-level code level table includes: Get high-level code; Filter out the highest-level module name and the instantiation names and module names of each level except the highest level in the high-level code; Fill the highest-level module name and the instantiation names and module names of each level except the highest level in the high-level code into the high-level code hierarchy table to be filled in to obtain a high-level code hierarchy table; wherein, the column headers of the high-level code hierarchy table are used to indicate the highest-level module name and the instantiation names and module names of each level except the highest level in sequence; the same module name / instance name is only filled in once.

3. The code checking method according to claim 2, characterized in that: The step of matching and updating the hierarchical structure of the module where the corresponding violation code in each violation exemption statement is located according to the high-level code hierarchy table until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with the preset target inspection level includes: Obtaining the hierarchical structure of the module where the corresponding violation code in each violation exemption statement in the low-level static exemption file is located; Find the highest level module name in the hierarchical structure of the module where the corresponding violation code is located; Matching the highest-level module name in the hierarchical structure of the module where the corresponding violation code is located with the high-level code hierarchy table to obtain the matching module name and matching hierarchy of the highest-level module name in the hierarchical structure of the module where the corresponding violation code is located in the high-level code hierarchy table; Comparing the matching level with a preset target inspection level to determine whether they are consistent; If there is any inconsistency, take the matching module name as the starting point, search to the left and upward in sequence until a non-empty cell is found, and record the module name / instance name in the non-empty cell in the hierarchical structure of the module where the corresponding violation code is located, until the matching level is consistent with the preset target inspection level, and obtain the updated hierarchical structure of the module where the corresponding violation code is located.

4. The code checking method according to claim 3, characterized in that: Starting from the matching module name, search leftward and upward in sequence until a non-empty cell is found, and record the module name / instance name in the non-empty cell in the hierarchical structure of the module where the corresponding violation code is located, until the matching level is consistent with the preset target inspection level, including: The row number of the cell corresponding to the matching module name is used as the first coordinate starting point value, and the column number of the cell corresponding to the matching module name is used as the second coordinate starting point value; Subtract 1 from the second coordinate starting point value to determine whether the corresponding cell is empty; If it is empty, the first coordinate starting point value is decremented in sequence with 1 as the decrement value to determine whether the corresponding cell is empty, until a non-empty cell is found, and the module name / instance name corresponding to the non-empty cell is recorded in the hierarchical structure of the module where the corresponding violation code is located; Return to the step of subtracting 1 from the starting point value of the second coordinate, and repeat until the level of the module name corresponding to the non-empty cell found is consistent with the preset target inspection level, and obtain the updated hierarchical structure of the module where the corresponding violation code is located.

5. The code checking method according to any one of claims 1 to 4, characterized in that: The step of replacing the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code includes: Reading the low-level static exemption file; Filtering out the file path of the corresponding violation code in each violation exemption statement in the low-level static exemption file; The file path of the corresponding violation code in each violation exemption statement is replaced with the file path of the high-level code to obtain an updated file path of the corresponding violation code in each violation exemption statement.

6. The code checking method according to any one of claims 1 to 4, characterized in that: The method of adding a random number suffix to the number of the corresponding violation code in each violation exemption statement includes: For the number of the corresponding violation code in each violation exemption statement, call the random number generation function to generate a random integer; Convert the random integer into a string type to obtain a random string; The random string is added as a suffix to the corresponding number.

7. The code checking method according to any one of claims 1 to 4, characterized in that: The method further comprises: Get the file path of the low-level static exemption file entered by the user; Extracting a pure directory path from the file path of the low-level static exemption file; Check whether the pure directory path exists in the high-level code development environment; The file path where a new low-level static file will be created if it does not exist.

8. A code checking device, characterized in that: The code checking device comprises: An acquisition module is used to obtain a high-level code hierarchy table, a file path of the high-level code, a preset target inspection level, and a low-level static exemption file corresponding to the low-level code; the low-level static exemption file includes multiple violation exemption statements; the violation exemption statement includes the number of the corresponding violation code, the file path of the corresponding violation code, and the hierarchical structure of the module where the corresponding violation code is located; A number update module, used for adding a random number suffix to the number of the corresponding violation code in each violation exemption statement; A path update module, used for replacing the file path of the corresponding violation code in each violation exemption statement with the file path of the high-level code; A hierarchical structure updating module is used to match and update the hierarchical structure of the module where the corresponding violation code in each violation exemption statement is located according to the high-level code hierarchy table, until the highest level of the hierarchical structure of the module where the corresponding violation code is located is consistent with the preset target inspection level; The static exemption file update module is used to obtain an updated low-level static exemption file based on the updated violation exemption statement, so as to be used for static inspection of the high-level code at a preset target inspection level.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the code checking method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the code checking method according to any one of claims 1 to 7 are implemented.

Images