Timing path analysis using flow graphs

A method for timing path analysis using flow graphs. The method includes receiving timing data associated with an integrated circuit (IC) design. The timing data includes a plurality of timing paths. The method also includes generating a graphical representation of the plurality of timing paths. A timing path is represented as a flow ribbon across one or more components of the IC design. A display attribute of the flow ribbon is indicative of a metric of the timing path. The graphical representation is provided in a graphical user interface (GUI) to a user.

TECHNICAL FIELD

The present disclosure relates to electronic design automation. In particular, the present disclosure relates to timing path analysis using flow graphs.

BACKGROUND

Timing analysis can be performed on a design after placement of components on a chip to determine signal delays between logic elements. Timing analysis results can be expressed in terms of slack. The slack may be a difference between a desired delay and an actual delay. The timing analysis results may include worst negative slack (WNS), total negative slack (TNS), number of violating paths (NVP) or give the WNS for each endpoint.

SUMMARY

In one aspect, a method includes receiving timing data associated with an integrated circuit (IC) design. The timing data includes a plurality of timing paths. The method also includes generating a graphical representation of the plurality of timing paths. A timing path is represented as a flow ribbon across one or more components of the IC design. A display attribute of the flow ribbon is indicative of a metric of the timing path. The graphical representation is provided in a graphical user interface (GUI) to a user.

In one aspect, a system includes a memory storing instructions and a processor, coupled with the memory and to execute the instructions. The instructions when executed cause the processor to receive timing data associated with an integrated circuit (IC) design, generate a graphical representation of the plurality of timing paths, and provide the graphical representation in a graphical user interface (GUI) to a user. The timing data includes a plurality of timing paths. A timing path is represented as a graphical object across one or more components of the IC design and a display attribute of the graphical object is indicative of a metric of the timing path.

DETAILED DESCRIPTION

Aspects of the present disclosure relate to timing path analysis using flow graphs. A timing flow graph may be generated based on timing data associated with a circuit design (e.g., an integrated circuit (IC) design). The timing flow graph may represent a timing path as a flow ribbon across one or more components of the IC design. A component may refer to a cell, a node, a block, or a module. The timing flow graph may be analyzed to determine a source and/or an owner of an issue in a timing path. In some aspects, the timing path may represent a list of pins. Each pin may be an input or an output from a component. In addition, the timing flow graph may be used to detect unexpected connections and to identify hotspots.

Users may have long lists of violating timing paths (i.e., timing paths that violate one or more design rules) and may desire to analyze each violating timing path to determine the root or cause of the violation. Full enumeration may not be feasible and analysis is very difficult due to the large amounts of timing data (e.g., large number of timing paths). Users struggle to determine where the roots of the timing violation are. For example, the users struggle to analyze the large amounts of data associated with violating timing paths to find patterns in the data that point to specific problems.

Conventional analysis techniques group the data by scenario, path-group, and the like. Some analysis techniques may aggregate with worst negative slack (WNS), total negative slack (TNS), number of violating paths (NVP) or give the WNS for each endpoint. These analysis techniques lose the data flow nature of the timing paths. Timing path may represent signal propagation through the one or more modules of the IC design. The module may be a high level module. Conventional analysis techniques do not show the timing paths with respect to the module or levels. The user cannot relate a metric associated with the timing path with the modules associated with the timing and with the order of the modules (e.g., level). Thus, debugging may require dropping down into all of the details of the timing paths that is time consuming.

Embodiments disclosed herein solve problems encountered in debugging and detecting root causes of violating paths. In particular, embodiments disclosed herein preserve the data flow nature of timing paths. The relation between the signal propagation between the modules and the corresponding timing paths is preserved. In addition, the relation between the timing paths and the order and/or level of the modules is preserved. Preserving the data flow nature of the timing paths helps in detecting the root of the violating path (e.g., a module).

The timing path flow graph described herein is a graphical representation of timing paths in the circuit. The graphical representation may be displayed in a user interface. The user interface (e.g., graphical user interface (GUI)) allows users to analyze issues in a large number of violating paths. The graphical representation may include modules associated with a timing path. The timing path flow graph may be a connectivity plot that displays all violating timing paths or timing paths of a particular module in a connectivity plot. The connectivity plot shows the modules and connectivity of an unfolded timing path by connection levels. The timing path flow graph can be global or for an individual module (i.e., module specific). The modules may be designed by separate engineers/groups.

Advantages of the present disclosure include, but are not limited to, providing efficient analysis of timing data, providing a visualization of a large number of timing paths, and reducing debugging time. In some aspects, the debugging time may be reduced because the user may locate the root of the violation using the timing flow graph without going through a massive amount of data associated of individual timing paths. For example, the user may identify from the timing flow graph the module that may be root of the violation (e.g., when all timing paths through the module appear to exceed a timing metric). The timing data may be analyzed efficiently by providing visibility of the timing paths and the ability for the user to analyze a high-level picture that includes a representation of a large number of timing paths and then turn to a more granular one as needed. Thus, the visualization of the large number of timing paths in the timing flow graph helps the user analyzes the large number of timing paths compared to the table or list of timing paths. Timing flow graph retains an overall representation of the paths, while having a flexible way to aggregate the nodes to help abstract out leaf level gates and instead focus on how the paths flow through the overall structure of the design.

In some embodiments, the graphical representation may display a plurality of metrics associated with the circuit design, for example, WNS, TNS, NVP, maximum number of gates, a number of bottleneck cells, path length, longest net, gate delay, number of levels, number of timing paths, and/or maximum path length in a group of timing paths. The graphical representation may display each metric of the plurality of metrics in response to an input from the user. Further, one or more attributes (characteristic) (e.g., color, line type, line width, fill pattern, or other display characteristics) of the displayed modules, timing paths, and/or group of timing paths based on a value of the metric.

In some embodiments, the flow graph may include violating timing paths. The flow graph shows path lengths for unrolled path, start/end/through cells, cell to cell path counts, and feedback loops by repeating the cell (unroll once) and sharing a display attribute (e.g., color).

In some embodiments, timing paths may share one or more components. Such collection of timing paths may be called an island. The timing flow graph may be used to identify connectivity “islands.”

The approaches described herein support interactive query of data. For example, the interactive query of data may include displaying fan in/out of a module (e.g., node, cell, component, block) and cross selecting into design by edge (i.e., timing path) or component.

The timing flow graph may include different levels of details. The timing flow graph is flexible to allow control over the level of details provided (i.e., all logical hierarchies, only physical hierarchies, architecturally interesting blocks, and the like). This provides the advantage of helping the user to see and understand the high level dependencies/flow of the paths with a flexible amount of details. A user may push down into the full path details if desired for further analysis.

In some embodiments, a module may be at different levels on different timing paths. A user may select the module to generate a module focused flow graph.

FIG.1is a schematic that shows a timing flow graph100, in accordance with an embodiment of the present disclosure. Timing flow graph100includes a flow ribbon102. Flow ribbon102can represent a set of one or more timing paths in the circuit design. Flow ribbon102may represent a series of arcs between the modules of the circuit design. Timing flow graph100may include one or more modules104between a start point and an end point of each flow ribbon102. The one or more timing paths share the same flow through the modules. In some aspects, module104may represent a high level module. Thus, the one or more timing paths may not share the same leaf level gates but share the high level module. The high level module may correspond to the module where an endpoint of the one or more timing paths reside. A unique attribute (e.g., color) may be associated with each module104. The color of module104may correspond with a module boundary color. For example, module104may be individually colored to help distinguish between them and detect duplicates. Each module104may be represented in one or more flow ribbons102because each module may be included in one or more timing paths.

In some embodiments, a first dimension106of the timing flow graph (e.g., x-coordinate) may correspond to a connection order in the timing path (i.e., a connection depth). For example, first dimension106may correspond to the order of the component in the timing path.

In some embodiments, flow ribbon102are ordered and connected vertically. For example, flow ribbon102may be displayed in a second dimension of timing flow graph100(e.g., y-coordinate). Flow ribbon102may be associated with a display attribute (e.g., colored) indicative of a timing path metric (e.g., WNS, TNS) (e.g., selected timing metric). A width of flow ribbon102may be indicative of a connection count or the number of timing paths associated with the flow ribbon102. The width of flow ribbon102may be proportional to the connection count between two modules. The length of flow ribbon102may be indicative of the number of levels. For example, a length of flow ribbon102ais greater than the length of flow ribbon102b. Both flow ribbon102aand flow ribbon104bstart at the same module but flow ribbon102agoes through more modules before ending. In some aspects, the display attribute (e.g., darker gray shading) of flow ribbon102amay indicate that for a selected timing metric, the magnitude of the metric is higher than the magnitude of the metric for flow ribbon104b(i.e., lighter shading). In addition, the width of flow ribbon102ais less than the width of flow ribbon104a. This may indicate that flow ribbon102ahas fewer timing paths compared to flow ribbon104a.

In some embodiments, a display attribute (e.g., color) of flow ribbon102may change as it goes from a first module to a second module to highlight/show hotspots. Thus, the user can see where the selected metric (e.g., WNS, TNS) is most intense as it goes from a module to another module in the timing path. The flow ribbon102may be associated with a unique identifier. The unique identifier may be used to trace the flow ribbon102across the flow graph100and align input/output edges.

In some embodiments, timing flow graph100may also be used to identify connection islands, e.g., island108. The user may identify timing paths that are interconnected with each other. For example, the plurality of flow ribbons112are interconnected with each others. Thus, the corresponding time paths are interconnected with each other. The user may also identify simple time paths that are not interconnected with other timing paths. For example, flow ribbon110is not interconnected with other flow ribbons. The user may focus on the interconnected areas to determine a source of an error or a violating timing paths as the source of the error is likely to be in the highly interconnected timing paths.

In some embodiments, details associated with module104or flow ribbon102may be displayed in tooltips to minimize text noise. The user can query the details of the modules, paths, and connectivity using mouse over feedback and clicking on module or path cross selects into a design layout for further analysis. For example, a mouse over may highlight flow ribbon102and show a fan in/fan out. Timing flow graph100is connected to other tables, views, or representations. For example, a selection of module104or flow ribbon102in timing flow graph100highlights module104or the timing path associated with flow ribbon102in a design layout view and in a hierarchical view.

In some embodiments, a display attribute of module104(e.g., color) may be used in the design layout to show the boundary of the selected module. The matching modules may be colored while the remaining modules may be non-colored. In other examples, each module may have a distinct color. The same display attribute may be used to highlight corresponding data in a tabular form or hierarchy.

In some embodiments, in response to the user selecting a portion of the graphical representation, associated data are filtered and outputted in a visual and/or tabular form. In response to selecting module104in the timing flow graph100, the display attribute of the same module in all other flow ribbons may be changed.

In some embodiments, a flow ribbon selection may be followed by a filter action to reduce the timing flow graph100to a region of interest. For example, the user may select one or more flow ribbons. The user may input one or more attributes via the GUI. Then, timing flow graph100is focused to the region of interest based on the one or more attributes.

In some embodiments, timing flow graph100may display identified modules and/or timing paths. For example, a user may select one or more modules or timing paths in a hierarchy or tabular view and the identified modules and/or timing paths are displayed in timing flow graph100.

In some embodiments, the user may filter data represented in timing flow graph100using a table. The user may select one or more modules and/or metrics in the table to reduce the timing flow graph100to the region of interest.

In some embodiments, the user may select to display timing paths having a timing path slack value less than a user-defined amount. Alternatively or additionally, the user may indicate to view the nthtiming path having the worst timing path slack values. Other restriction on display criteria may also be envisioned and the examples provided herein are not intended to limit the scope of the present disclosure.

In some embodiments, timing flow graph100may be displayed in an interface that includes one or more panes. For example, a first pane may display information associated with a query and a second pane may display information associated with a selected module/path in timing flow graph100(e.g., hover tooltip information). This provides the advantage of fast comparison by the user.

In some embodiments, timing flow graph100may be an initial view depicting the timing paths for the design. The user may select one or more modules for further analysis. A focused flow graph may show more detailed information for a selected module.

FIG.2is a schematic that shows a module focused flow graph200(call centric graph), in accordance with an embodiment of the present disclosure. A common cell in multiple timing paths at different levels can be normalized in module focused flow graph200. In response to selecting a module in timing flow graph100, the system may generate module focused flow graph200. Module focused flow graph200shows timing paths associated with the selected module. In some embodiments, module focused flow graph200displays a module202(i.e., selected module) and timing paths associated with module202. Input and output connections of module202are displayed. In some aspects, module202is represented once in the module focused flow graph200and all connections to the module are shown. The timing paths are represented as flow ribbons that include all modules downstream and upstream of the selected module202. Thus, all flow ribbons that include the selected module (focused module) at some level in their paths are represented.

In some embodiments, module202may be selected by clicking on a module in timing flow graph100. Module202may also be selected by entering a unique identifier (e.g., number, name) in a field in the GUI.

In some embodiments, a first dimension of module focused flow graph200may correspond to a connection level. In some embodiments, flow ribbons associated with module202may not start on a left edge of module focused flow graph200. For example, flow ribbon206aand flow ribbon206bcan start at level8and level9, respectively.

As discussed previously herein, timing flow graph100represents an abstraction of the data of the IC design. Bottlenecks may be displayed in timing flow graph100or module focused flow graph200. In one example, module focused flow graph200or timing flow graph100may be used to identify a module and/or a timing path. Then, the layout of the IC design or a table of data associated with the IC design may be filtered based on the identified module and/or timing path. A source code (e.g., RTL) associated with the identified module may also be retrieved.

FIG.3is a flowchart for a method300for visualization of timing paths, in accordance with an embodiment of the present disclosure.

In302, data associated with an IC design may be acquired. Data may include timing data. The timing data may be generated and/or acquired from a STA tool. The timing data may include information associated with a plurality of timing paths of the IC design.

In some embodiments, the data may be analyzed to determine one or more metrics of the plurality of timing paths. For example, WNS, TNS, and the like may be determined. In some embodiments, the one or more metrics may be included in the timing data and acquired from the STA tool.

In304, a graphical representation of the plurality of timing paths is generated. The timing path may be represented as a flow ribbon across one or more components of the IC design. A display attribute of the flow ribbon may be indicative of a metric of the timing path.

In some embodiments, a value corresponding to a first dimension may be assigned to each module based on a location of the component in a timing path. A flow number may be assigned to each connection (i.e., between modules). Each component may be displayed vertically in timing flow graph100based on the assigned value without overlaps between the components. A dimension of a representation of the component may be based on a maximum of the sum of the sizes of the input and output connections. For example, a component may be represented by a rectangle. A length of the rectangle may be based on the maximum of the sum of the input and output connections associated with the component. In addition, a width of the flow ribbon is based on the number of connections in the associated timing path.

In some embodiments, the component may be aligned to connected components from left to right in the first dimension. The component may be repositioned in a second dimension (e.g., y-coordinate) to remove overlaps and crossings between ribbon flows. The repositioning may be repeated for each value in the first dimension (e.g., x-value). In some aspects, input/output of each component may be ordered based on an identifier associated with the timing path. The identifier may be a unique identifier associated with each timing path. The unique identifier may identify the timing path as it flows through the modules (e.g., through pins of the cells). As described previously herein, each timing path may represent a list of pins. Each pin may be an input or an output from a cell. In some embodiments, edges of the component representation are centered such that an input edge y-coordinate center matches an output edge y-coordinate center.

In306, the graphical representation is provided in a GUI to a user. For example, the graphical representation may be presented to a display of a user device.

FIG.4is a flowchart for a method400for visualization of detailed connections of a component, in accordance with an embodiment of the present disclosure.

In402, a query to generate and view a module (i.e., component) focused flow graph (i.e., an additional graphical representation) may be received from a user. The query may be in the form of selecting a component in timing flow graph100, entering a component name, selecting a component in the layout view, entering a search criteria in a search field, or the like.

In404, a focused flow graph may be generated based on the query received from the user. In some embodiments, all timing paths associated with the selected component may be identified. The timing paths that are not associated with the selected component may not be displayed. The timing paths that are associated with the selected component may be represented as ribbon flow in the focused flow graph. Thus, one or more inputs and one or more outputs of the selected component are identified in the focused flow graph. In some embodiments, the flow ribbon may be reordered to remove overlaps.

In406, the focused flow graph may be presented to the user in a new visualization window.

FIG.5illustrates an example set of processes500used during the design, verification, and fabrication of an article of manufacture such as an integrated circuit to transform and verify design data and instructions that represent the integrated circuit. Each of these processes can be structured and enabled as multiple modules or operations. The term ‘EDA’ signifies the term ‘Electronic Design Automation.’ These processes start with the creation of a product idea510with information supplied by a designer, information which is transformed to create an article of manufacture that uses a set of EDA processes512. When the design is finalized, the design is taped-out534, which is when artwork (e.g., geometric patterns) for the integrated circuit is sent to a fabrication facility to manufacture the mask set, which is then used to manufacture the integrated circuit. After tape-out, a semiconductor die is fabricated536and packaging and assembly processes538are performed to produce the finished integrated circuit540.

During netlist verification520, the netlist is checked for compliance with timing constraints and for correspondence with the HDL code. During design planning522, an overall floor plan for the integrated circuit is constructed and analyzed for timing and top-level routing.

During analysis and extraction526, the circuit function is verified at the layout level, which permits refinement of the layout design. During physical verification528, the layout design is checked to ensure that manufacturing constraints are correct, such as DRC constraints, electrical constraints, lithographic constraints, and that circuitry function matches the HDL design specification. During resolution enhancement530, the geometry of the layout is transformed to improve how the circuit design is manufactured.

A storage subsystem of a computer system (such as computer system600ofFIG.6) may be used to store the programs and data structures that are used by some or all of the EDA products described herein, and products used for development of cells for the library and for physical and logical design that use the library.

The example computer system600includes a processing device602, a main memory604(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), a static memory606(e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device618, which communicate with each other via a bus630.

The computer system600may further include a network interface device608to communicate over the network620. The computer system600also may include a video display unit610(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device612(e.g., a keyboard), a cursor control device614(e.g., a mouse), a graphics processing unit622, a signal generation device616(e.g., a speaker), graphics processing unit622, video processing unit628, and audio processing unit632.

The data storage device618may include a machine-readable storage medium624(also known as a non-transitory computer-readable medium) on which is stored one or more sets of instructions626or software embodying any one or more of the methodologies or functions described herein. The instructions626may also reside, completely or at least partially, within the main memory604and/or within the processing device602during execution thereof by the computer system600, the main memory604and the processing device602also constituting machine-readable storage media.