A test code generation method and device for a target programming language

Abstract

This application provides a method and apparatus for generating test code in a target programming language. The method includes: during the verification phase of chip design, converting first test code into second test code based on a preset conversion program; the first test code is obtained by encoding the operation sequence in the verification requirements using a custom programming language, and the preset conversion program includes keyword conversion rules between the custom programming language and the target programming language, the keyword conversion rules including at least one of function mapping rules, register access mapping rules, and variable access mapping rules; determining the syntax tree corresponding to the second test code; at least one node in the syntax tree corresponds to at least one syntax keyword included in the second test code; traversing the syntax tree to obtain third test code in the target programming language; the third test code conforms to the direct programming interface specification. Using the above method can improve the generation efficiency of test code in the target programming language.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a method and apparatus for generating test code for a target programming language. Background Technology

[0002] During the chip design phase, Design Verification (DV) is a core step in ensuring the correctness of chip functionality and the stability of its performance. DV verification aims to cover all expected behaviors of the chip design through simulation and testing, ensuring that it meets specifications. The DV verification process typically includes test case generation, functional checks, and coverage-driven procedures.

[0003] During the test case generation phase, most of the technical personnel in the DV verification team use System Verilog (SV language) to develop test cases. Then, they run the test cases developed based on SV language on the SV verification platform to obtain verification results. After that, they output programming documents based on the test cases and verification results and deliver them to the software development team.

[0004] However, SV is a hardware description language, while the languages ​​used by software development teams are software development languages, such as C and C++. Therefore, after obtaining the programming documents, the software development team cannot use them directly. They still need to develop relevant code based on the programming documents using the software development languages, which affects work efficiency. Summary of the Invention

[0005] This application provides a method and apparatus for generating test code for a target programming language, thereby improving the efficiency of generating test code for the target programming language.

[0006] Firstly, this application provides a method for generating test code for a target programming language, the method comprising: During the chip design verification phase, a first test code is converted into a second test code based on a preset conversion program. The first test code is obtained by encoding the operation sequence in the verification requirements using a custom programming language. The preset conversion program includes keyword conversion rules between the custom programming language and the target programming language. The keyword conversion rules include at least one of function mapping rules, register access mapping rules, and variable access mapping rules. Determine the syntax tree corresponding to the second test code; at least one node in the syntax tree corresponds to at least one syntax keyword included in the second test code; Traverse the syntax tree to obtain the third test code of the target programming language; the third test code conforms to the direct programming interface specification.

[0007] During the chip design verification phase, the operation sequences in the verification requirements are first encoded using a custom programming language to obtain the first test code. Since the preset conversion program pre-configures keyword conversion rules between the custom programming language and the target programming language (including function mapping, register access mapping, and variable access mapping rules), the first test code can be quickly and accurately converted into second test code similar to the target programming language. Then, the syntax tree corresponding to the second test code is determined, and further, the syntax tree is traversed to obtain the third test code in the target programming language. This improves the efficiency of generating test code in the target programming language. When the target programming language is a software development language, the DV verification team delivers the third test code in the target programming language to the software development team. The software development team can directly use the third test code or make minor adjustments to it without redeveloping the test code, improving the software development team's efficiency and reducing the delivery difficulty between the DV verification team and the software development team. Furthermore, since the third test code conforms to the direct programming interface specification, it can be directly called by the SV verification platform without affecting the normal DV verification process of the chip design.

[0008] In one possible design, the syntax rules corresponding to the custom programming language include at least one of the following: static parameter definition rules, dynamic variable declaration rules, register read / write rules, and function declaration and definition rules.

[0009] Custom programming languages ​​provide a series of syntax rules, including rules for defining static parameters and declaring dynamic variables. The first test code obtained by coding in a custom programming language is more suitable for being converted into the second test code by a preset conversion program, thereby improving conversion efficiency and accuracy.

[0010] In one possible design, after obtaining the third test code in the target programming language, the following is also included: The third test code is compiled to obtain a static library file corresponding to the third test code; the static library file is used to verify the chip design in conjunction with the associated verification code; wherein, the associated verification code is developed based on a hardware description language.

[0011] The associated verification code can be understood as the code included in the DV-related verification file. The code in the DV-related verification file is written in the SV language. After obtaining the third test code, the third test code is compiled to obtain the corresponding static library file. The static library file can be abbreviated as lib file. After importing the lib file corresponding to the third test code into the DV-related verification file, the third test code can be called to verify the operation sequence in the verification requirements.

[0012] In one possible design, determining the syntax tree corresponding to the second test code includes: The first syntax keyword in the second test code is used as the first-level node of the syntax tree; The second syntax keyword in the second test code is used as a child node of the first-level node; the first syntax keyword appears earlier than the second syntax keyword in the second test code.

[0013] In one possible design, the method further includes: If the first syntax keyword has a corresponding name, input parameter, and return type, then the name, input parameter, and return type are used as the node parameters corresponding to the first-level node.

[0014] In one possible design, the syntax tree is traversed to obtain third test code for the target programming language, including: Traverse the syntax tree to determine the level corresponding to each syntax keyword included in the syntax tree; Based on the levels corresponding to each of the syntax keywords, the third test code of the target programming language is determined.

[0015] Secondly, this application also provides a test code generation apparatus for a target programming language, the apparatus including a processing unit and a determining unit; The processing unit is used to convert first test code into second test code based on a preset conversion program during the verification phase of chip design; the first test code is obtained by encoding the operation sequence in the verification requirements using a custom programming language; the preset conversion program includes keyword conversion rules between the custom programming language and the target programming language; the keyword conversion rules include at least one of function mapping rules, register access mapping rules, and variable access mapping rules. The determining unit is used to determine the syntax tree corresponding to the second test code; at least one node in the syntax tree corresponds to at least one syntax keyword included in the second test code; The processing unit is further configured to traverse the syntax tree to obtain third test code for the target programming language; the third test code conforms to the direct programming interface specification.

[0016] In one possible design, the syntax rules corresponding to the custom programming language include at least one of the following: static parameter definition rules, dynamic variable declaration rules, register read / write rules, and function declaration and definition rules.

[0017] In one possible design, after obtaining the third test code in the target programming language, the processing unit is further configured to compile the third test code to obtain a static library file corresponding to the third test code; the static library file is used to verify the chip design in conjunction with the associated verification code; wherein the associated verification code is developed based on a hardware description language.

[0018] In one possible design, the determining unit, when determining the syntax tree corresponding to the second test code, is specifically used for: The first syntax keyword in the second test code is used as the first-level node of the syntax tree; The second syntax keyword in the second test code is used as a child node of the first-level node; the first syntax keyword appears earlier than the second syntax keyword in the second test code.

[0019] In one possible design, the determining unit is further configured to, if the first grammatical keyword has a corresponding name, input parameter, and return type, use the name, input parameter, and return type as node parameters corresponding to the first-level node.

[0020] In one possible design, when the processing unit traverses the syntax tree to obtain the third test code of the target programming language, it is specifically used for: Traverse the syntax tree to determine the level corresponding to each syntax keyword included in the syntax tree; Based on the levels corresponding to each of the syntax keywords, the third test code of the target programming language is determined.

[0021] Thirdly, this application also provides a computer device, the device comprising: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method described in the first aspect above.

[0022] Fourthly, this application also provides a computer-readable storage medium comprising a program that, when executed on a device, causes the device to perform the method as described in any one of the first aspects above.

[0023] Fifthly, this application also provides a computer program product, the computer program product comprising a computer program that, when executed by a processor, implements the method described in the first aspect above. Attached Figure Description

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

[0025] Figure 1 A schematic flowchart of a test code generation method for a target programming language provided in an embodiment of this application; Figure 2 A schematic diagram of the first test code provided for an embodiment of this application; Figure 3 A schematic diagram of the second test code provided in the embodiments of this application; Figure 4 Provided for the embodiments of this application Figure 3 The diagram shown illustrates the syntax tree determination process corresponding to the second test code. Figure 5 Provided for the embodiments of this application Figure 3 The syntax tree diagram corresponding to the second test code is shown below; Figure 6 A schematic diagram of the third test code provided in the embodiments of this application; Figure 7 This is a schematic diagram of the joint simulation of the third test code and the associated verification code provided in the embodiments of this application; Figure 8 Schematic diagram of the test code generation device for the target programming language provided in the embodiments of this application Figure 1 ; Figure 9 Schematic diagram of the test code generation device for the target programming language provided in the embodiments of this application Figure 2 ; Figure 10 This is a schematic diagram of the computer device structure provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] The application scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided in this application are also applicable to similar technical problems. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0028] As described in the background section, after obtaining the verification document, the software development team cannot directly use the test cases developed based on the SV language included in the verification document. The fundamental reason for this is that the SV language is a hardware description language, while the programming language used by the software development team is a software development language. There are many incompatibilities between hardware description languages ​​and software development languages, and the test cases developed using the SV language are poorly readable for the software development team members.

[0029] Specifically, hardware description languages ​​and software development languages ​​serve completely different goals in terms of syntax, data types, and semantic design. For example, the data types in hardware description languages ​​are oriented towards hardware signals and do not have the concept of "variables," while software development languages ​​are oriented towards data computation, and variables are values ​​in memory. The "for" keyword in hardware description languages ​​is used to generate multiple hardware instances, such as multiple registers, while the "for" keyword in software development languages ​​represents a loop and is mainly used to control the execution order of instructions. Furthermore, the runtime environments for code developed using hardware description languages ​​and code developed using software development languages ​​are also different. The execution of code developed using hardware description languages ​​refers to the operation of hardware circuits; it does not require a central processing unit (CPU) and can achieve functionality directly through changes in the voltage levels of the hardware circuits. In contrast, the execution of code developed using software development languages ​​must rely on the CPU's instruction set architecture.

[0030] If the programming language corresponding to the test code delivered by the DV verification group to the software development group is the same as the software development language used by the software development group, the delivery difficulty between the DV verification group and the software development group can be reduced, and the work efficiency of the software development group can be improved. To achieve this goal, this application proposes the following... Figure 1 The method described herein can be executed by a server used by technical personnel in the DV verification group, a chip within the server, or a functional module within the server; this application does not limit the specific implementation. The following explanation uses a server as the executing entity. Figure 1 The methods shown specifically include: Step 101: In the chip design verification stage, the first test code is converted into the second test code based on a preset conversion program; the first test code is obtained by encoding the operation sequence in the verification requirements using a custom programming language.

[0031] For example, the chip design verification in this application mainly refers to the chip's DV verification. Complete DV verification covers multiple dimensions such as function, timing, and interface, and combines various methods such as simulation, formal verification, and prototype verification to ensure the success rate of chip mass production.

[0032] DV verification specifically includes: (1) Functional correctness verification: Functional correctness verification can be further subdivided into basic function point verification, boundary condition verification, abnormal scenario verification, and reverse function verification. Among them, basic function point verification mainly involves verifying all independent function points defined in the design specifications one by one to ensure that the logical behavior of each functional module is consistent with the design specifications. Boundary condition verification is mainly to verify the chip's functional performance under extreme inputs or extreme parameters. Abnormal scenario verification is mainly to verify the chip's robustness under illegal inputs and erroneous operations to ensure that there will be no functional crashes, deadlocks, or data corruption. Reverse function verification is mainly to verify whether unsupported functions are correctly disabled to avoid compatibility issues caused by out-of-specification functions.

[0033] (2) Timing correctness verification: Timing correctness verification can be further subdivided into static timing analysis and dynamic timing simulation. Static timing analysis uses tools to analyze the delay of all paths inside the chip to verify whether the constraints of clock frequency, setup time, and hold time are met. Dynamic timing simulation mainly refers to verifying the timing performance of the chip at the target operating frequency in a simulation environment.

[0034] (3) Interface protocol verification: Interface protocol verification can be further subdivided into protocol compliance verification, interface compatibility verification, and multi-interface concurrency verification. Protocol compliance verification mainly verifies the standard interfaces of the chip in all scenarios to ensure compliance with protocol specifications. Interface compatibility verification mainly verifies the chip's ability to interact with different manufacturers. Multi-interface concurrency verification mainly verifies the functional correctness of multiple interfaces working simultaneously to avoid resource contention and data conflicts between interfaces.

[0035] Verification of the operation sequence in the verification requirements is part of the aforementioned functional correctness verification. The operation sequence, also known as the operation sequence, is a series of hardware operation instructions arranged in a fixed timing and logic to achieve a specific function. For example, the operation sequence corresponding to the addition instruction is usually: ① fetch, ② decode, ③ execute, ④ access memory, and ⑤ write back. The operation sequence corresponding to the erasure of flash memory in the chip is usually: ① configure the flash control register, enable erasure mode, and set the erase sector number; ② send the erase start command, wait for the erase completion flag to be set to 1, and confirm that the sector data has been cleared; ③ switch the flash memory to programming mode and configure the programming bit width; ④ write the program data to be stored to the target address; ⑤ read the programming completion flag to verify whether the data has been successfully written; and ⑥ configure the flash control register and disable programming mode to avoid accidental operation.

[0036] This application uses a custom programming language to encode the operation sequence in the verification requirements, thereby obtaining the first test code. The custom programming language can be called a DV primitive. The syntax rules corresponding to the custom programming language include at least one of the following: static parameter definition rules, dynamic variable declaration rules, register read / write rules, and function declaration and definition rules. Code encoded using a custom programming language is easy to convert to SV language code and also easy to convert to software development language code, such as C or C++ code. Common syntax rules of custom programming languages ​​are shown in Table 1.

[0037] Table 1

[0038] For example, part of the code in the first test code coded in a custom programming language, such as Figure 2 As shown. Figure 2The code shown defines a function named "polling_init_done". Within this function, four variables are declared: rd_val0, rd_val1, rd_val2, and rd_val3, all initialized to 0. Then, values ​​are assigned to these four variables using a DOWHILE function. Specifically, the value read from mmP2PI_PRO0_P2P_INIT_DONE is assigned to rd_val0, the value read from mmP2PI_PRO1_P2P_INIT_DONE is assigned to rd_val1, the value read from mmP2PI_PRO2_P2P_INIT_DONE is assigned to rd_val2, and the value read from mmP2PI_PRO3_P2P_INIT_DONE is assigned to rd_val3.

[0039] After obtaining the first test code, a preset conversion program can be used to convert the first test code into the second test code. The preset conversion program includes keyword conversion rules between the custom programming language and the target programming language. These keyword conversion rules include at least one of function mapping rules, register access mapping rules, and variable access mapping rules. For example, if the target programming language is C or C++, the preset conversion program includes at least one of function mapping rules, register access mapping rules, and variable access mapping rules between the custom programming language and C or C++.

[0040] The second test code obtained by the preset conversion program is more similar in style to the target programming language. For example, assuming the target programming language is C or C++, the first test code written in a custom programming language has a significantly different style from C and C++, and cannot be directly converted into C or C++ test code. Therefore, the preset conversion program is used to perform a conversion first to obtain a second test code with a style similar to C or C++. Then, a third test code in C or C++ is obtained based on the second test code to improve the accuracy of the third test code.

[0041] For example, for Figure 2 The first test code shown is converted using a preset conversion program. Figure 2 The second test code corresponding to the first test code shown is as follows: Figure 3 As shown, Figure 3 The second test code shown is compared to Figure 2 The first test code shown is closer to C or C++ in both variable declaration and register reading; for example, declaring a variable rd_val0 with an initial value of 0... Figure 2The corresponding syntax in the code is "VAR BIT32 rd_val0 0", while in... Figure 3 The corresponding syntax is "DECL<:unit32_t:><:rd_val0:><:0:>".

[0042] Furthermore, in the second test code, the delimitation of any set of child nodes begins with "BLOCK" and ends with "ENDBLOK", such as... Figure 3 The code range of the child node set is shown in the box. In this embodiment, child nodes and child-level nodes can be interchanged.

[0043] Step 102: Determine the syntax tree corresponding to the second test code; at least one node in the syntax tree corresponds to at least one syntax keyword included in the second test code.

[0044] After obtaining the second test code, to improve the efficiency and accuracy of obtaining the third test code in the target programming language, the syntax tree corresponding to the second test code is first determined. Specifically, the first syntax keyword in the second test code is taken as the first-level node of the syntax tree, and the second syntax keyword in the second test code is taken as the child node of the first-level node; wherein, the first syntax keyword appears earlier than the second syntax keyword in the second test code. It should be noted that if the first syntax keyword has a corresponding name, input parameters, and return type, then the name, input parameters, and return type are taken as the node parameters corresponding to the first-level node.

[0045] by Figure 3 Taking the second test code shown as an example, Figure 3 In the second test code shown, the first syntax keyword that appears is FUNC. Therefore, FUNC is the first syntax keyword. FUNC can be regarded as the first-level node in the syntax tree. FUNC has a corresponding name, input parameters and return type. The name is "polling_init_done", the input parameter is "[]" and the return type is "void". Then "polling_init_done", "[]" and "void" are the node parameters corresponding to the first-level node FUNC.

[0046] Next, the code following FUNC is traversed to determine if FUNC has child nodes. After traversal, it is confirmed that there are four DECL syntax keywords and one DO WHILE syntax keyword after FUNC. Therefore, the four DECL syntax keywords and the DO WHILE syntax keyword are the second syntax keywords. In the syntax tree, the four DECL syntax keywords and the DO WHILE syntax keyword are the child nodes of the first-level node FUNC, and can be called the second-level nodes DECL1, DECL2, DECL3, DECL4, and DO WHILE.

[0047] in, Figure 3 The first DECL in the table is used to declare a variable of type unit32_t, named rd_val0, and initialized to 0. The variable's type, name, and initial value can be used as node parameters for the second-level node DECL1. Similarly, Figure 3 The second DECL in the code is used to declare a variable of type unit32_t, named rd_val1, and initialized to 0. The variable's type, name, and initial value are used as the node parameters for the second-level node DECL2... Figure 3 The fourth DECL in the code is used to declare a variable of type unit32_t, named rd_val3, and initialized to 0. The variable's type, name, and initial value are passed as node parameters to the second-level node DECL4; and... Figure 3 The DO WHILE syntax keyword in the code contains a conditional statement, namely !(rd_val0&&rd_val1&&rd_val2&&rd_val3), which serves as the node parameter corresponding to the second-level node DO WHILE.

[0048] Continuing to traverse the remaining code, it was confirmed that the DO WHILE syntax keyword is nested within code. This code contains the FuncCall syntax keyword and four ASSIGN syntax keywords. The FuncCall and ASSIGN syntax keywords are... Figure 3 In the code shown, all the syntax keywords appear after the DO WHILE keyword. Therefore, the FuncCall syntax keyword and the four ASSIGN syntax keywords can be called third syntax keywords. In the syntax tree, the FuncCall syntax keyword and the four ASSIGN syntax keywords are child nodes of the second-level node DO WHILE, and can be called third-level nodes FuncCall, ASSIGN1, ASSIGN2, ASSIGN3, and ASSIGN4.

[0049] Among them, FuncCall is used to call a function named delay_us, and the parameter passed to delay_us is 1. The function name and the parameter can be used as the node parameters corresponding to the third-level node FuncCall; ASSIGN is used to assign values ​​to variables, for example, Figure 3 The first ASSIGN in the code is used to assign a value to the previously declared variable rd_val0. The assigned value is FuncCall<:read_reg:><:mmP2PI_PRO0_P2P_INIT_DONE:>. The ASSIGN operator (=), the assignment object (rd_val0), and the assignment value (FuncCall<:read_reg:><:mmP2PI_PRO0_P2P_INIT_DONE:>) can be used as the node parameter corresponding to the third-level node ASSIGN1... Figure 3 The fourth ASSIGN in the code is used to assign a value to the previously declared variable rd_val3. The assigned value is FuncCall<:read_reg:><:mmP2PI_PRO3_P2P_INIT_DONE:>. The ASSIGN operator (=), the assignment object (rd_val0), and the assignment content (FuncCall<:read_reg:><:mmP2PI_PRO3_P2P_INIT_DONE:>) can be used as the node parameter corresponding to the third-level node ASSIGN4.

[0050] At this point, Figure 3 The second test code shown has completed its iteration. Figure 3 The complete process of determining the syntax tree corresponding to the second test code shown is as follows: Figure 4 As shown, via Figure 4 After the process shown is completed, Figure 3 The syntax tree corresponding to the second test code shown is as follows: Figure 5 As shown, Figure 5 Each node in the syntax tree shown has corresponding node parameters. Figure 5 Not shown in the image.

[0051] Based on the syntax tree corresponding to the second test code, the level of the nodes corresponding to the syntax keywords included in the second test code within the syntax tree can be determined, such as... Figure 5 As shown, the first grammatical keyword FUNC corresponds to Figure 5 The first-level node FUNC in the syntax is level 1; the second syntax keyword DECL is... Figure 5 The numbers in the text correspond to the second-level nodes DECL1~DECL4 and the second syntax keyword DO WHILE, respectively. Figure 5The corresponding second-level node DO WHILE, the second-level nodes DECL1~DECL4, and the level of the second-level node DO WHILE are 2; the third syntax keyword FuncCall is in Figure 5 The corresponding third-level node is FuncCall, and the third syntax keyword is ASSIGN. Figure 5 The corresponding third-level nodes ASSIGN1~ASSIGN4, the third-level node FuncCall, and the level of the third-level nodes ASSIGN1~ASSIGN4 is 3.

[0052] Step 103: Traverse the syntax tree to obtain the third test code for the target programming language; the third test code conforms to the direct programming interface specification.

[0053] After obtaining the syntax tree corresponding to the second test code, the syntax tree is traversed starting from the root node to determine the level corresponding to each syntax keyword included in the syntax tree; based on the level corresponding to each syntax keyword, the third test code of the target programming language can be determined.

[0054] For example, assuming the target programming language is C or C++, traversal Figure 5 The syntax tree shown, when traversing to the first-level node FUNC, retrieves the node parameters corresponding to FUNC, including its name, input parameters, and return type. Therefore, a function is defined in C or C++ according to the node parameters corresponding to the first-level node FUNC, such as... Figure 6 The code is shown in lines 1, 2, and 16.

[0055] After traversing the first-level nodes, the next step is to traverse the child nodes of the first-level nodes. Figure 5 In the context of second-level nodes, assuming the first second-level node encountered is DECL1, we obtain the node parameters corresponding to DECL1, including its type, name, and initial value. Therefore, we use C or C++ to declare a variable based on the node parameters corresponding to DECL1, such as... Figure 6 As shown in line 3 of the code, the processing procedure for second-level nodes DECL2~DECL4 is similar to that for second-level node DECL1, and will not be repeated here. The code written based on second-level nodes DECL2~DECL4 is as follows: Figure 6 The code in lines 4-6 is shown. The second-level node still has a DO WHILE statement left unprocessed. To retrieve the node parameters corresponding to the second-level node DO WHILE, including the conditional statements, a DO WHILE statement is written in C or C++ according to the node parameters corresponding to the second-level node DO WHILE, as shown below. Figure 6The code is shown in lines 7, 8, 14, and 15.

[0056] After traversing the second-level nodes, the next step is to traverse the child nodes of the second-level nodes. Figure 5 In the context of third-level nodes, assuming the first third-level node encountered is FuncCall, the node parameters corresponding to this third-level node are retrieved, including the function name and its arguments. Therefore, a function call statement is written in C or C++ based on the node parameters corresponding to the third-level node FuncCall, as follows: Figure 6 As shown in line 9 of the code; continue traversing the remaining third-level nodes. Assuming the third-level node encountered is ASSIGN1, obtain the node parameters corresponding to ASSIGN1, including the operator, the assignment object, and the assignment value. Therefore, a variable assignment statement is written in C or C++ according to the node parameters corresponding to ASSIGN1, as follows: Figure 6 As shown in line 10 of the code, the processing procedure for the third-level nodes ASSIGN2~ASSIGN4 is similar to that for the third-level node ASSIGN1, and will not be repeated here. The code written based on the third-level nodes ASSIGN2~ASSIGN4 is as follows: Figure 6 The code is shown in lines 11 to 13.

[0057] In addition to determining the third test code by traversing the nodes of the syntax tree and obtaining the corresponding node parameters after obtaining the second test code, mature conversion or parsing tools can be used to convert the syntax tree corresponding to the second test code into the third test code. For example, if the target programming language is C or C++, tools such as Clang and ANTLR can be used to determine the third test code for C or C++ based on the syntax tree corresponding to the second test code, thereby improving the efficiency of determining the third test code.

[0058] It should be noted that the third test code conforms to the Direct Programming Interface specification. The full name of the Direct Programming Interface is DPI. DPI is a cross-language interactive interface defined by the SystemVerilog standard. Its core function is to enable bidirectional calls between SystemVerilog and C or C++ languages. It is a key technology in chip DV verification that connects hardware simulation and software logic.

[0059] like Figure 7As shown, after obtaining the third test code, the third test code is compiled to obtain the corresponding static library file. The static library file can be abbreviated as lib file. The lib file is used to verify the chip design in conjunction with the associated verification code. The associated verification code can be understood as the code included in the DV related verification file. The code included in the DV related verification file is written in SV language.

[0060] When the lib file is used in conjunction with DV-related verification files to verify the chip design, it needs to be imported into the DV-related verification files. Since the lib file includes third-party test code, after importing the lib file into the DV-related verification files, the third-party test code can be called to perform co-simulation, obtain simulation results, and thus complete the verification of the operation sequence in the verification requirements.

[0061] The method for generating test code in the target programming language provided in this application innovatively proposes a custom programming language. After encoding the operation sequence in the verification requirements using the custom programming language to obtain the first test code, it is converted into a third test code in C or C++. After the third test code is delivered to the software development team, the team members can use it directly, improving work efficiency. Moreover, the third test code conforms to the DPI specification, and the DV verification team members can import and call it through DV-related verification files to perform co-simulation without affecting the normal DV verification process of chip design.

[0062] Figure 8 and Figure 9 This is a schematic diagram illustrating the structure of a possible test code generation apparatus for a target programming language provided in the embodiments of this application. These test code generation apparatuses for target programming languages ​​can be used to implement the server functionality described in the method embodiments above, and therefore can also achieve the beneficial effects of the method embodiments described above.

[0063] like Figure 8 As shown, the target programming language test code generation apparatus 800 includes a processing unit 810 and a determining unit 820. The target programming language test code generation apparatus 800 is used to implement the above... Figure 1 The server functionality is illustrated in the method embodiment shown.

[0064] When the test code generation device 800 of the target programming language is used to implement Figure 1 The server function in the method embodiment shown is as follows: The processing unit 810 is used to convert the first test code into the second test code based on a preset conversion program during the verification stage of chip design. The first test code is obtained by encoding the operation sequence in the verification requirements using a custom programming language. The preset conversion program includes keyword conversion rules between the custom programming language and the target programming language. The keyword conversion rules include at least one of function mapping rules, register access mapping rules, and variable access mapping rules. The determining unit 820 is used to determine the syntax tree corresponding to the second test code; at least one node in the syntax tree corresponds to at least one syntax keyword included in the second test code; The processing unit 810 is further configured to traverse the syntax tree to obtain third test code for the target programming language; the third test code conforms to the direct programming interface specification.

[0065] In one possible design, the syntax rules corresponding to the custom programming language include at least one of the following: static parameter definition rules, dynamic variable declaration rules, register read / write rules, and function declaration and definition rules.

[0066] In one possible design, after obtaining the third test code in the target programming language, the processing unit 810 is further configured to compile the third test code to obtain a static library file corresponding to the third test code; the static library file is used to verify the chip design in conjunction with the associated verification code; wherein the associated verification code is developed based on a hardware description language.

[0067] In one possible design, the determining unit 820, when determining the syntax tree corresponding to the second test code, is specifically used for: The first syntax keyword in the second test code is used as the first-level node of the syntax tree; The second syntax keyword in the second test code is used as a child node of the first-level node; the first syntax keyword appears earlier than the second syntax keyword in the second test code.

[0068] In one possible design, the determining unit 820 is further configured to, if the first grammatical keyword has a corresponding name, input parameter and return type, use the name, the input parameter and the return type as the node parameter corresponding to the first level node.

[0069] In one possible design, when the processing unit 810 traverses the syntax tree to obtain the third test code of the target programming language, it is specifically used for: Traverse the syntax tree to determine the level corresponding to each syntax keyword included in the syntax tree; Based on the levels corresponding to each of the syntax keywords, the third test code of the target programming language is determined.

[0070] For a more detailed description of the processing unit 810 and the determining unit 820, please refer to [link / reference needed]. Figure 1 The relevant descriptions in the method embodiments shown are directly obtained and will not be repeated here.

[0071] like Figure 9 As shown, the test code generation apparatus 900 for the target programming language includes a processor 910 and an interface circuit 920. The processor 910 and the interface circuit 920 are coupled together. It is understood that the interface circuit 920 can be a transceiver or an input / output interface. Optionally, the test code generation apparatus 900 for the target programming language may further include a memory 930 for storing instructions executed by the processor 910, or storing input data required by the processor 910 to execute instructions, or storing data generated after the processor 910 executes instructions.

[0072] When the test code generation device 900 of the target programming language is used to implement Figure 1 In the method shown, the processor 910 is used to implement the functions of the processing unit 810, and the interface circuit 920 is used to implement the functions of the determination unit 820.

[0073] Based on the same technical concept, embodiments of this application provide a computer device, such as... Figure 10 As shown, it includes at least one processor chip 1001 and a memory 1002 connected to at least one processor chip. In this embodiment, the specific connection medium between the processor chip 1001 and the memory 1002 is not limited. Figure 10 Taking the connection between processor chip 1001 and memory 1002 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0074] In this embodiment of the application, the memory 1002 stores instructions that can be executed by at least one processor chip 1001. By executing the instructions stored in the memory 1002, the at least one processor chip 1001 can perform the steps of the test code generation method of the target programming language described above.

[0075] The processor chip 1001 serves as the control center of the computer device. It connects to various parts of the device via various interfaces and lines, controlling the chip by running or executing instructions stored in the memory 1002 and accessing data stored in the memory 1002. Optionally, the processor chip 1001 may include one or more processing units. The processor chip 1001 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor chip 1001. In some embodiments, the processor chip 1001 and the memory 1002 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0076] The processor chip 1001 can be a general-purpose processor, such as a graphics processing unit (GPU), general-purpose computing on graphics processing units (GPGPU), central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0077] Memory 1002, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 1002 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory 1002 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer device, but is not limited thereto. In the embodiments of this application, memory 1002 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0078] Based on the same technical concept, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the test code generation method for the target programming language described above.

[0079] Based on the same technical concept, embodiments of this application provide a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer device, cause the computer device to perform the steps of the test code generation method for the target programming language described above.

[0080] Those skilled in the art will understand that embodiments of this application can be provided as methods or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0081] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer apparatus or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0082] These computer program instructions may also be loaded onto a computer device or other programmable data processing equipment to cause a series of operational steps to be performed on the computer device or other programmable equipment to produce a process implemented by the computer device, thereby providing instructions that execute on the computer device or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0083] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0084] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for generating test code for a target programming language, characterized in that, The method includes: During the chip design verification phase, a first test code is converted into a second test code based on a preset conversion program. The first test code is obtained by encoding the operation sequence in the verification requirements using a custom programming language. The preset conversion program includes keyword conversion rules between the custom programming language and the target programming language. The keyword conversion rules include at least one of function mapping rules, register access mapping rules, and variable access mapping rules. Determine the syntax tree corresponding to the second test code; at least one node in the syntax tree corresponds to at least one syntax keyword included in the second test code; Traverse the syntax tree to obtain the third test code of the target programming language; the third test code conforms to the direct programming interface specification.

2. The method as described in claim 1, characterized in that, The syntax rules corresponding to the custom programming language include at least one of the following: static parameter definition rules, dynamic variable declaration rules, register read / write rules, and function declaration and definition rules.

3. The method as described in claim 1, characterized in that, After obtaining the third test code in the target programming language, the following is also included: The third test code is compiled to obtain a static library file corresponding to the third test code; the static library file is used to verify the chip design in conjunction with the associated verification code; wherein, the associated verification code is developed based on a hardware description language.

4. The method as described in claim 1, characterized in that, Determine the syntax tree corresponding to the second test code, including: The first syntax keyword in the second test code is used as the first-level node of the syntax tree; The second syntax keyword in the second test code is used as a child node of the first-level node; the first syntax keyword appears earlier than the second syntax keyword in the second test code.

5. The method as described in claim 4, characterized in that, The method further includes: If the first syntax keyword has a corresponding name, input parameter, and return type, then the name, input parameter, and return type are used as the node parameters corresponding to the first-level node.

6. The method as described in claim 5, characterized in that, Traverse the syntax tree to obtain the third test code for the target programming language, including: Traverse the syntax tree to determine the level corresponding to each syntax keyword included in the syntax tree; Based on the levels corresponding to each of the syntax keywords, the third test code of the target programming language is determined.

7. A test code generation device for a target programming language, characterized in that, The device includes a processing unit and a determining unit; The processing unit is used to convert first test code into second test code based on a preset conversion program during the verification phase of chip design; the first test code is obtained by encoding the operation sequence in the verification requirements using a custom programming language; the preset conversion program includes keyword conversion rules between the custom programming language and the target programming language; the keyword conversion rules include at least one of function mapping rules, register access mapping rules, and variable access mapping rules. The determining unit is used to determine the syntax tree corresponding to the second test code; at least one node in the syntax tree corresponds to at least one syntax keyword included in the second test code; The processing unit is further configured to traverse the syntax tree to obtain third test code for the target programming language; the third test code conforms to the direct programming interface specification.

8. A computer device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-6.

Images