Anomaly module determination method and apparatus, device, storage medium, and program product

Abstract

The present disclosure provides an abnormal module determination method and device, equipment, storage medium and program product, and relates to the technical field of chip simulation verification. The method comprises the following steps: acquiring the calling path of each module in a to-be-verified chip in the to-be-verified chip and source code file storage information of each module; determining at least one reuse module from each module based on the calling path corresponding to each module; and determining an abnormal module from the at least one reuse module based on the source code file storage information corresponding to each reuse module. The method can effectively eliminate the risk of simulation verification environment collapse caused by the need to remove or trim the source code file corresponding to the abnormal module in the subsequent process, thereby ensuring the integrity and stability of the verification environment.

Description

Technical Field

[0001] This disclosure relates to the field of chip simulation and verification technology, specifically to a method for determining abnormal modules, a device for determining abnormal modules, an electronic device, a non-transient computer-readable storage medium, and a computer program product. Background Technology

[0002] Currently, in simulation verification of large-scale system-on-chips (SoCs), block-based and focused verification is required to improve simulation speed. This often employs stub / shell (Dummy) techniques. When focusing on verifying a specific subsystem (Sub-System, SubSS) of the SoC, the subsystem that is not currently of interest is replaced with a simplified Dummy model. Simultaneously, the original Register-Transfer Level (RTL) source code files of the replaced subsystems, which implement their full functionality, need to be removed or trimmed from the filelist used to guide the simulation tool or simulator's compilation, and the corresponding Dummy model files need to be added. However, during the process of removing or trimming the RTL source code files corresponding to the subsystems replaced by Dummy models, files may be accidentally deleted due to non-standard physical storage locations of some modules, potentially leading to simulation verification environment crashes. Summary of the Invention

[0003] This disclosure provides an abnormal module determination method, an abnormal module determination device, an electronic device, a computer-readable storage medium, and a computer program product.

[0004] In a first aspect, embodiments of this disclosure propose a method for determining abnormal modules, comprising: obtaining the calling paths of each module in the chip to be verified and the source code file storage information of each module; determining at least one reused module from each module based on the calling paths corresponding to each module; and determining an abnormal module from at least one reused module based on the source code file storage information corresponding to each reused module.

[0005] Secondly, embodiments of this disclosure propose an abnormal module determination device, comprising: an acquisition unit, a first determination unit, and a second determination unit. The acquisition unit is configured to acquire the call paths of each module in the chip to be verified and the source code file storage information of each module; the first determination unit is configured to determine at least one reusable module from the various modules based on the call paths corresponding to each module; and the second determination unit is configured to determine an abnormal module from at least one reusable module based on the source code file storage information corresponding to each reusable module.

[0006] Thirdly, embodiments of this disclosure provide an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the abnormal module determination method described in any of the implementations of the first aspect above.

[0007] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a processor, when executed, to implement the abnormal module determination method as described in any implementation of the first aspect.

[0008] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the abnormal module determination method as described in any implementation of the first aspect.

[0009] According to the solution provided in this disclosure, given the call paths and source code file storage information corresponding to each module in the chip to be verified, one or more reusable modules can be accurately identified from the modules included in the chip to be verified based on the call paths corresponding to each module. Furthermore, one or more abnormal modules can be accurately identified from the reusable modules based on the source code file storage information corresponding to each reusable module. Thus, by automatically and accurately identifying abnormal modules in advance based on the call paths and source code file storage information corresponding to each module in the chip to be verified during the simulation verification code submission or simulation verification environment construction stage, the risk of simulation verification environment crashing due to the need to remove or trim the source code files corresponding to abnormal modules can be effectively eliminated, thereby ensuring the integrity and stability of the verification environment.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is an exemplary system architecture to which this disclosure can be applied; Figure 2 This is a flowchart of an abnormal module determination method provided in an embodiment of this disclosure; Figure 3 A flowchart of another method for determining abnormal modules provided in this disclosure embodiment; Figure 4 A schematic diagram illustrating the source code file dependencies of a module provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram illustrating the process of an abnormal module determination method in an application scenario provided by an embodiment of the present disclosure; Figure 6 A structural block diagram of an anomaly module determination device provided in an embodiment of this disclosure; Figure 7 This is a schematic diagram of the structure of an electronic device suitable for executing an abnormal module determination method, provided in an embodiment of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0013] It should be noted that the collection, acquisition, storage, processing, transmission, provision, disclosure, and application of user personal information (such as user identification information) involved in the technical solution disclosed herein are all carried out with the user's knowledge and explicit authorization, comply with the provisions of relevant laws and regulations, and do not violate public order and good morals.

[0014] Currently, in simulation verification of large-scale SoCs, block-based and focused verification is required to improve simulation speed. This often employs the Dummy technique, where, when focusing on a specific subsystem (Sub-System, SubSS) of the SoC, the subsystem that is not currently of interest is replaced with a simplified Dummy model. Simultaneously, the original RTL source code files implementing the full functionality of the subsystem replaced by the Dummy model need to be removed or trimmed from the filelist guiding the simulation tool or simulator's compilation, and the corresponding Dummy model files need to be added. This ensures that the Dummy model is compiled and linked into the entire design during the compilation process, rather than the original RTL source code files. However, this approach typically has the following drawbacks: (1) The above-mentioned method of directly removing or trimming the RTL source code files corresponding to the subsystems replaced by the Dummy model in the Filelist presents a contradiction between the logical reuse between modules and the physical storage of the RTL source code files corresponding to the relevant modules, resulting in an unclear dependency relationship between the reused modules and their corresponding file storage locations. For example, when a common module of a SoC is instantiated and used by multiple subsystems, such as SubSS_A and SubSS_B, the RTL source code files corresponding to the common module, which should be stored in the common file directory, are stored in the private file directory corresponding to SubSS_A. This results in an incorrect dependency relationship between the common module and its corresponding file storage location.

[0015] (2) When performing focused verification on SubSS_B, if the files stored in the corresponding private file directory in the Filelist are needed to remove or trim SubSS_A which is replaced by the Dummy model, the files corresponding to the public modules stored in the private file directory will also be removed. As a result, the retained SubSS_B will fail to compile (Compile Error) because it cannot find the files corresponding to the public modules, which may easily cause the simulation verification environment to crash.

[0016] (3) The errors that occur in (2) above are usually reported later in the compilation process of converting the corresponding RTL source code into a simulation model that the simulation tool can execute. Moreover, the error message usually does not indicate information related to the specific module, such as only indicating "Undefined Module". Later, a lot of time needs to be spent manually to trace which directory the file corresponding to the module was "hidden" in, which is inefficient and will affect the efficiency of verification iteration.

[0017] Therefore, how to avoid the accidental deletion of the corresponding files of public modules during the subsystem removal or trimming operation due to non-standard physical storage location of the files corresponding to public modules in the SoC verification process, which could cause the simulation verification environment to crash, has become an urgent technical problem to be solved.

[0018] The following description of several optional embodiments illustrates the technical solutions of this disclosure and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, learned from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0019] Figure 1 An exemplary system architecture 100 is shown that can be applied to an abnormal module determination method provided in embodiments of this disclosure.

[0020] like Figure 1 As shown, the exemplary system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the terminal devices 101, 102, and 103 and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0021] Users can use terminal devices 101, 102, and 103 to interact with the aforementioned server 105 via network 104 to receive or send messages, etc. Various applications for verification can be installed on terminal devices 101, 102, and 103 and server 105, such as verification-related applications.

[0022] Terminal devices 101, 102, and 103 and server 105 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices, and can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here. When server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When server 105 is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here.

[0023] Server 105 can provide various services through its built-in applications. Taking the verification application as an example, when running this application, Server 105 can achieve the following: Given the call paths and source code file storage information corresponding to each module in the chip to be verified, it can accurately extract one or more reusable modules from the modules included in the chip based on the call paths of each module. Furthermore, it can accurately identify one or more abnormal modules from the reusable modules based on the source code file storage information corresponding to each reusable module. Thus, by automatically and accurately identifying abnormal modules in advance based on the call paths and source code file storage information corresponding to each module in the chip to be verified during the simulation verification code submission or simulation verification environment construction stage, the risk of simulation verification environment crashing due to the need to remove or trim the source code files corresponding to abnormal modules can be effectively eliminated, thereby ensuring the integrity and stability of the verification environment.

[0024] It should be noted that, in addition to being obtained from terminal devices 101, 102, and 103 via network 104, the simulation database can also be pre-stored locally on server 105 through various means. Therefore, when server 105 detects that this data is already stored locally (for example, when starting to process previously retained verification tasks), it can choose to directly retrieve this data from locally. In this case, the exemplary system architecture 100 may also exclude terminal devices 101, 102, and 103 and network 104.

[0025] Since verification requires significant computing resources and power, the abnormal module determination method provided in the subsequent embodiments of this disclosure is generally executed by a server 105 with strong computing power and abundant computing resources. Correspondingly, the abnormal module determination device is also generally located in the server 105. However, it should also be noted that when terminal devices 101, 102, and 103 also possess sufficient computing power and resources, they can also perform the aforementioned calculations performed by the server 105 through their installed verification applications, thereby outputting the same results as the server 105. Especially when multiple terminal devices with different computing capabilities exist simultaneously, but the verification application determines that the terminal device has strong computing power and abundant remaining computing resources, the terminal device can perform the aforementioned calculations, thereby appropriately reducing the computing pressure on the server 105. Accordingly, the abnormal module determination device can also be located in the terminal devices 101, 102, and 103. In this case, the exemplary system architecture 100 may also exclude the server 105 and the network 104.

[0026] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0027] Please refer to Figure 2 , Figure 2 A flowchart of an abnormal module determination method provided in this disclosure embodiment, wherein process 200 includes the following steps: Step 201: Obtain the calling path of each module in the chip to be verified and the source code file storage information of each module.

[0028] This step aims to determine the aforementioned execution entity of the method by the exception module (e.g., Figure 1When performing chip simulation verification on a chip to be verified, the server 105 shown can obtain the call paths and source code file storage information corresponding to each module in the chip to be verified. The call path of each module in the chip to be verified can refer to the unique hierarchical location of the module, starting from the top-level module, through successive module instantiations, representing an abstract position in the chip design logic hierarchy. Optionally, the call path of each module in the chip to be verified can also be called the instantiation path or logical instantiation path. The source code file storage information can be used to describe or indicate the physical storage location or file system path (e.g., absolute file system path) of the source code file corresponding to the module, in order to accurately locate the corresponding source code file.

[0029] For example, each module in the chip to be verified can be understood as a basic functional unit constituting the chip, and can be a reusable design block. The modules in the chip to be verified include, but are not limited to: interface modules, such as bus interfaces, serial-to-parallel interfaces, etc.; storage modules, such as random access memory (RAM), read-only memory (ROM), etc.; data processing modules, such as multipliers, filters, etc.; control modules, such as timers, interrupt controllers, etc.; communication modules, such as universal asynchronous receiver transceivers (UART), inter-integrated circuits (I2C), serial peripheral interfaces (SPI), etc.; and power management modules, such as power gating, voltage regulation, etc. Optionally, the chip to be verified can be a System-on-a-Chip (SoC).

[0030] Step 202: Based on the call paths corresponding to each module, identify at least one reusable module from each module.

[0031] In this embodiment, based on the call paths of each module in the chip to be verified obtained in step 201 above, one or more reusable modules can be accurately identified from each module, i.e., from the modules (or all modules) included in the chip to be verified. In some optional implementations of this disclosure, each module in the chip to be verified can correspond to multiple different call paths, i.e., starting from the top-level module of the chip to be verified, through the hierarchical module instantiation of different paths, to reach the module respectively. Optionally, the reusable module identified above can refer to the module that is used or called based on different call paths.

[0032] In some optional implementations of the embodiments of this disclosure, one or more call paths of each of the above modules in the chip to be verified can be stored in the form of a call path list.

[0033] Step 203: Based on the source code file storage information corresponding to each reuse module, identify the abnormal module from at least one reuse module.

[0034] In this embodiment, based on the determination of at least one multiplexed module from the various modules of the chip to be verified in step 202 above, abnormal modules can be accurately identified or filtered from the at least one multiplexed module by combining the source code file storage information corresponding to each multiplexed module. The abnormal modules filtered from the multiplexed modules can refer to modules whose physical storage location of their corresponding source code files is determined to be abnormal or incorrect based on their source code file storage information.

[0035] According to the abnormal module determination method provided in this disclosure, given the call paths and source code file storage information corresponding to each module in the chip to be verified, one or more reusable modules can be accurately identified from the modules included in the chip to be verified based on the call paths corresponding to each module. Furthermore, one or more abnormal modules can be accurately identified from the reusable modules based on the source code file storage information corresponding to each reusable module. Thus, by automatically and accurately identifying abnormal modules in advance based on the call paths and source code file storage information corresponding to each module in the chip to be verified during the simulation verification code submission or simulation verification environment construction stage, the risk of simulation verification environment crashing due to the need to remove or trim the source code files corresponding to abnormal modules can be effectively eliminated, thereby ensuring the integrity and stability of the verification environment.

[0036] Please refer to Figure 3 , Figure 3 A flowchart of another method for determining abnormal modules provided in this disclosure embodiment, wherein process 300 includes the following steps: Step 301: Obtain the calling path of each module in the chip to be verified and the source code file storage information of each module.

[0037] The above steps 301 and as follows Figure 2 The steps shown in step 201 are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0038] Step 302: The modules corresponding to the call paths that are determined from each module and associated with different subsystems in the chip to be verified are identified as reuse modules.

[0039] In some optional implementations of the embodiments of this disclosure, the chip to be verified may include multiple subsystems, power management, chip-level input / output, etc. These multiple subsystems may correspond to different functional partitions within the chip to be verified, or can be understood as functional units with specific functions, comprising one or more modules; that is, the modules in the chip to be verified can be the basic functional units constituting the subsystems. Optionally, these multiple subsystems may include, but are not limited to: a processor subsystem, such as a central processing unit (CPU) or cache; a graphics processing subsystem, such as a graphics processing unit (GPU) responsible for graphics rendering; a storage controller subsystem, such as a double-rate synchronous dynamic random access memory (DDR) controller; and an artificial intelligence acceleration subsystem, such as an embedded neural network processing unit (NPU).

[0040] This step aims to determine the aforementioned execution entity of the method by the exception module (e.g., Figure 1 The server 105 shown, when determining one or more reused modules from the modules included in the chip to be verified based on the obtained call paths of each module in the chip to be verified, can identify or verify reused modules from the modules of the chip to be verified by determining whether each module is reused by call paths associated with different subsystems. Specifically, modules corresponding to (multiple) call paths associated with different subsystems in the chip to be verified can be determined as reused modules. Thus, in this embodiment, a module in the chip to be verified can be determined as a reused module when it corresponds to multiple call paths and these multiple call paths are associated with different subsystems in the chip to be verified. That is, a reused module corresponds to call paths associated with different subsystems in the chip to be verified.

[0041] In some optional implementations of the embodiments of this disclosure, the association of the subsystem with the call path may refer to the call path including an identifier related to the subsystem, such as the identifier of the subsystem and / or the identifier of the function corresponding to the subsystem.

[0042] Step 303: The module whose source code file storage information is determined from at least one reused module is associated with the subsystem in the chip to be verified, and is identified as an abnormal module.

[0043] In some optional implementations of the embodiments of this disclosure, the source code file storage information of each module in the module to be verified may include, but is not limited to, the identifiers corresponding to each file storage directory level and the specific file names, etc., wherein the identifiers of the file storage directory levels may include, but are not limited to, at least one of the following: the identifier of the project root directory, the identifier of the module, the identifier related to the subsystem, the identifier of the public file directory, etc.

[0044] In this embodiment, when the execution entity determines one or more abnormal modules from at least one multiplexed module included in the chip to be verified based on the obtained source code file storage information of each multiplexed module, it can identify or verify the abnormal module from the at least one multiplexed module by determining whether the source code file storage information of each multiplexed module is associated with a subsystem in the chip to be verified. Thus, in this embodiment, if the source code file storage information of a multiplexed module in the chip to be verified is associated with any subsystem in the chip to be verified, the multiplexed module can be determined as an abnormal module, that is, the source code file storage information of the abnormal module is associated with a subsystem in the chip to be verified.

[0045] In some optional implementations of the embodiments of this disclosure, the association of the source code file storage information of the subsystem and the reuse module may refer to the fact that the source code file storage information includes an identifier related to the subsystem, such as the identifier of the subsystem and / or the identifier of the function corresponding to the subsystem.

[0046] According to the abnormal module determination method provided in this disclosure, after obtaining the call paths and source code file storage information corresponding to each module in the chip to be verified, the method first accurately determines the modules instantiated by different subsystems in the chip to be verified, i.e., reused modules, based on the call paths corresponding to each module. That is, when performing block-based and focused verification on different subsystems of the chip to be verified, the same instantiated modules can be called reused modules. By reusing the same module or design module in multiple different subsystems, there is no need for repeated development, which can shorten the development cycle and improve the stability of the design and the reliability of the verification. Furthermore, by tracing the source code file storage information of each reused module, the method can automatically and accurately verify the modules that should be stored in the public file directory but are incorrectly stored in the private file directory of the specific subsystem because the source code file storage information is associated with the specific subsystem, i.e., abnormal modules.

[0047] Thus, by identifying and verifying abnormal modules whose physical storage ownership contradicts their logical reuse identity during the simulation verification code submission or simulation verification environment construction phases, based on whether the call paths and source code file storage information of each module in the chip to be verified are associated with the subsystems in the chip to be verified, abnormal modules can be automatically and accurately identified or verified. By discovering the implicit dependencies between the physical storage ownership of reused modules and specific subsystems of the chip to be verified in advance, the risk of simulation verification environment crashing due to the accidental deletion of source code files of reused modules stored in the private file directory of the specific subsystem caused by the need to remove or trim the source code files of the specific subsystem that were replaced by the Dummy model can be effectively eliminated. This ensures the integrity and stability of the verification environment.

[0048] In one specific embodiment of this disclosure, the call path corresponding to each module in the chip to be verified includes the identifier of the corresponding subsystem in the chip to be verified, and the source code file storage information corresponding to each module may include, but is not limited to, the identifiers corresponding to each file storage directory level and the specific file names. For example, when the module in the chip to be verified is a reused module, its corresponding source code file storage information should include the identifier of the public file directory; while when the module is a non-reuse module, its corresponding source code file storage information should include the identifier of the private file directory, such as the identifier of the corresponding subsystem.

[0049] In this specific embodiment, modules that are identified from the various modules of the chip to be verified and include call paths associated with the identifiers of different subsystems in the chip to be verified can be identified as reused modules.

[0050] Furthermore, multiplexing modules whose source code file storage information, determined from at least one multiplexing module based on subsystem identifier verification, is associated with the identifier of the subsystem in the chip to be verified, can be identified as abnormal modules. In other words, modules whose source code file storage information, filtered from multiplexing modules, includes the identifier of a subsystem can be judged as abnormal modules. In this embodiment, when the source code file storage information of a multiplexing module includes the identifier of a subsystem, it indicates that the physical storage location of the source code file corresponding to the multiplexing module contradicts its current cross-functional partitioning, i.e., being reused by different subsystems. Furthermore, during simulation verification, when focusing on verifying the subsystems associated with the multiplexing module and replacing another part of the unimportant subsystems with a dummy model, the accidental deletion of the source code file corresponding to the multiplexing module may affect the subsequent compilation related to the subsystem to be verified.

[0051] For example, such as Figure 4As shown, for module A (mod_A) in the SoC of the chip to be verified, it is instantiated and reused by sub-system 1 (ss1) and sub-system 2 (ss2). This can be referred to... Figure 3 In the logic design view section, module A is a reused module, and its two corresponding call paths within the entire chip under test can be represented as "tb_top.dut.ss1.mod_A" and "tb_top.dut.ss2.mod_A". Further details can be found by referring to... Figure 4 In the physical storage view, the private file directory (file storage directory 1) corresponding to subsystem 1 for reusable module A can be represented as / project / ss1 / src, and the private file directory (file storage directory 2) corresponding to subsystem 2 can be represented as / project / ss2 / src. The source code file (represented as module_a.v) corresponding to reusable module A is stored in file storage directory 1. Therefore, when instantiating module A for simulation verification of subsystem 1, the compilation depends on the source code file corresponding to module A stored in file storage directory 1. However, when instantiating module A for simulation verification of subsystem 2, it requires cross-functionality instantiation, i.e., illegally depends on the source code file corresponding to module A stored in file storage directory 1. Thus, if focused verification of subsystem 2 requires performing a dummy model replacement on subsystem 1 to remove its corresponding file in file storage directory 1, the source code file corresponding to module A may be mistakenly deleted. Further simulation verification of subsystem 2 will then report an error due to missing files. In this case, module A can be classified as an abnormal module.

[0052] In the above Figure 2 or Figure 3 Based on the corresponding embodiments, in some optional implementations, a corresponding reuse identifier can be set for at least one reuse module determined from the modules of the chip to be verified, so as to classify and mark the reuse modules.

[0053] In the above Figure 2 or Figure 3 Based on the corresponding embodiments, in some optional implementations, the above steps 201 or 301 can be executed as follows: pre-compile all source code files corresponding to the chip to be verified to obtain compiled information; extract the logic instantiation information and source code file storage information corresponding to each module from the compiled information, wherein the logic instantiation information includes the calling path of each module in the chip to be verified.

[0054] In this embodiment, to ensure the completeness and accuracy of obtaining the call paths and source code file storage information corresponding to each module in the chip under test, all source code files corresponding to the chip under test can be pre-compiled. The required information is obtained by extracting the source code file storage information and the logical instantiation information, including the call paths corresponding to each module, from the pre-compiled information. Specifically, the logical instantiation information corresponding to each module can record all call paths of that module throughout the entire chip under test.

[0055] In some optional implementations of the embodiments of this disclosure, the compiled information obtained by pre-compiling all source code files corresponding to the chip to be verified can be stored in a simulation database. That is, the simulation database can store the source code file storage information and logic instantiation information corresponding to each module in the chip to be verified. This simulation database can also be called a compiled database. This database ensures that a definite, simulable real hardware logic is obtained and ensures the accuracy of abnormal module identification.

[0056] In this embodiment, considering that macro definitions and conditional compilation instructions are commonly used in SoC design and verification programs to select different code segments based on different configurations, the source code may contain multiple optional design versions adapted to different application scenarios or functional configurations. Which version is compiled depends on the macros defined during compilation. Directly parsing the source code may not reveal the actual compiled hardware logic, introducing uncertainty. Therefore, to ensure the accuracy of the reused and abnormal modules identified based on the simulation database, the execution entity can pre-compile the entire chip-level source code of the chip to be verified. By processing macro definitions and conditional compilation instructions, unnecessary code segments are excluded, and corresponding macro definitions are replaced with specific values. This ensures that the information in the generated simulation database is the version after macro definition expansion and conditional compilation, rather than the multiple conditional branches that may exist in the source code, thus providing clarity.

[0057] In some optional implementations of the embodiments of this disclosure, the steps of extracting the logical instantiation information and source code file storage information corresponding to each module from the compiled information can be performed as follows: traversing the compiled information stored in the simulation database using a database parsing tool to extract the logical instantiation information and source code file storage information associated with the identifiers of each module.

[0058] In this embodiment, a database parsing tool can traverse the compiled information stored in the simulation database, obtained by pre-compiling all source code files corresponding to the chip to be verified. Using the identifiers of each module as indexes, it can efficiently and accurately extract the source code file storage information associated with each module's identifier, as well as the logical instantiation information including the call paths corresponding to each module. Optionally, this database parsing tool may include, but is not limited to, the Verdi Interoperability Apps (VIA) platform, specifically through the application programming interface (API) provided by VIA for information extraction.

[0059] In some optional implementations of this disclosure, the aforementioned simulation database is a binary database formed by pre-compiling all source code files corresponding to the chip to be verified using a simulation tool. Thus, pre-compiling the entire chip-level source code into a binary database using a simulation tool facilitates efficient information analysis during the verification of reused and abnormal modules, and ensures that the provided data represents the hardware logic that will actually run in the simulation after macro definition expansion and conditional compilation. Optionally, the simulation tool used for pre-compilation may include, but is not limited to, Verdi or VCS (Verilog Compiler Simulator / Verilog Compiler Simulator), and the generated binary database includes information related to the complete design hierarchy of the chip to be verified, such as, but not limited to, the logic instantiation information and source code file storage information corresponding to each module in the chip to be verified.

[0060] In some optional implementations of this disclosure, to ensure that the actual physical storage path of the source code file can be uniquely and accurately located based on the storage information of the source code file corresponding to each module, the storage information of the source code file corresponding to the target module can be determined in advance based on the actual physical storage path of the source code file corresponding to the target module with the same name but different libraries specified in the library mapping file during the generation of the simulation database, and when a library mapping file exists. That is, the library where the source code file corresponding to the target module is located can be clearly indicated by the configuration information in the library mapping file. In this way, while ensuring that the false alarm rate is minimized in complex engineering environments, the actual storage path of the corresponding module can be determined by parsing once, which can improve the efficiency of subsequent information extraction or acquisition based on the simulation database. Here, the above-mentioned library can refer to a design library or source code library, which is a structured collection for storing and organizing various source code files, such as RTL source code files. Multiple different libraries may contain module versions with the same name but different implementations, such as a stable version and a performance-enhanced version of the same module.

[0061] According to the abnormal module determination method provided in this disclosure, modules instantiated by multiple subsystems of the chip under test (i.e., reused under a multi-functional partition) can be accurately identified based on the logical instantiation information of each module included in the simulation database associated with the chip under test. Then, by tracing the source code file storage information of the reused modules included in the simulation database, modules whose source code files should be stored in a public file directory but are incorrectly stored in the private file directory of a specific subsystem due to the association of the source code file storage information with that specific subsystem are identified as abnormal modules. Thus, during the simulation verification code submission or simulation verification environment construction phase, abnormal modules whose physical storage ownership contradicts their logical reuse identity can be automatically and accurately identified in advance. By discovering the implicit dependency between the physical storage ownership of reused modules and the specific subsystem of the chip under test in advance, the risk of simulation verification environment crashes due to the need to remove or trim the source code files corresponding to the specific subsystem replaced by the Dummy model can be eliminated, thereby ensuring the integrity and stability of the verification environment during configuration switching.

[0062] In some optional implementations of the embodiments of this disclosure, before extracting the logical instantiation information and source code file storage information corresponding to each module from the compiled information, the above-mentioned abnormal module determination method further includes: in response to determining that the source code files corresponding to each module in the chip to be verified are written based on the target hardware description language, recording the operation of determining abnormal modules that do not support source code files written based on the target hardware description language, and exiting the operation of precompiling all source code files corresponding to the chip to be verified.

[0063] In this embodiment, to ensure the successful verification of abnormal modules whose physical storage ownership contradicts their logical reuse identity, and thus guarantee the consistency between the verification results and simulation behavior, it is necessary to further clarify the applicable scenarios of the verification scheme provided in this embodiment. Specifically, it is necessary to pre-identify the programming language of the source code files corresponding to each module in the chip to be verified. Optionally, if it is identified that the source code files corresponding to each module in the chip to be verified are written in a target hardware description language (HDL), i.e., a format file that is incompatible with the abnormal module determination scheme provided in this embodiment, to avoid program crashes, processing of related files written in the target HDL should be avoided. That is, the pre-compilation operation of all source code files corresponding to the chip to be verified should be exited, and the unsupported type should be recorded, i.e., the operation of identifying abnormal modules using source code files written in the target HDL should be recorded. For example, this can be recorded in a relevant log. Optionally, the target HDL includes, but is not limited to, HDL (Hardware Description Language) or VHDL (VHSIC (Very High Speed ​​Integrated Circuit) Hardware Description Language).

[0064] In some optional implementations of the embodiments of this disclosure, the source code files corresponding to each module in the chip to be verified can be written based on a supported hardware description language such as Verilog or SystemVerilog. Thus, when it is identified that the source code files corresponding to each module in the chip to be verified are written based on such a supported hardware description language, abnormal modules can be determined. By conditionally initiating the determination of abnormal modules, the verification efficiency and accuracy of abnormal modules can be improved.

[0065] In some optional implementations of any of the above embodiments of this disclosure, the abnormal module determination method provided by the embodiments of this disclosure may further include the following: generating a verification report for the abnormal module.

[0066] In this embodiment, based on the identification of the abnormal module, a verification report can be further generated for that abnormal module. Optionally, the verification report may include, but is not limited to, at least one of the following: the identifier of each abnormal module, the source code file storage information corresponding to each abnormal module, and the identifiers of all subsystems that indicate the reuse of the abnormal module, i.e., the identifiers of all subsystems associated with the abnormal module. Through this verification report, a complete information chain of the abnormal module can be constructed from its logical call, physical affiliation to its reuse scope, so as to explicitly associate the characteristics of the abnormal module and its reuse status. The identifier of the abnormal module is usually its unique logical instantiation name, call name, or universally unique identifier, which can be used to accurately locate the abnormal module.

[0067] In some optional implementations of the embodiments of this disclosure, the aforementioned verification report can be a structured or semi-structured data carrier. The output form of the verification report includes, but is not limited to, tables, such as tables in a database, standard data tables in Excel, complex tables in Word documents, Extensible Markup Language (XML), JSON, or plain text tables. Thus, by making the information related to the verified abnormal modules explicit and traceable, the efficiency of performing operations related to the abnormal modules based on the generated verification report, which ensure the integrity and stability of the simulation verification environment during configuration switching, can be improved. Simultaneously, the cost of manually tracing abnormalities can be saved, the efficiency of troubleshooting can be improved, and the impact on the efficiency of verification iteration can be reduced.

[0068] Based on any of the above embodiments, in order to clarify how to specifically ensure the integrity and stability of the verification environment during configuration switching, at least one of the following implementation methods can be provided to perform related actions on abnormal modules based on the generated verification report, which can ensure the integrity and stability of the simulation verification environment during configuration switching.

[0069] In some optional implementations of the embodiments of this disclosure, when the identified abnormal module is reused by the first subsystem and the second subsystem in the chip to be verified, and the identifier of the second subsystem is included in the source code file storage information corresponding to the abnormal module, the abnormal module determination method provided in the embodiments of this disclosure may further include the following: during the process of simulating and verifying the first subsystem and replacing the second subsystem with an empty shell model, based on the verification report, a blocking removal instruction is generated for the source code file corresponding to the abnormal module, wherein the blocking removal instruction is used to instruct the blocking removal operation to be performed on the source code file corresponding to the abnormal module.

[0070] In this embodiment, based on the generated verification report for the abnormal module, in order to effectively ensure the integrity and stability of the simulation verification environment during configuration switching and avoid accidental deletion of related public files when performing subsystem removal or trimming operations due to non-standard physical storage location of the source code file corresponding to the abnormal module, a blocking removal instruction for the source code file corresponding to the abnormal module to be removed or trimmed can be generated based on the above verification report. Through this blocking removal instruction, when focusing on the simulation verification of the first subsystem of a specific subsystem reusing the abnormal module, such as the first subsystem of multiple subsystems of the chip to be verified, and when it is necessary to remove or trim a subsystem that does not need to be concerned, such as the second subsystem of the multiple subsystems that is different from the first subsystem, that is, when it is necessary to replace the second subsystem that reuses the abnormal module with the first subsystem with an empty shell model, the blocking removal operation is instructed to be performed on the source code file corresponding to the abnormal module, that is, to refuse to remove the source code file corresponding to the abnormal module. The identifier of the second subsystem is included in the storage information of the source code file corresponding to the abnormal module.

[0071] In this embodiment, when simulation verification of the first subsystem is required, and the entire second subsystem needs to be replaced with a dummy model, a blocking removal command can be triggered in real time. The operation indicated by this blocking removal command can eliminate the risk of verification environment crashes caused by configuration switching operations in advance. This ensures that the simulation verification of the first subsystem is not affected by the physical misalignment of the source code files corresponding to the abnormal modules, achieving a lossless replacement of the corresponding subsystem with a dummy model. The dummy model can be understood as an interface simulation surrogate for the atomic system, retaining only port declarations and basic timing behavior, but containing no internal logic.

[0072] In some alternative implementations of the embodiments of this disclosure, the abnormal module determination method provided in the embodiments of this disclosure may further include the following: based on the verification report, migrating the source code file corresponding to the abnormal module to a public file directory for storage, and updating the source code file storage information corresponding to the abnormal module based on the public file directory.

[0073] In this embodiment, based on the generated verification report for the abnormal module, in order to effectively ensure the integrity and stability of the simulation verification environment during configuration switching and avoid accidental deletion of related public files when performing subsystem removal or trimming operations due to non-standard physical storage location of the source code files corresponding to the abnormal module, a protection action can be automatically and timely triggered before the removal or trimming of the source code files corresponding to the abnormal module is required for focused verification of a specific subsystem that reuses the abnormal module in the chip under verification. This action involves adjusting the physical storage location of the source code files corresponding to the abnormal module in advance, that is, migrating the source code files corresponding to the abnormal module to a public file directory for storage, so as to avoid the simulation verification environment crashing due to accidental file deletion.

[0074] Simultaneously, to ensure accurate replacement of the subsystem reusing the anomalous module with a dummy model for subsequent focused verification, and to accurately locate and successfully delete the source code file corresponding to the anomalous module, it is necessary to update the source code file storage information of the anomalous module in the simulation database based on the current public file directory where the source code file corresponding to the anomalous module is located. This also allows the anomalous module to be converted into a regular reusable module, enabling successful execution of related operations on the source code file corresponding to the reusable module in the public file directory during simulation verification of subsystems instantiated using this reusable module. For example, this can be achieved by replacing the subsystem identifier in the original source code file storage information stored in the simulation database with an identifier corresponding to the public file directory.

[0075] In this embodiment, compared to the blocking and removal instructions in the above implementation, which sequentially reject the deletion operation of the source code file corresponding to the abnormal module when it is necessary to replace each subsystem reusing the abnormal module with a Dummy model, the above-mentioned migration of physical storage location operation can directly eliminate the conditions for the generation of abnormal state of the reuse module. After the migration is completed, the source code file storage information of the abnormal module no longer includes any subsystem identifier, and the subsequent reuse module verification process will automatically determine that it is no longer an abnormal module, which can further improve the stability of simulation verification. At the same time, each subsystem can obtain the complete source code file from the common file directory when reusing the abnormal module.

[0076] In some optional implementations of the embodiments of this disclosure, the abnormal module determination method provided by the embodiments of this disclosure may further include the following: generating a warning log for the abnormal module based on the verification report.

[0077] In this embodiment, based on the generated verification report for the abnormal module, a verification report for the abnormal module is pre-generated. This warning log, during simulation verification of a subsystem reusing the abnormal module, can promptly prompt for actions such as blocking and removing the source code file corresponding to the abnormal module, and / or migrating the source code file to a public file directory for storage. In other words, the warning log is used to prompt for actions such as blocking and removing the source code file corresponding to the abnormal module, and / or migrating it to a public file directory for storage during simulation verification of a subsystem reusing the abnormal module. Thus, when a reusing module (i.e., an abnormal module) whose source code file storage information includes the subsystem's identifier is detected—meaning the source code file corresponding to the abnormal module is verified to be stored in the subsystem's private file directory—protection actions are triggered promptly and automatically. This ensures that subsequent operations can seamlessly replace the corresponding subsystem with a dummy model, improving the efficiency of simulation verification.

[0078] It should be noted that the descriptions related to performing blocking and removal operations on the source code files corresponding to the abnormal modules, and migrating the source code files corresponding to the abnormal modules to a public file directory for storage, can be referred to the content in the corresponding implementation methods above, and will not be repeated here.

[0079] In some optional implementations of the embodiments of this disclosure, the warning log may include, but is not limited to, the identifier of the verified abnormal module, the physical storage location information of the abnormal module, i.e., the source code file storage information corresponding to the abnormal module, and the reuse status of the abnormal module, such as the identifiers of all subsystems that reuse the abnormal module.

[0080] It should be noted that there is no causal or dependency relationship between the above-mentioned different implementation methods, and they do not necessarily need to be applied in the same embodiment at the same time. They can be applied in different embodiments as needed. That is, at least one of the following operations can be performed based on the verification report: generating a blocking removal instruction for the source code file corresponding to the abnormal module; migrating the source code file corresponding to the abnormal module to the public file directory; and generating a warning log for the abnormal module.

[0081] The solution provided in this disclosure can generate a verification report based on abnormal modules whose physical storage ownership is inconsistent with their logical reuse identity, which are automatically and accurately verified in advance during the simulation verification code submission or simulation verification environment construction stage. Based on the verification report, the solution can automatically and timely trigger the execution of corresponding protection operations for the abnormal modules, so as to ensure that the corresponding subsystem can be replaced with the Dummy model without loss in the future. This helps to improve the efficiency of simulation verification, save the cost of manually tracing anomalies, improve the efficiency of investigation, and reduce the impact on the efficiency of verification iteration.

[0082] To deepen understanding, refer to Figure 5 This disclosure also provides a specific implementation scheme in conjunction with a specific application scenario. This implementation scheme can provide an automated verification method for ensuring the consistency of module reuse relationships and file physical storage locations during the development of SoC for integrated circuit design and verification.

[0083] In this implementation, Electronic Design Automation (EDA) tools can be used to generate a compiled full-chip database (corresponding to the simulation database in the above embodiment). By parsing this compiled database, the actual hardware instantiation relationships are extracted and cross-referenced with the physical paths of the file system to construct the mapping relationship between the logical topology (or logical instantiation topology) of the module and the physical file path. This allows for the automated detection and reporting of abnormal modules that are "reused in multiple places but whose source code files are stored in the private directory of the subsystem," thereby ensuring the integrity and stability of the simulation verification environment during configuration switching (such as replacement operations based on the dummy model). The process corresponding to this implementation can include the following main steps: Step 501: Build a full-chip database.

[0084] In this embodiment, simulation tools (such as Verdi / VCS) can be used to pre-compile the entire chip-level source code of the SoC, generating a binary database (such as simv.daidir or fsdb) containing the complete design hierarchy. This ensures that the information provided by the database represents the actual hardware logic after macro definition expansion and conditional compilation. Thus, compared to traditional text scanning, this implementation, by parsing the compiled database instead of relying on static text lists, can accurately handle macro definitions, nested include structures, and conditional compilations corresponding to source code written in Verilog or SystemVerilog languages, thereby ensuring that the verification results are completely consistent with the simulation behavior.

[0085] Step 502: Traverse the database to extract module information.

[0086] In this embodiment, the script corresponding to this implementation can be run via command line, specifying the corresponding simulation database and the top-level path of the SoC to be verified, to determine the verification scope. Further, the script can call a database parsing tool (such as the Verdi Apps interface) to traverse the information of all modules in the database to extract the logical instantiation information (Instance Info) and physical file information (File Path Info) corresponding to each module (corresponding to the source code file storage information in the above embodiment). The logical instantiation information can be used to record the list of instantiation paths for each module throughout the chip, and the physical file information can be used to record the specific absolute file system path of the source code file corresponding to each module.

[0087] Step 503: Determine whether the module is reused in multiple places.

[0088] In this embodiment, the logical instantiation information of each module can be analyzed. If the instantiation path list of a module contains the identifiers of two or more different top-level subsystems, for example, if the instantiation path list contains both subsystem identifiers ss0 and ss1, it is determined that the module is reused in multiple places, and the module can be marked as a reused module, and step 504 can be executed. If it is determined that the module is not reused in multiple places, step 506 is executed.

[0089] Step 504: Determine whether the physical storage path of the source code file corresponding to the reuse module is located in the private file directory of the subsystem to perform location compliance verification.

[0090] In this embodiment, for the reuse module, its physical file information is checked, that is, whether its corresponding source code file is stored in the private file directory of the subsystem. If so, step 505 is executed; otherwise, step 506 is executed. Optionally, the judgment rule can be: whether the physical storage path information of the source code file corresponding to the reuse module contains the identifier of a specific subsystem.

[0091] Step 505: Mark the abnormal module.

[0092] In this embodiment, if step 504 determines that the physical storage path information of the source code file corresponding to the reuse module includes the identifier of a specific subsystem, such as the name of a private file directory (e.g., / ss0 / src / ), instead of the name of a public file directory (e.g., / common / ), then the reuse module can be marked as an abnormal module with dependency integrity risk. Thus, by verifying the module's reusability (whether it is instantiated and used by multiple subsystems) and its physical affiliation (whether it is located in the private file directory corresponding to the subsystem), potential dependency loss risks can be identified.

[0093] Step 506: Skip the current module and validate the next module.

[0094] Step 507: Generate a verification report, that is, output the verification results and generate an information list related to the non-compliant module or abnormal module.

[0095] In this embodiment, the physical location and reuse status of all abnormal module machines can be listed in tabular form.

[0096] Step 508: In response to replacing a specific subsystem of the instantiated exception module with a Dummy model, the deletion operation of the source code file corresponding to the specific subsystem can be automatically blocked based on the above verification report before executing the Dummy script, or the source code file corresponding to the specific subsystem can be automatically migrated to a public file directory and the reference path can be corrected. Optionally, a warning log can also be generated based on the above verification report to prompt the execution of the above blocking deletion operation or file migration operation. In this way, when it is detected that the source code file corresponding to the public module, i.e., the reused module, is located in the private directory corresponding to the subsystem to be removed, the protection action is automatically triggered to achieve lossless Dummy operation.

[0097] The automated verification implemented in the above method can identify implicit dependencies of the aforementioned abnormal modules in advance during the code submission or verification environment construction phase. This eliminates the risk of environment crashes caused by subsequent dummy operations, thereby improving the stability of the verification environment. Furthermore, this also provides an objective quality inspection method that can standardize the storage and management of source code files for common modules, i.e., reusable modules, and avoid parasitic design.

[0098] During the execution of the above-described implementation, if source code files written in HDL or VHDL (i.e., HDL or VHDL format files) are encountered, logs are logged and "Unsupported Type" is marked in the verification report accordingly. This avoids program crashes by identifying and skipping formats that do not support hierarchical analysis. Furthermore, if a Libmap exists, the actual physical storage path of modules with the same name but different libraries specified in the Libmap can be used to enable the script to perform corresponding verifications based on the parsed final physical storage path, ensuring that the false positive rate is minimized in complex engineering environments. Thus, filtering and exception handling mechanisms are provided during the verification process.

[0099] Further reference Figure 6 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of an anomaly module determination device, which is similar to... Figure 2 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices (e.g., servers).

[0100] like Figure 6 As shown, the abnormal module determination device 600 of this embodiment may include: an acquisition unit 601, a first determination unit 602, and a second determination unit 603.

[0101] The acquisition unit 601 is configured to acquire the call path of each module in the chip to be verified and the source code file storage information of each module; the first determination unit 602 is configured to determine at least one reused module from each module based on the call path corresponding to each module; and the second determination unit 603 is configured to determine an abnormal module from at least one reused module based on the source code file storage information corresponding to each reused module.

[0102] In this embodiment of the disclosure, the specific processing of the acquisition unit 601, the first determination unit 602, and the second determination unit 603 in the above-mentioned anomaly module determination device 600, and the resulting technical effects, can be referred to respectively. Figure 2 The relevant descriptions of steps 201-203 in the corresponding embodiments will not be repeated here.

[0103] In some optional implementations of the embodiments of this disclosure, the first determining unit 602 is further configured to: determine the modules corresponding to the call paths determined from each module and associated with different subsystems in the chip to be verified as reuse modules.

[0104] In some optional implementations of the embodiments of this disclosure, the second determining unit 603 is further configured to: determine the module that associates the source code file storage information determined from at least one reuse module with the subsystem in the chip to be verified as an abnormal module.

[0105] In some optional implementations of the embodiments of this disclosure, the acquisition unit 601 is further configured to: pre-compile all source code files corresponding to the chip to be verified to obtain compiled information; extract the logic instantiation information and source code file storage information corresponding to each module from the compiled information, wherein the logic instantiation information includes the calling path of each module in the chip to be verified.

[0106] In some optional implementations of the embodiments of this disclosure, the above-mentioned compiled information is stored in a simulation database; and the acquisition unit 601 is further configured to: traverse the compiled information stored in the simulation database through a database parsing tool to extract the logical instantiation information and source code file storage information associated with the identifiers of each module.

[0107] In some optional implementations of the embodiments of this disclosure, the above-mentioned simulation database is a binary database formed by pre-compiling all source code files corresponding to the chip to be verified using simulation tools.

[0108] In some optional implementations of the embodiments of this disclosure, the above-mentioned abnormal module determination device 600 may further include a recording unit (not shown in the figure), configured to: before extracting the logical instantiation information and source code file storage information corresponding to each module from the compiled information, in response to determining that the source code files corresponding to each module in the chip to be verified are written based on the target hardware description language, record the operation of determining abnormal modules that do not support source code files written based on the target hardware description language, and exit the operation of pre-compiling all source code files corresponding to the chip to be verified.

[0109] In some optional implementations of the embodiments of this disclosure, the above-mentioned abnormal module determination device 600 may further include a report generation unit (not shown in the figure), configured to generate a verification report for the abnormal module, wherein the verification report includes the identifier of the abnormal module, the source code file storage information corresponding to the abnormal module, and the identifiers of all subsystems that reuse the abnormal module.

[0110] In some optional implementations of the embodiments of this disclosure, the above-mentioned abnormal module is reused by a first subsystem and a second subsystem in multiple subsystems, and the identifier of the second subsystem is included in the source code file storage information corresponding to the abnormal module; and the above-mentioned abnormal module determination device 600 may further include an instruction generation unit (not shown in the figure), which is configured to: generate a blocking removal instruction for the source code file corresponding to the abnormal module based on the verification report during the process of simulating and verifying the first subsystem and replacing the second subsystem with an empty shell model, wherein the blocking removal instruction is used to instruct the blocking removal operation to be performed on the source code file corresponding to the abnormal module.

[0111] In some optional implementations of the embodiments of this disclosure, the above-mentioned abnormal module determination device 600 may further include a storage unit (not shown in the figure), which is configured to: migrate the source code file corresponding to the abnormal module to a public file directory for storage based on the verification report, and update the storage information of the source code file corresponding to the abnormal module based on the public file directory.

[0112] In some optional implementations of the embodiments of this disclosure, the above-mentioned abnormal module determination device 600 may further include a log generation unit (not shown in the figure), configured to: generate a warning log for the abnormal module based on the verification report, wherein the warning log is used to prompt the execution of blocking and removal operations on the source code file corresponding to the abnormal module and / or migration of the source code file corresponding to the abnormal module to a public file directory for storage during the simulation verification of the subsystem for reusing the abnormal module.

[0113] This embodiment exists as a device embodiment corresponding to the above method embodiment. The key steps or equivalent technical means that can be implemented by each component in the anomaly module determination device 600 embodiment provided in this embodiment, as well as the technical effects brought about by this device embodiment, can be referred to the relevant descriptions in the above method embodiments, and will not be repeated here.

[0114] According to embodiments of this disclosure, this disclosure also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the abnormal module determination method described in any of the above embodiments when executed.

[0115] According to embodiments of this disclosure, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions that enable a computer to implement the abnormal module determination method described in any of the above embodiments when executed.

[0116] According to embodiments of this disclosure, this disclosure also provides a computer program product, which includes a computer program that, when executed by a processor, can implement the abnormal module determination method described in any of the above embodiments.

[0117] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. Electronic device 700 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 700 may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0118] like Figure 7As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0119] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of displays, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0120] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as the anomaly module determination method. For example, in some embodiments, the anomaly module determination method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the anomaly module determination method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform the anomaly module determination method by any other suitable means (e.g., by means of firmware).

[0121] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0122] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0123] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0124] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0125] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0126] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, distributed system servers, or servers incorporating blockchain technology. Cloud servers, also known as cloud computing servers or cloud hosts, are a hosting product within the cloud computing service ecosystem, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak business scalability.

[0127] According to the technical solution of this disclosure, given the call paths and source code file storage information corresponding to each module in the chip to be verified, one or more reusable modules can be accurately extracted from the modules included in the chip to be verified based on the call paths corresponding to each module. Furthermore, one or more abnormal modules can be accurately identified from the reusable modules based on the source code file storage information corresponding to each reusable module. Thus, by automatically and accurately identifying abnormal modules in advance based on the call paths and source code file storage information corresponding to each module in the chip to be verified during the simulation verification code submission or simulation verification environment construction stage, the risk of simulation verification environment crashing due to the need to remove or trim the source code files corresponding to abnormal modules can be effectively eliminated, thereby ensuring the integrity and stability of the verification environment.

[0128] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0129] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for determining an abnormal module, characterized in that, include: Obtain the calling path of each module in the chip to be verified and the source code file storage information of each module in the chip to be verified; Based on the call paths corresponding to each module, at least one reusable module is determined from each module; Based on the source code file storage information corresponding to each of the reuse modules, the abnormal module is determined from the at least one reuse module.

2. The method according to claim 1, wherein, The step of determining at least one reusable module from the various modules based on the call paths corresponding to each module includes: The modules corresponding to the call paths that are determined from each of the modules and associated with different subsystems in the chip to be verified are identified as the reuse modules.

3. The method according to claim 1, wherein, The step of determining the abnormal module from the at least one reuse module based on the source code file storage information corresponding to each of the reuse modules includes: The module whose source code file storage information is determined from the at least one reused module and associated with the subsystem in the chip to be verified is identified as the abnormal module.

4. The method according to claim 1, wherein, The process of obtaining the call paths of each module in the chip under test and the source code file storage information of each module includes: All source code files corresponding to the chip to be verified are pre-compiled to obtain the compiled information; Extract the logical instantiation information and source code file storage information corresponding to each module from the compiled information, wherein the logical instantiation information includes the calling path of each module in the chip to be verified.

5. The method according to claim 4, wherein, The compiled information is stored in the simulation database; as well as The step of extracting the logical instantiation information corresponding to each module and the source code file storage information from the compiled information includes: The database parsing tool traverses the compiled information stored in the simulation database to extract the logical instantiation information associated with the identifiers of each module and the source code file storage information.

6. The method according to claim 5, wherein, The simulation database is a binary database formed by pre-compiling all source code files corresponding to the chip to be verified using simulation tools.

7. The method according to claim 4, wherein, Before extracting the logical instantiation information corresponding to each module and the source code file storage information from the compiled information, the method further includes: In response to determining that the source code files corresponding to each module in the chip to be verified are written in the target hardware description language, the operation of identifying the abnormal module based on the source code files written in the target hardware description language is not supported, and the operation of precompiling all source code files corresponding to the chip to be verified is exited.

8. The method according to any one of claims 2 to 7, wherein, The method further includes: A verification report is generated for the abnormal module, wherein the verification report includes the identifier of the abnormal module, the source code file storage information corresponding to the abnormal module, and the identifiers of all subsystems that reuse the abnormal module.

9. The method according to claim 8, wherein, The exception module is reused by the first and second subsystems of multiple subsystems, and the identifier of the second subsystem is included in the source code file storage information corresponding to the exception module. as well as The method further includes: During the simulation verification of the first subsystem and the replacement of the second subsystem with an empty shell model, based on the verification report, a blocking removal instruction is generated for the source code file corresponding to the abnormal module. The blocking removal instruction is used to instruct the blocking removal operation to be performed on the source code file corresponding to the abnormal module.

10. The method according to claim 8, wherein, The method further includes: Based on the verification report, the source code file corresponding to the abnormal module is migrated to a public file directory for storage, and the storage information of the source code file corresponding to the abnormal module is updated based on the public file directory.

11. The method according to claim 8, wherein, The method further includes: Based on the verification report, a warning log is generated for the abnormal module. The warning log is used to prompt the execution of blocking and removal operations on the source code file corresponding to the abnormal module and / or migration of the source code file corresponding to the abnormal module to a public file directory for storage during the simulation verification of the subsystem that reuses the abnormal module.

12. An abnormal module determination device, characterized in that, include: The acquisition unit is configured to acquire the call path of each module in the chip to be verified and the source code file storage information of each module in the chip to be verified. The first determining unit is configured to determine at least one reused module from the various modules based on the calling paths corresponding to each module. The second determining unit is configured to determine the abnormal module from the at least one reuse module based on the source code file storage information corresponding to each of the reuse modules.

13. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the abnormal module determination method according to any one of claims 1-11.

14. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the processor to execute the abnormal module determination method according to any one of claims 1-11.

15. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method for determining an abnormal module according to any one of claims 1-11.

Images