Simulation verification platform construction method, simulation verification method, device and equipment

Abstract

The embodiment of the application provides a simulation verification platform construction method, a simulation verification method, a device and equipment, the simulation verification platform construction method comprises the following steps: determining conflict information between a plurality of to-be-tested subsystems; compiling modules corresponding to the conflict information in the plurality of to-be-tested subsystems respectively, and configuring the modules to different compilation libraries, so that the modules in the same to-be-tested subsystem are configured to the same compilation library; constructing a joint simulation environment, the joint simulation environment comprises a top-level simulation environment and a plurality of instance subsystems contained in the top-level simulation environment, the plurality of instance subsystems are obtained by instantiating the plurality of to-be-tested subsystems; wherein, the compilation library corresponding to a to-be-tested subsystem is called only by the instance subsystem corresponding to the to-be-tested subsystem, so that error calling during simulation verification of the plurality of to-be-tested subsystems can be avoided, and system-level joint verification of a plurality of subsystem chips can be implemented.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of chip technology, specifically to a method for constructing a simulation verification platform, a simulation verification method, an apparatus, and equipment. Background Technology

[0002] Chip verification is used to verify, in an appropriate verification environment, whether a chip design meets the chip definition requirements and specifications, whether it contains design defects, and to correct defects in a timely manner after they are discovered, before chip production.

[0003] With the rapid development of the integrated circuit industry, chip size has increased significantly, making chip simulation and verification increasingly complex and difficult. Therefore, for ultra-large-scale system-on-a-chip (SoC), it is typically divided into multiple subsystem chips for separate verification. After the verification of each subsystem chip is completed, only simple system-level joint debugging of the subsystem chips can be performed through a hardware platform.

[0004] How to provide a simulation verification platform to achieve joint verification of multiple subsystem chips at the system level has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a simulation verification platform construction method, simulation verification method, apparatus and equipment to achieve joint verification of multiple subsystem chips at the system level.

[0006] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions.

[0007] In a first aspect, embodiments of the present invention provide a method for constructing a simulation verification platform, comprising:

[0008] Determine conflict information between multiple subsystems under test;

[0009] In the multiple subsystems under test, the modules corresponding to the conflict information are compiled separately and configured into different compilation libraries, so that the modules in the same subsystem under test are configured into the same compilation library.

[0010] A co-simulation environment is constructed, comprising a top-level simulation environment and multiple instance subsystems contained within the top-level simulation environment, wherein the multiple instance subsystems are instantiated based on the multiple subsystems under test; wherein, the compilation library corresponding to a subsystem under test is called only by the instance subsystem corresponding to that subsystem under test.

[0011] Optionally, the construction of the co-simulation environment specifically involves constructing a co-simulation environment based on a simulation configuration file; wherein the simulation configuration file defines a top-level simulation environment and multiple instance subsystems contained in the top-level simulation environment, and constrains the compilation library corresponding to a subsystem under test to be called only by the instance subsystem corresponding to that subsystem under test.

[0012] Optionally, determining the conflict information among multiple subsystems under test includes:

[0013] Perform name matching analysis on multiple subsystems under test to identify files with the same name in the multiple subsystems under test; wherein, the file with the same name is a file that has the same name in any two subsystems under test;

[0014] Determine whether the contents of the files with the same name are identical;

[0015] If yes, then the file with the same name is used as a public file; otherwise, the naming information of the file with the same name is used as conflict information.

[0016] Optionally, after determining the conflict information among multiple subsystems under test and before constructing the joint simulation environment, the method further includes:

[0017] Compile the common files in the multiple subsystems under test and configure them in the common library directory; wherein, the common files are files that are contained in at least two subsystems under test.

[0018] In the step of building the co-simulation environment, the files in the public library directory can be called by the multiple instance subsystems.

[0019] Optionally, after constructing the co-simulation environment, the following steps are also included:

[0020] Verify the interconnection relationships between multiple instance subsystems in the co-simulation environment.

[0021] Optionally, verifying the interconnection relationships between multiple instance subsystems in the co-simulation environment includes:

[0022] Establish the interconnection relationship between the multiple instance subsystems;

[0023] Using one of the multiple instance subsystems as the target subsystem, the other instance subsystems are replaced with a verification model subsystem to verify the interconnection relationship of the target subsystem; the verification model subsystem is a simplified verification model for interconnection verification.

[0024] Select one instance subsystem from other instance subsystems as the target subsystem for interconnection relationship verification, until the interconnection relationships of all instance subsystems have been verified.

[0025] Optionally, after constructing the co-simulation environment, the following steps are also included:

[0026] A joint verification environment is constructed, comprising a top-level verification environment and multiple verification subsystems contained within the top-level verification environment. The multiple verification subsystems are used to verify the multiple subsystems under test, and the multiple verification subsystems correspond one-to-one with the multiple subsystems under test.

[0027] Optionally, before constructing the joint simulation environment, the method further includes: using a verification system that corresponds one-to-one with the plurality of subsystems under test to verify each subsystem under test in the plurality of subsystems under test respectively;

[0028] In the step of constructing the joint verification environment, the verification subsystem reuses the verification system that corresponds one-to-one with the multiple subsystems to be tested.

[0029] Optionally, after constructing the joint verification environment, the method further includes:

[0030] In the joint verification environment, the multiple instance subsystems are initialized.

[0031] Optionally, initializing the plurality of instance subsystems includes:

[0032] The initialization of the multiple instance subsystems is performed in parallel.

[0033] Initialize the interconnection relationship of the multiple instance subsystems to establish a link relationship between the multiple instance subsystems.

[0034] Optionally, after initializing the plurality of instance subsystems, the method further includes:

[0035] In the joint verification environment, each instance subsystem among the multiple instance subsystems is verified.

[0036] Secondly, embodiments of the present invention provide a simulation verification method, including:

[0037] Based on a co-simulation environment, system-level co-verification is performed on the multiple subsystems under test. The co-simulation environment includes a top-level simulation environment and multiple instance subsystems contained within the top-level simulation environment. The multiple instance subsystems are instantiated based on the multiple subsystems under test. Modules corresponding to conflict information between the multiple subsystems under test are compiled and configured into different compilation libraries, so that modules in the same subsystem under test are configured into the same compilation library. Furthermore, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem.

[0038] Optionally, before performing system-level joint verification of the multiple subsystems under test based on the co-simulation environment, the method further includes:

[0039] Determine conflict information between multiple subsystems under test;

[0040] In the multiple subsystems under test, the modules corresponding to the conflict information are compiled separately and configured into different compilation libraries, so that modules in the same subsystem under test are configured into the same compilation library.

[0041] Thirdly, embodiments of the present invention provide a simulation verification platform construction apparatus, comprising:

[0042] The information determination module is used to determine conflict information between multiple subsystems under test;

[0043] The compilation module is used to compile the modules corresponding to the conflict information in the multiple subsystems under test respectively, and configure them to different compilation libraries, so that the modules in the same subsystem under test are configured to the same compilation library.

[0044] A simulation environment construction module is used to construct a co-simulation environment, which includes a top-level simulation environment and multiple instance subsystems contained in the top-level simulation environment. The multiple instance subsystems are instantiated based on the multiple subsystems under test. The compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem under test.

[0045] Fourthly, embodiments of the present invention provide a simulation verification device, comprising:

[0046] A joint verification module is used to perform system-level joint verification of the multiple subsystems under test based on a joint simulation environment. The joint simulation environment includes a top-level simulation environment and multiple instance subsystems contained within the top-level simulation environment. These instance subsystems are instantiated from the multiple subsystems under test. Modules corresponding to conflict information between the multiple subsystems under test are compiled and configured into different compiler libraries, so that modules within the same subsystem under test are configured into the same compiler library. Furthermore, the compiler library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem.

[0047] Fifthly, embodiments of the present invention provide a simulation verification platform, which is constructed based on the simulation verification platform construction method provided in the embodiments of the present invention, and is used to execute the simulation verification method provided in the embodiments of the present invention.

[0048] In a sixth aspect, embodiments of the present invention provide a simulation verification device, comprising: at least one memory and at least one processor; the memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the simulation verification platform construction method provided in the embodiments of the present invention, or to execute the simulation verification method provided in the embodiments of the present invention.

[0049] In a seventh aspect, embodiments of the present invention provide a storage medium storing one or more executable instructions, which are used to execute the simulation verification platform construction method provided in the embodiments of the present invention, or to execute the simulation verification method provided in the embodiments of the present invention.

[0050] The present invention provides a simulation verification platform construction method, simulation verification method, apparatus, and device. The method includes: determining conflict information among multiple subsystems under test; compiling modules corresponding to the conflict information in the multiple subsystems under test and configuring them to different compilation libraries, so that modules in the same subsystem under test are configured to the same compilation library; constructing a joint simulation environment, the joint simulation environment including a top-level simulation environment and multiple instance subsystems contained in the top-level simulation environment, the multiple instance subsystems being instantiated based on the multiple subsystems under test; wherein, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem under test.

[0051] As can be seen, the simulation verification platform construction scheme in this embodiment of the invention compiles the modules with conflict information in multiple subsystems under test separately and configures them to different compilation libraries, so that the modules in the same subsystem under test are configured to the same compilation library. Furthermore, in the constructed co-simulation environment, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem under test, which can avoid erroneous calls when multiple subsystems under test are simulated and verified, thereby realizing system-level co-verification of multiple subsystem chips. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0053] Figure 1 An optional flowchart of the simulation verification platform construction method provided in the embodiments of the present invention;

[0054] Figure 2An optional flowchart of step S10 provided in an embodiment of the present invention;

[0055] Figure 3 Another optional flowchart for the simulation verification platform construction method provided in the embodiments of the present invention;

[0056] Figure 4 An optional flowchart of step S16 provided in an embodiment of the present invention;

[0057] Figure 5 An optional example diagram provided for verifying the interconnection relationship between two instance subsystems in an embodiment of the present invention;

[0058] Figure 6 This is another optional example diagram provided by an embodiment of the present invention for verifying the interconnection relationship between two instance subsystems;

[0059] Figure 7 An optional flowchart of step S20 provided in an embodiment of the present invention;

[0060] Figure 8 An optional flowchart of the simulation verification method provided in the embodiments of the present invention;

[0061] Figure 9 An optional block diagram of the simulation verification platform construction device provided in the embodiments of the present invention;

[0062] Figure 10 This is an optional block diagram of the simulation verification device provided in an embodiment of the present invention. Detailed Implementation

[0063] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0064] As described in the background section, for ultra-large-scale system-on-a-chip (SoC), it is typically divided into multiple subsystem chips for separate verification. For example, a complete server chip system can be divided into a central processing unit (DIE) and an external device (DIE), and these two DIEs are verified as independent subsystem chips. The central processing unit (DIE) is the CPU (central processing unit) portion of a high-performance server chip, composed of components such as the CPU core, memory controller, and chip interconnect interfaces. The external device (DIE) is the I / O (input / output) portion of a high-performance server chip, composed of components such as the northbridge, southbridge, and system management unit.

[0065] However, due to the limitations of test cases in the hardware platform, the method of dividing the overall system into multiple subsystem chips for separate verification and then performing system-level joint debugging of two subsystem chips through the hardware platform is difficult to fully verify the overall system. This can lead to problems such as inconsistent attribute definitions between systems and inconsistent understanding of functions and parameters by different system designers when the overall system is composed of multiple subsystem chips.

[0066] Therefore, it is essential to perform system-level joint verification of multiple subsystem chips.

[0067] The inventors discovered that within a single system, numerous conflicting IPs (intellectual property cores, or "IPs" for short, are often reusable circuit modules with specific functions used in a system-on-a-chip) may exist between different subsystem chips. These conflicting IPs may have different code contents but share the same filenames, module names, parameters, or macro definitions. Therefore, integrating a large number of IPs from multiple subsystem chips for simulation verification can easily lead to erroneous calls, making system-level joint verification difficult to achieve.

[0068] Based on this, embodiments of the present invention provide a simulation verification platform construction method, simulation verification method, apparatus, and device. The simulation verification platform construction method includes: determining conflict information among multiple subsystems under test; compiling modules corresponding to the conflict information in the multiple subsystems under test respectively, and configuring them to different compilation libraries, so that modules in the same subsystem under test are configured to the same compilation library; constructing a joint simulation environment, the joint simulation environment including a top-level simulation environment, and multiple instance subsystems contained in the top-level simulation environment, the multiple instance subsystems being instantiated based on the multiple subsystems under test; wherein, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem under test.

[0069] As can be seen, by compiling modules with conflict information in multiple subsystems under test separately and configuring them into different compilation libraries, modules in the same subsystem under test can be configured into the same compilation library. Furthermore, in the constructed co-simulation environment, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem under test. This can avoid erroneous calls when multiple subsystems under test are simulated and verified, thereby achieving system-level co-verification of multiple subsystem chips.

[0070] The simulation verification platform construction scheme provided in the embodiments of this application will be described in detail below.

[0071] In one alternative implementation, Figure 1An exemplary flowchart of an optional simulation verification platform construction method provided in an embodiment of the present invention is shown, with reference to... Figure 1 The method includes:

[0072] Step S10: Determine the conflict information between multiple subsystems under test;

[0073] The subsystem under test (DUT) can be understood as a subsystem chip, which, as part of the overall system, is used to implement a preset function. It should be noted that both the subsystem chip and the overall system are design schemes to be verified (also known as designs under test), such as designs composed of RTL (Register Transfer Level) code, rather than physical chips.

[0074] The plurality of subsystems under test can be all the subsystems that make up the overall system chip, or they can be some of the subsystems that make up the overall system. Furthermore, the plurality of subsystems under test can be the same or different, and the present invention does not make any specific limitation.

[0075] It is understandable that the subsystem under test consists of multiple modules, each used to implement different functions. When defining a module, it may be necessary to define the module's file name, module name, parameters, or macro definitions. If two modules in different subsystems under test have the same file name, module name, parameters, or macro definitions, they will conflict when running on the same system, making it impossible to determine which module to call, thus resulting in a module call error.

[0076] In this embodiment of the invention, the conflict information can be understood as information that may cause conflicts in module calls. The determination of this conflict information is used to provide a basis for subsequent solutions to avoid the occurrence of conflicts.

[0077] In multiple subsystems under test, conflict information can be understood as information that causes conflicts in module calls between any two subsystems under test; in a scheme containing two subsystems under test, conflict information can be information that causes conflicts in module calls between the two subsystems under test.

[0078] Step S12: Compile the modules corresponding to the conflict information in the multiple subsystems under test respectively, and configure them to different compilation libraries, so that the modules in the same subsystem under test are configured to the same compilation library.

[0079] After determining the conflict information, the module corresponding to the conflict information can be processed to avoid possible calling errors.

[0080] The module corresponding to the conflict information can be a module containing conflict information. The modules corresponding to the conflict information are compiled and configured into different compiler libraries, and modules within the same subsystem under test are configured into the same compiler library. This distinguishes the modules corresponding to conflict information in different subsystems under test and provides a basis for subsequent compilation processes of the subsystem under test to execute calls based on different compiler libraries.

[0081] In an optional example, for a subsystem under test, based on conflict information, the module corresponding to the conflict information can be identified within the subsystem under test, and the identified module can be compiled and configured into the compilation library corresponding to that subsystem under test. This step can be achieved by performing the above process on multiple subsystems under test one by one.

[0082] Understandably, the generation of conflict information indicates that at least two of the multiple subsystems under test have a corresponding module. In other words, when the number of subsystems under test is greater than two, the module corresponding to a particular conflict message may not exist in all of them. Therefore, when the number of subsystems under test is greater than two, it is permissible if no module corresponding to a particular conflict message is found in one of the subsystems under test.

[0083] Step S14: Construct a co-simulation environment;

[0084] The co-simulation environment includes a top-level simulation environment and multiple instance subsystems contained in the top-level simulation environment, wherein the multiple instance subsystems are instantiated based on the multiple subsystems under test; wherein, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem under test.

[0085] By setting up a top-level simulation environment and including multiple instance subsystems instantiated from the multiple subsystems under test within the top-level simulation environment, and further constraining the correspondence between the compilation libraries of the instance subsystems and the subsystems under test, different subsystems under test can be distinguished from different code layer structures, avoiding calling errors during the compilation or simulation phases, thereby enabling joint verification of multiple subsystems under test.

[0086] In an optional example, a co-simulation environment can be built based on a pre-defined simulation configuration file. This configuration file can define a top-level simulation environment, multiple instance subsystems contained within that top-level simulation environment, and constrain the compilation library corresponding to a subsystem under test to be called only by the instance subsystem corresponding to that subsystem.

[0087] For example, in the simulation of two subsystems under test, DIE1 and DIE2, the simulation configuration file can declare the compilation libraries lib_die1 and lib_die2 for DIE1 and DIE2 respectively, and associate lib_die1 with the storage path $DIE1_PATH / src of the RTL files that need to be compiled separately in DIE1, and associate lib_die2 with the storage path $DIE1_PATH / src of the RTL files that need to be compiled separately in DIE2.

[0088] Furthermore, the simulation configuration file can also be configured with a top-level file called soc_all. This top-level file can declare that the top-level simulation environment of the verification environment is tb. The top-level simulation environment tb contains two instantiated chip subsystems, tb.soc_die1 and tb.soc_die2. tb.soc_die1 is instantiated from the RTL code of DIE1, and tb.soc_die2 is instantiated from the RTL code of DIE2.

[0089] Furthermore, the simulation configuration file further restricts the DIE1 library lib_die1 to be called only by modules at the tb.soc_die1 level, and the DIE2 library to be called only by modules at the tb.soc_die2 level. For example, if the co-simulation environment contains two RTL code levels, tb.soc_die1.ip1 and tb.soc_die2.ip1, both of which contain the IP ip1, and these IPs contain some duplicate definitions, the configuration file constraint ensures that conflicting content in tb.soc_die1.ip1 is called from the $DIE1_PATH / src / * directory, and similarly, conflicting content in tb.soc_die2.ip1 is called from the $DIE2_PATH / src / * directory. This allows for precise control over the file sources used by each module, ensuring that no calling errors occur.

[0090] When compiling using simulation tools, the simulation configuration file can be specified using the libmap parameter, and the top-level verification environment can be specified as the name of the configuration file soc_all, such as –vcs_comp_opts'–libmaplibmap.v-top soc_all'.

[0091] In an optional implementation, step S10 determines conflict information between multiple subsystems under test. This can be done by comparing information, and after comparison, conflicting and non-conflicting information are distinguished and processed differently. Specifically, Figure 2An exemplary flowchart of an optional step S10 provided in an embodiment of the present invention is shown. Step S10 may include:

[0092] Step S101: Perform name matching analysis on multiple subsystems under test to identify files with the same name in the multiple subsystems under test;

[0093] The same-name analysis is used to compare files with the same name in the multiple subsystems under test. The file type can be a module, parameter, or macro definition, etc. By performing same-name analysis on multiple subsystems under test, files with the same name in the multiple subsystems under test can be identified.

[0094] It should be noted that, in multiple subsystems under test, the file with the same name is a file that has the same name in any two subsystems under test, thereby determining whether the file with the same name is conflict information.

[0095] Step S102: Determine if the contents of files with the same name are identical;

[0096] If yes, then the file with the same name is used as the common file; otherwise, the naming information of the file with the same name is used as conflict information.

[0097] Understandably, if files with the same name have different contents, it means that the files have the same name but different contents, which can easily cause calling errors. Therefore, the naming information of the files with different contents is used as conflict information. If the files with the same name have the same contents, it means that the files with the same name will not cause calling conflicts. In this example, the files with the same contents can be further defined as common files, and then compiled into the common library directory to improve compilation efficiency.

[0098] When the naming information of the file with the same name is used as conflict information, step S12 is executed; when the file with the same name is determined to be a public file, step S13 is executed.

[0099] It should be noted that in step S12, the module corresponding to the conflict information can be a file with the same name, or a file containing a file with the same name.

[0100] Step S13: Compile the common files in the multiple subsystems under test and configure them in the common library directory;

[0101] The common files are files contained in at least two subsystems under test; in the step of building the co-simulation environment, the files in the common library directory can be called by the multiple instance subsystems.

[0102] It should be noted that steps S12 and S13 are not mutually exclusive. Given multiple sets of files with the same name, some files may have identical content while others may have different content. In this case, steps S12 and S13 can be executed simultaneously, and step S14 can be executed after steps S12 and S13 are completed.

[0103] It is understandable that compiling common files into a common library directory allows each subsystem under test to directly call the common files from the common library directory, thus enabling the common files to be called multiple times with only one compilation, thereby saving a lot of compilation time and improving compilation efficiency.

[0104] In an optional implementation, refer to Figure 3 The illustrated embodiment of the present invention provides another optional flowchart for constructing a simulation verification platform. To verify the feasibility of the co-simulation environment, step S16 is further executed: verifying the interconnection relationship between multiple instance subsystems in the co-simulation environment; specifically, Figure 4 An exemplary flowchart of an optional step S16 provided in an embodiment of the present invention is shown. Step S16 includes:

[0105] Step S161: Establish the interconnection relationship between the multiple instance subsystems;

[0106] The interconnection relationship between the multiple instance subsystems should be as realistic as possible. Therefore, a real PCS (Physical Coding Sublayer), PHY (Physical Layer), and data bus configuration can be used to establish the interconnection relationship between the multiple instance subsystems.

[0107] Step S162: Taking one of the multiple instance subsystems as the target subsystem, at least some modules in the other instance subsystems are replaced with the verification model to verify the interconnection relationship of the target subsystem;

[0108] The verification model can be understood as a simplified model for interconnection verification. It can be understood that during the verification of the interconnection relationship of the target subsystem, other instance subsystems do not need overly complex module settings. The complex modules in other instance subsystems can be replaced with the verification model to improve verification efficiency.

[0109] In the process of verifying the interconnection relationship of the target subsystem, block compilation and simulation can be performed based on the aforementioned configuration information, and test verification can be performed based on the designed test cases.

[0110] It should be noted that before building the co-simulation environment, the subsystem under test can be verified separately. For details, please refer to [reference needed]. Figure 3Step S01 can be executed: using a verification system that corresponds one-to-one with the plurality of subsystems under test, each of the plurality of subsystems under test is verified respectively. This step can be executed in the manner described in the background art. In this step, some modules of the instance subsystem can be replaced based on the verification model already established in the verification of each subsystem under test, thereby further improving the verification efficiency.

[0111] Continue to refer to Figure 4 Step S163: Select one instance subsystem from other instance subsystems as the target subsystem for interconnection relationship verification until the interconnection relationship of all instance subsystems has been verified;

[0112] After the target subsystem in step S162 is verified, one of the other instance subsystems can be selected as the target subsystem, and step S162 is executed again to verify the interconnection relationship. After the verification is passed, the target subsystem is selected again until the interconnection relationship of the multiple instance subsystems is verified.

[0113] For example, refer to Figure 5 The diagram shown illustrates an optional example of verifying the interconnection between two instance subsystems. For the co-simulation environment of the two subsystems under test, DIE1 and DIE2, the interconnection verification for DIE2 can be performed by replacing some modules in the instance subsystem corresponding to DIE1 with the verification model already established in step S01 of DIE1. For example, the CPU in DIE1 can be replaced with a CPU model, and the DDR with a DDR model (the replaced DIE1 is marked as "Simplified DIE1" in the diagram). DIE2 is a complete instance subsystem containing multiple IP modules, such as IP1, IP2, and IP3. Simultaneously, the interconnection between DIE1 and DIE2 is kept realistic, i.e., using real PCS, PHY, and data bus settings. Similarly, refer to... Figure 6 Another optional example diagram of the interconnection relationship between the two instance subsystems is shown. For the interconnection verification of DIE1, the instance subsystem corresponding to DIE2 can be replaced with the verification model that has been established in the separate verification process of DIE2. For example, the IP module in DIE2 can be replaced with an external device model (the replaced DIE2 is marked as "Simplified DIE2" in the figure). DIE1 is a complete instance subsystem, which contains multiple CPU modules, such as CPU0, CPU1, etc., as well as a DDR module (marked as DDR in the figure). At the same time, the interconnection relationship between DIE1 and DIE2 is kept real, that is, the real PCS, PHY and data bus settings are used.

[0114] By verifying the interconnections between multiple instance subsystems, a foundation is laid for verifying the feasibility of the co-simulation environment, enabling early detection and correction of issues and preventing subsequent verification errors. Simultaneously, the verification models already established in the separate verification processes for each subsystem under test are reused, fully utilizing existing resources, reducing manpower costs, and improving verification efficiency.

[0115] After creating the co-simulation environment, refer to Figure 3 The illustrated embodiment of the present invention provides an alternative flowchart for constructing a simulation verification platform. The embodiment may further execute step S18: constructing a joint verification environment. Specifically, when constructing the joint verification environment, the joint verification environment may include a top-level verification environment and multiple verification subsystems contained within the top-level verification environment. These multiple verification subsystems are used to verify the multiple subsystems under test, and each verification subsystem corresponds one-to-one with the multiple subsystems under test. It can be seen that the hierarchical structure of the joint verification environment corresponds to the joint simulation environment. By constructing a verification environment with a corresponding hierarchy to the joint simulation environment, the verification of the subsystems under test is facilitated.

[0116] Understandably, before constructing the co-simulation environment, step S01 has already been performed: using a verification system corresponding one-to-one with each of the multiple subsystems under test to verify each of the multiple subsystems under test. This step can be performed as described in the background art. In this process, the multiple verification subsystems can reuse the verification systems corresponding one-to-one with the multiple subsystems under test, thereby achieving efficient verification of multiple subsystems under test.

[0117] For example, to construct a joint verification environment for two subsystems under test, DIE1 and DIE2, we can first build a top-level soc_env for the joint verification environment. Under soc_env, we can further build two verification subsystems: die1env for DIE1 and die2env for DIE2. The UVM (Universal Verification Methodology) components of the verification systems for the multiple subsystems under test during their respective verification processes are then instantiated into soc_env. Referring to the verification components listed in Table 1, each verification subsystem can include verification components such as IP1_sub_env, IP2_sub_env, IP3_sub_env, ..., and IPn_sub_env. By instantiating these verification components into the joint verification environment, flexible test stimuli can be generated according to requirements. Simultaneously, it allows for real-time monitoring of key signals and states in the system, such as whether changes in registers, state machines, bus signals, and signal combinations meet expectations. This improves verification efficiency while enhancing the real-time monitoring capability of the verification process. Clearly, the advantages of the stimulus generation and inspection mechanisms in these simulations during the functional debugging process are unmatched by hardware debugging platforms.

[0118] Table 1: Verification Components in Each Verification Subsystem

[0119]

[0120] In an optional example, refer to Figure 3 Another optional flowchart of the simulation verification platform construction method provided by the embodiment of the present invention is shown. After constructing the joint verification environment, step S20 is further performed: in the joint verification environment, the plurality of instance subsystems are initialized.

[0121] For details, please refer to Figure 7 The illustrated optional flowchart of step S20 shows that step S20 may include:

[0122] Step S201: Perform the initialization of the multiple instance subsystems in parallel;

[0123] In this example, to shorten process time, the initialization processes of multiple instance subsystems can be executed in parallel. For instance, in a joint verification environment for two subsystems under test, DIE1 and DIE2, the initialization programs in DIE1 and DIE2 can run independently and in parallel to reduce runtime and improve efficiency. Specifically, referring to the initialization process listed in Table 2, the initialization program can employ a fork-join parallel execution mechanism, allowing multiple systems to begin initialization simultaneously, executing bootcode programs, clock reset (clk-reset), fuse initialization, and initialization of various IPs within the system.

[0124] Step S202: Initialize the interconnection relationship of the multiple instance subsystems to establish a link relationship between the multiple instance subsystems.

[0125] After the initialization of multiple instance subsystems is completed, the interconnection relationship between the multiple instance subsystems can be initialized to establish a link relationship between the multiple instance subsystems.

[0126] Specifically, the fork join mechanism can also be used to complete the handshake between the two subsystems through the initialization of pcs and phy.

[0127] Table 2: Initialization Process

[0128]

[0129] In an optional example, after initializing the plurality of instance subsystems, step S22 is further performed: In the joint verification environment, each instance subsystem within the plurality of instance subsystems is verified. Specifically, the verification of each instance subsystem can be performed using the test cases from step S01, which are used to verify each subsystem under test in the plurality of subsystems under test. It should be noted that the scheme of generating test stimuli from the verification model in the original test cases is replaced with generating test stimuli from the actual RTL code of each instance subsystem to fully verify the plurality of instance subsystems.

[0130] In one alternative implementation, Figure 8 An exemplary flowchart of an optional simulation verification method provided by an embodiment of the present invention is shown. This method can be implemented based on a simulation verification platform constructed using the aforementioned simulation verification platform construction method. Specifically, refer to... Figure 8 The method includes:

[0131] Step S40: Based on the co-simulation environment, perform system-level joint verification of the multiple subsystems under test;

[0132] The co-simulation environment includes a top-level simulation environment and multiple instance subsystems contained within the top-level simulation environment. The multiple instance subsystems are instantiated based on the multiple subsystems under test. Modules corresponding to conflict information between the multiple subsystems under test are compiled and configured into different compilation libraries, so that modules in the same subsystem under test are configured into the same compilation library. Furthermore, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem.

[0133] It should be noted that during system-level joint verification, each instance subsystem in the joint simulation environment, as well as any external devices that may be involved, are compiled from real RTL code to recreate the real-world running scenario of each instance subsystem and improve the accuracy of the joint simulation environment.

[0134] It is understandable that modifications may occur to the code of the subsystem under test during the construction of the simulation verification platform. To ensure the accuracy of module calls during the verification process, refer to... Figure 8 Before performing the system-level joint verification, this embodiment of the invention further includes:

[0135] Step S30: Determine the conflict information between multiple subsystems under test;

[0136] Step S32: Compile the modules corresponding to the conflict information in the multiple subsystems under test respectively, and configure them to different compilation libraries, so that the modules in the same subsystem under test are configured to the same compilation library.

[0137] The execution process of steps S30 and S32 can be referred to the description of steps S10 and S12, and will not be repeated here.

[0138] As can be seen, by compiling modules with conflict information in multiple subsystems under test separately and configuring them into different compilation libraries, modules in the same subsystem under test can be configured into the same compilation library. Furthermore, in the constructed co-simulation environment, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem under test. This can avoid erroneous calls when multiple subsystems under test are simulated and verified, thereby achieving system-level co-verification of multiple subsystem chips.

[0139] The following describes the simulation verification platform construction apparatus provided in the embodiments of the present invention. The apparatus described below can be considered as simulation verification equipment or computer equipment, and includes the functional modules required to implement the simulation verification platform construction method provided in the embodiments of the present invention. The apparatus described below can be referred to in correspondence with the method described above.

[0140] Figure 9An optional block diagram of the simulation verification platform construction apparatus provided in an embodiment of the present invention is shown. For example... Figure 9 As shown, the device may include:

[0141] Information determination module 100 is used to determine conflict information between multiple subsystems under test;

[0142] The compilation module 110 is used to compile the modules corresponding to the conflict information in the multiple subsystems under test respectively, and configure them to different compilation libraries, so that the modules in the same subsystem under test are configured to the same compilation library.

[0143] The simulation environment construction module 120 is used to construct a co-simulation environment, which includes a top-level simulation environment and multiple instance subsystems contained in the top-level simulation environment. The multiple instance subsystems are instantiated based on the multiple subsystems under test. The compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem under test.

[0144] Optionally, the simulation environment construction module 120 is used to construct a co-simulation environment, specifically, based on a simulation configuration file, to construct a co-simulation environment; wherein, the simulation configuration file defines a top-level simulation environment, and multiple instance subsystems contained in the top-level simulation environment, and constrains the compilation library corresponding to a subsystem under test to be called only by the instance subsystem corresponding to that subsystem under test.

[0145] Optionally, the information determination module 100 is used to determine conflict information between multiple subsystems under test, including:

[0146] Perform name matching analysis on multiple subsystems under test to identify files with the same name in the multiple subsystems under test; wherein, the file with the same name is a file that has the same name in any two subsystems under test;

[0147] Determine whether the contents of the files with the same name are identical;

[0148] If yes, then the file with the same name is used as a public file; otherwise, the naming information of the file with the same name is used as conflict information.

[0149] Optionally, the compilation module 110 is further configured to:

[0150] Compile the common files in the multiple subsystems under test and configure them in the common library directory; wherein, the common files are files that are contained in at least two subsystems under test.

[0151] In the simulation environment construction module 120, during the step of constructing a joint simulation environment, the files in the public library directory are allowed to be called by the multiple instance subsystems.

[0152] Optionally, the simulation verification platform construction device further includes:

[0153] The interconnection verification module 130 is used to verify the interconnection relationship between multiple instance subsystems in the co-simulation environment.

[0154] Optionally, the interconnection verification module 130 is used to verify the interconnection relationship between multiple instance subsystems in the co-simulation environment, including:

[0155] Establish the interconnection relationship between the multiple instance subsystems;

[0156] Using one of the multiple instance subsystems as the target subsystem, the other instance subsystems are replaced with a verification model subsystem to verify the interconnection relationship of the target subsystem; the verification model subsystem is a simplified verification model for interconnection verification.

[0157] Select one instance subsystem from other instance subsystems as the target subsystem for interconnection relationship verification, until the interconnection relationships of all instance subsystems have been verified.

[0158] Optionally, the simulation verification platform construction device further includes:

[0159] The verification environment construction module 140 is used to construct a joint verification environment, which includes a top-level verification environment and multiple verification subsystems contained in the top-level verification environment. The multiple verification subsystems are used to verify the multiple subsystems under test, and the multiple verification subsystems correspond one-to-one with the multiple subsystems under test.

[0160] Optionally, the simulation verification platform construction device further includes: a subsystem verification module 150, used to verify each subsystem under test in the plurality of subsystems under test by using a verification system that corresponds one-to-one with the plurality of subsystems under test;

[0161] In the step of constructing a joint verification environment, the verification subsystem of the verification environment construction module 140 reuses the verification system that corresponds one-to-one with the multiple subsystems to be tested.

[0162] Optionally, the simulation verification platform construction device further includes:

[0163] Initialization module 160 is used to initialize the multiple instance subsystems in the joint verification environment.

[0164] Optionally, the initialization module 160 is used to initialize the plurality of instance subsystems, including:

[0165] The initialization of the multiple instance subsystems is performed in parallel.

[0166] Initialize the interconnection relationship of the multiple instance subsystems to establish a link relationship between the multiple instance subsystems.

[0167] Optionally, the simulation verification platform construction device further includes:

[0168] The instance verification module 170 is used to verify each instance subsystem in the plurality of instance subsystems in the joint verification environment.

[0169] The simulation verification apparatus provided in the embodiments of the present invention will be described below. The apparatus described below can be considered as a simulation verification device or a computer device, which are the functional modules required to implement the simulation verification method provided in the embodiments of the present invention. The apparatus described below can be referred to in correspondence with the method described above.

[0170] Figure 10 An optional block diagram of the simulation verification apparatus provided in an embodiment of the present invention is shown. For example... Figure 10 As shown, the device may include:

[0171] The joint verification module 200 is used to perform system-level joint verification of the multiple subsystems under test based on a joint simulation environment. The joint simulation environment includes a top-level simulation environment and multiple instance subsystems contained within the top-level simulation environment. These instance subsystems are instantiated from the multiple subsystems under test. Modules corresponding to conflict information between the multiple subsystems under test are compiled and configured into different compilation libraries, so that modules within the same subsystem under test are configured into the same compilation library. Furthermore, the compilation library corresponding to a subsystem under test is only called by the instance subsystem corresponding to that subsystem.

[0172] Optionally, the simulation verification device further includes:

[0173] Information determination module 210 is used to determine conflict information between multiple subsystems under test;

[0174] The compilation module 220 is used to compile the modules corresponding to the conflict information in the multiple subsystems under test respectively, and configure them to different compilation libraries, so that the modules in the same subsystem under test are configured to the same compilation library.

[0175] This invention also provides a simulation verification platform, which can be constructed based on the simulation verification platform construction method in this invention, and is used in the simulation verification method in this invention.

[0176] This invention also provides a computer device, which may include: at least one memory and at least one processor; the memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the simulation verification platform construction method provided in this invention, or to execute the simulation verification method provided in this invention.

[0177] This invention provides a storage medium that stores one or more executable instructions. The one or more executable instructions are used to execute the simulation verification platform construction method provided in this invention, or to execute the simulation verification method provided in this invention.

[0178] The foregoing describes multiple embodiments of the present invention. The optional methods described in each embodiment can be combined and cross-referenced without conflict, thereby extending to a variety of possible embodiments. These can all be considered as embodiments disclosed or made public by the present invention.

[0179] While the embodiments of the present invention have been disclosed above, the present invention is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of the present invention; therefore, the scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. A simulation verification platform construction method, characterized in that, The method comprises the following steps: determining conflict information between a plurality of to-be-tested subsystems, the plurality of to-be-tested subsystems being all subsystems constituting a whole system chip or being partial subsystems constituting a whole system; the to-be-tested subsystems being composed of a plurality of modules, and the conflict information being information that will cause conflict in module calling in the plurality of to-be-tested subsystems; compiling modules corresponding to the conflict information in the plurality of to-be-tested subsystems respectively and configuring the modules to different compiling libraries so as to configure modules in the same to-be-tested subsystem to the same compiling library; constructing a joint simulation environment, the joint simulation environment comprising a top-level simulation environment and a plurality of instance subsystems contained in the top-level simulation environment, the plurality of instance subsystems being instantiated based on the plurality of to-be-tested subsystems; wherein a compiling library corresponding to a to-be-tested subsystem is called only by an instance subsystem corresponding to the to-be-tested subsystem.

2. The method of claim 1, wherein, The step of constructing the joint simulation environment comprises the following steps:

3. The method of claim 1, wherein, based on a simulation configuration file, constructing the joint simulation environment; wherein the simulation configuration file defines the top-level simulation environment and the plurality of instance subsystems contained in the top-level simulation environment and restricts that a compiling library corresponding to a to-be-tested subsystem is called only by an instance subsystem corresponding to the to-be-tested subsystem. The step of determining the conflict information between the plurality of to-be-tested subsystems comprises the following steps: performing same-name analysis on the plurality of to-be-tested subsystems to determine same-name files in the plurality of to-be-tested subsystems; wherein the same-name files are files having the same name in any two to-be-tested subsystems; determining whether the contents of the same-name files are consistent; 4. The method according to any one of claims 1 to 3, characterized in that, if yes, taking the same-name files as common files; and if no, taking naming information of the same-name files as the conflict information. After the step of determining the conflict information between the plurality of to-be-tested subsystems and before the step of constructing the joint simulation environment, the method further comprises the following steps: compiling common files in the plurality of to-be-tested subsystems and configuring the common files to a common library directory; wherein the common files are files contained in at least two to-be-tested subsystems simultaneously; 5. The method according to claim 1 or 2, characterized in that, in the step of constructing the joint simulation environment, files in the common library directory are allowed to be called by the plurality of instance subsystems. After the step of constructing the joint simulation environment, the method further comprises the following steps:

6. The method of claim 5, wherein, verifying interconnection relationships between the plurality of instance subsystems in the joint simulation environment. The step of verifying the interconnection relationships between the plurality of instance subsystems in the joint simulation environment comprises the following steps: establishing interconnection relationships between the plurality of instance subsystems; taking one of the plurality of instance subsystems as a target subsystem, replacing other instance subsystems with verification model subsystems to verify the interconnection relationship of the target subsystem; the verification model subsystems being simplified verification models used for interconnection verification; 7. The method according to claim 1 or 2, characterized in that, selecting one of the other instance subsystems as a target subsystem to verify the interconnection relationship, until the interconnection relationships of the plurality of instance subsystems are verified. After the step of constructing the joint simulation environment, the method further comprises the following steps: Constructing a joint verification environment, the joint verification environment includes a top-level verification environment, and a plurality of verification subsystems contained in the top-level verification environment, the plurality of verification subsystems are used for verifying the plurality of to-be-tested subsystems, and the plurality of verification subsystems correspond to the plurality of to-be-tested subsystems one by one.

8. The method of claim 7, wherein, Before the constructing the joint simulation environment, further comprising: verifying each to-be-tested subsystem in the plurality of to-be-tested subsystems respectively by using a verification system corresponding to the to-be-tested subsystem; In the step of constructing the joint verification environment, the verification subsystem reuses the verification system corresponding to the plurality of to-be-tested subsystems one by one.

9. The method of claim 7, wherein, After the constructing the joint verification environment, further comprising: Initializing the plurality of instance subsystems under the joint verification environment.

10. The method of claim 9, wherein, The initializing the plurality of instance subsystems comprises: Parallelly executing the initialization of the plurality of instance subsystems; Initializing the interconnection relationship of the plurality of instance subsystems, so as to establish a link relationship between the plurality of instance subsystems.

11. The method of claim 9, wherein, After the initializing the plurality of instance subsystems, further comprising: Verifying each instance subsystem in the plurality of instance subsystems under the joint verification environment.

12. A method of simulation verification, the method comprising: Comprising: Based on a joint simulation environment, performing system-level joint verification on a plurality of to-be-tested subsystems; wherein the joint simulation environment includes a top-level simulation environment, and a plurality of instance subsystems contained in the top-level simulation environment, the plurality of instance subsystems are instantiated based on a plurality of to-be-tested subsystems; wherein the plurality of to-be-tested subsystems are all subsystems constituting a whole system chip, or are part of subsystems constituting a whole system; modules corresponding to conflict information between the plurality of to-be-tested subsystems are compiled and configured to different compilation libraries respectively, so that modules in the same to-be-tested subsystem are correspondingly configured to the same compilation library, and the compilation library corresponding to a to-be-tested subsystem is only called by the instance subsystem corresponding to the to-be-tested subsystem; the to-be-tested subsystem is composed of a plurality of modules, and the conflict information is information that will cause conflicts in module calling in the plurality of to-be-tested subsystems.

13. The method of claim 12, wherein, Before the performing the system-level joint verification on the plurality of to-be-tested subsystems based on the joint simulation environment, further comprising: Determining conflict information between the plurality of to-be-tested subsystems; Compiling and configuring modules corresponding to the conflict information in the plurality of to-be-tested subsystems to different compilation libraries respectively, so that modules in the same to-be-tested subsystem are correspondingly configured to the same compilation library.

14. A simulation verification platform construction apparatus, characterized by comprising: Comprising: An information determination module is configured to determine conflict information between a plurality of to-be-tested subsystems, the plurality of to-be-tested subsystems are all subsystems constituting a whole system chip, or are part of subsystems constituting a whole system; the to-be-tested subsystem is composed of a plurality of modules, and the conflict information is information that will cause conflicts in module calling in the plurality of to-be-tested subsystems; A compiling module is configured to compile and configure modules corresponding to the conflict information in the plurality of to-be-tested subsystems to different compilation libraries respectively, so that modules in the same to-be-tested subsystem are correspondingly configured to the same compilation library. The simulation environment construction module is configured to construct a joint simulation environment, which includes a top-level simulation environment and a plurality of instance subsystems contained in the top-level simulation environment, the plurality of instance subsystems being instantiated based on the plurality of to-be-tested subsystems; wherein a compiled library corresponding to a to-be-tested subsystem is called only by an instance subsystem corresponding to the to-be-tested subsystem.

15. An emulation verification apparatus comprising: The simulation verification platform comprises: The joint verification module is configured to perform system-level joint verification on the plurality of to-be-tested subsystems based on the joint simulation environment; wherein the joint simulation environment includes a top-level simulation environment and a plurality of instance subsystems contained in the top-level simulation environment, the plurality of instance subsystems being instantiated based on the plurality of to-be-tested subsystems; wherein the plurality of to-be-tested subsystems are all subsystems constituting a whole system chip or are partial subsystems constituting a whole system; modules corresponding to conflict information between the plurality of to-be-tested subsystems are respectively compiled and configured to different compiled libraries, so that modules in the same to-be-tested subsystem are correspondingly configured to the same compiled library, and a compiled library corresponding to a to-be-tested subsystem is called only by an instance subsystem corresponding to the to-be-tested subsystem; the to-be-tested subsystem is composed of a plurality of modules, and the conflict information is information that will cause conflict in module calling in the plurality of to-be-tested subsystems.

16. An emulation verification platform, comprising: The simulation verification platform is constructed based on the simulation verification platform construction method of any one of claims 1-11, and is configured to perform the simulation verification method of any one of claims 12-13.

17. An emulation verification device comprising: The simulation verification platform comprises: at least one memory and at least one processor; The memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to perform the simulation verification platform construction method of any one of claims 1-11 or the simulation verification method of any one of claims 12-13.

18. A storage medium, characterized by The storage medium stores one or more executable instructions, and the one or more executable instructions are used to perform the simulation verification platform construction method of any one of claims 1-11 or the simulation verification method of any one of claims 12-13.

Images