CN116227396A

CN116227396A - Method and simulation platform for post-simulation of system on chip

Info

Publication number: CN116227396A
Application number: CN202310258992.7A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Moore Threads Technology Co Ltd
Current assignee: Moore Threads Technology Co Ltd
Priority date: 2023-03-17
Filing date: 2023-03-17
Publication date: 2023-06-06

Abstract

The application discloses a method and a simulation platform for performing post-simulation on a system on a chip. The system-on-chip includes a plurality of modules, the method comprising: configuring a custom subsystem to be simulated later in a simulation platform according to a simulation command; replacing other modules of the system on chip except the custom subsystem with a blank file; and determining a post-simulation file of the custom subsystem according to the simulation command, and performing post-simulation on the custom subsystem based on the post-simulation file.

Description

Method and simulation platform for post-simulation of system on chip

Technical Field

The present application relates to the field of integrated circuit technology. And in particular to a method and simulation platform for post-simulation of a system on a chip.

Background

Design and verification of integrated circuit systems on a chip (SoC) is a very time consuming and cumbersome process. A product takes a few months to years from initial design, to design, validation, film-casting, testing, and to mass production. In the design of integrated circuit systems on chip, simulations and verification are often required to check whether the designed system on chip can perform as envisaged. The system design verification process of the integrated circuit chip requires pre-functional simulation and post-timing simulation. The pre-function simulation is a simulation for a register transfer stage (Register Transfer Level, RTL), and the logic function correctness of the designed circuit is mainly verified through the simulation, so that the simulation speed is high. The post-timing simulation is based on a Netlist (Netlist) composed of basic gate cells, while taking into account gate delays of the Netlist and wire delays between various gate circuits. Post-timing simulation is mainly to find out potential constraints and timing problems of the design through simulation. And because the delay of circuit elements and paths is considered in the post-simulation, the simulation speed is slow, and often the post-simulation of an integrated circuit system-on-chip takes hours or even days.

To speed up post-simulation of integrated circuit systems on chip, hierarchical designs and verification have evolved. Layering refers to dividing the whole large-scale integrated circuit into a plurality of relatively independent subsystems at the initial stage of product design, and assigning the subsystems to different engineers or teams to perform design and verification respectively, so that a huge design object is divided into a plurality of relatively independent parts to perform design and verification in parallel, thereby shortening the period of product research, development, design and verification, and particularly shortening the time of post-simulation verification.

However, existing layering methods for design and verification of integrated circuit systems on chip generally divide layers in advance at the beginning of product design. In the subsequent simulation verification link, design and verification are performed based on the divided fixed hierarchy, but a verification engineer cannot flexibly and custom select a module to be subjected to simulation verification based on an application scene and a simulation efficiency requirement, so that after-simulation is often performed together with some modules which are not actually concerned or needed during the simulation verification, the time of the after-simulation is still long, and the efficiency of the after-simulation is still low. Meanwhile, errors or warnings generated after the existing hierarchical design and verification are manually and mechanically processed one by one, so that on one hand, tedious verification workload is brought to a verification engineer, and on the other hand, errors are easy to occur.

Disclosure of Invention

Aiming at the defects in the prior art, the present disclosure provides a method and a simulation platform for performing post-simulation on a system on a chip. The post-simulation method and platform can define the user-defined subsystem to be post-simulated and the target module included in the user-defined subsystem according to the actual application scene requirements on the basis of the existing hierarchical design and verification, so that the post-simulation verification between the flexible user-defined modules is realized, and the efficiency of the post-simulation verification is greatly improved. Further, a target version of the post-simulation file may be selected from multiple versions of the post-simulation file for post-simulation. Meanwhile, the automatic processing of errors or warnings reported in the post-simulation verification is realized, so that the efficiency of the post-simulation verification is further improved, and the period of product development is further shortened. In addition, the post-simulation method and the simulation platform are extremely user-friendly, and a user can realize post-simulation and post-simulation processing of the custom subsystem based on a specific post-simulation file by simply inputting relevant parameters in a simulation command, so that the post-simulation efficiency is improved, and the product development period is shortened.

In one aspect, the present disclosure proposes a method for post-simulation of a system-on-chip, the system-on-chip comprising a plurality of modules, the method comprising: configuring a custom subsystem to be simulated later in a simulation platform according to a simulation command; replacing other modules of the system on chip except the custom subsystem with a blank file; and determining a post-simulation file of the custom subsystem according to the simulation command, and performing post-simulation on the custom subsystem based on the post-simulation file.

In one embodiment, configuring a custom subsystem to be post-simulated in a simulation platform according to a simulation command includes: generating subsystem codes for defining the custom subsystem according to subsystem parameters in the simulation command; and determining a target module included in the custom subsystem according to the subsystem code.

In one embodiment, the emulation platform supports multiple versions of post-emulation files of the system-on-chip. Determining a post-simulation file of the custom subsystem according to the simulation command includes: designating a post-simulation file of the target version according to the version parameters in the simulation command; and extracting the post-simulation file of the custom subsystem from the post-simulation file of the target version according to the subsystem code.

In one embodiment, the post-simulation file specifying the target version according to the version parameters in the simulation command includes: generating version codes for defining information of the post-simulation file of the target version according to version parameters in the simulation command; and selecting the target version of the post-simulation file from the plurality of versions of the post-simulation files according to the version code.

In one embodiment, the post-simulation file includes a netlist, a standard delay-format file, and a standard cell library, and the method further comprises: and performing anti-labeling on a standard delay format file in the post-simulation file of the custom subsystem to obtain a netlist with anti-labeled time sequence information.

In one embodiment, the method further comprises: classifying errors reported in the anti-tagging process to output the same type of errors into the same file, while providing information related to each of the errors; and categorizing the alerts reported in the anti-tagging process to output the same type of alert to the same file while providing an information customization subsystem associated with each of the alerts.

In one embodiment, the method further comprises: and when the post-simulation is carried out on the custom subsystem, comparing the actual delay amount on the specific components and paths included in the target module of the custom subsystem with the delay information of the corresponding components and corresponding paths recorded in the standard delay format file so as to evaluate the accuracy of the post-simulation of the custom subsystem.

In one embodiment, the method further comprises: setting a time point and a keyword to filter out timing violations before the time point from timing violations reported in post-simulation of the custom subsystem, wherein the timing violations comprise the keyword; and sorting the remaining timing violations after filtering by time and grouping by path and respectively outputting into two files while providing information related to each of the remaining timing violations.

In one embodiment, wherein the plurality of versions of the post-simulation file comprises: different versions of the post-simulation file generated by different personnel or based on different process corners at different design stages of the system-on-chip.

In another aspect, the present disclosure also proposes an emulation platform for post-emulating a system-on-chip, the system-on-chip comprising a plurality of modules, the emulation platform comprising: the subsystem configuration unit is used for configuring a user-defined subsystem to be simulated later in the simulation platform according to the simulation command; a dummy unit for replacing other modules of the system on chip except the custom subsystem with a blank file; the post-simulation file determining unit is used for determining a post-simulation file of the custom subsystem according to the simulation command; and the post-simulation unit is used for carrying out post-simulation on the custom subsystem based on the post-simulation file.

In one embodiment, the subsystem configuration unit includes: a subsystem definition unit, configured to generate a subsystem code for defining the custom subsystem according to a subsystem parameter in the simulation command; and the target module determining unit is used for determining a target module included in the custom subsystem according to the subsystem code.

In one embodiment, the simulation platform supports multiple versions of a post-simulation file of the system-on-chip, and the post-simulation file determination unit includes: version designating unit for designating the post-simulation file of the target version according to the version parameters in the simulation command; and a post-simulation file extraction unit, configured to extract, according to the subsystem code, a post-simulation file of the custom subsystem from the post-simulation file of the target version.

In one embodiment, the version specification unit includes: a version definition unit for generating a version code for defining information of the post-simulation file of the target version according to the version parameter in the simulation command; and the version selection unit is used for selecting the post-simulation file custom subsystem of the target version from the plurality of versions of post-simulation files according to the version code.

In one embodiment, the post-simulation file includes a netlist, a standard delay format file, and a standard cell library, and the simulation platform further includes: and the anti-labeling unit is used for carrying out anti-labeling on the standard delay format file in the post-simulation file of the self-defining subsystem so as to obtain a netlist with time sequence information after the anti-labeling.

In one embodiment, the simulation platform further comprises a post-label processing unit, which is used for classifying errors reported in the post-label process to output the same type of errors into the same file, and simultaneously providing information related to each error in the errors; and categorizing the alerts reported in the anti-tagging process to output the same type of alert to the same file while providing information related to each of the alerts.

In one embodiment, the simulation platform further includes an evaluation unit, configured to compare, when performing post-simulation on the custom subsystem, an actual delay amount on a specific component and a path included in a target module of the custom subsystem with delay information of a corresponding component and a corresponding path recorded in a standard delay format file, so as to evaluate accuracy of post-simulation of the custom subsystem.

In one embodiment, the simulation platform further comprises a timing violation processing unit, configured to set a time point and a keyword to filter out timing violations before the time point and timing violations including the keyword from timing violations reported in post-simulation of the custom subsystem; and sorting the remaining timing violations after filtering by time and grouping by path and respectively outputting into two files while providing information related to each of the remaining timing violations.

In another aspect, the present disclosure also proposes a simulation platform for post-simulating a system on a chip, characterized in that the simulation platform supports multiple versions of post-simulation files of the system on a chip, the simulation platform being configured for: generating version codes of information of the post-simulation file for defining the target version according to the version parameters in the simulation command; selecting a post-simulation file of the target version from the plurality of versions of post-simulation files according to the version code; switching from the current version of the post-simulation file to the target version of the post-simulation file; and performing post-simulation on the system on chip based on the post-simulation file of the target version.

In another aspect, the present disclosure also proposes a computing device comprising the simulation platform according to an embodiment of the present disclosure.

In yet another aspect, the present disclosure also proposes a machine-readable medium having stored thereon instructions that, when executed by a machine, cause the machine to perform a method for post-simulation of a system-on-chip according to an embodiment of the present disclosure.

The present disclosure includes any combination of two, three, four, or more features or elements set forth in the present disclosure, whether or not such features or elements are expressly combined or otherwise recited in the specific example implementations described herein. The disclosure is intended to be read in whole such that any individual feature or element of the disclosure should be considered combinable unless the context of the disclosure clearly dictates otherwise.

Drawings

Specific exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings. Features, aspects, and advantages of the present disclosure will become apparent from the following detailed description when taken in conjunction with the accompanying drawings. In the drawings:

FIG. 1 shows a flow of a digital integrated circuit design;

FIG. 2a shows a schematic diagram of a system-on-chip for configuring a custom subsystem according to an embodiment of the present disclosure;

FIGS. 2b and 2c illustrate schematic diagrams of additional systems-on-chip for configuring custom subsystems, according to embodiments of the present disclosure;

FIG. 3 shows a schematic diagram of a four-core GPU system for specifying a configuration of a custom subsystem, in accordance with an embodiment of the present disclosure;

FIG. 4 illustrates a method for post-simulation of a custom subsystem according to an embodiment of the present disclosure;

FIG. 5 illustrates a method for post-simulating a system on a chip based on a post-simulation file of a target version, in accordance with an embodiment of the present disclosure;

FIG. 6 illustrates an additional method for post-simulation of a system-on-chip in accordance with an embodiment of the present disclosure;

FIG. 7 illustrates a simulation platform for post-simulation of a system-on-chip in accordance with an embodiment of the present disclosure; and

fig. 8 shows a schematic diagram of a computing device according to an embodiment of the disclosure.

Detailed Description

Some implementations of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all implementations of the disclosure are shown. Indeed, various implementations of the disclosure may be embodied in many different forms and should not be construed as limited to the implementations set forth herein; rather, these example implementations are provided so that this disclosure will be better understood by those skilled in the art.

To facilitate an understanding of the principles of the present disclosure, a general flow of a digital integrated circuit design is shown in fig. 1. The digital integrated circuit design includes two stages, front-end and back-end. There is no obvious boundary between the front end and the back end. In general, a stage above the broken line in fig. 1 is referred to as a front end, and a stage below the broken line is referred to as a rear end. The first stage of front-end-algorithm or hardware architecture design and analysis aims to complete the analysis and modeling of the high-level algorithm or architecture of the digital part in the chip, provide a correct software function model for hardware, and more importantly, provide general design guidance for RTL realization through a large amount of high-level simulation and debugging. The second stage, RTL, is to complete the high level description to the description of the circuit based on the transfer between registers in hardware language such as Verilog HDL or VHDL, depending on the result of the first stage. And the third stage runs code style check, and aims to eliminate the problems of cross clock domain, lint and the like in RTL codes. The fourth stage is to perform functional verification, and aims to find out artificial or non-artificial loopholes or errors in the circuit design process through a large number of simulations under ideal conditions without delay. This stage is the pre-simulation mentioned above. The main indicator of functional verification is functional coverage. The next stage is logic synthesis, which aims to translate the program code obtained in the RTL level design into the various components of the actual circuit and their connections, and then represent them with a table, called a gate level netlist. The logic synthesis stage enables mapping of code to netlists associated with the process library. And (3) carrying out static time sequence analysis, wherein compared with a quasi-exhaustive verification method of dynamic simulation, from the perspective of static analysis, all paths in the design are ensured, and the requirements of an internal time sequence unit on the establishment time and the retention time are met. I.e. whatever the start point is, the signal can be passed to the end point of the path in time and remain constant for the period of time necessary for the circuit to function properly. The next stage is consistency verification. Both the RTL code and the logic synthesized netlist can be abstracted into two graphs consisting of nodes and edges, and the consistency verification stage adopts a method similar to the direct comparison of whether the two graphs are consistent or not to determine whether the logic synthesized netlist is correct or not. The next stage is timing simulation. In contrast to functional simulation, timing simulation replaces the RTL code with a netlist and then requires loading of standard delay-format file (SDF) files and process library models. The purpose of the timing simulation is to see if the function is still correct, taking into account the near-real operation of the units and path delays etc. The timing simulation is also referred to as post simulation with respect to the pre-functional simulation.

The back-end design of a digital integrated circuit, also known as a physical design, converts the text in netlist format into cells, wires (layout and routing (placement and routing)) of individual physical size and location. And in the implementation process, the requirements of area, power consumption, performance and the like are met. In fig. 1, for simplicity, the back end only shows the step of laying out wiring. In practice, however, the backend also needs to perform many steps such as extracting delay information, running DRC (design rule check) and LVS (consistency check of layout and circuit diagram), etc. And the layout and wiring stages adjust the layout and connection of the circuit components, so that a standard delay format file after layout and wiring is obtained through calculation, and then the simulation after time sequence is carried out again.

The whole ASIC design flow is a iterative process, both digital and analog integrated circuit design verification. When either step fails to meet the constraints or fails to function, the previous steps need to be repeated, even redesigning the RTL code. So although some down arrows are used in fig. 1 to connect the stages, in practice, after any one step has ended, it may be necessary to return to the previous step to be modified again for simulation verification if the requirements are not met. And finally obtaining the GDSII file of the designed system-on-chip for streaming. The digital integrated circuit design may include, but is not limited to, the stages shown in fig. 1. In addition, the order of some of the stages shown in fig. 1 may be changed. And some of these stages may be combined or omitted as desired.

In the case of a large scale integrated circuit system on a chip comprising a number of modules, a post simulation may be performed for all modules comprised by the whole system on a chip. However, it is also possible that some of the modules may be needed in an application scenario. And in another application scenario other modules are needed. In order to support flexibility adaptation to these and other application scenarios in the post-simulation process and further improve the efficiency of the post-simulation, the present disclosure proposes a method and a simulation platform for inter-module joint simulation in a flexible custom subsystem. And automated post-simulation processing is performed after post-simulation is supported.

Fig. 2a shows a schematic diagram of a system on a chip 200 for configuring a custom subsystem according to an embodiment of the present disclosure. The system on chip 200 comprises modules 201-206 for implementing different functions, respectively. The system-on-chip 200 may be a large scale or very large scale integrated circuit system-on-chip, such as a digital integrated circuit, an analog integrated circuit, or an analog/digital hybrid integrated circuit system-on-chip. In one embodiment, modules 201-206 may include power supply modules, speakers, memory, codecs, sensors, filters, or other functional modules. Although the system-on-chip 200 shown in fig. 2a includes only six modules 201-206, this is merely illustrative. In practice, more (e.g., tens, hundreds) or fewer modules may be included within the system-on-chip 200. In post-simulating the system on chip 200, all modules of the entire system on chip 200 may be post-simulated. However, in cases where the function of some of the modules is not of concern, the post-simulation of the entire system-on-chip 200 may take a lot of time, with very low efficiency.

In the embodiment of the disclosure, one or more modules from the multiple modules of the system-on-chip may be selected to form a custom subsystem according to an actual application scenario to perform post-simulation. For example, module 201 is a Graphics Processor (GPU), module 202 is a Double Data Rate (DDR) memory, and module 203 is a display. In the case where only emulation verification of the GPU's data storage and access operations to DDR is required, no post-emulation is required in conjunction with the display of module 203 and modules 204-206. But only post-simulation of modules 201 and 202. Reference in this disclosure to a "custom subsystem" is a subsystem to be post-simulated that is formed by combining one or more of all functional modules of the system-on-chip 200 according to the needs of the post-simulation. For example, module 201 and module 202 make up custom subsystem A, and module 202 and module 203 make up another custom subsystem B. For ease of distinguishing and explaining the principles of the present disclosure, the modules included in the "custom subsystem" are referred to as "target modules". The post-simulation of a "custom subsystem" is essentially a post-simulation of the target modules that the custom subsystem includes. For example, the post-simulation of custom subsystem A is essentially a post-simulation of target modules 201 and 202 included in custom subsystem A.

A direct customization subsystem for the configuration of the modules included in the system on chip 200 is disclosed in fig. 2 a. In addition, the system on a chip may also include a plurality of subsystems, each subsystem including a plurality of modules therein. The subsystems may be separately designed and verified according to the existing layering method, and may be divided in other manners. In this case, it is possible that a large number of modules are still included in each subsystem, some of which are not applicable in some scenarios. At this time, it still takes much time to perform the post-simulation on the entire subsystem, and the simulation efficiency is still not high. In addition, it may be desirable to have some modules in one subsystem perform post-simulation along with some modules in another subsystem. The existing hierarchical design and verification method cannot meet the flexible post-simulation requirements of the post-simulation under various application scenes and simulation efficiency requirements due to the fact that design verification is performed based on a fixed hierarchy divided in the initial stage of design. According to the method for post-simulation, the post-simulation of each subsystem can be realized, the post-simulation of partial modules of the subsystems can be realized, and the post-simulation of a plurality of modules crossing different subsystems can be realized, so that the efficiency of the post-simulation is further improved.

Additional schematic diagrams of a system-on-chip for configuring a custom subsystem in accordance with embodiments of the present disclosure are disclosed in fig. 2b and 2 c. In fig. 2b, the system on chip 200 comprises a subsystem E and a subsystem F. Wherein subsystem E comprises modules 201-203 and subsystem F comprises modules 204-206. In one embodiment, custom subsystem C to be post-simulated is configured to include modules 205 and 206 in subsystem F as target modules. In other embodiments, the custom subsystem C to be post-simulated may also include other modules in the subsystem F or modules in the subsystem E as target modules. In fig. 2c, the system on chip 200 comprises a subsystem E and a subsystem F. Wherein subsystem E comprises modules 201-203 and subsystem F comprises modules 204-206. In one embodiment, the custom subsystem D to be post-simulated is configured to include the module 202 in subsystem E and the module 205 in subsystem F as target modules. In other embodiments, the custom subsystem D to be post-simulated may also include other modules in the subsystems E and F as target modules. In other words, the method for configuring the custom subsystem according to the present disclosure may implement post-simulation of a portion of modules within the same subsystem, and may also implement post-simulation between multiple modules across different subsystems.

Fig. 3 shows a schematic diagram of a four-core GPU system for specifying a configuration of a custom subsystem, according to an embodiment of the present disclosure. The four-core GPU system 300 shown in fig. 3 includes a first GPU core, a second GPU core, a third GPU core, a fourth GPU core, and modules that are common to the various GPU cores. Each GPU core may include a respective functional module, such as a processor, buffer, etc. The universal modules may include a power module, a clock module, a display, and the like. Each GPU core may be referred to as a subsystem. In post-simulation, each GPU core may be post-simulated separately along with the generic module. However, the design of the individual GPU cores may only be slightly different. In the case where the function and timing of one of the GPU cores (e.g., the first GPU core) has passed the post-simulation verification, the post-simulation may be performed only on the portion of the modules within the other GPU cores (e.g., the second to fourth GPU cores) that are different from the first GPU core, so as to improve the efficiency of the post-simulation. In one embodiment, the custom subsystem may be configured to include the module 305 of the second GPU-core (e.g., the module 305 differs from the corresponding module within the first GPU-core) along with the required general-purpose modules (e.g., the power modules and clock modules in general-purpose modules 313-316) for post-simulation. In another embodiment, for example, only to debug a module, other modules within the corresponding subsystem that are debugged with that module are not yet verified by simulation, but the function and timing of the other modules are not of interest in the current and subsequent simulations. At this time, the corresponding module which has passed the simulation verification in the other subsystem may be utilized to perform the post-simulation together with the module to be debugged. For example, the custom subsystem to be post-emulated may be configured to include the module 306 of the second GPU-core (which may be the module to be debugged) and the module 301 of the first GPU-core (which has been validated by the emulation and may cooperate with the module 306 of the second GPU-core to perform the required debugging) along with one or more generic modules (e.g., module 315) as target modules for the post-emulation. Thus, the post-simulation method of the custom subsystem proposed by the present disclosure supports joint post-simulation of multiple modules across multiple subsystems.

It is noted that multiple subsystems, such as a first through fourth GPU cores, may be included in the system on a chip. In addition to the plurality of subsystems, the system-on-chip may also include other modules, such as a plurality of general-purpose modules. In further embodiments, the on-chip subsystem may include multiple subsystems, without including other modules in addition to the multiple subsystems. In this case, each subsystem may include some or all of the generic modules. However, whether or not all of the modules of the system-on-chip are included in an existing subsystem, and how the existing subsystem is partitioned, does not affect the implementation of the method of configuring a custom subsystem for post-simulation proposed by the present disclosure. In other words, the method for configuring a custom subsystem for post-simulation proposed by the present disclosure can be configured as needed to include different modules present in different existing subsystems as target modules, independent of the partitioning of existing subsystems that may be present in the system-on-chip. It is also noted that while the method for post-simulation according to the present disclosure is described above with embodiments of a multi-core GPU, the method of the present disclosure may be applicable to any other system on chip, such as a multi-core CPU system or the like.

FIG. 4 illustrates a method for post-simulation of a custom subsystem according to an embodiment of the present disclosure. In step S11, subsystem codes for defining the custom subsystem are generated according to subsystem parameters in the simulation command. In step S12, a target module included in the custom subsystem is determined according to the subsystem code. In step S13, other modules of the system-on-chip except the custom subsystem are replaced with a dummy file. In step S14, a post-simulation is performed on the custom subsystem. The custom subsystem may be configured according to application scenarios, post-simulation efficiencies, or other requirements. In the case shown in FIG. 2, the target modules of custom subsystem A are modules 201-202. The target modules of custom subsystem B are modules 202-203. In other cases, not shown, the custom subsystem may include other modules as target modules. Therefore, only the target module included in the custom subsystem can be subjected to post-simulation, and the efficiency of post-simulation of the system on a chip is greatly improved.

It is noted that the ultimate goal of the development of integrated circuit chips is to obtain chips that are integrated with integrated circuit system-on-chip. In the method for accelerating the post-simulation of the system on chip, the post-simulation can be performed according to the application scene or the self-defined subsystem such as the requirement of the simulation efficiency and the like during the post-simulation. The configuration of the custom subsystem may be very flexible. Each verification engineer may be configured as desired. In one embodiment, the custom subsystem may include only one module, and in another embodiment, the custom subsystem may be the smallest custom subsystem that can be made up of one or more of all the modules of the system-on-chip to achieve a certain function. The minimum custom subsystem has the highest flexible adaptability, and the subsequent post-simulation of any larger custom subsystem can be realized by adding the minimum custom subsystem included in the post-simulation. In the case of an integrated circuit system-on-chip comprising a very large number of modules (e.g., hundreds or thousands), configuring one or more custom subsystems as needed, and then performing a post-simulation can more easily and quickly implement a post-simulation of the target modules of interest in the overall system-on-chip.

The method for post-simulation of a custom subsystem of a system-on-chip comprising a plurality of modules is described above in connection with the embodiment of fig. 4. By the method, flexible customized post-simulation among a plurality of modules or among different modules of a plurality of subsystems can be realized. Compared with layering of the large-scale integrated circuit in the early design stage in the prior art, the post-simulation method described in connection with fig. 4 can realize flexible configuration of the custom subsystem to be post-simulated and determination of the target module thereof during the post-simulation, and the module which is not needed or not concerned is replaced by the empty file, so that the post-simulation is not performed. The time required by the post-simulation is greatly saved, and the efficiency of the post-simulation is improved.

Design verification of integrated circuit systems on chip is a complex iterative process involving the collaborative work among a plurality of different engineers or teams at the front-end and back-end. Often, in the case of an unrepairable warning or error encountered in the simulation verification stage or even in the back-end place-and-route stage, it is necessary to return to the previous step or even to re-modify the RTL code, and then to repeat the simulation verification, place-and-route, etc. Thus, although the design verification of the integrated circuit system on a chip will ultimately result in a GDSII file corresponding to the layout, and deliver it to the foundry for streaming. However, throughout the development of a system-on-chip, there may be many versions of the post-simulation file of the system-on-chip that may be used to build a simulation environment. For example, a netlist of the system-on-chip and its corresponding standard delay-format file may be obtained after the logic synthesis stage illustrated in FIG. 1. This phase also calls the vendor's device library, but the connections between devices are simply logical connections. The standard delay format file obtained at this stage includes delay information of all devices in the corresponding netlist but does not include path delays on the device wiring. After the back-end place and route adjustment in fig. 1, a standard delay format file is obtained taking the path delay into account. Even in the same development stage, netlists and their corresponding standard delay-format files change due to editing standard cell libraries, modifying RTL code, adding constraints, repairing some timing violations, etc. Thus, during design verification of an integrated circuit system-on-chip, the post-simulation files of the system-on-chip are also updated periodically, such as once every two weeks. Thus, versions of post-simulation files of the system-on-chip, obtained at many (e.g., tens of) different stages, updated at different times, defined by different engineers, or for different application scenarios, or based on different process corners, are stored inside the simulation platform. The method for post-simulation disclosed in fig. 4 may configure the custom subsystem and then perform post-simulation on the configured custom subsystem. The method for post-simulation of the system on chip in the present disclosure may also realize that the entire system on chip is post-simulated by automatically switching to a post-simulation file of any one of all versions according to the version parameters in the simulation command.

A method 500 of post-simulating a system-on-chip based on a post-simulation file of a target version of the system-on-chip in accordance with an embodiment of the present disclosure is shown in fig. 5. In step S21, a version code of information of the post-simulation file defining the target version is generated from the version parameters in the simulation command. In step S22, a target version of the post-simulation file is selected from the plurality of versions of the post-simulation files according to the version code. Version code may be used to isolate the target version from other versions of the post-emulation file. The multiple versions of the post-simulation file of the system-on-chip include versions of the post-simulation file of the system-on-chip generated by different personnel on different dates, or at different design stages of the system-on-chip, or based on different process corners or application scenarios. In other embodiments, the post-simulation file may also include a library file of memory (memory). Whether the post-emulation file includes a library file of memory depends on the needs of the system-on-chip design and post-emulation, such as whether the system-on-chip design uses memory and whether the library file of memory changes during development of the system-on-chip, etc. Different process corners correspond to different gate delays. The speed fluctuation range of NMOS and PMOS transistors is generally limited to a rectangle defined by four corners. The four angles are respectively: fast NFET and fast PFET (FF), slow NFET and slow PFET (SS), fast NFET and slow PFET (FS), slow NFET and fast PFET (SF). The process corner of the center typical range is TT. In one embodiment, the process corner may include only three of TT, SS, and FF.

The user or verification engineer may input version parameters of the target version of the system-on-chip to be post-simulated in the command box based on the application scenario and the requirements of the simulation efficiency. The emulation platform can automatically generate version code of a hardware language defining version information of a post-emulation file of the system-on-chip. And automatically selecting a target version post-simulation file of the system-on-chip based on the version code.

In step S23, the simulation platform automatically switches from the current version of the post-simulation file to the target version of the post-simulation file of the system-on-chip. In step S24, the system on chip is post-simulated based on the post-simulation file of the target version. In one embodiment, automatically switching to the post-emulation file of the target version of the system-on-chip includes automatically replacing the default post-emulation file with the post-emulation file of the target version of the system-on-chip. In another embodiment, automatically switching to the post-emulation file of the target version of the system-on-chip includes switching from the post-emulation file of the other version of the currently loaded system-on-chip to the post-emulation file of the target version of the system-on-chip. Without manually selecting one of the tens, hundreds, of post-simulation file versions to execute. For some large scale integrated circuit systems on chip, the product development cycle is long, the number of post-simulation files in the intermediate version is large, the naming of the versions may be very similar, and the existing manual selection of the version of the post-simulation file is time consuming and very error prone. And once the error is selected, the user or verification engineer may not easily find it, resulting in wasted post-simulation time while losing the effectiveness of the post-simulation. According to the method described in the disclosure with respect to fig. 5, the post-simulation file that is completely and automatically switched to the target version of the system-on-chip can be implemented according to the version parameters in the simulation command input by the user or the verification engineer, so that the post-simulation time is saved, and errors in version selection in the post-simulation are reduced, thereby further improving the efficiency of the post-simulation.

The post-simulation method illustrated in FIG. 5 may automatically switch post-simulation files of a target version of a system-on-chip, as compared to post-simulation of a target module included in a custom subsystem as illustrated in FIG. 4. The embodiments described with respect to fig. 4 and 5 may be used separately or both may be used in combination, such as selecting a post-simulation file of a target version of a post-simulation system on a chip and extracting a post-simulation file of a custom subsystem from the post-simulation files of all modules of the system on a chip that is to actually perform the post-simulation.

Alternatively, the embodiments set forth with respect to fig. 4 and 5 may also be performed simultaneously. For example, a user or verification engineer may enter both version parameters and subsystem parameters in the command box at the same time. Fig. 6 illustrates a method 600 for post-simulation of a system-on-chip (e.g., systems-on-chip 200 and 300) including a plurality of modules, in accordance with an embodiment of the present disclosure. Wherein the system on a chip comprises a plurality of modules. The method shown in FIG. 6 combines the configuration of the custom subsystem of FIG. 4 with the selection of the target version of the post-simulation file of FIG. 5. In step S31, a custom subsystem to be post-simulated is configured in the simulation platform according to the simulation command. Wherein the custom subsystem may include at least one module of the plurality of modules. The configuration of the custom subsystem may be performed according to application scenarios, post-simulation efficiencies, or other requirements. In one embodiment, step S31 may include generating subsystem code for defining the custom subsystem based on subsystem parameters in the emulation command; and determining a target module included in the custom subsystem according to the subsystem code. Wherein the subsystem parameters have been defined in advance in the simulation platform. The verification engineer or other users can directly input corresponding subsystem parameters in the simulation command according to the application scene, the simulation efficiency requirement and the like, and the simulation platform can determine the target module included in the custom subsystem to be simulated.

In step S32, other modules of the system-on-chip than the custom subsystem are replaced with blank files, because in the current back-simulation, the user is not paying attention to these other modules. In the case of custom subsystem A shown in FIG. 2, modules 203-206 are replaced with empty files. Therefore, only the target module included in the custom subsystem can be subjected to post-simulation, and the post-simulation time is greatly saved.

In step S33, a post-simulation file of the custom subsystem is determined according to the simulation command. The emulation platform supports multiple versions of post-emulation files of the system-on-chip. In one embodiment, step S33 may include specifying a post-simulation file of the target version according to the version parameters in the simulation command; and extracting the post-simulation file of the custom subsystem from the post-simulation file of the target version according to the subsystem code. The simulation platform may generate a version code for defining information of the target version of the post-simulation file according to the version parameters in the simulation command, and then select the target version of the post-simulation file from the plurality of versions of the post-simulation file according to the version code. Wherein the multiple versions of post-simulation files comprise different versions of post-simulation files developed by different personnel or generated based on different process corners at different design stages of the system-on-chip. And the post-simulation file includes a netlist, a standard delay-format file, and a standard cell library. In other embodiments, the post-simulation file may also include a library file of memory (memory). Whether the post-emulation file includes a library file of memory depends on the needs of the system-on-chip design and post-emulation, such as whether the system-on-chip design uses memory and whether the library file of memory changes during development of the system-on-chip, etc.

In step S34, a post-simulation is performed on the custom subsystem based on the post-simulation file. The method realizes the configuration of the custom subsystem according to subsystem parameters and version parameters in the simulation command and the post-simulation of the custom subsystem. Therefore, the version selection of the post-simulation file of the system on chip can be automatically controlled by simultaneously transmitting two parameters to the simulation platform, and the custom subsystem to be really subjected to the post-simulation and the target module included in the custom subsystem are selected. Therefore, the switching of the post-simulation files of different versions can be realized on the same simulation platform, and the flexible post-simulation verification of the custom subsystem can be realized. This may further improve the efficiency of the post-simulation.

The post-simulation files referred to in this disclosure include netlists, standard Delay Format (SDF) files, and standard cell libraries. In some embodiments, the post-simulation file may also include a library file of memory. The netlist can be a netlist obtained after the logic synthesis of the system-on-chip, or a netlist with time sequence information after the de-labeling of the standard delay format file. The Standard Delay Format (SDF) file may be a standard delay format file corresponding to the synthesized netlist. The standard delay format file can also be obtained by extracting parasitic parameters and then calculating after performing back-end layout wiring on the system on chip. The standard delay format file retains the information of device delay and line delay in the process of layout and wiring, so that the time sequence of the whole path can be calculated in the time sequence analysis of the path. Inherent delays, interconnect delays, port delays, timing checks, timing constraints, path pulses, etc. may be specified in the standard delay format file.

When the post-simulation is performed on the custom subsystem, the standard delay format file obtained after layout and wiring can be reversely marked in the corresponding netlist to obtain the netlist with reverse-marked time sequence information, so that the post-simulation is performed on the netlist. Many errors or warnings are reported during the de-labelling of standard delay format files. According to the post-simulation method and the simulation platform, automatic analysis of SDF anti-mark logs which appear when the standard delay format file of the target module included in any user-defined subsystem is subjected to anti-mark can be realized, errors reported in the anti-mark process are classified to be output to the same file in the same type, and information related to each error in the errors is provided; and/or automatically classifying the warnings reported in the anti-tagging process, so that the warnings of the same type are output to the same file, and information related to each warning is provided, thereby improving the efficiency of SDF anti-tagging analysis and confirmation.

In addition, in post-Timing simulation of a system-on-chip, a significant portion of the reported results are Timing violations (Timing violations). By timing violation is meant a situation in which the setup time or hold time is violated such that the sampling clock is unable to collect data. Verification engineers need to expend much effort in analyzing whether these timing violations are caused by real timing issues. The method according to the present disclosure also enables the automated filtering and analysis of timing violations occurring in any custom subsystem post-simulations. In one embodiment, the time points and keywords may be set to automatically filter out timing violations before the time point and timing violations including the keywords from timing violations reported in the post simulation process. And then the filtered residual time sequence violations are respectively output to two files according to time sequence or grouping according to paths, and information related to each time sequence violation is provided, so that the efficiency of analyzing and confirming the time sequence violations is improved. The point in time may be a point in time when the target module clock of the custom subsystem is asynchronously reset. The keywords may be any number, letter, or regular expression, such as "DFT.

For the design of large-scale or very large-scale integrated circuit systems on chip, the modules and wires involved in the system on chip are numerous. The SDF file obtained after placement and routing does not necessarily correspond exactly to the netlist. When the post-simulation is performed on the custom subsystem, for example, in the initial stage of the post-simulation, the actual delay amounts of the components and paths included in the target module of the custom subsystem can be directly compared with the delay information of the corresponding components and corresponding paths recorded in the corresponding standard delay format file, for example, in a waveform window, so as to evaluate the accuracy of the post-simulation of the custom subsystem and grasp the progress of the post-simulation.

It is noted that although arrows are used in fig. 4, 5 and 6 to connect the steps of each post simulation, this is merely illustrative. Indeed, the order of these post-simulation steps may be interchanged without departing from the principles of the present disclosure. It is also noted that although the present disclosure is developed based on post-simulation of integrated circuit system-on-chip, the methods of the present disclosure are not limited to application in integrated circuit system-on-chip. Rather, the methods of the present disclosure may be applied to any product in the form of an integrated circuit chip, such as a Network On Chip (NOC) or other chip that includes one or more functional modules, with simple adaptations. Additionally, the methods set forth in this disclosure may also be stored in a computer-readable storage medium in the form of program instructions that, when executed on one or more processors, cause the one or more processors to perform a method for post-simulation of a system-on-chip according to this disclosure.

FIG. 7 illustrates a simulation platform 700 for post-simulating a system on a chip in accordance with an embodiment of the present disclosure. Wherein the system on a chip comprises a plurality of modules. The various units in simulation platform 700 may each be configured to implement a method according to an embodiment of the present disclosure. In one embodiment, a subsystem configuration unit 701, a dummy (dummy) unit 702, a post-simulation file determination unit 703, and a post-simulation unit 704 may be included in the simulation platform 700. The subsystem configuration unit 701 is configured to configure a custom subsystem to be simulated later in the simulation platform according to a simulation command. Dummy unit 702 is used to replace other modules of the system-on-chip, except for the custom subsystem, with a blank file. The post-simulation file determining unit 703 is configured to determine a post-simulation file of the custom subsystem according to the simulation command. The post-simulation unit 704 is configured to perform post-simulation on the custom subsystem based on the post-simulation file.

The subsystem configuration unit 701 includes a subsystem definition unit 705 and a target module determination unit 706. Wherein the subsystem definition unit 705 is configured to generate subsystem codes for defining the custom subsystem according to subsystem parameters in the emulation command. The target module determining unit 706 is configured to determine, according to the subsystem code, a target module included in the custom subsystem. The simulation platform proposed by the present disclosure supports multiple versions of post-simulation files of a system-on-chip. The post-simulation file determination unit 703 includes a version specification unit 707 and a post-simulation file extraction unit 708. The version specification unit 707 is configured to specify a post-simulation file of the target version according to the version parameter in the simulation command. The post-simulation file extraction unit 708 is configured to extract a post-simulation file of the custom subsystem from the post-simulation files of the target version according to the subsystem code. The version specification unit 707 may include a version definition unit 709 and a version selection unit 710. Wherein the version definition unit 709 is configured to generate a version code for defining information of the post-simulation file of the target version according to the version parameter in the simulation command. The version selection unit 710 is configured to select a post-simulation file of the target version from the plurality of versions of post-simulation files according to the version code. The simulation platform 700 may also include other units such as a superscript unit 711, a superscript post-processing unit 712, an evaluation unit 713, and a timing violation processing unit 714. The anti-scaling unit 711 is configured to perform anti-scaling on a standard delay format file in a post-simulation file of the custom subsystem to obtain a netlist with anti-scaled timing information. The anti-labeling post-processing unit 712 is configured to categorize errors reported in the anti-labeling process to output the same type of errors into the same file, and provide information related to each of the errors; and categorizing the alerts reported in the anti-tagging process to output the same type of alert to the same file while providing information related to each of the alerts. The evaluation unit 713 is configured to compare, when performing post-simulation on the custom subsystem, an actual delay amount on a specific component and a path included in a target module of the custom subsystem with delay information of a corresponding component and a corresponding path recorded in a standard delay format file, so as to evaluate accuracy of post-simulation of the custom subsystem, and facilitate a user or a verification engineer to grasp a simulation progress. The timing violation processing unit 714 is configured to set a time point and a keyword, so as to filter out timing violations before the time point and timing violations including the keyword from timing violations reported by the post simulation; and sorting the remaining timing violations after filtering by time and grouping by path and respectively outputting into two files while providing information related to each of the remaining timing violations.

In one embodiment, the simulation platform 700 shown in FIG. 7 may also include a storage unit 715, such as a post-simulation file for storing multiple versions of the system-on-chip. Alternatively, the storage unit 715 may not be included, and the post-simulation files of the multiple versions of the system-on-chip may be stored in a remote memory or in the cloud. In other embodiments, the simulation platform 700 may also include other elements not shown, such as a simulation command input element, an automatic place and route element, a Standard Delay Format (SDF) file generation element, and so forth. The simulation platform 700 shown in fig. 7 is merely illustrative and does not show detailed interactions between the various elements. In addition, some elements of simulation platform 700 may be combined together or split into multiple elements without departing from the principles set forth in this disclosure. Furthermore, simulation platform 700 may be configured as a software product, a hardware device, or firmware. The simulation platform 700 may be provided by EDA tool vendors or may be custom developed by the user on his own as desired. It is noted that, although the functions of the respective units included in the simulation platform in fig. 7 are described corresponding to the method for post-simulation shown in fig. 6. However, the simulation platform in FIG. 7 may also be used to implement the methods for post-simulation disclosed in connection with FIGS. 4 and 5.

Fig. 8 illustrates a computing device 800 according to an embodiment of the disclosure. Computing device 800 may include an emulation platform as set forth above in accordance with an embodiment of the present disclosure. Computing device 800 also includes, but is not limited to, a processor, at least one communication circuit, a storage device, a display screen, a camera, a chipset, a battery, an antenna, and an I/O subsystem, among others. Wherein the processor may be any device or portion of a device that is capable of processing electronic data from registers and/or storage to transform that electronic data into other electronic data that may be stored in registers and/or storage. The processor may be a Central Processing Unit (CPU), a portion thereof, or may be a multi-core CPU. The communication circuitry may be used to transfer data from the computing device 800 to external components, or to transfer data from the outside to the computing device 800, either wirelessly through an antenna in the computing device. The communication circuitry may implement any of the existing and future developed wireless communication standards or protocols. Further, multiple communication circuits may be included in computing device 800. Some of which are dedicated to shorter range communications and others are dedicated to longer range communications. The storage device may be any device suitable for permanently or temporarily storing data, such as volatile memory (e.g., DRAM), non-volatile memory (e.g., ROM), flash memory, and the like. Computing device 800 may also include a memory controller (although not shown in fig. 8) for controlling the operation of the storage. The display screen in computing device 800 may be any screen capable of displaying graphics or video, such as a touch screen. The I/O subsystem within computing device 800 may be used to connect various components internal to computing device 800 or to connect computing device 800 with components external thereto. The chipset within computing device 800 may include any other components including, but not limited to, a digital signal processor, a cryptographic processor, a touch screen controller, a power amplifier, a GPS system, a graphics processing unit, and the like. Computing device 800 may be a computing device within a mobile terminal (e.g., a smart phone), or may be a computing device in a desktop or workstation.

It should be understood that for clarity, embodiments of the present disclosure have been described with reference to different functional units. It is apparent that the functions of each functional unit may be implemented in a single unit, in a plurality of units, or as part of other functional units without departing from the disclosure. Thus, the present disclosure may be implemented in a single unit or may be physically and functionally distributed between different units and circuits.

It should be understood that, although the terms first, second, third, etc. may be used herein to describe various devices, elements, components or stages, these devices, elements, components or stages should not be limited by these terms. These terms are only used to distinguish one device, element, component, or stage from another device, element, component, or stage.

Although the present disclosure has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present disclosure is limited only by the appended claims. In addition, although individual features may be included in different claims, these may be combined. The order of features in the claims does not imply any specific order in which the features must be worked. Furthermore, in the claims, the word "comprising" does not exclude other elements, and the term "a" or "an" does not exclude a plurality.

Claims

1. A method for post-simulation of a system-on-chip, the system-on-chip comprising a plurality of modules, the method comprising:

configuring a custom subsystem to be simulated later in a simulation platform according to a simulation command;

replacing other modules of the system on chip except the custom subsystem with a blank file;

determining a post-simulation file of the custom subsystem according to the simulation command, and

and performing post-simulation on the custom subsystem based on the post-simulation file.

2. The method of claim 1, wherein configuring the custom subsystem to be post-simulated in the simulation platform in accordance with the simulation command comprises:

generating subsystem codes for defining the custom subsystem according to subsystem parameters in the simulation command; and

and determining a target module included in the custom subsystem according to the subsystem code.

3. The method of claim 2, wherein the simulation platform supports multiple versions of post-simulation files of the system-on-chip, determining post-simulation files of the custom subsystem according to simulation commands comprises:

designating a post-simulation file of the target version according to the version parameters in the simulation command; and

And extracting the post-simulation file of the custom subsystem from the post-simulation file of the target version according to the subsystem code.

4. The method of claim 3, wherein specifying the post-simulation file for the target version according to the version parameter in the simulation command comprises:

generating version codes for defining information of the post-simulation file of the target version according to version parameters in the simulation command; and

and selecting the post-simulation file of the target version from the post-simulation files of the multiple versions according to the version code.

5. The method of any of claims 1-4, wherein the post-simulation file comprises a netlist, a standard delay-format file, and a standard cell library, and the method further comprises:

and performing anti-labeling on a standard delay format file in the post-simulation file of the custom subsystem to obtain a netlist with anti-labeled time sequence information.

6. The method of claim 5, further comprising:

classifying errors reported in the anti-tagging process to output the same type of errors into the same file, while providing information related to each of the errors; and

Alerts reported in the anti-tagging process are categorized to output the same type of alert to the same file while providing information related to each of the alerts.

7. The method of claim 1, further comprising: and when the post-simulation is carried out on the custom subsystem, comparing the actual delay amount on the specific components and paths included in the target module of the custom subsystem with the delay information of the corresponding components and corresponding paths recorded in the standard delay format file so as to evaluate the accuracy of the post-simulation of the custom subsystem.

8. The method of claim 1, further comprising: setting a time point and a keyword to filter out timing violations before the time point from timing violations reported in post-simulation of the custom subsystem, wherein the timing violations comprise the keyword; and

the remaining timing violations after filtering are time ordered and path grouped and output to two files separately while providing information about each of the remaining timing violations.

9. The method of claim 3, wherein the plurality of versions of post-simulation files comprise: different versions of the post-simulation file generated by different personnel or based on different process corners at different design stages of the system-on-chip.

10. A simulation platform for post-simulation of a system-on-chip, the system-on-chip comprising a plurality of modules, the simulation platform comprising:

the subsystem configuration unit is used for configuring a user-defined subsystem to be simulated later in the simulation platform according to the simulation command;

a dummy unit for replacing other modules of the system on chip except the custom subsystem with a blank file;

the post-simulation file determining unit is used for determining a post-simulation file of the custom subsystem according to the simulation command; and

and the post-simulation unit is used for carrying out post-simulation on the custom subsystem based on the post-simulation file.

11. The simulation platform of claim 10, wherein the subsystem configuration unit comprises:

a subsystem definition unit, configured to generate a subsystem code for defining the custom subsystem according to a subsystem parameter in the simulation command; and

and the target module determining unit is used for determining a target module included in the custom subsystem according to the subsystem code.

12. The simulation platform of claim 11, wherein the simulation platform supports a post-simulation file of multiple versions of the system-on-chip, the post-simulation file determination unit comprising:

Version designating unit for designating the post-simulation file of the target version according to the version parameters in the simulation command; and

and the post-simulation file extraction unit is used for extracting the post-simulation file of the custom subsystem from the post-simulation file of the target version according to the subsystem code.

13. The simulation platform of claim 12, wherein the version specification unit comprises:

a version definition unit for generating a version code for defining information of the post-simulation file of the target version according to the version parameter in the simulation command; and

and the version selection unit is used for selecting the post-simulation file of the target version from the post-simulation files of the multiple versions according to the version code.

14. The simulation platform of any of claims 10-13, wherein the post-simulation file comprises a netlist, a standard delay format file, and a standard cell library, and the simulation platform further comprises:

and the anti-labeling unit is used for carrying out anti-labeling on the standard delay format file in the post-simulation file of the self-defining subsystem so as to obtain a netlist with time sequence information after the anti-labeling.

15. The simulation platform of claim 14, further comprising a de-labeling post-processing unit to:

16. The simulation platform of claim 10, further comprising an evaluation unit, configured to compare an actual delay amount on a specific component and path included in a target module of the custom subsystem with delay information of a corresponding component and a corresponding path recorded in a standard delay format file, when performing post-simulation on the custom subsystem, so as to evaluate accuracy of post-simulation of the custom subsystem.

17. The simulation platform of claim 10, further comprising a timing violation processing unit to:

setting a time point and a keyword to filter out timing violations before the time point from timing violations reported in post-simulation of the custom subsystem, wherein the timing violations comprise the keyword; and

18. A simulation platform for post-simulation of a system-on-chip, the simulation platform supporting multiple versions of post-simulation files of the system-on-chip, the simulation platform configured to:

generating version codes of information of the post-simulation file for defining the target version according to the version parameters in the simulation command;

selecting a post-simulation file of the target version from the plurality of versions of post-simulation files according to the version code;

switching from the current version of the post-simulation file to the target version of the post-simulation file; and

and performing post-simulation on the system on chip based on the post-simulation file of the target version.

19. A computing device comprising the simulation platform of any of claims 10-18.

20. A machine-readable medium having instructions stored thereon, which when executed by a machine, cause the machine to perform the method of any of claims 1-9.