Code file generation method and device, electronic equipment and storage medium
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG YUNHAI GUOCHUANG CLOUD COMPUTING EQUIP IND INNOVATION CENT CO LTD
- Filing Date
- 2026-03-25
- Publication Date
- 2026-06-09
Smart Images
Figure CN122173068A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of integrated circuit technology, and in particular to methods, apparatus, electronic devices and storage media for generating code files. Background Technology
[0002] In the field of integrated circuit technology, after the design of the test case is completed, multi-level verification operations are required. However, each level of verification operation uses a different programming language, requiring technicians to perform the programming operations separately. This results in low verification efficiency. Summary of the Invention
[0003] This application provides a method, apparatus, electronic device, storage medium, and program product for generating code files to solve the problem of low efficiency in integrated circuit verification.
[0004] This application provides a method for generating code files, including: Obtain a first code file corresponding to a first programming language, at least one code template corresponding to a second programming language, and operation information collection rules; Using the first code file, perform the first level of verification on the test instance corresponding to the first code file; During the first-level verification process, the operation information of the test instance is collected according to the signal and operation information collection rules transmitted between the test instance and the target device; Generate logs corresponding to the operation information based on the operation information; After completing the first-level verification operation, a second code file corresponding to the second programming language is generated based on the logs and at least one code template. The second code file is used for the second-level verification operation after the first level.
[0005] This application also provides a code file generation apparatus, including: The acquisition module is used to acquire a first code file corresponding to a first programming language, at least one code template corresponding to a second programming language, and operation information collection rules; The verification module is used to perform a first-level verification operation on the test instance corresponding to the first code file using the first code file. The acquisition module is used to acquire the operation information of the instance under test during the first-level verification operation, based on the acquisition rules for signals and operation information transmitted between the instance under test and the target device. The generation module is used to generate logs corresponding to the operation information based on the operation information; after completing the first-level verification operation, it generates a second code file corresponding to the second programming language based on the logs and at least one code template, wherein the second code file is used for the second-level verification operation after the first level.
[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described code file generation methods when executing the computer program.
[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described code file generation methods.
[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described code file generation methods.
[0009] This application first obtains a first code file corresponding to a first programming language, at least one code template corresponding to a second programming language, and operation information collection rules. Then, using the first code file written in the first programming language, a first-level verification operation can be performed on the instance under test. During this verification operation, operation information of the instance under test is collected according to the signal and operation information collection rules between the instance under test and the target device. Further, logs are generated based on the operation information. After completing the first-level verification operation, a second code file in the second programming language can be automatically generated based on the logs and a preset code template in the second programming language, allowing for direct use of the second code file for the second-level verification operation. This eliminates the need for technicians to write files in the second programming language; instead, logs are recorded directly from the operation information generated during the verification operation, and the logs are automatically converted to the programming language, significantly improving the efficiency of the verification work. Attached Figure Description
[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the 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.
[0011] Figure 1 A flowchart illustrating a method for generating a code file provided in an embodiment of this application; Figure 2 A schematic diagram illustrating an operation information collection rule provided in an embodiment of this application; Figure 3 A flowchart illustrating another method for generating code files provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the flow of another code file generation method provided in this application embodiment; Figure 5 A schematic diagram of a code file generation apparatus provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0012] The technical solutions of the embodiments of this application will be clearly and completely described 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 of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0015] The following is an explanation of the technical terms used in this application.
[0016] System Verilog (SV) is a high-level hardware description and verification language widely used in digital chip design and verification. C is a computer programming language that combines features of both high-level and assembly languages. It can be used as a system design language for writing operating system applications, and also as an application design language for writing applications that are independent of computer hardware.
[0017] In the field of integrated circuits, verification engineers first need to perform module-level verification using SV / Verilog programming languages to ensure the functionality of the test instance itself. Subsequently, they need to perform system-level verification using C / C++ languages to ensure the functional requirements of the system-level multi-module collaboration are met. However, converting SV-language code files into C-language code files often involves a large amount of repetitive work, making manual conversion inefficient and reducing the overall efficiency of the verification process.
[0018] To address the aforementioned technical problems, embodiments of this application provide a method for generating code files, which can be executed by an electronic device (e.g., a computer, server, etc.). Figure 1 As shown, the specific processing steps for generating code files may include: Step S101: Obtain the first code file corresponding to the first programming language, at least one code template corresponding to the second programming language, and operation information collection rules.
[0019] The first programming language can be a hardware description language, such as Verilog or SV. The first code file can include the hardware circuit description and data flow of the instance under test, and is generally referred to as a test case. The second programming language can be a software programming language, such as C or C++.
[0020] Specifically, after completing the design of an integrated circuit, the design can be verified to determine if any defects exist. If defects are found, the design can be improved. Electronic devices can be equipped with simulation tools to run a verification environment based on the first programming language. For example, the simulation tool could be a Verilog Compiled Simulator (VCS), which can run the entire Verilog (SV) verification environment and perform relevant verification operations based on code files written in the SV programming language.
[0021] To perform the first level of verification, technicians can upload the first code file to the electronic device. To facilitate subsequent programming language conversion, technicians can pre-design operation information collection rules based on the target communication protocol used between the target device and the instance under test, and write code templates in a second programming language. These operation information collection rules and all code templates are then uploaded to the electronic device. In this way, the electronic device can obtain the first code file, code templates, and operation information collection rules.
[0022] Step S102: Using the first code file corresponding to the first programming language, perform the first-level verification operation on the test instance corresponding to the first code file.
[0023] The first-level verification operation can be a module-level verification operation.
[0024] Specifically, during the first-level verification process, the electronic device can input the first code file into the simulation tool. In this way, the simulation tool can construct a test instance based on the input first code file and perform verification operations on the test instance.
[0025] Step S103: During the first-level verification operation, the operation information of the test instance is collected according to the signal and operation information collection rules transmitted between the test instance and the target device.
[0026] The target device can be a central processing unit, and the instance under test can be the design of peripheral components, such as a memory manager.
[0027] Specifically, the electronic device can also input the aforementioned operation information collection rules into the simulation tool. Furthermore, during the first-level verification process, the electronic device can monitor the signals transmitted between the test instance and the target device according to the operation information collection rules, and collect the operation information of the test instance.
[0028] Step S104: Generate a log corresponding to the operation information based on the operation information.
[0029] Specifically, the electronic device can generate and record logs based on the operation information. In this way, after completing the above verification operations, the electronic device can record all logs related to the operations performed by the instance under test.
[0030] The second-level verification operation only requires the data flow content, while the first code file includes both hardware circuit descriptions and data flow content. Due to varying habits among technical personnel, the first code files differ. If the technician responsible for the second-level verification operation directly identifies the data flow content from the first code file and then translates it into a second programming language, the process involves many repetitive steps. Manual execution by technicians is prone to errors and inefficient. Therefore, this solution, during the first-level verification process, collects operational information by monitoring the signal transmission operations of the instance under test, which is more convenient.
[0031] In addition, some code files written in the first programming language are encrypted, making it impossible to know their specific contents. Consequently, technicians cannot convert the programming language based on the first code file. However, this solution can collect operation information through signal transmission during the verification process of the test instance using the first code file, so that the programming language conversion operation can be performed directly afterward.
[0032] Step S105: After completing the first-level verification operation, generate a second code file corresponding to the second programming language based on the log and at least one code template.
[0033] The second code file can be used for verification operations at the second level, following the first level; it is also generally referred to as a test case. The second-level verification operations can be system-level verification operations.
[0034] Specifically, after completing the first-level verification operation, the electronic device can use the code template corresponding to the second programming language to convert the recorded logs, obtaining a second code file in the second programming language. Then, technicians can directly use the second code file to perform the second-level verification operation on the instance under test, without the need for manually writing the second code file.
[0035] The code file generation method of this application first obtains a first code file corresponding to a first programming language, at least one code template corresponding to a second programming language, and operation information collection rules. Then, the first code file written in the first programming language can be used to perform a first-level verification operation on the instance under test. During this verification operation, operation information of the instance under test is collected according to the signal and operation information collection rules between the instance under test and the target device. Further, a log is generated based on the operation information. After completing the first-level verification operation, a second code file in the second programming language can be automatically generated based on the log and a preset code template in the second programming language, so that the second code file can be directly used for the second-level verification operation. In this way, technicians do not need to write files in the second programming language; instead, the operation information generated during the verification operation can be directly recorded in logs, and the logs can be automatically converted to the programming language, greatly improving the efficiency of the verification work.
[0036] In some optional implementations, since different instances under test can communicate with the target device using different communication protocols, and the signal transmission methods corresponding to different communication protocols are different, in order to ensure accurate acquisition of operation information, the above-mentioned operation information acquisition rules may include the acquisition timing of candidate signals, the identification information of candidate signals corresponding to the target communication protocol, and at least one triggering condition. The target communication protocol is the communication protocol used by the target device and the instance under test for communication operations. The triggering condition may include the state combination and / or timing relationship of the candidate signals. Accordingly, in step S103 above, the electronic device may acquire the operation information of the instance under test using the following specific steps: Step 1: Based on the identification information of the candidate signals, determine at least one candidate signal corresponding to the identification information of the candidate signals from the signals transmitted between the instance under test and the target device.
[0037] Step two: Monitor the state of at least one candidate signal.
[0038] Step 3: After detecting that the state of the candidate signal meets the target triggering condition among at least one triggering condition, collect the operation information corresponding to the target triggering condition.
[0039] Specifically, the electronic device can determine candidate signals corresponding to the target communication protocol from the signals between the instance under test and the target device based on the signal identification information specified in the operation information acquisition rules, and monitor the status of the candidate signals. The candidate signals can include one or more types, and any candidate signal can be in a high-level or low-level state. Once the status of a candidate signal is detected to meet any of the triggering conditions specified in the operation information acquisition rules (i.e., the aforementioned target triggering conditions), operation information acquisition can begin according to the met triggering conditions.
[0040] This approach allows for greater flexibility by setting corresponding operation information collection rules for different communication protocols. Furthermore, by defining trigger conditions, it can be ensured that the operation information collection action occurs at the correct protocol timing, avoiding erroneous data collection during bus idle periods or invalid phases, and guaranteeing the accuracy of the recorded operation information.
[0041] In some optional implementations, where there are multiple candidate signals, including strobe signals and access control signals, the strobe signal is used to indicate whether the target device selects the instance under test for communication, and the access control signal is used to indicate the type of operation. Accordingly, in step three above, the electronic device can use the following specific steps to collect operation information corresponding to the target triggering condition: Step 1: If the state of the strobe signal and the state of the access control signal are both in the first state, determine that the state of the candidate signal meets the first triggering condition (i.e., the target triggering condition).
[0042] Step 2: Based on the first triggering condition, determine the write operation type as the operation type, and read the write data from the data signal line between the instance under test and the target device, and read the write address from the address signal line between the instance under test and the target device.
[0043] Step 3: The write data, write address, and write operation type are collectively determined as the operation information corresponding to the first triggering condition.
[0044] Alternatively, in step 4, if the state of the strobe signal is detected to be in the first state and the state of the access control signal is in the second state, it is determined that the state of the candidate signal meets the second triggering condition (i.e., the target triggering condition).
[0045] Step 5: Based on the second triggering condition, determine the read operation type as the operation type, and read the read data from the data signal line between the instance under test and the target device, and read the read address from the address signal line between the instance under test and the target device.
[0046] Step 6: Determine the read data, read address, and read operation type together as the operation information corresponding to the second trigger condition.
[0047] The target state can be used to indicate that a signal (such as a strobe signal or an access control signal) is valid. The access control signal can be a write enable signal or a read enable signal. For example, when the access control signal on the access control signal line is in the first state (e.g., a high level state), the access control signal can be a write enable signal to indicate that the current operation is a write operation. When the access control signal on the access control signal line is in the second state (e.g., a low level state), the access control signal can be a read enable signal to indicate that the current operation is a read operation.
[0048] Specifically, the electronic device can periodically monitor the state of each candidate signal. In any given period, the electronic device can determine whether the state of each candidate signal meets any of the trigger conditions included in the operation information acquisition rules. If so, it can execute the operation information acquisition operation corresponding to the trigger condition. For example, if both the strobe signal and the access control signal are in the first state, it can be determined that both the strobe signal and the write enable signal are valid. In this case, the write operation type can be determined as the operation type, and write data can be read from the data signal line (e.g., the write data signal line) between the instance under test and the target device, and the write address can be read from the address signal line between the instance under test and the target device. This way, the operation information corresponding to the write operation type can be obtained. If the strobe signal is in the first state and the access control signal is in the second state, it can be determined that both the strobe signal and the read enable signal are valid. In this case, the read operation type can be determined as the operation type, and read data can be read from the data signal line (e.g., the read data signal line) and the read address can be read from the address signal line.
[0049] For example, the rules for collecting operational information can be as follows: Figure 2 As shown, the process includes a first trigger condition and a second trigger condition. The first trigger condition is that both the strobe signal and the write enable signal are valid. The second trigger condition is that both the strobe signal and the read enable signal are valid. Furthermore, the operation information acquisition rules specify that the acquisition operation is triggered when the rising edge of the clock signal (Clock, CLK) is detected, that is, at the beginning of each clock cycle. The state of the strobe signal is acquired from the strobe signal line, and the state of the access control signal is acquired from the access control signal line. Then, it is determined whether the states of the strobe signal and the access control signal meet the aforementioned first or second trigger condition. If the first trigger condition is met, the address is read from the address signal line, and the write data is read from the write data signal line and printed. If the second trigger condition is met, the address is read from the address signal line, and the read data is read from the read data signal line and printed. If neither the first nor the second trigger condition is met, the process waits for the next rising edge of the clock signal to proceed with the next acquisition operation.
[0050] In this way, monitoring only the state combinations of key signals can trigger the acquisition of address and data signals, resulting in efficient resource utilization and simple logic. Furthermore, it ensures that the correct signal is acquired at the correct time.
[0051] In some alternative implementations, since data reading is not required during the second-level verification operation, if the state of the candidate signal is determined to meet the second triggering condition in the above process, data reading may not be recorded, which can save resources and improve verification efficiency.
[0052] In some optional implementations, since the key information required for different operation types in the second programming language differs, different code templates can be pre-set for different operation types in order to accurately and completely generate the final second code file. This allows the corresponding code template to be used to generate the code. Accordingly, in step S105 above, the electronic device can adopt the following specific steps: Step 1: Extract the operation type from the logs.
[0053] Step 2: Based on the operation type, determine the target code template corresponding to the operation type from a variety of code templates.
[0054] In addition, step three involves extracting candidate operation information from the logs that corresponds to the operation type, based on the operation type.
[0055] Step 4: Generate the second code file based on the target code template and candidate operation information.
[0056] Specifically, after completing the first-level verification operation, the electronic device obtains a log file. Then, the electronic device iterates through each log entry in this file, extracting the operation type from each entry. Based on the operation type, the electronic device determines the target code template corresponding to the operation type from at least one code template, and extracts candidate operation information corresponding to the operation type from the log. Finally, the electronic device adds the candidate operation information to a specified position in the target code template, obtaining the final second code file.
[0057] Thus, different operation types (such as "write" and "read") have fundamentally different code structures, semantics, and required information in the second programming language. Write operations are typically assignment statements, while read operations involve assignment and possible comparison verification. Therefore, predefining a dedicated code template for each operation type ensures that every line of generated code strictly conforms to the syntax requirements of that operation in the second programming language. Furthermore, by extracting corresponding candidate operation information based on the operation type, the necessary parameters for that type of operation can be accurately extracted from the log (e.g., write operations require writing addresses and data, read operations require reading addresses), avoiding information misalignment or loss that may occur with general parsing and ensuring the functional integrity of the generated code. Additionally, when new bus operation types need to be supported, there is no need to modify the core generation engine; only a new code template needs to be designed for the new operation type, which is quite convenient.
[0058] In some optional implementations, in step three above, the electronic device may use the following specific steps to extract candidate operation information corresponding to the operation type from the log based on the operation type: Step 1: If the operation type is read, extract the read address from the log.
[0059] Step 2: Determine the read address as the candidate operation information.
[0060] Alternatively, in step 3, if the operation type is a write operation, extract the write address and write data from the log.
[0061] Step 4: Determine the write address and write data together as candidate operation information.
[0062] Specifically, when the operation type is determined to be a read operation, the electronic device can extract only the read address from the log and identify the read address as candidate operation information so that the read address can be added to a specified position in the target code template. Alternatively, when the operation type is determined to be a write operation, the electronic device can extract the write address and write data from the log and identify the write address and write data as candidate operation information so that the write address can be added to a first position in the target log template and the write data can be added to a second position in the target log template.
[0063] In some optional implementations, during the first-level verification operation, multiple test instances can be verified simultaneously. Accordingly, for any test instance, the electronic device can establish a mapping relationship table between the identification information of the test instance and the identification information of the operation information collection rules. Then, based on the identification information of the test instance, the identification information of the operation information collection rules corresponding to the identification information of the test instance can be determined in the mapping relationship table. Then, based on the determined identification information of the operation information collection rules, the corresponding operation information collection rule file can be obtained so that the operation information of the test instance can be accurately collected based on the obtained operation information collection rules.
[0064] In some optional implementations, in step S104 above, the electronic device may also record the timestamp of the operation information acquisition and generate a log based on the acquisition timestamp and operation information. This helps to reproduce accurate timing relationships in system-level verification or to debug timing-sensitive issues.
[0065] In some optional implementations, in step S105 above, the electronic device may also perform the following analysis operations on the log; To determine if there exist multiple consecutive logs with the same operation type (called candidate logs) and whose addresses are consecutively increasing (e.g., the address of the current operation = the address of the previous operation + a fixed step size), the candidate logs are merged to generate a merged log. Specifically, the smallest address among them can be determined as the starting address, and the product of the number of candidate logs and the fixed step size can be used to determine the total data length. If the operation type is a read operation, the merged log can be generated directly based on the starting address and the total data length. If it is a write operation, a data array arranged in sequence can also be generated (e.g., a write data array). Then, based on the starting address, the total data length, and the data array, the merged log is generated. During the generation of the second code file, for merged logs of read operation type, the corresponding code template can be directly obtained (e.g., a read data function). For merged logs of write operation type, the target operation type can be determined based on the data included in the data array. Then, based on the target operation type, the corresponding code template can be determined, and the code is generated using the corresponding code template and the merged log. For example, if every element in the data array is zero, the zeroing operation can be identified as the target operation type. Then, code templates for calling memory setting functions (e.g., the "memset" function) can be used to generate code for setting the memory mode. As another example, if the data in the data array is distinct, the write operation can be identified as the target operation type. Then, code templates for writing functions (e.g., "memcpy") can be used to generate code for writing data.
[0066] In this way, by merging multiple lines of code into function call code, the execution speed is far faster than hundreds of independent assignment statements that require a "fetch-decode-execute" loop. Furthermore, it saves a significant amount of time in system-level simulation. In addition, the number of lines in the generated source code file is greatly reduced, making it easier to manage.
[0067] The following is a detailed explanation of the execution process of the code file generation method described above, using a specific example. The first programming language is SV, and the second programming language is C.
[0068] like Figure 3 As shown, the generation of the code file involves three steps. First, environment configuration: adding a printing module (i.e., the operation information collection rules mentioned above) to the existing verification environment (including the simulation tool and the first code file) to print the interface data generated by the interface of the instance under test. Then, performing module-level simulation operations using the existing first code file, and subsequently, using the printing program added in the previous step to output the generated addresses and read / write data as logs for later use. Finally, converting the information in the logs into C language instructions to generate the corresponding C language instance, i.e., generating the second code file.
[0069] Specifically, such as Figure 4 As shown, the first code file can be as follows: "The instance to be tested.paddr <= a certain address;" The test instance.psel <= 1; The instance under test.pwrite<=1; The instance under test.pwdata <= some data; @(posedgeclk); The instance under test.penable<=1; Wait(test instance.pready==1) "The instance under test.penable<=0;" Here, "DUT.paddr <= address" means driving the address to be accessed to the paddr of the Advanced Peripheral Bus (APB); "DUT.psel <= 1" means setting the strobe signal psel high (i.e., setting it to 1), indicating that the master device has selected the current slave device, that is, the target device has selected the DUT for communication; "DUT.pwrite <= 1" means setting the access control signal pwrite to 1, explicitly indicating that this operation is a write operation; "DUT.pwdata <= data" means driving the data to be written to the APB's write data signal pwdata; and "@(posedgeclk)" means waiting for the rising edge of the clock signal. "test_example.penable<=1" means that the enable signal penable will be set to high immediately after the rising edge of the clock signal. When both psel and penable are high, it indicates that the transmission is officially valid. "Wait(test_example.pready==1)" means waiting for the slave device to return a ready signal. The slave device tells the master device that the transmission is complete by pulling pready high. "test_example.penable<=0" means that once pready is detected to be 1, it means that the write operation has been successfully completed, and the master device will pull penable low.
[0070] During VCS simulation, operation information can be collected using operation information collection rules, and then operation logs can be generated based on this information, as follows: "32'hxxxx_xxxx(a certain address); WR (represents write); 32'hxxxx_xxxx(some data)”; The read operation log is generated as follows: "32'hxxxx_xxxx(a certain address); RD (represents readout); 32'hxxxx_xxxx(some data)”; Finally, based on the characteristics of C language used in system verification, a scripting language can be used to convert all printed logs into read / write operations for specific addresses in C language, thereby realizing the conversion from SV programming language to C language.
[0071] For example, a write log template can be represented as "*(unsigned int*)(32'hxxxx_xxxx) = 32'hxxxx_xxxx", where the first "hxxxx_xxxx" is used to add the write address and the first "hxxxx_xxxx" is used to add the write data. Overall, it can be represented as converting the 32-bit write address into an unsigned integer (Int) and then writing the corresponding write data to the address where the corresponding number is located.
[0072] The log reading template can be represented as "rd_data=*(unsigned int*)(32'hxxxx_xxxx)", where "hxxxx_xxxx" can be used to add the read address. After converting the 32-bit read address into an unsigned integer, the whole can be used to represent reading the data at the address of the corresponding number and storing it in the variable rd_data.
[0073] In this way, since C language is generally used for address read and write access during system-level verification operations, this solution converts code files written in SV programming language into C language form by intercepting bus interface information, enabling rapid conversion from SV programming language to C language during system verification. Furthermore, SV code files can be quickly generated directly during the verification process, eliminating the need to rewrite the relevant C language code files, thus greatly improving the efficiency of verification work. Simultaneously, using a scripting language for programming language conversion allows for the reuse of SV code files, eliminating human error. This significantly improves verification accuracy and saves time, especially in system simulations that often require several hours or even days. In addition, the C language code files can be reused not only in the verification field but also in subsequent driver development, such as in Field-Programmable Gate Array (FPGA) prototype testing, improving tape-out efficiency.
[0074] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.
[0075] Embodiments of this application also provide a code file generation apparatus, such as... Figure 5 As shown, it includes: The acquisition module 510 is used to acquire a first code file corresponding to a first programming language, at least one code template corresponding to a second programming language, and operation information collection rules; The verification module 520 is used to perform a first-level verification operation on the test instance corresponding to the first code file using the first code file; The acquisition module 530 is used to acquire the operation information of the instance under test according to the signal and operation information acquisition rules transmitted between the instance under test and the target device during the first-level verification operation. The generation module 540 is used to generate a log corresponding to the operation information based on the operation information; after completing the first-level verification operation, it generates a second code file corresponding to the second programming language based on the log and at least one code template, wherein the second code file is used for the second-level verification operation after the first level.
[0076] In some optional implementations, the operation information acquisition rules include identification information of candidate signals corresponding to the target communication protocol and at least one triggering condition. The target communication protocol is the communication protocol used for communication operations between the target device and the instance under test. The acquisition module 530 is specifically used for: Based on the identification information of the candidate signals, at least one candidate signal corresponding to the identification information of the candidate signals is determined from the signals transmitted between the instance under test and the target device. Monitor the status of candidate signals; After detecting that the state of the candidate signal meets the target trigger condition among at least one trigger condition, the operation information corresponding to the target trigger condition is collected.
[0077] In some optional implementations, when there are multiple candidate signals, the multiple candidate signals include strobe signals and access control signals; the acquisition module 530 is specifically used for: If both the state of the strobe signal and the state of the access control signal are detected to be in the first state, it is determined that the state of the candidate signal meets the first triggering condition, wherein the first triggering condition is the target triggering condition. Based on the first triggering condition, the write operation type is determined as the operation type, and the write data is read from the data signal line between the instance under test and the target device, and the write address is read from the address signal line between the instance under test and the target device. The write data, write address, and write operation type are collectively determined as the operation information corresponding to the first triggering condition.
[0078] In some alternative implementations, the acquisition module 530 is specifically used for: If the state of the strobe signal is detected to be in the first state and the state of the access control signal is in the second state, it is determined that the state of the candidate signal meets the second triggering condition, wherein the second triggering condition is the target triggering condition. Based on the second triggering condition, the read operation type is determined as the operation type, and read data is read from the data signal line between the instance under test and the target device, and read address is read from the address signal line between the instance under test and the target device. The read data, read address, and read operation type are collectively determined as the operation information corresponding to the second trigger condition.
[0079] In some alternative implementations, the generation module 540 is specifically used for: Extract the operation type from the logs; Based on the operation type, determine the target code template corresponding to the operation type from at least one code template; In addition, based on the operation type, candidate operation information corresponding to the operation type is extracted from the log; A second code file is generated based on the target code template and candidate operation information.
[0080] In some alternative implementations, the generation module 540 is specifically used for: When the operation type is read, extract the read address from the log; The read address is identified as a candidate operation information; Alternatively, if the operation type is write operation, extract the write address and write data from the log; Write address and write data are identified as candidate operation information.
[0081] In some optional implementations, the first programming language is a hardware description language, the first-level verification operation is a module-level verification operation, the second programming language is a software programming language, and the second-level verification operation is a system-level verification operation.
[0082] For a description of the features in the embodiment corresponding to the code file generation device, please refer to the relevant description in the embodiment corresponding to the code file generation method, which will not be repeated here.
[0083] Embodiments of this application also provide an electronic device, such as... Figure 6 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 perform the steps in any of the above-described code file generation method embodiments.
[0084] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described code file generation method embodiments at runtime.
[0085] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0086] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the code file generation method embodiments described above.
[0087] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the code file generation method embodiments described above.
[0088] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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.
[0089] The foregoing has provided a detailed description of a method, apparatus, electronic device, storage medium, and program product for generating code files provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A method for generating code files, characterized in that, include: Obtain a first code file corresponding to a first programming language, at least one code template corresponding to a second programming language, and operation information collection rules; Using the first code file, a first-level verification operation is performed on the test instance corresponding to the first code file; During the first-level verification process, the operation information of the test instance is collected based on the signals transmitted between the test instance and the target device and the operation information collection rules. Based on the operation information, generate a log corresponding to the operation information; After completing the first-level verification operation, a second code file corresponding to the second programming language is generated based on the log and at least one of the code templates, wherein the second code file is used for the second-level verification operation after the first level.
2. The method for generating code files according to claim 1, characterized in that, The operation information collection rules include identification information of candidate signals corresponding to the target communication protocol and at least one triggering condition. The target communication protocol is the communication protocol used for communication operations between the target device and the instance under test. During the first-level verification operation, the operation information of the instance under test is collected based on the signals transmitted between the instance under test and the target device and the operation information collection rules, including: Based on the identification information of the candidate signals, at least one candidate signal corresponding to the identification information of the candidate signals is determined from the signals transmitted between the test instance and the target device. Monitor the state of the candidate signals; After detecting that the state of the candidate signal meets at least one of the target triggering conditions, the operation information corresponding to the target triggering condition is collected.
3. The method for generating code files according to claim 2, characterized in that, When there are multiple candidate signals, the multiple candidate signals include strobe signals and access control signals; after detecting that the state of at least one of the candidate signals meets the target triggering condition among at least one of the triggering conditions, the operation information corresponding to the target triggering condition is collected, including: If both the state of the strobe signal and the state of the access control signal are detected to be in the first state, it is determined that the state of the candidate signal meets the first triggering condition, wherein the first triggering condition is the target triggering condition. Based on the first triggering condition, the write operation type is determined as the operation type, and write data is read from the data signal line between the instance under test and the target device, and write address is read from the address signal line between the instance under test and the target device; The write data, the write address, and the write operation type are collectively determined as the operation information corresponding to the first triggering condition.
4. The method for generating code files according to claim 3, characterized in that, After detecting that the state of at least one of the candidate signals meets the target triggering condition among at least one of the triggering conditions, the step of collecting the operation information corresponding to the target triggering condition includes: If the state of the strobe signal is detected to be the first state and the state of the access control signal is the second state, it is determined that the state of the candidate signal meets the second triggering condition, wherein the second triggering condition is the target triggering condition. According to the second triggering condition, the read operation type is determined to be the operation type, and read data is read from the data signal line between the instance under test and the target device, and read address is read from the address signal line between the instance under test and the target device; The read data, the read address, and the read operation type are collectively determined as the operation information corresponding to the second triggering condition.
5. The method for generating code files according to any one of claims 1 to 4, characterized in that, After completing the first-level verification operation, the step of generating a second code file corresponding to the second programming language based on the log and at least one of the code templates includes: Extract the operation type from the log; Based on the operation type, a target code template corresponding to the operation type is determined from at least one of the code templates; Furthermore, based on the operation type, candidate operation information corresponding to the operation type is extracted from the log; The second code file is generated based on the target code template and the candidate operation information.
6. The method for generating code files according to claim 5, characterized in that, The step of extracting candidate operation information corresponding to the operation type from the log according to the operation type includes: If the operation type is a read operation, the read address is extracted from the log. The read address is determined as the candidate operation information; Alternatively, if the operation type is a write operation, the write address and write data can be extracted from the log. The write address and the write data are determined as the candidate operation information.
7. The method for generating code files according to any one of claims 1 to 4, characterized in that, The first programming language is a hardware description language, the first-level verification operation is a module-level verification operation, the second programming language is a software programming language, and the second-level verification operation is a system-level verification operation.
8. A code file generation apparatus, characterized in that, include: The acquisition module is used to acquire a first code file corresponding to a first programming language, at least one code template corresponding to a second programming language, and operation information collection rules; The verification module is used to perform a first-level verification operation on the test instance corresponding to the first code file using the first code file. The acquisition module is used to acquire the operation information of the instance under test during the first-level verification operation, based on the signals transmitted between the instance under test and the target device and the operation information acquisition rules. The generation module is used to generate a log corresponding to the operation information based on the operation information. After completing the first-level verification operation, a second code file corresponding to the second programming language is generated based on the log and at least one of the code templates, wherein the second code file is used for the second-level verification operation after the first level.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the code file generation method as described in any one of claims 1 to 7.
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, it implements the steps of the method for generating a code file as described in any one of claims 1 to 7.