Chip simulation method, electronic device and readable storage medium

Abstract

The application discloses a chip simulation method, an electronic device and a readable storage medium, and belongs to the computer field. The method comprises the following steps: acquiring a to-be-compiled module of a to-be-tested chip based on chip design of the to-be-tested chip; the to-be-compiled module comprises a first module obtained based on cohesion division from the chip design and a second module obtained based on stability division from the chip design; the first module comprises a plurality of first sub-modules which are associated in design logic, and the second module comprises a plurality of second sub-modules, and each of the plurality of second sub-modules is a sub-module with a change frequency of a preset time period module implementation code lower than a threshold value; a to-be-compiled verification environment module is acquired; a compilation operation is performed on the to-be-compiled module of the to-be-tested chip and the to-be-compiled verification environment module, so as to obtain an executable file of the to-be-tested chip; and simulation verification is performed on the to-be-tested chip based on the executable file.

Description

Technical Field

[0001] This application belongs to the field of computer science, and specifically relates to a chip emulation method, an electronic device, and a readable storage medium. Background Technology

[0002] During chip simulation, if a file or test case in the chip design is modified, the entire design needs to be recompiled, which often makes the full chip simulation compilation time take several hours or even tens of hours.

[0003] Currently, related technologies typically employ a modular compilation approach to shorten compilation time, which involves dividing the chip design into blocks and performing compilation operations on each block. However, this modular approach suffers from low compilation efficiency. Summary of the Invention

[0004] This application provides a chip emulation method, an electronic device, and a readable storage medium, which can solve the problem of low compilation efficiency in related technologies.

[0005] In a first aspect, embodiments of this application provide a chip simulation method, including: Based on the chip design of the chip under test, the module to be compiled of the chip under test is obtained; the module to be compiled includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning; the first module includes multiple first sub-modules that are logically related in design, and the second module includes multiple second sub-modules, all of which are sub-modules whose module implementation code change frequency is lower than a threshold during a preset time period; Obtain the modules to be compiled and verified; Compilation operations are performed on the compilation module of the chip under test and the compilation verification environment module to obtain the executable file of the chip under test; Based on the executable file, the chip under test is simulated and verified.

[0006] In a second aspect, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores programs or instructions executable on the processor, and the programs or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0007] Thirdly, embodiments of this application provide a computer-readable storage medium on which a program or instructions are stored, which, when executed, implement the steps of the method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0009] The at least one technical solution provided in the embodiments of this application can achieve the following technical effects: In this embodiment, based on the chip design of the chip under test, a module to be compiled for the chip under test is obtained; the module to be compiled includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning; the first module includes multiple first sub-modules that are logically related in the design, and the second module includes multiple second sub-modules, all of which are sub-modules whose code change frequency is lower than a threshold during a preset time period; a compilation verification environment module is obtained; a compilation operation is performed on the module to be compiled and the compilation verification environment module of the chip under test to obtain an executable file of the chip under test; and simulation verification is performed on the chip under test based on the executable file. Therefore, compared to related technologies that do not consider the characteristics of the modules themselves when dividing the chip design, the embodiments of this application take into account the cohesion between modules or the stability of the modules themselves during the chip design division process of the chip under test. Sub-modules that are logically related are grouped into one module, and sub-modules whose implementation code changes less than a threshold are grouped into another module. This allows for a more reasonable division of the chip design under test, reducing duplicate compilations caused by unreasonable divisions, thereby improving the compilation efficiency of the chip under test and solving the problem of low compilation efficiency in related technologies. Simultaneously, it also enables the compilation operation of the compilation verification environment module for the chip under test, allowing for a more comprehensive simulation verification of the chip under test. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart of a chip simulation method provided in an embodiment of this application; Figure 2 This is a flowchart of another chip simulation method provided in the embodiments of this application; Figure 3 This is a flowchart of another chip simulation method provided in the embodiments of this application; Figure 4This is a flowchart illustrating a SoC chip simulation process provided in an embodiment of this application; Figure 5 This is a structural block diagram of a chip emulation device provided in an embodiment of this application; Figure 6 This is a structural block diagram 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 described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0014] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0015] The chip simulation method provided in this application can be applied to simulation technology. Specifically, the chip design of the chip under test can be divided according to cohesion and stability to obtain a first module and a second module. This can more reasonably realize the division of the chip design of the chip under test, reduce repeated compilation caused by unreasonable division, and improve the compilation efficiency of the chip under test.

[0016] The chip simulation method provided in this application can be executed by a target device, which can be a single electronic device or multiple electronic devices. Specifically, the chip simulation method can be executed by a single electronic device, such as a desktop computer, laptop, mobile phone, or tablet, or a server, such as a standalone physical server, a server cluster consisting of multiple servers, or a cloud server capable of cloud computing. A simulation and verification platform for the chip under test can be deployed on the electronic device. When the chip simulation method is executed by multiple electronic devices, these devices can form a service cluster, cooperating to complete each step.

[0017] The chip simulation method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0018] Please see Figure 1 , Figure 1 This is a flowchart of a chip simulation method provided in an embodiment of this application. Figure 1 As shown, the method includes the following steps: Step 110: Based on the chip design of the chip under test, obtain the module to be compiled of the chip under test; the module to be compiled includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning; the first module includes multiple first sub-modules that are logically related in the design, and the second module includes multiple second sub-modules, all of which are sub-modules whose module implementation code change frequency is lower than a threshold during a preset time period.

[0019] In this embodiment, the division of the modules to be compiled is used to reduce the number of compilation operations. Cohesion measures the tightness of functional relationships between elements within a module; high cohesion means that a change in one element within the module will simultaneously affect other elements within the module. Stability measures the module's ability to resist changes. If a module has high stability, it means that few other modules depend on it, and the module itself rarely changes; if a module has low stability, it means that fewer modules depend on it, and the module itself may change frequently.

[0020] In this embodiment, when dividing the chip design of the chip under test, several sub-modules with strong coupling between modules can be grouped into one module, thus obtaining a first module from the chip design of the chip under test. Several stable sub-modules that do not change frequently can be grouped into one module, thus obtaining a second module from the chip design of the chip under test. It is understood that the first module is a module with high cohesion, and the number of the first module can be one or more. The second module is a module with high stability, and the number of the second module can be one or more. Since both the first and second modules are obtained from the chip design, both the first and second modules can be chip modules. In this embodiment, the first and second modules can be collectively referred to as target modules, i.e., modules to be subsequently compiled. Here, the target module can also be understood as a subsystem or hardened block, and the chip under test is, for example, a System-on-Chip (SoC) chip. However, it should be noted that the chip simulation method provided in this embodiment is not limited to SoC chips and can also be applied to other chips. Furthermore, the chip emulation method provided in this application is particularly applicable to various large-scale or ultra-large-scale chips, such as large-scale SoC chips.

[0021] In this embodiment, because the multiple first sub-modules in the first module are logically related, the modules within the first module are highly cohesive. This allows several sub-modules that might trigger a chain reaction to be grouped into one module, making the recompilation scope clearer and avoiding excessive recompilation. The logical relatedness of the multiple first sub-modules means that for any one of the multiple first sub-modules, a first target sub-module can be determined from the multiple first sub-modules, making the first sub-module and the first target sub-module logically related. When the first sub-module is changed, it may trigger changes to other first modules among the multiple first sub-modules. Taking a SoC chip as an example, the SoC chip may include sub-module 1, sub-module 2, sub-module 3, and sub-module 4. Sub-module 1 and sub-module 2 are logically related, sub-module 2 and sub-module 3 are logically related, and sub-module 4 is logically independent of the other three modules. In this case, sub-module 1, sub-module 2, and sub-module 3 can be grouped into one first module.

[0022] In this embodiment, because the frequency of code changes to the implementation of each of the multiple second sub-modules within the second module is lower than a threshold within a preset time period, the module design of the sub-modules within the second module is relatively stable and unlikely to change subsequently. This avoids the need for repeated compilation of stable modules during the implementation of block compilation. For example, the second sub-module may be a stable and mature commercial intellectual property (IP) module or a self-developed module. Specifically, for any one of the multiple second sub-modules, the frequency of code changes to the implementation of the second sub-module being lower than a threshold within a preset time period means that the frequency of changes to the module implementation code of the second sub-module is low within a certain period in the future, i.e., the module design of the second sub-module is relatively stable and unlikely to change subsequently. The preset time period can be understood as a future predicted period. For example, the second sub-module may be a stable and mature commercial intellectual property (IP) module or a self-developed module.

[0023] In this embodiment, the entire SoC design can be divided into several logically independent modules (also called subsystems or sub-blocks) at the start of the project or during the compilation and configuration phase. The purpose of module division is to reduce the compilation of blocks, and the division is mainly based on the cohesion and stability of the modules. In other words, the principle for dividing modules in this embodiment can be: clear dependencies between sub-modules, well-defined interfaces, and strong internal file cohesion within the module. Alternatively, the sub-module design can be stable, such as commercial IP or self-developed modules. For example, the modules to be compiled in the chip under test may include a CPU module, a memory controller module, a graphics processing unit (GPU) module, and a Peripheral Component Interconnect Express (PCIe) module, etc.

[0024] For example, in one embodiment, the plurality of first sub-modules includes at least one first sub-module whose implementation code changes more frequently than a threshold during the preset time period, and / or, the plurality of second sub-modules includes at least two second sub-modules that are logically unrelated. That is, for stable and mature commercial IP, even if modules are not functionally related, they can be grouped into one sub-module. For modules that are frequently modified and have strong coupling between them, they can be grouped into one sub-module.

[0025] Step 120: Obtain the compilation and verification environment module.

[0026] In this embodiment, the verification environment module to be compiled is constructed based on the simulation verification platform of the chip under test and the simulation test cases of the chip under test. This embodiment allows the verification environment of the chip under test to be defined as a module to be compiled independently, and supports the independent compilation of the verification environment module. The number of the verification environment modules to be compiled can be one or more. For example, the module to be compiled can include one or more modules (e.g., multiple first modules and multiple second modules), depending on the specific design of the chip under test. The number of verification environment modules to be compiled can be one, meaning the verification environment of the chip under test is defined as a single module to be compiled.

[0027] Step 130: Perform a compilation operation on the compilation module of the chip under test and the compilation verification environment module to obtain the executable file of the chip under test.

[0028] In this embodiment, the executable file refers to a file containing machine code (binary instructions) that can be loaded into memory by the operating system and executed directly by the CPU. The compilation operation can be performed on the module to be compiled for the chip under test and the compilation verification environment module to be compiled, respectively, to obtain the compiled file (also called the linker file) of the module to be compiled and the compiled file of the compilation verification environment module to be compiled. A linking operation is then performed on the compiled files of the module to be compiled and the compiled files of the compilation verification environment module to obtain the executable file required for the final simulation.

[0029] Step 140: Based on the executable file, perform simulation verification on the chip under test.

[0030] In this embodiment, after obtaining the executable file, the simulation verification process of the chip under test can be executed by running the file. It should be noted that the executable file in this embodiment is not limited to a fixed file. If the compilation file of the module to be compiled or the compilation file of the verification environment module to be compiled changes during the simulation verification of the chip under test, a recompilation operation can be performed on both the module to be compiled and the verification environment module to be compiled, regenerating the latest executable file. The simulation verification of the chip under test can then continue using the latest executable file.

[0031] In this embodiment, based on the chip design of the chip under test, a module to be compiled for the chip under test is obtained; the module to be compiled includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning; the first module includes multiple first sub-modules that are logically related in the design, and the second module includes multiple second sub-modules, all of which are sub-modules whose code change frequency is lower than a threshold during a preset time period; a compilation verification environment module is obtained; a compilation operation is performed on the module to be compiled and the compilation verification environment module of the chip under test to obtain an executable file of the chip under test; and simulation verification is performed on the chip under test based on the executable file. Therefore, compared to related technologies that do not consider the characteristics of the modules themselves when dividing the chip design, the embodiments of this application take into account the cohesion between modules or the stability of the modules themselves during the chip design division process of the chip under test. Sub-modules that are logically related are grouped into one module, and sub-modules whose implementation code changes less than a threshold are grouped into another module. This allows for a more reasonable division of the chip design under test, reducing duplicate compilations caused by unreasonable divisions, thereby improving the compilation efficiency of the chip under test and solving the problem of low compilation efficiency in related technologies. Simultaneously, it also enables the compilation operation of the compilation verification environment module for the chip under test, allowing for a more comprehensive simulation verification of the chip under test.

[0032] Please see Figure 2 , Figure 2 This is a flowchart of another chip simulation method provided in an embodiment of this application. For example... Figure 2 As shown, the method includes the following steps: Step 210: Based on the chip design of the chip under test, obtain the module to be compiled of the chip under test; the module to be compiled includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning.

[0033] Step 220: Obtain the compilation and verification environment module.

[0034] Step 230: Perform compilation operations on multiple target modules to obtain multiple first files, wherein each target module corresponds to one of the multiple first files.

[0035] In this embodiment, the first module, the second module, and the verification environment module are all target modules among the plurality of target modules. For example, if the module to be compiled includes three first modules and four second modules, and the verification environment module is a single module, then eight target modules can be identified. Initially, a full compilation of all target modules can be performed. Specifically, an independent compilation process can be executed for each target module using Electronic Design Automation (EDA) tools to obtain multiple first files. These multiple first files may include a first file corresponding to each of the multiple target modules, and each first file in the multiple first files may correspond to one of the multiple target modules. The first file may contain a symbol table and relocation information. The first file can be used as a compiled file or an intermediate linker file for direct use by the subsequent linker without recompilation.

[0036] Taking the chip under test (DUT) as an example of a System-on-a-Chip (SoC), the multiple target modules include N chip modules and a compilation and verification environment module. The chip modules can also be called Register Transfer Level (RTL) sub-modules or SoC sub-modules. The compilation and verification environment module is not directly related to the SoC chip; the SoC chip is part of the design, while the compilation and verification environment module consists of a verification platform, test cases, etc., and is used to verify the SoC chip. For each chip module (RTL sub-module), a corresponding intermediate linker file (i.e., the first file) can be generated, such as subsys_cpu.o or subsys_cpu.a. Similarly, for the compilation and verification environment module, a corresponding verification environment linker file (i.e., the first file) can be generated, such as tb_env.o. During this process, the compilation and verification environment module can be executed independently.

[0037] Step 240: For any one of the multiple target modules, if the first file corresponding to the target module has not been changed, determine the first file of the target module as the compilation file of the target module.

[0038] In this embodiment, if the first file corresponding to the target module has not changed (i.e., it is the same as the file from the previous compilation operation), the first file obtained from the previous compilation can be directly reused without recompiling the target module. In other words, for situations where the compiled files of a target module have changed, this embodiment does not require recompiling every target module, but only recompiles the changed portion of the target modules. This avoids unnecessary compilation operations, reduces the number of compilation operations, and improves compilation efficiency.

[0039] Step 250: For any one of the multiple target modules, if the first file corresponding to the target module is changed, the target module is recompiled to obtain a second file; the second file is determined as the compilation file of the target module.

[0040] In this embodiment, if the first file corresponding to the target module changes, i.e., the module implementation code of the target module changes, then the first file corresponding to the target module obtained from the previous compilation cannot be used. In this case, a recompiling operation can be performed on the target module, and the recompiled second file is determined as the compiled file of the target module.

[0041] Step 260: Based on the compilation file of each of the multiple target modules, obtain the executable file of the chip under test.

[0042] In this embodiment, each of the plurality of target modules can be modified and incrementally compiled in the manner shown in steps 240-250 to obtain a compiled file for each of the plurality of target modules. Further details are omitted here. After obtaining the compiled files for each of the plurality of target modules, a linking operation can be performed on the multiple compiled files of the plurality of target modules to obtain the executable file for the chip under test.

[0043] For example, an EDA linker can collect the compiled files (linked files) of all target modules (subsystems), including the compiled files of chip modules (chip subsystems) and the compiled files of the verification environment module to be compiled (verification environment subsystem). A single linking operation generates the executable file (e.g., simv) required for the final simulation. Specifically: Final executable file (simv) = Linked (linked file 1, linked file 2, ..., linked file N, verification environment linked file). The linker only needs to perform symbol resolution and address relocation based on the linked files; no recompilation of any source code is required. Furthermore, the linking operation itself typically takes only seconds to minutes, far less than the compilation time.

[0044] Step 270: Based on the executable file, perform simulation verification on the chip under test.

[0045] In this embodiment of the application, by using change detection, incremental compilation can be performed only on the target module that has changed, thereby reducing the number of compilation operations and eliminating the need for unnecessary compilation operations.

[0046] Please see Figure 3 , Figure 3 This is a flowchart of another chip simulation method provided in an embodiment of this application. For example... Figure 3 As shown, the method includes the following steps: Step 310: Based on the chip design of the chip under test, obtain the module to be compiled of the chip under test; the module to be compiled includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning.

[0047] Step 315: Obtain the compilation and verification environment module.

[0048] Step 320: Perform compilation operations on multiple target modules to obtain multiple first files, wherein each target module corresponds to one of the multiple first files.

[0049] It should be noted that steps 325-345 are used to implement change detection and incremental compilation of one of the multiple target modules. Change detection and incremental compilation of each of the multiple target modules can be implemented in the same way. They will not be elaborated on here. The following will use the change detection and incremental compilation process of any one of the target modules as an example.

[0050] Step 325: For any one of the plurality of target modules, if the first file corresponding to the target module has not been changed, determine the first file of the target module as the compilation file of the target module.

[0051] Step 330: For any one of the multiple target modules, if the first file corresponding to the target module is changed, obtain the file change identifier of each sub-file in the first file corresponding to the target module.

[0052] In this embodiment, the file change identifier can be an indication of whether the file has been changed. Specifically, the file change identifier can be one of a first change identifier and a second change identifier, whereby the first change identifier indicates that the sub-file has been changed, and the second change identifier indicates that the sub-file has not been changed.

[0053] For example, the first change identifier can be a first value, and the second change identifier can be a second value. The first value is 1, and the second value is 0. That is, for any sub-file in the first file, if the file change identifier of the sub-file is 1, it means that the sub-file has been changed; if the file change identifier of the sub-file is 0, it means that the sub-file has not been changed. In another example, the first change identifier can be "recompiled", and the second change identifier can be "reusable".

[0054] Step 335: Based on the file change identifier of each subfile in the plurality of subfiles, determine at least one target subfile from the plurality of subfiles; the file change identifier of each target subfile in the at least one target subfile indicates that the target subfile has been changed.

[0055] In this embodiment of the application, the sub-files whose file change identifiers indicate changes can be identified as target sub-files, thereby filtering out at least one target sub-file that has changed from multiple sub-files, thus accurately determining the range of sub-files that have changed, which facilitates the subsequent accurate implementation of recompiling operations.

[0056] Step 340: Recompile each of the at least one target sub-files to obtain at least one third file; the at least one target sub-file corresponds one-to-one with the at least one third file.

[0057] In this embodiment, each of the at least one third file corresponds to one of the at least one target sub-files, and the at least one third file includes a third file obtained by recompiling each of the at least one target sub-files. This embodiment provides fine-grained file-level change detection and file-level incremental compilation. That is, the granularity of change detection is precise to a single sub-file, rather than a module or subsystem. Simultaneously, the execution granularity of recompilation can be precise to a single sub-file, rather than a module or subsystem, avoiding recompilation of sub-files that have not undergone changes, further reducing the workload of recompilation and improving compilation efficiency.

[0058] Step 345: Determine the remaining sub-files (excluding the at least one target sub-file) and the at least one third file from the plurality of sub-files as the second file; determine the second file as the compilation file of the target module.

[0059] In this embodiment, for the at least one target sub-file, since the at least one target sub-file is a modified file, at least one recompiled third file can be used to replace the previously compiled first file. For the remaining sub-files in the multiple sub-files of the first file, excluding the at least one target sub-file, since the remaining sub-files have not been modified, they can be directly reused. By repackaging or linking the remaining sub-files and the at least one third file, a second file (a new module linker file) is generated and identified as the latest compiled file of the target module.

[0060] In one example, for any subsystem, only the subfiles marked as "recompiled" need to be recompiled, generating new object files (.o), i.e., the third file. For subfiles marked as "reusable," the object files generated in the previous compilation (i.e., the first file) are used directly. All object files (a mix of old and new) within the subsystem are then repackaged or linked to generate a new subsystem linker, i.e., the second file. For instance, if a subsystem contains 1000 files, and only one file has been modified, then only that one file needs to be compiled subsequently; the remaining 999 files can directly reuse the object files obtained in the previous compilation.

[0061] Step 350: Based on the compilation file of each of the multiple target modules, obtain the executable file of the chip under test.

[0062] Step 355: Based on the executable file, perform simulation verification on the chip under test.

[0063] In this embodiment, fine-grained file-level change detection can be achieved through the file change identifier of sub-files, thereby enabling file-level incremental compilation. The recompilation scope is precisely located to the specific sub-files within the module, thus avoiding excessive compilation workload caused by recompiling unchanged sub-files, reducing the number of recompilation operations, and improving compilation efficiency.

[0064] In one embodiment of this application, the file change identifier includes a first change identifier and a second change identifier. Obtaining the file change identifier of each sub-file in the first file corresponding to the target module includes: for any one of the plurality of sub-files, performing the following operations: obtaining first indication information of the sub-file at a first time point and second indication information of the sub-file at a second time point; the first time point is the current time point, and the second time point is the time point when the sub-file last performed a compilation operation; if the first indication information and the second indication information are different, determining the file change identifier of the sub-file as the first change identifier, the first change identifier indicating that the sub-file has undergone a file change; if the first indication information and the second indication information are the same, determining the file change identifier of the sub-file as the second change identifier, the second change identifier indicating that the sub-file has not undergone a file change; based on the plurality of sub-files, obtaining the file change identifier of each sub-file in the plurality of sub-files. Wherein, the first indication information and the second indication information are both file modification timestamps, or the first indication information and the second indication information are both Message-Digest Algorithm 5 (MD5) hash values.

[0065] The file modification timestamp can be the timestamp of the last modification of the file. Specifically, the first indication information can be the timestamp of the last modification of the sub-file based on the current time. The second indication information can be the timestamp of the last modification of the sub-file based on the time when the compilation operation of the sub-file was last performed. Alternatively, the first indication information can be the MD5 hash value of the sub-file at the current time, and the second indication information can be the MD5 hash value of the file when the compilation operation was last performed. It should be noted that the above two methods of setting indication information are only examples, and the embodiments of this application are not limited to these two methods. Other methods can also be used, as long as it is ensured that the file content can be detected as changed.

[0066] In this embodiment, when file content or metadata changes, the file is considered modified, the file modification timestamp is updated, and the file's MD5 hash also changes. Therefore, by determining whether a subfile has been modified, it can be determined whether the subfile's modification timestamp or MD5 hash has changed. This method enables file-level change detection, thereby accurately locating which subfiles among multiple subfiles have been modified.

[0067] In the example above, the following change detection logic can be executed at any compilation start. For each subsystem (target module), the following operations are performed to determine whether files within the subsystem have changed: For each subfile in the subsystem, determine whether the subfile's file modification timestamp is greater than the file modification timestamp of the subfile during the last compilation, or whether the subfile's MD5 has changed. If the subfile's file modification timestamp is greater than the file modification timestamp of the subfile during the last compilation, or the subfile's MD5 has changed, then the subfile is marked as "needs recompilation". If the subfile's file modification timestamp is less than or equal to the file modification timestamp of the subfile during the last compilation, and the subfile's MD5 has not changed, then the subfile is marked as "reusable". This change detection logic allows for granular detection down to a single subfile, rather than a module or subsystem.

[0068] In one embodiment of this application, when the target module is the compilation and verification environment module, the first file corresponding to the compilation and verification environment module includes a simulation verification platform file and a test case file. The number of test case files can be one or more, and is not limited here. Generally, during the simulation verification of the chip under test, new test cases are continuously added, meaning the test case file will be updated, and the simulation verification platform may occasionally undergo minor changes. By detecting changes in the simulation verification platform file and the test case file, changes to the verification environment of the chip under test can be detected in a timely manner.

[0069] In one embodiment of this application, the at least one target sub-file to be recompiled is a sub-file in the first file corresponding to the verification environment module to be compiled. This enables independent incremental compilation of the verification environment module to be compiled.

[0070] In this embodiment, the module to be compiled for the verification environment can also follow the above-described file-level incremental compilation rules. For example, if the compilation file of the module to be compiled remains unchanged (RTL unchanged), but the compilation file of the module to be compiled for the verification environment changes, such as a change in the test case file, then only the modified test case file needs to be recompiled to regenerate the compilation file of the module to be compiled for the verification environment, without needing to recompile the module to be compiled. Alternatively, if the compilation file of the module to be compiled changes, but the compilation file of the module to be compiled for the verification environment remains unchanged (both the simulation verification platform file and the test case file remain unchanged), then the compilation file of the module to be compiled for the verification environment obtained in the previous compilation can be completely reused, without needing to recompile any verification environment files; only the module to be compiled needs to be recompiled.

[0071] In the above embodiments, when the code of the module to be compiled or the module to be compiled and verified changes, the entire process can automatically form a minimal refactoring closed loop, as shown in Table 1 below:

[0072] Table 1 The following section uses the Synopsys VCS toolchain as an example to introduce a specific implementation method. First, the chip design is partitioned into subsystems using a subsystem partitioning script. Specifically, the `partition.py` script parses the project configuration file to generate a list of files (.f files) for each subsystem.

[0073] Perform a full compilation for the first time using the following command: "vcs -f subsys_cpu.f -o subsys_cpu.o vcs -f subsys_mem.f -o subsys_mem.o vcs -f tb_env.fo tb_env.o” Next, the timestamps of the modified files are compared using inc_compile.py, and incremental compilation is performed on the changed files using the incremental compilation script: "vcs -c -o changed_file.o changed_file.v". Then, the linker files of each subsystem are repackaged.

[0074] Finally, link the compiled files of each subsystem using the following command: "vcs -link subsys_cpu.o subsys_mem.o ... tb_env.o -o simv".

[0075] For ease of understanding, the following is combined with Figure 4 This section introduces an example workflow for chip simulation. (See also...) Figure 4 , Figure 4 This is a flowchart illustrating a SoC chip simulation process provided in an embodiment of this application. Figure 4 As shown, after starting chip simulation, step 1, subsystem partitioning, is performed. Specifically, the SoC chip is divided into N chip subsystems (i.e., the modules to be compiled mentioned earlier), and the verification environment is defined as an independent subsystem (i.e., the verification environment module to be compiled mentioned earlier). Next, step 2, initial full compilation, is performed. Specifically, each chip subsystem is compiled separately, and the verification environment subsystem is compiled separately. Intermediate linker files subsys_1.o, subsys_2.o,... are generated for each subsystem; these intermediate linker files are the first file mentioned earlier.

[0076] Next, proceed to step 3: Change Detection. Specifically, iterate through each sub-file of each subsystem and check if the file timestamp (i.e., file modification timestamp) or MD5 hash of the sub-file has changed. If it has changed, mark it as needing recompilation; otherwise, mark it as reusable. Next, proceed to step 4: File-Level Incremental Compilation. Specifically, only compile the changed files, reuse the object files of the unchanged files, and update the linker files of the corresponding subsystems. Next, proceed to step 5: Independent Incremental Compilation for the Verification Environment. Specifically, determine if the verification environment has changed. If the verification environment files have not changed, keep the verification environment linker files unchanged; otherwise, only recompile the changed verification environment files.

[0077] After completing the incremental compilation of all subsystems, step 6, global fast linking, can be executed. Specifically, the linker files of all subsystems are collected, and symbol resolution and relocation are performed using the EDA linker to generate the final simulation executable file simv. Next, step 7, minimizing the reconstruction loop, is executed. During the simulation verification of the chip under test, any new changes are continuously monitored. If new changes occur, the process returns to step 3, and the executable file is regenerated until the simulation verification of the chip under test is completed.

[0078] It should be noted that the interpretations of the same or corresponding content in the embodiments of this application can be referred to each other, for example, regarding Figure 1 Explanation of step 110 Figure 2 The explanations of step 210 can be referenced together.

[0079] In large-scale SoC projects, full-chip simulation compilation time often lasts for hours or even tens of hours. Traditional EDA tools, in full-build mode, require recompiling the entire design even if only one file or test case is modified, severely limiting verification iteration efficiency. While some EDA tools offer block compilation or incremental compilation, the automatic partitioning of RTL blocks is often unreasonable, and incremental compilation fails to quickly identify incremental files, compiling unmodified files instead, thus failing to isolate the verification environment as an independent subsystem. Currently, there is a lack of a systematic, integrated acceleration solution that combines subsystem partitioning, file-level change detection, independent compilation of the verification environment, and incremental linking. Based on this, this application provides a five-stage pipelined compilation acceleration method, including a partitioning stage, an initial compilation stage, a change detection stage, an incremental compilation stage, and a rapid linking stage. Furthermore, by treating the verification environment as a special subsystem under unified management, the chip simulation method provided in this application features fine-grained incremental processing, decoupling of the verification environment from RTL, rapid iteration, and high scalability.

[0080] Please refer to Table 2 below, which compares the compilation scheme provided in the embodiments of this application with many aspects of traditional incremental compilation.

[0081]

[0082] Table 2 As shown in Table 2 above, the change detection granularity adopted in this application embodiment is finer, transforming the traditional module / library level change detection granularity into a file level. Furthermore, this application embodiment supports defining the verification environment as an independent subsystem for independent compilation, rather than mixing it with RTL. This application embodiment can fully reuse unmodified files, rather than reusing only a limited number of files. This application embodiment can achieve independent and rapid linking of compiled files, and the linking process does not involve recompilation. Moreover, traditional incremental compilation is typically only suitable for small to medium-scale chips under test, while the compilation scheme provided by this application embodiment is particularly suitable for large-scale / ultra-large-scale SoC chips.

[0083] For reference Figure 5 , Figure 5 This is a structural block diagram of a chip emulation device provided in an embodiment of this application. For example... Figure 5 As shown, the chip simulation device 500 provided in this application embodiment includes: an acquisition module 510, a compilation module 520, and a simulation verification module 530.

[0084] The acquisition module 510 is used to acquire the compileable module of the chip under test based on the chip design of the chip under test; the compileable module includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning; the first module includes multiple first sub-modules that are logically related in design, and the second module includes multiple second sub-modules, all of which are sub-modules whose module implementation code change frequency is lower than a threshold during a preset time period; and to acquire the compileable verification environment module; The compilation module 520 is used to perform compilation operations on the compilation module of the chip under test and the compilation verification environment module to obtain the executable file of the chip under test; The simulation verification module 530 is used to perform simulation verification on the chip under test based on the executable file.

[0085] In this embodiment, based on the chip design of the chip under test, a module to be compiled for the chip under test is obtained; the module to be compiled includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning; the first module includes multiple first sub-modules that are logically related in the design, and the second module includes multiple second sub-modules, all of which are sub-modules whose code change frequency is lower than a threshold during a preset time period; a compilation verification environment module is obtained; a compilation operation is performed on the module to be compiled and the compilation verification environment module of the chip under test to obtain an executable file of the chip under test; and simulation verification is performed on the chip under test based on the executable file. Therefore, compared to related technologies that do not consider the characteristics of the modules themselves when dividing the chip design, the embodiments of this application take into account the cohesion between modules or the stability of the modules themselves during the chip design division process of the chip under test. Sub-modules that are logically related are grouped into one module, and sub-modules whose implementation code changes less than a threshold are grouped into another module. This allows for a more reasonable division of the chip design under test, reducing duplicate compilations caused by unreasonable divisions, thereby improving the compilation efficiency of the chip under test and solving the problem of low compilation efficiency in related technologies. Simultaneously, it also enables the compilation operation of the compilation verification environment module for the chip under test, allowing for a more comprehensive simulation verification of the chip under test.

[0086] The chip simulation device provided in this application embodiment can implement all the processes implemented in the above method embodiments, and will not be described again here to avoid repetition.

[0087] like Figure 6As shown, this application embodiment also provides an electronic device 600, which can be an adapter or various types of computers, etc. The electronic device 600 includes a processor 610 and a memory 620. The memory 620 stores programs or instructions, which, when executed by the processor 610, implement the steps of any of the methods described above. For example, when the program is executed by the processor 610, it implements the following process: based on the chip design of the chip under test, obtain the compilation module of the chip under test; the compilation module includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning; the first module includes multiple first sub-modules that are logically related in the design, and the second module includes multiple second sub-modules, all of which are sub-modules whose code change frequency is lower than a threshold during a preset time period; obtain a compilation verification environment module; perform a compilation operation on the compilation module of the chip under test and the compilation verification environment module to obtain an executable file of the chip under test; and perform simulation verification on the chip under test based on the executable file. Therefore, compared to related technologies that do not consider the characteristics of the modules themselves when dividing the chip design, the embodiments of this application take into account the cohesion between modules or the stability of the modules themselves during the chip design division process of the chip under test. Sub-modules that are logically related are grouped into one module, and sub-modules whose implementation code changes less than a threshold are grouped into another module. This allows for a more reasonable division of the chip design under test, reducing duplicate compilations caused by unreasonable divisions, thereby improving the compilation efficiency of the chip under test and solving the problem of low compilation efficiency in related technologies. Simultaneously, it also enables the compilation operation of the compilation verification environment module for the chip under test, allowing for a more comprehensive simulation verification of the chip under test.

[0088] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the steps of various embodiments of the chip emulation method and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0089] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0090] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0091] This application provides a computer program product that is stored in a storage medium and executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, further details are omitted here.

[0092] It should be noted that, in this document, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0093] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of 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. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0094] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A chip simulation method, characterized in that, include: Based on the chip design of the chip under test, obtain the module to be compiled for the chip under test; The module to be compiled includes a first module obtained from the chip design based on cohesion partitioning, and a second module obtained from the chip design based on stability partitioning; the first module includes multiple first sub-modules that are logically related in the design, and the second module includes multiple second sub-modules, all of which are sub-modules whose module implementation code change frequency is lower than a threshold during a preset time period; Obtain the modules to be compiled and verified; Compilation operations are performed on multiple target modules to obtain multiple first files, and the multiple target modules correspond one-to-one with the multiple first files; wherein, the first module, the second module, and the verification environment module to be compiled are all target modules among the multiple target modules; the first file includes multiple sub-files, and the sub-files have file change identifiers indicating whether the sub-files have been modified; For any one of the plurality of target modules, if the first file corresponding to the target module has not been changed, the first file of the target module is determined as the compilation file of the target module; When the first file corresponding to the target module is changed, the file change identifier of each sub-file in the first file corresponding to the target module is obtained; based on the file change identifier of each sub-file in the plurality of sub-files, at least one target sub-file is determined from the plurality of sub-files; the file change identifier of each target sub-file in the at least one target sub-file indicates that the target sub-file has been changed; each target sub-file in the at least one target sub-file is recompiled to obtain at least one third file; the at least one target sub-file corresponds one-to-one with the at least one third file; the remaining sub-files in the plurality of sub-files other than the at least one target sub-file and the at least one third file are determined as the second file; the second file is determined as the compiled file of the target module; Based on the compilation file of each of the multiple target modules, the executable file of the chip under test is obtained; Based on the executable file, the chip under test is simulated and verified.

2. The method according to claim 1, characterized in that, The file change identifier includes a first change identifier and a second change identifier; obtaining the file change identifier of each sub-file in the first file corresponding to the target module includes: For any one of the multiple subfiles, perform the following operations: Obtain the first indication information of the sub-file at a first time point and the second indication information of the sub-file at a second time point; the first time point is the current time point, and the second time point is the time point when the sub-file last performed a compilation operation; If the first indication information is different from the second indication information, the file change identifier of the sub-file is determined to be the first change identifier, and the first change identifier indicates that the sub-file has undergone a file change; If the first indication information and the second indication information are the same, the file change identifier of the sub-file is determined to be the second change identifier, and the second change identifier indicates that the sub-file has not undergone file changes; Based on the multiple sub-files, the file change identifier of each sub-file in the multiple sub-files is obtained; Wherein, the first indication information and the second indication information are both file modification timestamps, or the first indication information and the second indication information are both Message Digest Algorithm Version 5 hash values.

3. The method according to claim 1, characterized in that, The at least one target sub-file that is recompiled is a sub-file in the first file corresponding to the verification environment module to be compiled.

4. The method according to claim 1, characterized in that, When the target module is the compilation and verification environment module, the first file corresponding to the compilation and verification environment module includes a simulation verification platform file and a test case file.

5. The method according to any one of claims 1-4, characterized in that, The plurality of first sub-modules include at least one first sub-module whose code implementation frequency during the preset time period is higher than a threshold, and / or the plurality of second sub-modules include at least two second sub-modules that are not logically related.

6. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a program or instructions that, when executed by the processor, implement the steps of the method as described in any one of claims 1-5.

7. A readable storage medium, characterized in that, The medium stores a program or instructions that, when executed, implement the steps of the method as described in any one of claims 1-5.

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

Images