Method for calculating timing yield and yield bottlenecks using correlated sample generation and efficient statistical simulation

Abstract

Various embodiments of a method and apparatus for determining parametric timing yield and bottlenecks are disclosed. The method and apparatus account for dependencies between circuit paths through common timing arcs in an integrated circuit chip under design. Monte Carlo samples of timing arc delays are generated and used to calculate timing yield and identify yield bottlenecks.

Description

[0001] Copyright Notice

[0002] The assignee of this patent document has no objection to the facsimile reproduction by anyone of the patent document itself or the patent application as it appears in the U.S. Patent and Trademark Office files, but otherwise reserves all rights whatsoever to the extent such rights are protected by copyright in any incorporated work of authorship. Technical Field

[0003] The present disclosure relates generally to the field of electronic design automation. More specifically, the present disclosure relates to statistical timing analysis, including the following topics: specifically, calculating timing yield and yield bottlenecks using correlated sample generation and efficient statistical simulation. Background Art

[0004] With the rapid development of mobile devices, the "Internet of Things" (IOT) and artificial intelligence devices, the demand for circuit designs that can perform complex functions while consuming less power and therefore using power more efficiently is increasing. This demand for low power consumption has led to a reduction in the operating voltage of integrated circuit (IC) chips used in many products built today. This reduction in operating voltage has in turn led to a significant increase in the negative impact of changes in the process environment for manufacturing very large-scale integration (VLSI) circuit chips. More specifically, changes in the process used to manufacture IC chips lead to challenges related to parameter timing yield. Parameter timing yield is the ratio of IC chips that meet timing requirements to IC chips that fail to meet timing requirements. Today's corner-based timing issuance methods face increasing challenges in predicting the timing yield of IC designs. Although methods such as parameter yield variations have been widely adopted in leading static timing analysis software, there is still a lack of good methods that can be used to accurately calculate timing yield using variation information. The main challenge in accurate yield calculation is capturing the topological correlation between different timing paths of the design. Brute-force full-chip Monte Carlo (MC) analysis, where randomized values ​​are used to assist in predicting statistical results, is not feasible due to the extreme runtime impact (ie, the relatively large amount of time required to run such models).

[0005] It would be advantageous, therefore, to provide a system that can more accurately predict the impact of specific characteristics (e.g., process and environmental variations) on the likelihood that a VLSI chip will meet timing requirements and, therefore, predict parametric timing yield for specific assumptions about process and environmental variations that require modeling millions of local random variables. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The disclosed methods and apparatus according to one or more various embodiments are described with reference to the following figures. The figures are provided for illustrative purposes only and depict only some examples of embodiments of the disclosed methods and apparatus. These figures are provided to facilitate the reader's understanding of the disclosed methods and apparatus. The figures should not be construed as limiting the breadth, scope, or applicability of the claimed invention. It should be noted that for clarity and ease of illustration, the figures are not necessarily drawn to scale.

[0007] Figure 1A A simplified diagram of a portion or "block" of the circuit design of an integrated circuit (IC).

[0008] Figure 1B is the delay d of timing arc 7 1,7 Plot of the probability distribution function of .

[0009] Figure 1C is the delay d of timing arc 7 2,7 Plot of the probability distribution function of .

[0010] Figure 2 is a plot of the statistical minimum of 100 random variables where the random variables are perfectly correlated.

[0011] Figure 3 is with Figure 2 A plot similar to the plot shown in , however the random variables are completely independent.

[0012] Figure 4 is a high-level flow chart of some embodiments of the methods disclosed herein.

[0013] Figure 5 is sample pseudocode intended to provide one example of how statistical moments may be calculated incrementally during simulation to determine yield and bottlenecks.

[0014] Figure 6A is a simplified block diagram of a computer system suitable for use with embodiments of the present technology.

[0015] Figure 6B Explain the circuit design.

[0016] Figure 6C An integrated circuit embodiment of the present technology is described.

[0017] Figure 7 Describes an example of the design and manufacturing processes performed in the design, verification, and fabrication of a manufacturing item.

[0018] Figure 8 Additional details are described regarding an implementation of one example of a test platform including a host system and an emulator.

[0019] The drawings are not intended to be exhaustive or to limit the claimed invention to the precise form disclosed. It should be understood that the disclosed methods and apparatus can be practiced with modification and alteration, and the invention should be limited only by the claims and their equivalents. DETAILED DESCRIPTION

[0020] Figure 1A is a simplified diagram of a portion or "block" 100 of a circuit design for an integrated circuit (IC). In some cases where analysis of circuit delays is done by "path-based" analysis, the IC design is modeled as including multiple paths, each of which passes through multiple elements. For example, in Figure 1A In FIG, there are six unique paths through block 100 of the circuit design. The first path is designated D1. Path D1 traverses three elements of block 100. The first element is a register 102 having a clock input and output, the second element is a two-input AND gate 104, and the third element is an inverter 106. Each path through the elements is associated with a unique timing arc numbered 1 through 9 in block 100. For example, there are two paths through input AND gate 104; a first path from the first input to the output and a second path from the second input to the output. Each of these two paths has a unique timing arc 4, 5. Path D1 arrives at register 108 with a delay that is a result of the "timing arcs" 1, 4, 7 associated with each element 102, 104, 106. The first timing arc encountered by the signal traversing path D1 is timing arc 1, and the delay of timing arc 1 through path D1 is designated d 1,1 The first digital index refers to the path id "1" of the path D1, and the second digital index refers to the timing arc id "1" of the element 102. The second timing arc encountered is the timing arc 4 of the second element 104, which has a value designated as d 1,4 Finally, the third timing arc encountered on path D1 is a timing arc with a delay d as a result of the third element 106. 1,7 7. Note that the numerical index "7" refers to the timing arc id "7" associated with inverter 106. As can be seen, in this simple example, there are 6 unique paths and 9 unique timing arcs. In addition, there are three unique "endpoints" 110, each at the input of a capture flip-flop 108. Note that the endpoints are not necessarily at the input of the capture flip-flop, but rather at the points where the slack of the path is measured (i.e., points where no additional delay that could affect slack will be applied). Slack is the difference between the required time and the time to reach the endpoint. A positive slack s at an endpoint means that the time to reach that endpoint can be increased by s without affecting the overall delay of the circuit. Conversely, a negative slack means that the path is too slow and that the path must be sped up (or the reference signal delayed) if the entire circuit is to operate at the desired speed.

[0021] In other cases, a graph-based model of the circuit is used to assist in the analysis of circuit delays. In the case of graph-based analysis, a timing graph is used to model the circuit, where there are source and sink nodes at the start and end of the circuit. Several other nodes and a set of circuit elements (such as gates and wires) are defined between the sink and the source. The nodes represent the pins of the circuit elements. The propagation delay between the nodes is modeled. In some cases, the nodes may be coupled in such a way that some routes from the source to the sink pass through the same element. In some cases, the delay is modeled as a distinct node in the graphical representation of the circuit. In contrast, path analysis defines a set of paths, each of which has an input and an output and a set of elements with delays that the path traverses. Some elements in one path may be common to elements in one or more other paths. In both cases, the delay from the start to the end can be characterized and the slack can be determined based on the difference between the sum of the delays and the minimum time required to traverse from the start to the end.

[0022] In some embodiments of the disclosed methods and apparatus in which path-based analysis is used, the path context (i.e., which path is in question) and the speed index of the delay distribution determined based on the variation-aware timing analysis determine the delay of the timing arcs along each path of interest. Once the analysis is complete, a set of paths is extracted, and the common timing arcs for the paths are collected and a subset of the timing arcs are associated with endpoints. A timing arc is considered common to two paths if it is due to a delay through the same circuit element. For example, the delay d of the timing arc 7 on path D1 is d 1,7 and the delay d of the timing arc 7 on path D2 2,7 Share a common timing arc 7, this is because they are all through Figure 1A However, it should be understood that the delay d of the timing arc 7 on path D1 is 1,7 The shape of the probability distribution function of (i.e., the probability distribution function of the possible delay values ​​produced by inverter 106 for a signal traversing path D1) may differ from the delay d of timing arc 7 on path D2 due to the fact that a signal traversing path D1 will traverse different components than a signal traversing path D2. 2,7 The shape of the probability distribution function is different. Figure 1B is the delay d of the timing arc 7 of path D1 1,7 Plot of the probability distribution function of . Figure 1C is the delay d of the timing arc 7 of path D2 2,7 As can be seen from these two plots, the shape of the probability distribution function of each plot is slightly different.

[0023] After collecting common timing arcs, random delay samples are generated for each of the timing arcs. This is accomplished by having a Monte Carlo value generator generate a plurality of speed indices, each associated with one of the timing arcs of the IC design. The speed index is a measure of the slowness of a timing arc (i.e., the relative delay through a circuit element) relative to local process and environmental variations. Each value of the speed index generated by the Monte Carlo value generator is associated with a timing arc to generate a delay value within a matrix (i.e., a "delay matrix") of specific delay samples associated with the timing arcs of the IC being simulated. Thus, each element of the delay matrix represents the delay associated with a timing arc along a path of the IC design in question. The disclosed analysis can be performed on each path of a block within a complex circuit or on individual paths through the circuit for an entire complex circuit (e.g., a circuit of a VLSI IC chip). The use of the speed index allows the effects of local process and environmental variations to be accounted for when determining the delay of each timing arc along each yield-critical path. Using Monte Carlo techniques accounts for the statistical distribution of delay values ​​due to process and environmental variations (e.g., based on a probability density function determined by variation-aware timing analysis) and allows accounting for correlations between delays associated with common timing arcs in different paths.

[0024] The disclosed method accurately calculates parametric timing yield and identifies yield-critical timing arcs, paths, and blocks by performing Monte Carlo simulations on a set of yield-critical paths. For timing arcs common to more than one path, the same speed index value is used to generate delay values ​​placed in the delay matrix for each path where the common timing arc is located. A speed index value for timing arcs common to several paths takes into account the dependencies between paths that share a common timing arc, such as the shared timing arc d in path D1. 1,4 and d in path D3 3,4 Therefore, considering the impact of common timing arcs allows capturing the correlations between different paths.

[0025] exist Figure 1A In the example of block 100 of FIG. 1 , the delay matrix (from a set of samples of the simulation) may contain the following entries:

[0026] D1=d 1,1 +d 1,4 +d 1,7

[0027] D2=d 2,2 +d 2,5 +d 2,7

[0028] D3=d 3,1 +d 3,4 +d 3,8

[0029] D4=d4,2 +d 4,5 +d 4,8

[0030] D5=d 5,3 +d 5,6 +d 5,9

[0031] D6=d 6,3 +d 6,6

[0032] During simulation, several such "instances" of the delay matrix are generated to create a set of simulated sample ICs, each having the same structure but different delay values, wherein the delay value of any particular element of each instance of the delay matrix (i.e., of each simulated sample IC) is determined by a speed index output by the Monte Carlo generator, which is then used to reference the delay value of each timing arc. The criterion used by the Monte Carlo generator to generate each speed index value is based on a probability density function of the delay of a particular timing arc as resolved by the speed index, as determined by the variation-aware timing analysis performed on the circuit element responsible for that particular timing arc.

[0033] In contrast to "path-based" analysis, "graph-based" analysis can be used to perform similar modeling of sample cells. That is, in embodiments of the disclosed methods and apparatus using graph-based analysis, delays modeled in a graphical representation of a circuit are identified and modeled based on relevant process and environmental variables, as determined by variation-aware timing analysis. In some cases, a first delay within the graphical representation of a circuit may be the result of a first signal traversing a circuit element. A second delay within the graphical representation of a circuit may be the result of a second signal traversing the same common circuit element. However, if the second signal traverses a different element than the first signal before entering the common circuit element, the second delay through the common element may be different from the first delay through the common element. Similarly, connections to different output elements may affect the delays. Nevertheless, the first and second delays will be process- and environment-dependent (i.e., the same process and environmental factors are responsible for variations in both the first and second delays). Therefore, a "speed index" associated with specific process and environmental conditions can be defined. Thus, one or more delays responsive to changes in specific process and environmental conditions are associated with a specific speed index.

[0034] Random samples (i.e., elements of the delay matrix) are generated and used to evaluate the path "reach / slack" and "design slack". Reach / slack is the difference between the calculated timing at an endpoint and the timing required for that endpoint. For example, for a particular design, a signal must traverse a particular path with a delay of no more than 13ns. If the signal can traverse the path in 10ns, then there is a positive reach / slack of 3ns. On the other hand, if the signal requires 15ns to traverse the path, then the slack is -2ns. If a particular VLSI chip design has 100 such paths (typically a much larger number), then the minimum reach / slack will define the "design slack". That is, if any of the 100 paths fails to meet the timing requirements, then the design will also fail to meet the timing requirements. Therefore, the design slack is determined by the worst slack of all paths (i.e., worst is the minimum, negative numbers are smaller than positive numbers, and negative numbers with higher absolute values ​​are smaller than negative numbers with lower absolute values). Therefore, the design slack is the statistical minimum (min) of all slacks in each path. Since there will be multiple samples of the IC (i.e., multiple delay matrices), there will be a distribution of slack values ​​across a set of IC samples. Once the Monte Carlo simulation is complete (i.e., several timing matrices have been generated, one for each IC sample), the design yield is determined from the ratio of non-negative slack relative to the total number of IC samples, and yield bottlenecks are identified for applications where the design can be optimized, such as yield ECOs (engineering change orders) where logic can be directly inserted into the gate-level netlist corresponding to the changes required to increase yield.

[0035] Figure 2 is a plot of the statistical minima of 100 random variables, where the random variables are perfectly correlated. For example, each random variable may represent the delay of a particular path through the VLSI IC. In this case, if each time arc of one path is identical to the corresponding time arc in every other path of all 100 paths, then the random variables will be perfectly correlated. Therefore, Figure 2 The plots shown in are Gaussian and centered at zero.

[0036] Figure 3 is a similar plot. However, the random variables are completely independent. In the example where these are paths through VLSIIC, there will be no common timing arcs in the paths. Comparing the two plots, it can be seen that the Figure 3 The distribution of the set of independent random variables shown in is narrower, but has a significant mean shift and relatively long tails. Therefore, the distribution shown in this plot is better than that from Figure 2The distribution of the set of correlated random variables shown in Figure 1 (which is more centered around zero) is even worse, with far fewer points in the range of -4 to -2. As can be seen from these two plots, the correlation between paths has a strong impact on the design slack distribution. Therefore, it is important to consider this correlation between paths when determining the design slack distribution used to determine timing yield.

[0037] Figure 4 is a high-level flow chart of some embodiments of the method disclosed herein. First, timing paths are identified within cells of the IC design to be simulated (step 400). Variation-aware timing analysis is performed (step 402) to determine timing arcs along the timing paths that run through the design. Several techniques for performing variation-aware timing analysis are well known in the art. Any known technique may be employed for the purposes of the disclosed method. That is, the method is not dependent on any particular technique for performing this analysis. After determining the statistical variation in delay of the timing arcs that are a result of the analysis, a set of yield-critical timing paths is identified. Such yield-critical timing paths include those paths that are most likely to be statistically significant in determining yield. That is, such yield-critical timing paths will likely help determine design slack because they are paths that are likely to have negative slack. In some embodiments, that set of yield-critical timing paths is "pruned" to its 6σ angle (step 404). That is, the timing arcs output from the variation-aware timing analysis are limited to those resulting from variations within 6 standard deviations from nominal, such as deviations exceeding 6 standard deviations from the nominal doping concentration. This pruning provides a closed value universe for path timing by eliminating distant anomalies.

[0038] After those yield-critical timing paths are identified and pruned to their 6σ angles, common timing arcs within the different yield-critical paths are identified (step 406).

[0039] Next, a simulation is run to generate random delay samples of timing arcs (i.e., elements of a delay matrix representing the delays of timing arcs in a sample of the design). These random delay samples are assigned to yield-critical paths throughout the cell based on the speed index values ​​generated by the Monte Carlo value generator, and in particular, ensure that paths with common timing arcs use the same speed index value generated by the Monte Carlo value generator. Thus, the delay samples for each particular timing arc provide a delay distribution associated with that particular timing arc (step 408), with each delay sample populating one element of a delay matrix. A set of delay samples for any particular timing arc forms the delay distribution for that timing arc. One such delay distribution exists for each timing arc across a set of IC samples (i.e., multiple delay matrices). Specifically, a Monte Carlo value generation technique is used to generate a delay matrix of values ​​for each of the timing arcs for each yield-critical timing path. Timing arcs shared by two or more other paths use the same generated speed index value to generate delays within the same delay matrix (i.e., the simulated cell sample). The Monte Carlo generation technique uses a probability distribution determined from information provided by variation-aware timing analysis and the constraints imposed by 6σ clipping as criteria for determining the speed index value for each delay for a particular instance (i.e., a simulated instance of the delays of a sample IC) to be used to generate the delay matrix. That is, the Monte Carlo value generator generates each speed index based on the results of the variation-aware timing analysis and 6σ clipping of the distribution of values ​​generated from the variation-aware timing analysis. The delay sample value for each timing arc is selected based on the delay distribution determined by the variation-aware timing analysis, the path context (i.e., which path is in question), and the speed index.

[0040] Next, the arrival / slack for each endpoint of each IC sample can be calculated based on the delay subset associated with each endpoint and the delay requirement of each endpoint (i.e., for each delay matrix). The design slack for each IC sample can be determined by identifying the endpoint with the worst slack. A delay distribution can be determined for each endpoint over a set of IC samples. Additionally, the design slack distribution is the distribution of slack values ​​over a set of IC samples. The calculated arrival / slack and the design slack distribution are used to determine the design yield and update the block and design level slack distributions (step 410). That is, the value of the timing yield is determined by determining the endpoint with the worst slack for each IC sample and determining that the number of IC samples for which the worst slack is non-negative divided by the total number of IC samples. That is, the timing yield is the ratio of all IC samples in which all endpoints have negative slack relative to the total number of all IC samples.

[0041] After updating the block and design-level slack distributions, a new set of random delay samples for the cells can be generated and used to sample the path delay distributions again (step 408). At the completion of the iterative process performed in steps 408 and 410, or at specific points throughout that iterative process, a parameter timing yield can be measured based on the ratio of IC samples (i.e., delay matrices) in which all paths have non-negative slack to the total number of IC samples. That is, a measurement can be made to determine the ratio of the resulting product that will meet timing requirements to the resulting product that will not meet timing requirements. In addition, timing yield bottlenecks can be identified, such as critical cells, paths, and blocks with very poor slack. These measurements and bottlenecks can be used to determine when to end the iterative process that occurs by repeating steps 408 and 410. The determination of bottlenecks can be made simply by identifying specific paths that more consistently have negative slack.

[0042] Figure 5 is sample pseudo code intended to provide an example of how the cross moment can be incrementally calculated during simulation to determine bottlenecks. In some embodiments, after the simulation is complete, the yield bottleneck can be calculated by calculating the cross moment between the design slack distribution and the individual delay distribution for each timing arc.

[0043] Check Figure 5 , the first three "For Loops" 502, 504, 506 are executed, where the innermost loop 506 calculates the self-moments, the middle loop 504 calculates the cross-moments with respect to the slack, and the outer loop 502 advances the process to perform that calculation for each of the samples (i.e., for each instance of the delay matrix). Next, two more For Loops 508, 510 are executed. The inner loop 508 determines the mean of the self-moments. The outer loop 510 calculates the correlation in the cross-moments, crossing the delay distribution of each timing arc with the slack distribution over the IC sample.

[0044] In addition to providing accurate parameter timing yield, the disclosed method and apparatus also Figure 5 The statistical regression method presented in [5] identifies yield bottlenecks at different design levels. The method incrementally calculates statistical moments during simulation in inner loop 506. When the simulation is complete, it calculates the yield bottleneck by computing the cross-moments (correlation, co-skewness, etc.) between the design slack distribution and the individual delay distributions in computation loop 510. Once the cross-moments are computed in loop 510, they can be used in bottleneck analysis to identify yield bottlenecks for potential yield ECOs. That is, bottleneck cells are defined as cells with large correlations ("ds" in the pseudocode).

[0045] Hardware implementation

[0046] Figure 6Ais a simplified block diagram of a computer system suitable for use with embodiments of the present technology. Figure 6B Explain the circuit design and Figure 6C An integrated circuit embodiment of the present technology is described.

[0047] In some embodiments, the computer system 610 includes at least one processing device 614, such as a computer or processor. The processing device 614 communicates with a number of peripheral devices 616, 620, 622, 626, 628 via a bus subsystem 612. In some such embodiments, the processing device 614 may be or include a processor, a microprocessor, a graphics processing unit, a digital signal processor, or their electronic processing equivalents, such as an application specific integrated circuit ('ASIC') or a field programmable gate array ('FPGA'). The term 'processor' is used herein in the broadest sense to include a single processor and multi-core or multi-processor arrays, including graphics processing units, digital signal processors, digital processors, and combinations of these devices. In addition, although only a single computer system or a single machine may be described, use of the singular form of such terms shall also refer to any collection of computer systems or machines that individually or jointly execute instructions to perform any one or more of the several sets of instructions discussed herein. Due to the ever-changing nature of computers and networks, Figure 6A The description of the computer system 610 depicted in FIG is intended only as an example for purposes of illustrating the preferred embodiment. Figure 6A Many other configurations of the computer system are possible with more or fewer components than the depicted.

[0048] In some embodiments, the peripheral devices include one or more of the following: a storage subsystem 624, which includes a memory subsystem 626 and a file storage subsystem 628; a user interface input device 622; a user interface output device 620; and a network interface subsystem 616. The user interface input device 622 and the user interface output device 620 allow a user to interact with the computer system 610.

[0049] Computer system 610 may be a server computer, a client computer, a workstation, a mainframe, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a smartphone, a network appliance, a rack-mounted 'blade', a kiosk, a television, a game station, a network router, a switch or bridge, or any data processing machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.

[0050] In some embodiments, computer system 610 includes an operating system, such as Microsoft Windows, Sun Microsystems Solaris, Apple Computer Inc. MacOS, Linux, or Unix. In some embodiments, computer system 610 may also include a basic input / output system (BIOS) and processor firmware. In some such embodiments, the operating system BIOS and / or firmware are maintained in storage subsystem 624. In some such embodiments, the operating system, BIOS, and firmware are used by processor 614 to control subsystems and interfaces connected to processor 614. Typical processors compatible with these operating systems include the Pentium and Itanium processors from Intel, the Opteron and Athlon processors from Advanced Micro Devices, and the ARM processors from ARM Holdings.

[0051] The claimed innovations, embodiments, and / or examples are not limited to conventional computer applications nor to programmable devices on which they are run. For example, the claimed innovations, embodiments, and / or examples may include optical computers, quantum computers, analog computers, and the like. The computer system may be a multi-processor or multi-core system and may be implemented using or in a distributed or remote system.

[0052] Network interface subsystem 616 provides an interface to external networks, such as a communications network 618, and in some embodiments, couples to corresponding interface devices in other computer systems or machines (not shown) via communications network 618. In some embodiments, communications network 618 includes a number of interconnected computer systems, machines, and communications links, not explicitly shown. These communications links may be wired, optical, wireless, and / or may use any other type of device to communicate information. Furthermore, communications network 618 may be any suitable computer network, for example, a wide area network such as the Internet and / or a local area network such as Ethernet. Communications network 618 may be wired and / or wireless, and in some embodiments, utilize encryption and decryption methods, such as those used in virtual private networks. In some embodiments, communications network 618 utilizes one or more communications interfaces that can receive and transmit data from other systems. Some examples of communications interfaces include an Ethernet card, a modem (e.g., telephone, satellite, cable, or ISDN), an (asynchronous) digital subscriber line (DSL) unit, a FireWire interface, a USB interface, and the like. In some embodiments, one or more communication protocols may be used, such as HTTP, TCP / IP, RTP / RTSP, IPX, and / or UDP.

[0053] The user interface input devices 622 may include an alphanumeric keyboard, a keypad, a pointing device such as a mouse, trackball, touchpad, stylus, or graphics tablet, a scanner, a touch screen incorporated into a display, an audio input device such as a voice recognition system or microphone, eye gaze recognition, brainwave pattern recognition, and other types of input devices. Such devices may be connected to the computer system via wires or wirelessly. In general, the use of the term 'input device' is intended to include all possible types of devices and methods for inputting information into the computer system 610 or onto the communication network 618.

[0054] User interface input devices typically allow a user to select objects, icons, text, etc. that appear on some type of user interface output device (eg, a display subsystem).

[0055] The user interface output device 620 may include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. The display subsystem may include a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), a projection device, or some other device for creating visible images, such as a virtual reality system. The display subsystem may also provide a non-visual display, such as via an audio output or a tactile output (e.g., vibration) device. In general, the use of the term 'output device' is intended to include all possible types of devices and methods for outputting information from the computer system 610 to a user or to another machine or computer system.

[0056] The memory subsystem 626 typically includes several memories, including a main random access memory ('RAM') 630 (or other volatile storage device) for storing instructions and data during program execution and a read-only memory ('ROM') 632 in which fixed instructions are stored. The file storage subsystem 628 provides persistent storage for program and data files and may include a hard drive, a floppy disk drive with associated removable media, a CD-ROM drive, an optical drive, flash memory, or removable media cartridges. Databases and modules that implement the functionality of certain embodiments may be stored by the file storage subsystem 628.

[0057] The bus subsystem 612 provides a means for the various components and subsystems of the computer system 610 to communicate with each other as intended. Although the bus subsystem 612 is schematically shown as a single bus, alternative embodiments of the bus subsystem may use multiple buses. For example, a RAM-based main memory may use a direct memory access ('DMA') system to communicate directly with a file storage system.

[0058] In some embodiments, software modules may be stored within the memory subsystem 626 that cause the computer system to perform the functions mentioned above with respect to the methods described in the present disclosure. Such software modules improve the operation of the computer system by allowing the computer system to perform improved operations in the field of manufacturing integrated circuit chips. The functions performed by the computer system operating in accordance with such software modules are a significant improvement in the art and represent a specific embodiment of a method for solving real and important problems in determining design yield and where bottlenecks exist in the timing of integrated circuits, thereby allowing design improvements to be made on the fly to improve integrated circuit design yield and reduce manufacturing costs by reducing waste and inefficiencies in the production of such integrated circuits.

[0059] Figure 6B Memory 640, a non-transitory computer-readable data and information storage medium, is depicted, for example, in association with file storage subsystem 628 and / or network interface subsystem 616, and may include data structures specifying circuit designs. Memory 640 may be a hard disk, floppy disk, CD-ROM, optical media, removable media cartridge, or other medium that stores computer-readable data in volatile or non-volatile form. Software read into a computer from this memory may, at a selected instant in time, be converted from a tangible form into a transmission signal that propagates through a medium (as electrical pulses, such as through a network, connector, wire, or trace, or as electromagnetic radiation having wavelengths in the electromagnetic spectrum longer than infrared light, through a medium such as space or the atmosphere).

[0060] Figure 6C An integrated circuit 690 created using the described techniques is illustrated and includes one or more cells, for example, selected from a cell library.

[0061] Some of the innovations, embodiments, and / or examples described herein include and / or use computer systems, such as the computer system 610 described above. As used herein, the term 'computer system' refers to a tangible data and information processing device that typically uses a sequence of transformations (also referred to as 'operations') to physically transform data and information. Data and information may be physically represented by electrical, magnetic, optical, or acoustic signals that can be stored, accessed, transferred, combined, compared, or otherwise manipulated by a processor. The term 'processor' may refer to a single processor and a multi-core system or multi-processor array, including a graphics processing unit, a digital signal processor, a digital processor, or a combination of these elements.

[0062] Computer systems can be electronic, for example, including digital logic circuit systems (e.g., binary logic), or analog (e.g., operational amplifiers). Computer systems can also be non-electronic, for example, as seen in computer systems based on optical signal processing, DNA transformations, or quantum mechanics, or a combination of technologies (e.g., optoelectronic computer systems). For data and information structured in binary form, any computer system that can use AND, OR, and NOT logical operations (and their derivatives, such as NAND, NOR, and XOR operations) to transform data and information can use any Boolean logic function to transform data and information. Computer systems, such as those that simulate neural network computer systems, can also transform data and information non-digitally. There is no scientific evidence that any of these computer systems processes, stores, and retrieves data and information in any manner or form equivalent to the bioelectrical structure of the human brain.

[0063] The one or more computer systems may also be operable to support execution of the related operations in a 'cloud computing' environment or as 'software as a service' (SaaS). For example, at least some operations may be performed by a group of computer systems available at distributed or remote systems, accessible via a communications network (e.g., the Internet) and via one or more software interfaces (e.g., application programming interfaces (APIs)).

[0064] As used herein, the term 'module' refers to a tangible data and information processing device that is typically limited in size and / or complexity. For example, the term 'module' may refer to one or more methods or procedures that can transform data and information. The term 'module' may also refer to the combination of one or more methods and procedures in a computer program. The term 'module' may also refer to a small network of digital logic devices, where the interconnection of the logic devices provides the structure of the network. Methods and procedures that include modules specified in a specialized language (e.g., System C) can be used to generate specifications for a network of digital logic devices that process data and information, where the results are identical to those obtained from the methods and procedures.

[0065] Modules can be permanently configured (e.g., hardwired to form hardware), temporarily configured (e.g., programmed with software), or a combination of both (e.g., a structured ASIC). For example, permanently configured modules can be manufactured using application-specific integrated circuits (ASICs), such as arithmetic logic units (ALUs), programmable logic arrays (PLAs), or read-only memories (ROMs), all of which are typically configured during manufacturing. Temporarily configured modules can be manufactured using, for example, field-programmable gate arrays (FPGAs—such as those sold by Xilinx or Intel's Altera), random access memories (RAMs), or microprocessors. Modules are configured to process data and information, typically using a series of transformations (also referred to as 'operations') applied to the data and information (or, in the case of ROMs and RAMs, by transforming the data and information using input information as addresses for the memory in which the data and information is stored) to perform aspects of the present innovations, embodiments, and / or examples of the present invention.

[0066] A temporarily configured module need not be configured at any one instant in time. For example, a computer system comprising one or more modules may have modules configured at different times. A computer system may include one set of one or more modules at one instant in time and a different set of one or more modules at a different instant in time. The decision to manufacture or implement a module in a permanent configuration, a temporarily configured configuration, or a combination of both may be driven by cost, time considerations, engineering constraints, and / or specific design goals. The 'essence' of a module's processing is independent of its manufacturing or implementation form.

[0067] As used herein, the term 'algorithm' refers to a process comprising a sequence or set of operations or instructions that a module can use to transform data and information to achieve a result. A module can include one or more algorithms. As used herein, the term 'thread' refers to a series of instructions that can comprise a subset of the instructions of an entire process or algorithm. A process or algorithm can be divided into multiple threads that can be executed in parallel.

[0068] As used herein, the term 'computer' includes at least one information processor, which can use electronic gates, such as transistors, to perform certain operations such as (but not limited to) AND, OR, and NOT logical operations, plus memory (e.g., flip-flop-based memory using NOT-AND or NOT-OR operations). Such a processor is referred to as Turing-complete or computationally universal. A computer, whether digital or not, typically comprises a number of modules.

[0069] As used herein, the term 'software' or 'program' refers to one or more algorithms and data structures that configure a computer system for use with the innovations, embodiments, and examples described in this specification. Such devices that can be configured by software include one or more computers, e.g., stand-alone, client, or server computers, or one or more hardware modules, or a system of one or more such computers or modules. As used herein, the term 'software application' refers to a set of data and instructions that configure a computer system to achieve a specific result, e.g., to perform a word processing operation or encrypt a set of data.

[0070] As used herein, the term "programming language" refers to the grammar and syntax used to specify sets of instructions and data that comprise software. A programming language includes assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more higher-level languages, such as a conventional procedural programming language, such as the C programming language or a similar programming language (e.g., SystemC), or an object-oriented programming language (e.g., Smalltalk, C++, etc.), and any future equivalent programming languages.

[0071] Software is imported, or equivalently, read, from a data and information storage device into one or more memories of a computer or computer system. Computers typically have a means for reading the storage medium used to deliver the software or an interface for receiving the software over a network. This process is discussed in the general computer interpretation section.

[0072] The present invention as recited in the appended claims may be implemented by computer system 610 to perform the functions of a design and manufacturing process (DMP) to create a manufacturing project. The DMP may include an electronic design automation (EDA) process. In this DMP, information about product concepts is provided by designers. This information is transformed by the DMP to create a manufacturing project.

[0073] In some embodiments, DMP 700 uses EDA software tool 712 (which, in some embodiments, is EDA software) as a design tool or verification tool. When the design is complete, the EDA software tool 734 can be exited, at which point the artwork (e.g., geometric pattern) for the integrated circuit is typically sent to a fabrication facility to produce a mask set, which is then used to fabricate the integrated circuit. After exiting, semiconductor die 736 is fabricated and packaging and assembly processes 738 are performed, resulting in a completed integrated circuit 740, which may also be referred to herein as a circuit, device, component, chip, or SoC (system on a chip).

[0074] Manufacturing projects, such as circuits or systems produced by DMP, are used in the business at a variety of abstraction levels, from low-level transistor layouts to high-level description languages. Most designers start at a high level of abstraction to design their circuits and systems using a hardware description language ('HDL') such as VHDL, Verilog, SystemVerilog, SystemC, MyHDL, or OpenVera. High-level HDLs are easier for developers to understand, especially for large systems, and can describe highly complex concepts that are difficult to grasp using lower levels of abstraction. HDL descriptions can be converted into other levels of abstraction that are helpful to developers. For example, a high-level description can be converted into a logic-level register transfer level ('RTL') description, a gate-level description, a layout-level description, or a mask-level description. Each lower level of abstraction introduces more detail into the design description. Lower levels of abstraction can be automatically generated by a computer, derived from a design library, or created through another design automation technology. An example of a specification language at a lower level of abstraction is SPICE, which is mostly used for detailed descriptions of simulation-based circuits.

[0075] Figure 7 One example of a DMP 700 implemented in the design, verification, and fabrication of a fabrication project, such as an integrated circuit, is illustrated using software tools coupled with a computer system, such as computer system 610, and possibly specialized hardware-assisted tools not explicitly shown herein, to transform and verify design data and instructions representing an integrated circuit design. Figure 7 The disclosed DMP is for illustrative purposes only and is not intended to limit the present disclosure. For example, in some embodiments of the disclosed methods and apparatus, the DMP may require the designer to perform design operations in a sequence different from that described herein.

[0076] Example DMP 700 begins with the creation of a product concept (step 710). In some embodiments, DMP 700 implements EDA software tools 712. During system design 714, designers use EDA tools to assist in describing the functionality to be manufactured. Designers may also perform what-if planning to refine functionality and examine costs, among other things. Hardware-software architecture partitioning may occur at this stage. Examples of EDA software products from Synopsys, Inc. of Mountain View, California that can be used at this stage include Model Architect, Sabre, System Studio, and Designware products.

[0077] Next, logic design and functional verification are performed (step 716). During logic design and functional verification, the modules in the circuit are specified in one or more hardware description languages, or HDLs. Additionally, the design is checked for functional accuracy. That is, the design is checked to ensure that it matches the requirements of the specification for the circuit or system being designed to produce the correct outputs. Examples of HDL languages ​​include Verilog, VHDL, and SystemC. Functional verification is typically accomplished using software-based simulators and other tools, such as testbench generators, static HDL checking tools, and formal verification tools. In some cases, specialized hardware called "emulators" or "prototyping systems" is used to accelerate functional verification. Examples of EDA software products that can be used at this stage include VCS, Vera, Designware, Magellan, Formality, ESP, and Leda, each from Synopsys, Inc., Mountain View, California. Examples of simulators and prototyping products that can be used at this stage, also available from Synopsys, include Zebu.RTM. and Protolink.RTM. (RTM stands for "Registered Trademark").

[0078] The next step requires synthesis and design for test (step 718). During synthesis and design for test, the HDL code is converted into a netlist. The netlist can be optimized for the target technology. In addition, tests can be designed and implemented to check the completed integrated circuit. Examples of EDA software products that can be used at this stage include: Design Compiler, Physica Compiler, Test Compiler, Power Compiler, FPGA Compiler, Tetramax, and Designware products, each from Synopsys, Inc. of Mountain View, California.

[0079] After synthesis and design for testing, the netlist is verified (step 720). During netlist verification, the netlist is checked to see if it meets timing constraints and corresponds to the HDL code. Examples of EDA software products that can be used at this stage include Formality, Primetime, and VCS products, each from Synopsys, Inc., Mountain View, California.

[0080] Next, design planning is performed (step 722). During design planning, the overall floor plan of the integrated circuit is constructed and analyzed for timing and top-level routing. Examples of EDA software products that can be used at this stage include Astro and IC Compiler products, each from Synopsys Technologies, Inc. of Mountain View, California.

[0081] After design planning, layout is performed (step 724). During layout, physical placement (positioning of circuit elements such as transistors or capacitors) and routing (connection of these circuit elements via multiple conductors) occur, and library cells may be selected to perform specific logic functions. Examples of EDA software products that can be used at this stage include the Astro and ICCompiler products, each from Synopsys, Inc. of Mountain View, California.

[0082] Once layout implementation is complete, analysis and extraction are performed (step 726). During analysis and extraction, circuit functionality is verified at the layout level, which allows for refinement of the layout design. Examples of EDA software products that can be used at this stage include Astrorail, Primerail, Primetime, and Star RC / XT products, each from Synopsys, Inc. of Mountain View, California.

[0083] Next, the physical layout is verified (step 728). During physical verification, the layout design is checked to ensure correctness of manufacturing constraints, such as design rule constraints, electrical constraints, lithography constraints, and circuit system functionality matching the HDL design specifications. Examples of EDA software products that can be used at this stage include Hercules products from Synopsys, Inc. of Mountain View, California.

[0084] Next, the layout resolution is enhanced (step 730). During resolution enhancement, geometric manipulation of the layout is performed to improve the manufacturability of the design. An example of an EDA software product that can be used at this stage is the Proteus product from Synopsys Technologies, Inc. of Mountain View, California.

[0085] During one or more of design planning, physical implementation, analysis and extraction, physical verification, and resolution enhancement, such as described above in Figure 4 The methods and apparatus for determining and optimizing design yield disclosed in may be performed as part of one or more of these steps.

[0086] Next, the mask is prepared and the design is "exited" (step 732). Data is created for the production of lithographic masks (after applying lithographic enhancements, if appropriate). The exit data is used to produce lithographic masks used to produce the finished integrated circuit. Examples of EDA software products that can be used at this stage include the CATS product line from Synopsys, Inc. of Mountain View, California. Additionally, examples of EDA software products that can be used during exit include the IC Compiler and Custom Designer product lines from Synopsys, Inc. of Mountain View, California.

[0087] The integrated circuit design tools mentioned above are merely examples of tools that can be used. Similar commercial tools and various non-commercial tools from other EDA vendors (eg, Cadence, Siemens), other corporate entities, universities, or open source repositories can be used as alternatives.

[0088] The storage subsystem is preferably used to store programs and data structures that provide the functionality of some or all of the EDA tools described herein, as well as tools for developing cells of the library and for the physical and logical design of the library. These programs and data structures are typically executed by one or more processors in a manner known to those skilled in the art.

[0089] According to some embodiments of the disclosed method and apparatus, an EDA process, for example, Figure 7 The EDA process disclosed in DMP 700 typically includes a simulator for verifying the functionality of the circuit design. Figure 7 In the DMP 700 mentioned above, examples of simulators and prototyping products available from Synopsys that can be used to assist in logic design functional verification (step 712 ) include Zebu.RTM. and Protolink.RTM. (RTM stands for 'registered trademark'). Figure 8 Additional details are provided regarding an embodiment of a test platform 800 including a host system 801 and an emulator 802. In some embodiments, the emulator 802 is a set of programmable devices, such as an FPGA 804. In some such embodiments, the host system 801 uses a compiler 810 to generate data and information to configure the emulator 802 to simulate a circuit design. The one or more circuit designs to be simulated are referred to as designs under test ('DUTs'). The emulator 802 is a hardware system that simulates the DUTs. That is, the emulator 802 is used to simulate the performance of the DUTs to verify the functionality of the DUTs. An example of a product that can be used as the emulator 802 for the embodiments disclosed herein is the ZeBu server available from Synopsys.

[0090] The host system 801 includes one or more processors 806. In embodiments where the host system 801 is comprised of multiple processors 806, the functions described herein as being performed by the host system 801 may be distributed among the multiple processors 806.

[0091] In some embodiments, at least one of the processors 806 within the host system 801 includes a compiler 810 that processes code written in a hardware description language that represents the DUT being emulated by the emulator 802. The compiler generates data (typically binary) and information used to configure the emulator 802 to emulate the DUT. The compiler 810 can transform the DUT, change the DUT, reconfigure the DUT, add new functionality to the DUT, and / or control the timing of the DUT.

[0092] Host system 801 and emulator 802 exchange data and information using signals carried by emulated connection 808. Connection 808 can be one or more cables, such as a cable with a pin configuration compatible with RS232 or USB protocols. Connection 808 can be a wired communication medium or a network, such as a local area network or a wide area network, such as the Internet. The connection can be a wireless communication medium or a network with one or more access points using a wireless protocol such as Bluetooth® RTM or IEEE 802.11. Host system 801 and emulator 802 can exchange data and information through a third device, such as a network server (not shown).

[0093] In some embodiments, the emulator 802 includes multiple FPGAs 804. In some such embodiments, each FPGA 804 interfaces with the other FPGAs 804 of the emulator 802 (and potentially other emulator hardware components) via a bus 811 to allow the FPGAs 804 to exchange signals. While some embodiments disclosed herein use emulators that include FPGAs, other embodiments may include other types of logic blocks in place of or in conjunction with FPGAs 804 for emulating the DUT. For example, some embodiments may use custom FPGAs, dedicated ASICs for emulation or prototyping, memory, and input / output devices.

[0094] FPGA 804 may reside on one or more hardware boards 812. Several boards 812 may be placed into hardware units 814. The boards 812 within each unit 814 may be connected to each other by cables or any other means to form a multi-unit emulator 802. In some embodiments, emulator 802 includes a single board 812, a single unit 814 having one or more boards 812, or multiple units 814, each having one or more boards 812, and each board 812 having one or more units, without departing from the teachings of the present disclosure.

[0095] For the DUT to be simulated, the simulator 802 receives one or more "bit files" from the host system 801. The bit file contains a description of the DUT. The bit file further specifies the partitions of the DUT created by the host system 801, with: (1) trace and injection logic, (2) the mapping of the partitions to the FPGA of the simulator 802, and (3) design constraints. Based on the bit file, the simulator 802 configures the FPGA 804 to perform the functions of the simulated DUT. For some simulators 802, one or more FPGAs 804 of the simulator 802 have the trace and injection logic built into the silicon of the FPGA 804. For this type of simulator 802, the FPGA 804 does not have to be configured by the host system 801 to simulate the trace and injection logic.

[0096] The host system 801 receives a description of the DUT to be simulated (e.g., from a user or from a data store). In one embodiment, the DUT description is in the form of a hardware description language (HDL), such as register transfer language (RTL). In another embodiment, the DUT description is in the form of a netlist-level file, or a mixture of a netlist-level file and an HDL file. If part or all of the DUT description is in HDL form, the host system 801 synthesizes the DUT description to create a gate-level netlist based on the DUT description. The host system 801 can use the DUT's netlist to partition the DUT into multiple partitions, some of which include trace and injection logic. The trace and injection logic tracks interface signals exchanged through the interface of the FPGA. In addition, the trace and injection logic can be used to inject the traced interface signals into the logic of the FPGA. The host system 801 maps each partition to the FPGA of the simulator 802. For some simulators, the trace and injection logic is only included in select partitions of a group of FPGAs. The trace and injection logic can be built into one or more of the FPGAs of the simulator 802. The host system 801 can synthesize the multiplexer to map into the FPGA. The trace and injection logic can use the multiplexer to inject the interface signal into the DUT logic.

[0097] The host system 801 creates a bitfile that describes each partition of the DUT and the mapping of the partitions to the FPGAs. For partitions where trace and injection logic is incorporated, the bitfile also describes the incorporation of logic. The bitfile may also include placement and routing information and design constraints. The host system 801 stores the bitfile and also stores the components of the DUT information that describe which FPGAs will emulate each component of the DUT (to which FPGAs each component is mapped).

[0098] Upon request, host system 801 transfers the bitfile to emulator 802. Host system 801 instructs emulator 802 to emulate the DUT. During or at the end of the DUT simulation, host system 801 receives simulation results from emulator 802 via emulation connection 808. Simulation results are data and information generated by emulator 802 based on the simulation of the DUT. The simulation results include interface signals (the states of the interface signals) tracked by the trace and injection logic of each FPGA. Host system 801 can store the simulation results or transmit them to another processing system.

[0099] After simulating a DUT, a user may request to debug a component of the DUT. If such a request is made, the user may provide a simulated time period for debugging. The host system 801 identifies which FPGAs are configured to simulate the component based on stored information. The host system 801 retrieves the stored interface signals associated with the time period and tracked by the trace and injection logic of each identified FPGA. The host system 801 instructs the emulator 802 to re-simulate the identified FPGAs one by one, multiple at a time, or all at once. The host system 801 transmits the retrieved interface signals to the emulator 802 to re-simulate the component within the time period. The trace and injection logic of each identified FPGA injects the corresponding interface signal it receives from the host system 801 into the logic of the DUT mapped to the FPGA. In the case of multiple re-simulations of the FPGA, the results can all be merged together to obtain a complete debug view.

[0100] During the re-simulation of the component, the host system 801 receives signals traced by the logic of the identified FPGA from the simulator. The host system 801 stores the signals received from the simulator 802. The signals traced during the re-simulation may have a higher sampling rate than during the initial simulation. For example, in the initial run, the traced signal may consist of hardware states saved every X milliseconds. However, in the re-simulation, the traced signal may consist of hardware states saved every Y milliseconds, where Y is less than X. If the user requests to view the waveform of the signal traced during the re-simulation, the host system 801 can retrieve the stored signal and display a plot of the signal (generating the waveform of the signal). Thereafter, the user can, for example, request to re-simulate the same component but in a different time period or to re-simulate another component.

[0101] Host system 801 typically includes at least seven subsystems: a design synthesizer, a mapping module, a runtime module, a results module, a debug module, a waveform module, and a storage module. Each of these subsystems can be implemented as hardware, software, firmware, or a combination thereof. Together, these components configure simulator 802 and monitor simulation results.

[0102] The design synthesizer converts the HDL of the DUT into gate-level logic. For the DUT to be simulated, the design synthesizer receives a description of the DUT. If the description of the DUT is in whole or in part in the form of HDL (e.g., RTL or other abstraction level), the design synthesizer 210 synthesizes the HDL of the DUT to create a gate-level netlist that describes the DUT in terms of gate-level logic.

[0103] The mapping module partitions the DUT and maps the partitions to the simulator FPGA. The mapping module uses the DUT's netlist to partition the DUT at the gate level into a number of partitions. For each partition, the mapping module retrieves a gate-level description of trace and injection logic and incorporates the logic into the partition. As described above, the trace and injection logic contained in the partition is configured to trace signals exchanged through the interface of the FPGA to which the partition is mapped (trace interface signals). The trace and injection logic can be incorporated into the DUT before partitioning. For example, the trace and injection logic can be incorporated by the design synthesizer before or after synthesizing the DUT's HDL. Therefore, the trace and injection logic may not match the partition, but may be a subset, a superset, or even different from the partition.

[0104] In addition to including trace and injection logic, the mapping module may also include additional trace logic in the partitions to track the states of certain DUT components that are not tracked by the trace and injection logic (to track signals other than interface signals tracked by the trace and injection logic). The mapping module may include the additional trace logic in the DUT before partitioning or in the partitions after partitioning. The design synthesizer may include the additional trace logic in the HDL description of the DUT before synthesizing the description.

[0105] The mapping module maps each partition of the DUT to an FPGA of the simulator 802. The mapping module performs the partitioning and mapping using design rules, design constraints (e.g., timing or logic constraints), and information about the simulator 802. For components of the DUT, the mapping module stores information in a memory module that describes which FPGA will simulate each component.

[0106] Based on the partitioning and mapping, the mapping module generates one or more bitfiles that describe the mapping of the created partitions and logic to each FPGA in the simulator 802. The bitfiles may include additional information, such as the constraints of the DUT and routing information for connections between FPGAs and within each FPGA. The mapping module generates a bitfile for each partition of the DUT, which may be stored in a storage module. Upon user request, the mapping module transmits the bitfiles to the simulator 802, which uses the bitfiles to configure the FPGAs to simulate the DUT.

[0107] If the emulator 802 comprises a dedicated ASIC containing trace and injection logic, the mapping module may generate a specific configuration that allows it to be connected to the DUT or simply save information on what the traced / injected signals are and where that information is stored on the dedicated ASIC.

[0108] The runtime module controls the simulation executed on the simulator 802. The runtime module can cause the simulator 802 to start or stop executing the simulation. In addition, the runtime module can provide input signals / data to the simulator 802. The input signals can be provided to the simulator 802 directly via a connection or indirectly via other input signal devices. For example, the host system 801 with the runtime module can control the input signal device to provide the input signal to the simulator 802. The input signal device can be, for example, a test board (directly or via a cable), a signal generator, another simulator (not shown), or another host system (not shown).

[0109] The results module processes the simulation results generated by the simulator 802. During the simulation and / or after the simulation is completed, the results module receives the simulation results generated during the simulation from the simulator 802. The simulation results include signals tracked during the simulation. Specifically, the simulation results include the trace and interface signals tracked by the injection logic simulated by each FPGA. The simulation results may also include signals tracked by additional logic included in the DUT. Each tracked signal may span multiple simulation cycles. A tracked signal is composed of multiple hardware states, and each hardware state is associated with a simulation time. The results module stores the received trace signals in the storage module. For each stored signal, the results module may store information indicating which FPGA generated the tracked signal.

[0110] The debug module allows the user to debug a component of the DUT. After the simulator 802 has simulated the DUT and the results module has received the interface signals traced by the trace and injection logic during simulation, the user can request to debug the component by resimulating the component within a specific timing period. In the request to debug a component, the user identifies the component and indicates the simulation time period for debugging. The user's request may also include a sampling rate indicating how often the logic for tracing signals should save the hardware state.

[0111] The debug module identifies one or more FPGAs of the emulator 802 that are configured to emulate the components based on the information stored in the memory module by the mapping module. For each identified FPGA, the debug module retrieves from the memory module the interface signals traced by the trace and injection logic of the FPGA during the user-indicated time period (i.e., retrieves the hardware state associated with the time period traced by the trace and injection logic).

[0112] The debug module transmits the retrieved interface signals to the simulator 802. The debug module instructs the debug module to run on the identified FPGAs and causes the trace and injection logic of each identified FPGA to inject its corresponding traced signal into the FPGA's logic to re-simulate the component within the requested time period. The debug module may also transmit a user-supplied sampling rate to the simulator 802 so that the trace logic tracks the hardware state at appropriate intervals. To debug a component, the simulator 802 only needs to run on the FPGA to which the component has been mapped. Furthermore, re-simulation of a component does not have to start from scratch, but can be started at any point desired by the user.

[0113] For the identified FPGA, the debug module can transmit instructions to the simulator 802 to load multiple simulator FPGAs with the same configuration of the identified FPGA. The debug module can also instruct the simulator 802 to run the multiple FPGAs in parallel. Each FPGA from the multiple FPGAs runs with a different time window for the interface signal, thereby generating a larger time window in a shorter amount of time. For example, it may take an hour for the identified FPGA to run a certain number of loops. However, if the multiple FPGAs are loaded with the configuration of the identified FPGA and each of the FPGAs runs a subset of the loops, it may only take a few minutes for the FPGAs to run all the loops together.

[0114] The user can identify a hierarchy or list of DUT signals to be re-simulated. To accomplish this, the debug module determines the FPGA required to simulate the hierarchy or list of signals, retrieves the necessary interface signals, and transmits the retrieved interface signals to the simulator 802 for re-simulation. Thus, the user can identify any element (e.g., component or signal) of the DUT for debugging / re-simulation.

[0115] The waveform module generates waveforms based on the tracked signals. If a user requests to view the waveform of a signal tracked during a simulation run, the host system 801 retrieves the signal from the storage module. The waveform module displays a plot of the signal to the user. For one or more signals, the waveform module can automatically generate a plot of the signal when the signal is received from the simulator 802.

[0116] Although the disclosed methods and apparatus are described above with respect to various examples of embodiments and implementations, it should be understood that the specific features, aspects, and functions described in one or more individual embodiments are not limited in their applicability to the specific embodiments in which they are described. Accordingly, the breadth and scope of the claimed invention should not be limited by any examples provided in describing the disclosed embodiments above.

[0117] The terms and phrases used in this document, and variations thereof, unless expressly stated otherwise, should be interpreted as open-ended and non-restrictive. As examples of the foregoing: the term "including" should be interpreted to mean "including but not limited to," etc.; the term "example" is used to provide an example of an example of the item being discussed, rather than an exhaustive or limiting list thereof; the terms "a" or "an" should be interpreted to mean "at least one," "one or more," etc.; and adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be interpreted as limiting the described items to items available in a given time period or from a given time, but should be interpreted to encompass conventional, traditional, normal, or standard technology available or known at any time now or in the future. Similarly, where this document refers to technology that would be understood or known to one of ordinary skill in the art, such technology encompasses technology that would be understood or known to one of ordinary skill in the art at any time now or in the future.

[0118] A grouping of items associated with the conjunction "and" should not be read as requiring that each of those items be present in the grouping, but rather should be read as "and / or" unless expressly stated otherwise. Similarly, a grouping of items associated with the conjunction "or" should not be read as requiring mutual exclusivity within that grouping, but rather should be read as "and / or" unless expressly stated otherwise. Furthermore, although items, elements, or components of the disclosed methods and apparatus may be described or claimed in the singular, the plural is contemplated as being within the scope thereof unless limitation to the singular is expressly stated.

[0119] In some instances, the presence of expanders and phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be construed as indicating that a narrower context is intended or required in instances where such expanders may be absent. The use of the term "module" does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. In fact, any or all of the various components of the module, whether control logic or otherwise, may be combined in a single package or maintained separately and may further be distributed among multiple groups or packages or across multiple locations.

[0120] In addition, the various embodiments described herein are described with the aid of block diagrams, flow charts, and other illustrations. After reading this document, it will become apparent to those skilled in the art that the illustrated embodiments and their various alternatives may be implemented without limitation to the examples described herein. For example, the block diagrams and accompanying descriptions should not be construed as enforcing a specific architecture or configuration.

Claims

1. A method for calculating a timing yield of an integrated circuit (IC) having a plurality of timing arcs and endpoints, and a plurality of subsets of the timing arcs, each subset being associated with an endpoint, the method comprising: a) generating a speed index associated with each timing arc of a first IC sample to determine a random delay value, wherein the same speed index is used for a common timing arc to determine the random delay value of a signal path associated with the common timing arc of the first IC sample; b) generating a first delay sample for each timing arc of the first IC sample based on the associated speed index, the delay distribution of the timing arc, and a path context; c) determining the slack of each endpoint of the first IC sample; d) determining a worst slack among the slacks determined for the first IC sample; e) repeating a) to d) for multiple IC samples; and f) determining a timing yield of the IC based on a ratio of the number of determined worst slacks having non-negative values ​​relative to a total number of IC samples. The method of claim 1 , wherein the delay profile of each timing arc is determined based on variation-aware timing analysis. 3 . The method of claim 1 , wherein the subset of timing arcs comprises a signal path through an analog sample cell of the IC sample. The method according to claim 1 , wherein the speed index is generated by a Monte Carlo value generator. 5 . The method of claim 1 , wherein determining the slack for each endpoint of the first IC sample comprises summing the delayed samples for the each endpoint.

6. The method of claim 3, wherein the common timing arc comprises timing arcs on a first signal path and a second signal path, wherein the delay of the timing arc on the first signal path is different from the delay of the timing arc on the second signal path. 7 . The method of claim 6 , further comprising generating a delay matrix having elements comprising the delayed samples for all timing arcs, each delay matrix representing the analog sample unit.

8. A computer system comprising: a) a storage subsystem comprising an electronic design automation (EDA) module; b) a processor coupled to the storage subsystem to receive instructions from the storage subsystem to direct the processor: i. generating a speed index associated with each timing arc of the first integrated circuit IC sample to determine a random delay value, wherein the same speed index is used for a common timing arc to determine different random delay values ​​for signal paths associated with the common timing arc of the first IC sample; ii. generating a first delay sample of each timing arc of the first IC sample based on the associated speed index, the delay distribution of the timing arc and the path context; iii. determining the slack of each endpoint of the first IC sample; iv. determining the worst slack among the slacks determined for the first IC sample; v. Repeat i. to iv. for multiple IC samples having a unit; and vi. Determining a timing yield of the IC based on a ratio of the number of determined worst slacks having non-negative values ​​relative to the total number of IC samples.

9. The computer system of claim 8 , wherein the instructions received from the memory subsystem direct the processor to identify paths having negative slack in a maximum number of IC samples, identify the cells residing in the identified paths, and adjust the design of the identified cells to reduce the likelihood of negative slack in the identified paths.

10. The computer system of claim 8, wherein the instructions received from the storage subsystem direct the processor to: a) Generate a delay matrix of multiple IC samples; b) determining a design slack of each of the plurality of IC samples and a design slack distribution of the plurality of IC samples; c) determining a delay distribution of a first timing arc across the plurality of IC samples; d) Calculate the cross moment of: i. the design slack distribution; and ii. the delay distribution of the delay of the first timing arc; and e) repeating c) and d) for each timing arc of the IC; and f) determining which cells of the IC sample have timing arcs that result in a crossing moment having a value above a predetermined threshold, and determining those determined cells as timing bottlenecks.

Images