CN115983171B

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

Info

Publication number: CN115983171B
Application number: CN202310258993.1A
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-09
Anticipated expiration: 2043-03-17
Also published as: CN115983171A

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: creating a timing check white list for each of a plurality of modules within the system-on-chip; and closing the time sequence check of the components included in the time sequence check white list of the target module of the custom subsystem so as to perform post-simulation on the custom subsystem.

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 (SoC).

Background

The design and verification of integrated circuit systems on a chip 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.

In addition, a large number of timing violations are reported during post-simulation of the integrated circuit system on a chip relative to pre-simulation, which severely slows down the process of post-simulation. By timing violations is meant violations of setup or hold times or other timing constraints such that the sampling clock cannot properly collect the data. Verification engineers are required to expend a great deal of effort in analyzing whether these timing violations are real timing violations caused by design issues or are negligible false timing violations. This brings a laborious verification effort to the verification engineer.

Disclosure of Invention

Aiming at the defects in the prior art, the application provides a method and a simulation platform for performing post-simulation on a system on a chip. This post-simulation method and simulation platform is capable of creating a timing check white list for each of all the modules included in the system-on-chip. Therefore, the time sequence inspection of the components on the time sequence inspection white list is automatically closed when the post-simulation is carried out on the custom subsystem system in the whole system-on-chip. Thus, the number of timing violations reported when post-simulation is performed on the system-on-chip is greatly reduced. In addition, the method and the simulation platform for post simulation according to the present disclosure may further configure a custom subsystem to be post-simulated according to a simulation command, and further determine a post-simulation file of the custom subsystem according to the simulation command, so as to post-simulate the custom subsystem. In addition, the method and the simulation platform for performing post-simulation on the system on chip can further add the related components with the reported time sequence violations being false time sequence violations to the time sequence checking white list of the corresponding module through analyzing the post-simulation report of the system on chip or the custom subsystem, so that the components can be prevented from being subjected to time sequence checking again in the next simulation, and the number of the time sequence violations of the post-simulation report can be further reduced.

Thus, instead of post-simulating the entire system-on-chip, the desired custom subsystem of the system-on-chip is post-simulated to increase the efficiency of the post-simulation. The timing sequence inspection of the components in the timing sequence inspection white list of all the modules of the system on chip is not closed, but the timing sequence inspection of the components in the timing sequence inspection white list of the target module included in the configured custom subsystem is closed, so that the number of false timing violations reported in the post-simulation of the system on chip is reduced, errors, which are not existed in corresponding registers and reported by other modules outside the custom subsystem due to substitution of empty files, are avoided, and the post-simulation of the system on chip is smoother. In addition, instead of using a fixed timing inspection white list for each module of the system-on-chip, each time a post-simulation report of the system-on-chip is analyzed, the timing inspection white list of the module participating in the post-simulation is updated and maintained, and relevant components of which the reported timing violations are false timing violations are added to the corresponding timing inspection white list, so that the number of the timing violations reported in the post-simulation is further reduced, and the workload of a verification engineer is reduced. In addition, the method and the simulation platform for post simulation are extremely user friendly, and a user can realize the configuration of the custom subsystem, the time sequence inspection of the components in the time sequence inspection white list of the target module included in the closed custom subsystem, the determination of the post simulation file of the custom subsystem and the post simulation of the custom subsystem only by simply inputting corresponding parameters in a simulation command, so that the post simulation efficiency is improved, and the product development period is further shortened.

In addition, the method and the simulation platform for post-simulation of the system on chip can also filter the timing violations reported by the post-simulation of the system on chip according to time points and keywords so as to filter out part of false timing violations in the post-simulation report, thereby further reducing the workload of a verification engineer.

In one aspect, the present application proposes a method for post-simulation of a system-on-chip, the system-on-chip comprising a plurality of modules, the method comprising: creating a timing check white list for each of the plurality of modules; and closing the time sequence check of the components included in the time sequence check white list of the target module of the custom subsystem so as to perform post-simulation on the custom subsystem.

In one embodiment, the method further comprises: configuring the custom subsystem 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, wherein configuring the custom subsystem 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 determining a target module included in the custom subsystem according to the subsystem code.

In one embodiment, wherein the simulation platform supports multiple versions of the post-simulation file of the system-on-chip, determining the 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-emulation file in which the target version is specified according to the version parameters in the emulation 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 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, wherein the timing check whitelist of each module comprises: a first level register list across the clock domain and a list of additional components.

In one embodiment, the method further comprises: the post-simulation report of the custom subsystem is analyzed to add relevant components for which the reported timing violation is a false timing violation to the list of additional components.

In one embodiment, the post-simulation file includes a netlist, a Standard Delay Format (SDF) 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 information related to 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, the point in time includes a time at which an asynchronous reset of the clock occurs.

In one embodiment, wherein the system on chip is a multi-core GPU system, and each GPU core of the multi-core GPU system includes at least one module of the plurality of modules.

In another aspect, the present application also discloses a simulation platform for post-simulation of a system-on-chip, the system-on-chip including a plurality of modules, the simulation platform comprising: a timing inspection white list creation unit configured to create a timing inspection white list for each of the plurality of modules; and a timing inspection setting unit configured to close timing inspection of components included in a timing inspection white list of a target module of a custom subsystem to perform post-simulation on the custom subsystem.

In one embodiment, the simulation platform further comprises: a subsystem configuration unit configured to configure the custom subsystem in a simulation platform according to a simulation command; a dummy unit configured to replace other modules of the system-on-chip, except for the custom subsystem, with a blank file; a post-simulation file determining unit configured to determine a post-simulation file of the custom subsystem according to a simulation command; and a post-simulation unit configured to post-simulate the custom subsystem based on the post-simulation file.

In one embodiment, the simulation platform further comprises: a subsystem definition unit configured to generate subsystem codes for defining the custom subsystem according to subsystem parameters in the simulation command; and a target module determining unit configured to determine a target module included in the custom subsystem according to the subsystem code.

In one embodiment, wherein the simulation platform supports multiple versions of the post-simulation file of the system-on-chip, the post-simulation file determination unit comprises: a target version specification unit configured to specify a post-simulation file of the target version according to version parameters in the simulation command; and a post-simulation file extraction unit configured to extract a 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 simulation platform further comprises a post-simulation analysis unit configured to: the post-simulation report of the system-on-chip is analyzed to add to the list of additional components relevant components for which the reported timing violation is a false timing violation.

In one embodiment, the evaluation unit simulation platform further comprises an evaluation unit configured to: 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 simulation platform further comprises a timing violation processing unit: is configured 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 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 aspect, the present application also proposes a computing device comprising an emulation platform for post-emulating a system-on-chip according to the teachings herein.

In one aspect, the present application 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 the teachings herein.

The present disclosure includes any combination of two, three, four, or more features or elements that are set forth in this summary, whether or not such features or elements are explicitly combined or otherwise described in the particular 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 invention 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. 2 illustrates a flow chart of a method for post-simulation of a system-on-chip according to an embodiment of the present disclosure;

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

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

FIG. 4 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. 5 illustrates a flow chart for post-simulation of a custom subsystem according to an embodiment of the present disclosure;

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

FIG. 7 illustrates a flow chart of a method of post-simulating a system-on-chip in combination with the methods described with respect to FIGS. 2, 5, and 6, in accordance with an embodiment of the present disclosure;

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

fig. 9 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 invention, 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 (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 post-simulation of a system-on-chip, a large number of timing violations are reported. Some of these are timing violations that do not meet timing constraints and require adjustment of the design or are caused by problems with the timing constraints themselves. There are also significant false timing violations that can be ignored. In general, cross-Clock Domain (CDC) design, design for testability (DFT), asynchronous reset, etc., all cause false timing violations. Large scale integrated circuit systems on chip typically include tens or even hundreds of modules, some of which may be clocked together or clocked differently. Typically, multiple clocks are used in a large scale integrated circuit system on a chip. The signals need to be synchronized by a synchronizer before the asynchronous signals are subjected to combinational logic operations. For example, where a slower (lower frequency) clock signal is utilized to sample a faster (higher frequency) clock-domain crossing signal, it is generally required that the faster clock-domain crossing signal be maintained for a longer period of time in the receiving clock domain to ensure that it can be properly sampled by the slower clock signal. The timing violations generated by the first stage registers across the clock domain in all modules of the system-on-chip are false timing violations. The timing checks for the first level registers across the clock domain in the various modules of the system-on-chip may be turned off or not performed prior to post-simulation of the system-on-chip. Not performing the timing check means that the components perform the post-timing simulation with timing information, but no longer verify whether the components meet the set timing constraints. Thereby reducing the number of false timing violations reported at the time of post-emulation of the system-on-chip.

Fig. 2 illustrates a method 200 for post-simulation of a system-on-chip in accordance with an embodiment of the present disclosure. In step S11, a timing check white list may be created for each of the plurality of modules of the system-on-chip. Wherein the creating step may have been completed prior to a current post-simulation of the system on chip. Alternatively, the timing check whitelist may also be created for each module using a post-simulation file (e.g., netlist) of the system-on-chip at the same time as the current post-simulation of the system-on-chip. As set forth above, the timing violations reported by the first level registers of each module across the clock domains are false timing violations, so in one embodiment, the timing check white list may include a list of the first level registers of each module across the clock domains of all the modules of the system-on-chip. In one embodiment, a list of first level registers of each module that cross clock domains may be generated based on connection relationships between the various components and between clocks that are described in a post-simulation file (e.g., netlist) of each module.

In one embodiment, the timing check white list may also include a list of additional components. The user, front-end engineer or verification engineer may add specific components within each module to the list of additional components based on experience or by analysis of post-simulation reports of post-simulations in which each module was previously engaged, thereby avoiding timing checks for components listed in the list of additional components when post-simulating the system on chip. In one embodiment, the post-simulation report of the system on chip may be analyzed to add relevant components for which the reported timing violations are false timing violations to the additional component list, thereby implementing updating and maintaining the timing inspection white list of each module, so as to reduce the false timing violations reported in the post-simulation of the system on chip to the greatest extent, further reduce the workload of relevant engineers, improve the efficiency of the post-simulation, and shorten the development period of the product. For example, by analyzing a post-simulation report of the system on chip, finding that a timing violation reported by a specific register in a circuit for design for testability (DFT) is a false timing violation, the specific register may be added to the additional component list to skip timing inspection of the specific component at the next post-simulation of the system on chip. In one embodiment, the specific register dedicated to the design for testability may be found from all components included in the corresponding module by means of keyword matching, and added to the additional component list. In one embodiment, post-simulation reports of multiple post-simulations of the system-on-chip may also be analyzed (e.g., a comprehensive analysis of the types of components reporting false timing violations or connection relationships with other components) to update and maintain the list of additional components in the timing check white list for each module of the system-on-chip based on the results of the analysis. Wherein, the multiple post-simulations may be post-simulations performed by different engineers on the system-on-chip at different process angles. The analysis may be manual or may be performed using any machine learning method. In further embodiments, the verification engineer may also shut down/skip timing checks of particular components of the modules participating in the post-simulation based on other needs (e.g., post-simulation efficiency or application scenario notification) independent of analysis of the post-simulation report.

The principle of creating a timing check white list for each module in the system-on-chip in the present application is described above in connection with step S11 in fig. 2. It is noted that analysis of timing violations is an extremely stringent effort. If the real timing violations are determined to be false timing violations and are ignored, a certain function abnormality of the corresponding module can be caused, and even the final streaming sheet obtains a defective finished product. This presents a significant challenge to verifying the experience and effort of engineers. Therefore, in the process of creating the timing inspection white list, it is necessary to confirm that the reported timing violations related to the specific component are false timing violations, so that the specific component can be added to the list of additional components in the timing inspection white list. Although it takes some time to create the timing check white list, as described above, the operation of creating the timing check white list may be performed in advance. In addition, the created time sequence checking white list of each module can be uniformly stored in a memory of the simulation platform or in the cloud as a set, so that each authorized engineer can access and use the time sequence checking white list, and the efficiency of each engineer on post-simulation report analysis of the current and subsequent post-simulation can be improved.

In step S12, the timing inspection of the components included in the timing inspection white list of each of the plurality of modules of the system-on-chip may be turned off to perform post-simulation on the system-on-chip. In another embodiment, the timing inspection of the components in the white list may also be turned off as needed for timing inspection of some of all of the modules of the system-on-chip. For example, in the case of performing post-simulation on a subsystem of a system-on-chip, only the timing inspection of components in the timing inspection white list of modules included in the subsystem to be post-simulated may be turned off. And the time sequence check of the components in the time sequence check white list of other modules which do not participate in the post-simulation is not required to be closed, so that the error that the corresponding components in the other modules cannot be found in the post-simulation of the subsystem is avoided, and the post-simulation process is slowed down.

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 flexible adaptation to these and other application scenarios in the post-simulation process, the efficiency of the post-simulation is further improved, and the method and the simulation platform for post-simulation of the present disclosure flexibly configure the custom subsystem to be post-simulated according to requirements (e.g., different application scenarios or efficiency requirements, etc.). And automated post-simulation processing is performed after post-simulation is supported.

Examples of flexible configuration custom subsystems according to embodiments of the present disclosure are described below in connection with fig. 3a, 3b, and 3 c. Wherein fig. 3a shows a schematic diagram of a system-on-chip 300 for configuring a custom subsystem according to an embodiment of the present disclosure. The system on chip 300 comprises modules 301-306 for implementing different functions, respectively. The system-on-chip 300 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 301-306 may include power supply modules, speakers, memory, codecs, sensors, filters, or other functional modules. Although the system-on-chip 300 shown in fig. 3a includes only six modules 301-306, this is merely illustrative. In practice, more (e.g., tens, hundreds) or fewer modules may be included within the system-on-chip 300. In post-simulating the system on chip 300, all modules of the entire system on chip 300 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 300 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 301 is a Graphics Processor (GPU), module 302 is a Double Data Rate (DDR) memory, and module 303 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 303 and modules 304-306. But only post-simulation of modules 301 and 302. 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 300 according to the needs of the post-simulation. For example, module 301 and module 302 constitute a custom subsystem A, and module 302 and module 303 constitute 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 301 and 302 included in custom subsystem A.

A direct customization subsystem for the configuration of the modules included in the system-on-chip 300 is disclosed in fig. 3 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. 3b and 3 c. In fig. 3b, the system on chip 300 comprises a subsystem E and a subsystem F. Wherein subsystem E comprises modules 301-303 and subsystem F comprises modules 304-306. In one embodiment, custom subsystem C to be post-simulated is configured to include modules 305 and 306 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. 3c, the system on chip 300 includes a subsystem E and a subsystem F. Wherein subsystem E comprises modules 301-303 and subsystem F comprises modules 304-306. In one embodiment, the custom subsystem D to be post-simulated is configured to include the module 302 in subsystem E and the module 305 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. In other words, the method and simulation platform for post-simulation according to the present disclosure supports the maximally flexible configuration of custom subsystems at the time of post-system-on-chip simulation.

Fig. 4 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 400 shown in fig. 4 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 405 of the second GPU-core (e.g., the module 405 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 413-416) 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 406 of the second GPU-core (which may be the module to be debugged) as well as the module 401 of the first GPU-core (which has been validated by the emulation and may cooperate with the module 406 of the second GPU-core to perform the required debugging) along with one or more generic modules (e.g., module 415) 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 common modules, some of which may be crossed (in other words, different subsystems include the same module). 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. 5 illustrates a method 500 for post-simulation of a custom subsystem according to an embodiment of the present disclosure. In step S21, subsystem codes for defining the custom subsystem are generated according to subsystem parameters in the simulation command. In step S22, a target module included in the custom subsystem is determined according to the subsystem code. In step S23, other modules of the system-on-chip except the custom subsystem are replaced with a dummy file. In step S24, a post-simulation is performed on the custom subsystem. The custom subsystem can be flexibly configured according to application scenarios, post-simulation efficiency or other requirements. In the case shown in FIG. 3, the target modules of custom subsystem A are modules 301-302. The target modules of custom subsystem B are modules 302-303. 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. 5. 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. In addition, the post-simulation method described in connection with fig. 5 is extremely user-friendly, and a user can realize configuration and post-simulation of the subsystem by simply inputting subsystem parameters in a simulation command, so that the user experience is improved, the post-simulation efficiency of the system on chip is improved, and the development period of the system on chip is shortened.

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. 5 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 further 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 600 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. 6. In step S31, 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 S32, 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 S33, 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 S34, 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. It can be seen that the method and simulation platform of post-simulation according to the present disclosure are extremely user friendly, and the selection of a post-simulation file of a target version of a system-on-chip can be achieved by simply inputting version parameters in a simulation command without manually selecting one of tens and hundreds of post-simulation file versions. 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. 6, the post-simulation file which is completely and automatically switched to the target version of the system-on-chip can be realized 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, the error of version selection in the post-simulation is reduced, the user experience is further improved, the efficiency of the post-simulation is improved, and the product development period is shortened.

In contrast to the post-simulation of the target modules included in the custom subsystem illustrated in FIG. 5, the post-simulation method illustrated in FIG. 6 may automatically switch post-simulation files of the target version of the system-on-chip. The method embodiments described with respect to fig. 5 and 6 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 method embodiments described with respect to fig. 5 and 6 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. 7 illustrates a method 700 of post-simulation of a system-on-chip (e.g., systems-on-chip 300 and 400) that incorporates the methods described with respect to fig. 2, 5, and 6, in accordance with an embodiment of the present disclosure. Wherein the system on a chip comprises a plurality of modules. In step S41, a timing check white list may be created for each of the plurality of modules of the system-on-chip. The specific operation of creation of the timing check white list is similar to the creation operation described above in connection with fig. 2. In step S42, the 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 S42 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 S43, 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. 3, modules 303-306 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 S44, the timing inspection of the components included in the timing inspection white list of the target module of the custom subsystem may be turned off to perform post-simulation on the custom subsystem. And closing the time sequence check of the components in the time sequence check white list in the target module, wherein the components still normally participate in the post-simulation of the custom subsystem, but the false time sequence violations related to the components are not reported, so that the workload of analysis and processing of post-simulation reports by verification engineers or other personnel is reduced.

In step S45, 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 S45 may include specifying a post-simulation file for the target version based on 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 S46, the custom subsystem is post-simulated based on the extracted post-simulation file of the custom subsystem. Although the method for post-simulation of a custom subsystem of a system-on-chip is illustrated in FIG. 7 in connection with steps S41-S46. However, not all steps are necessary, for example, some or all of the steps indicated in the dashed boxes in fig. 7 may be omitted. Each step in fig. 7 may also include multiple sub-steps. And fig. 7 may also include other steps, such as processing steps after post-simulation.

In one embodiment, the method according to the present disclosure may further analyze the post-simulation report of the system on chip to add the relevant component of the reported timing violation being a false timing violation to the list of additional components in the timing inspection white list, thereby implementing updating and maintenance of the timing inspection white list, and further reducing the number of timing violations reported by the post-simulation. Such maintenance and updating of the timing check white list may be performed by a dedicated post-simulation analysis unit in the simulation platform. The method and the device realize the timing sequence checking of configuring the custom subsystem according to subsystem parameters and version parameters in the simulation command, closing or skipping the timing sequence checking white list components of the target module in the custom subsystem, and updating and maintaining the timing sequence checking white list by post-simulating the custom subsystem based on post-simulation files under the target version. 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, the custom subsystem to be really subjected to the post-simulation and the target module included in the custom subsystem are selected, and the time sequence inspection of the components in the time sequence inspection white list of the target module of the custom subsystem is skipped. Therefore, the switching of the post-simulation files with different versions and the flexible post-simulation verification of the custom subsystem can be realized on the same simulation platform, and the number of false timing violations reported in the post-simulation is further reduced. The method can further improve user experience, improve the efficiency of post-simulation and shorten the development period of products.

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.

Furthermore, the method according to the present disclosure also enables the automated filtering and analysis of timing violations reported in post-simulations of a system-on-chip or custom subsystems of a system-on-chip. 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 sequencing the filtered residual time sequence violations according to a time sequence or grouping the time sequence violations according to a path to be respectively output to two files, and providing information related to each time sequence violation, thereby improving the efficiency of analyzing and confirming the time sequence violations. 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. In the post-simulation, for example, in the initial stage of the post-simulation, the actual delay amounts of the components and paths included in the target module performing the post-simulation can be intuitively 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 effectiveness of the post-simulation of the system on chip and grasp the progress of the post-simulation. Alternatively, the comparison may also be performed directly and quickly.

It is noted that although arrows are used in fig. 2, 5, 6 and 7 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 application expands based on post-simulation of integrated circuit system-on-chip, the methods disclosed herein are not limited to application in integrated circuit system-on-chip. Rather, the methods disclosed herein 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. 8 illustrates a simulation platform 800 for post-simulating a system on a chip in accordance with an embodiment of the present disclosure. The various units in simulation platform 800 may each be configured to implement a method according to an embodiment of the present disclosure. In one embodiment, the simulation platform 800 may include therein a timing check white list creation unit 801 and a timing check setting unit 802. Wherein the timing check white list creation unit 801 may be configured to create a timing check white list for each of a plurality of modules of the system on chip. The components in the time sequence checking white list can avoid time sequence checking when the corresponding module participates in the post simulation. The timing check white list may include a list of first level registers and a list of additional components for each module of the system on a chip. The timing inspection setting unit 602 may be configured to turn off timing inspection of components included in the timing inspection white list of at least one module (or each module) of the plurality of modules. Under the condition of performing post-simulation on a custom subsystem of a system-on-chip, the time sequence inspection of components included in a time sequence inspection white list of a target module of the custom subsystem can be closed, but the time sequence inspection of components in the time sequence inspection white list of other modules of the system-on-chip outside the custom subsystem is not closed, so that errors reported due to the fact that corresponding components in the other modules cannot be found in the post-simulation are avoided, and the process of the post-simulation is dragged.

In one embodiment, simulation platform 800 may further include a subsystem configuration unit 803, a dummy (dummy) unit 804, and a post-simulation file determination unit 805. The subsystem configuration unit 803 is configured to configure a custom subsystem to be simulated later in the simulation platform according to a simulation command. Dummy unit 804 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 805 is configured to determine a post-simulation file of the custom subsystem according to the simulation command. The simulation platform may further comprise a post-simulation unit (not shown) for post-simulating the custom subsystem based on the post-simulation file.

The subsystem configuration unit 803 includes a subsystem definition unit 806 and a target module determination unit 807. Wherein the subsystem definition unit 806 is configured to generate subsystem codes for defining the custom subsystem according to subsystem parameters in the simulation command. The target module determining unit 807 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 805 includes a version specification unit 808 and a post-simulation file extraction unit 809. The version specification unit 808 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 809 is configured to extract, according to the subsystem code, a post-simulation file of the custom subsystem from the post-simulation files of the target version. The version specification unit 808 may include a version definition unit 810 and a version selection unit 811. Wherein the version definition unit 810 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 811 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 800 may also include other units such as a post-simulation analysis unit 812, an evaluation unit 813, a storage unit 814, and a timing violation processing unit 815. The post-simulation analysis unit 812 is configured to analyze the post-simulation report of the system-on-chip to add the relevant component of the reported timing violation that is a false timing violation to the additional component list in the timing inspection white list, thereby implementing updating and maintenance of the timing inspection white list, and further reducing the number of timing violations reported by the post-simulation report. The evaluation unit 813 is configured to compare an actual delay amount on a specific component and a path included in the 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, and facilitate a user or a verification engineer to grasp a simulation progress. The storage unit 814 is used to store multiple versions of the post-emulation files of the system-on-chip. Alternatively, the storage unit 814 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. The timing violation processing unit 815 is configured to set a time point and a keyword, so as to filter a timing violation before the time point and a timing violation 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 addition, although not shown, the simulation platform 800 may also include a reverse labeling unit for performing reverse labeling on the standard delay format file in the post-simulation file of the custom subsystem to obtain a netlist with reverse labeled timing information; the anti-labeling post-processing unit is used for classifying errors reported in the anti-labeling 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.

The simulation platform 800 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 800 shown in fig. 8 is merely illustrative and does not show detailed interactions between the various elements. In addition, some elements of simulation platform 800 may be combined together or split into multiple elements without departing from the principles set forth in this disclosure. Furthermore, the simulation platform 800 may be configured as a software product, a hardware device, or firmware. The simulation platform 800 may be provided by EDA tool vendors or may be custom developed by the user on its own as desired. It is noted that, although the functions of the respective units included in the simulation platform in fig. 8 are described corresponding to the method for post-simulation shown in fig. 7. However, the simulation platform in FIG. 8 may also be used to implement the methods for post-simulation disclosed in connection with FIGS. 2, 5, and 6.

Fig. 9 illustrates a computing device 900 according to an embodiment of the invention. Computing device 900 may include an emulation platform as set forth above in accordance with an embodiment of the invention. Computing device 900 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 900 to external components, or from outside to the computing device 900, either through an antenna in the computing device or wirelessly. 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 900. 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. The computing device 900 may also include a memory controller (although not shown in fig. 9) for controlling the operation of the storage. The display screen in computing device 900 may be any screen capable of displaying graphics or video, such as a touch screen. The I/O subsystem within computing device 900 may be used to connect various components internal to computing device 900 or to connect computing device 900 with components external thereto. The chipset within computing device 900 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 900 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 will 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:

creating a timing check white list for each of the plurality of modules, wherein the timing check white list for each module comprises: a first level register list across the clock domain and a list of additional components;

closing time sequence checking of components included in a time sequence checking white list of a target module of the custom subsystem so as to perform post-simulation on the custom subsystem; and

the post-simulation report of the custom subsystem is analyzed to add relevant components for which the reported timing violation is a false timing violation to the list of additional components.

2. The method of claim 1, further comprising:

configuring the custom subsystem 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.

3. The method of claim 2, wherein configuring the custom subsystem in the simulation platform in accordance with simulation commands 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.

4. The method of claim 3, 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.

5. The method of claim 4, wherein specifying a post-simulation file for a target version according to a version parameter in a 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.

6. The method of any of claims 1-5, wherein 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.

7. The method of claim 6, 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.

8. The method of claim 2, 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.

9. The method of claim 2, 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.

10. The method of claim 9, wherein the point in time comprises a time at which an asynchronous reset of a clock occurs.

11. The method of claim 1, wherein the system-on-chip is a multi-core GPU system, and each GPU core of the multi-core GPU system comprises at least one module of the plurality of modules.

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

a timing inspection white list creation unit configured to create a timing inspection white list for each of the plurality of modules, wherein the timing inspection white list of each module includes: a first level register list across the clock domain and a list of additional components;

A timing inspection setting unit configured to close timing inspection of components included in a timing inspection white list of a target module of a custom subsystem to perform post-simulation on the custom subsystem; and

a post-simulation analysis unit configured to: the post-simulation report of the custom subsystem is analyzed to add relevant components for which the reported timing violation is a false timing violation to the list of additional components.

13. The simulation platform of claim 12, further comprising:

a subsystem configuration unit configured to configure the custom subsystem in a simulation platform according to a simulation command;

a dummy unit configured to replace other modules of the system-on-chip, except for the custom subsystem, with a blank file;

a post-simulation file determining unit configured to determine a post-simulation file of the custom subsystem according to a simulation command; and

and the post-simulation unit is configured to perform post-simulation on the custom subsystem based on the post-simulation file.

14. The simulation platform of claim 13, further comprising:

a subsystem definition unit configured to generate subsystem codes for defining the custom subsystem according to subsystem parameters in the simulation command; and

And the target module determining unit is configured to determine a target module included in the custom subsystem according to the subsystem code.

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

a target version specification unit configured to specify a post-simulation file of the target version according to version parameters in the simulation command; and

and the post-simulation file extraction unit is configured to extract the post-simulation file of the custom subsystem from the post-simulation file of the target version according to the subsystem code.

16. The simulation platform of claim 13, further comprising an evaluation unit configured to:

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.

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

18. The simulation platform of claim 17, wherein the point in time comprises a time at which an asynchronous reset of a clock occurs.

19. A computing device comprising the simulation platform of any of claims 12-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-11.