Critical Path Analyzer With Path Context Window

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

This invention generally relates to electronic design automation apparatus and, more particularly, to an improved critical path analyzer, also referred to as a timing analyzer or timing verifier.

Logic simulation is now an important tool in the design and verification of electronic circuits, including transistor level, gate level, and block level designs. Simulation tests the function of a design by exercising and evaluating circuit logic with a set of input patterns called test vectors. Logic simulators available today have simplified the generation of test vectors and made simulation a time- and cost-efficient method of uncovering many circuit-behavior problems before test-program development or production. A thorough simulation can reveal a variety of errors such as reversed polarities, missed clock periods, or incorrect logic implementation.

Simulation, however, cannot provide complete information about timing errors that occur in circuits employing sequential logic. Signal propagation in sequential logic circuits is not simultaneous. Propagation delays, for example, may influence the arrival time of signals at the several inputs of a single gate. If a signal misses a clock period as the result of such delay, simulation might show an error, but it may not report the signal path that introduced the critical delay. Moreover, if the delay occurs under conditions not exercised by the test vectors, simulation might miss the timing error entirely.

Timing analyzers provide the timing analysis lacking in logic simulators and allow a designer to identify signal paths whose timing is of concern. A signal path is considered to be a sequence of pins through a design that a signal will follow. Although path analysis approaches vary, at the heart of any path-analysis method is the concept of the critical path--the slowest of all signal propagation paths during a given cycle of circuit operation. A timer analyzer that provides critical path analysis typically searches for and identifies the fastest and slowest paths to a destination register in the circuit such as a clocked circuit element.

Prior timing analyzers, nevertheless, suffer from a number of drawbacks that limit their ease of use. One drawback is the difficulty in collecting information on different critical paths in the design. Information on each path is typically found in separate locations throughout the output from the analyzer, either on separate sheets of a printout or on separate terminal screen displays. A designer wanting to gather the different path information together must spend considerable time searching the output for the desired information and then record it.

Another drawback is the difficulty in visually tracing the critical path across the schematic sheets of the circuit. Most timing analyzers merely provide a textual description of the critical path, identifying the path by source and destination pins. It is left to the designer to trace the critical path across one or more schematic sheets to determine the path's circuit components and related signal delays. This process is not only time-consuming, but prone to error. Recognizing this, a timing analyzer available from Silicon Design Automation of San Jose, Calif., is constructed to highlight all critical paths directly on the schematic sheet when viewed on a terminal screen and to indicate delays for each component along path. But this analyzer still requires the designer to page through several screen displays of schematic sheets to view the entire signal path if the path crosses more than one schematic sheet.

An object of the invention, therefore, is to provide an improved apparatus for displaying paths along which signals propagate through a circuit.

Another object of the invention is to provide such an apparatus that displays in a screen display a signal path entirely, the signal path having portions that appear on separate schematic sheets.

Yet another object of the invention is to provide an apparatus that displays a list of critical signal paths in a screen display.

Still another object of the invention is to provide such an apparatus that displays in a screen display both the list of critical signal paths for selection of a critical path and, upon selection, the entire signal path that may cross several schematic sheets.

In accordance with the invention, a screen display is described for displaying a signal path in its entirety in isolation from the schematic sheets on which the path portions appear. The screen display comprises multiple display portions, each portion graphically displaying in isolation a path portion appearing on a separate schematic sheet. The multiple display portions are arranged adjacent to each other to display the signal path in its entirety in isolation from the schematic sheets.

The screen display includes other features to assist the user in viewing the signal path. Sheet identifiers are included in each display portion for identifying the schematic sheet for the path portion. Separators are shown between path portions for indicating a transition from one schematic sheet to another. A path list display shows a list of signal paths that can be selected for display. Separate schematic sheet displays may also appear in the screen display upon selection of a path portion from the displayed signal path.

Apparatus for displaying the signal path comprises means for accepting data defining signal paths in a circuit and display generator means for producing a display of the signal path entirely in a screen display. In particular, the apparatus may include analyzing means for determining which of the defined signal paths are considered critical. The display generator means responds to the selection of a critical path for producing a display of the selected critical path. Path list generator means may also be included in the apparatus for displaying in the screen display the list of the signal paths for selection.

In the present embodiment, the invention is described and shown in the context of a critical path analyzer for analyzing the timing of signal paths in a circuit design. The screen display includes a path context window that contains the entire signal path across multiple schematic sheets. Accompanying the path context window is a path list window that contains a list of the critical paths. A designer selects a critical path from the list in the window via conventional control means such as a keyboard or mouse. The selected path then appears in the path context window. To view the schematic sheet of a portion of the displayed path, the designer selects the path portion. A view sheet window appears in the screen display in response, displaying the schematic sheet corresponding to the selected portion.

The foregoing and other objects, features, and advantages of the invention will become more apparent from the following detailed description of a preferred embodiment which proceeds with reference to the accompanying drawings.

FIG. 1 is a hierarchial view of schematic sheets for a circuit design, each level of the hierarchy representing a different level of hardware modeling.

FIG. 2 is a screen display generated by apparatus according to the invention, the screen display including a path context window, path list window, and view sheet windows.

FIG. 3 is a second screen display generated by the apparatus which shows multiple path context windows.

FIG. 4 is a block diagram showing the relationship between various data structures and the apparatus, which enables the apparatus to generate the path context window and other features of the invention.

Referring now to FIG. 1 of the drawings, there is shown a hierarchial view of schematic sheets for a circuit design. These "sheets" are created by a designer on a computer using a computer program known as a schematic editor or schematic capture package. Schematic editors are known in the art and are available from a number of sources including Mentor Graphics of Beaverton, Oreg.; Daisy Systems of Mountain View, Calif.; and Valid Logic Systems of San Jose, Calif. With a schematic editor, a designer can create a hierarchy of design levels, with each level representing a different level of hardware modeling. For example, in FIG. 1, the top level of schematic sheets is the most general design. The lower level is more specific, with each sheet corresponding to an individual component which the designer wishes to model. Each level of design is given a filename, and the sheets within each filename are individually numbered. For purposes of describing the present invention, it will be assumed that a designer has designed a circuit with two levels of modeling. The top level is labeled with the filename ADD.sub.-- DET and includes at least one sheet and possibly more as indicated by the adjacent sheet shown in dashed lines. The lower level is labeled with the filename DECODE, referring to a component within sheet 1 of ADD.sub.-- DET and includes at least one sheet. Other components may also be shown more explicitly on schematic sheets at the second level, as indicated by the dashed box at the lower level in the figure. The circuit data entered graphically by the designer via the schematic editor includes component symbols taken from a library and connections between the components to create the circuit. The components so entered are referred to in the art as "instances" and the wire connections between instances as "nets." As will be described, this data is placed by the schematic editor in various data structures where it can be accessed by other design automation packages such as fault simulator, logic simulators, and timing analyzers.

The present invention is described in the context of a timing analyzer, in particular, a critical path analyzer. The critical path analyzer accepts data from a schematic editor or equivalent apparatus, defines signal paths from that data, and determines which of the defined signal paths are considered critical in terms of timing. It should be understood, however, that the present invention is not limited to use with a timing analyzer. The invention as described and claimed herein may be practiced in any electronic design automation apparatus where signal paths are an object of interest.

Referring now to FIG. 2 of the drawings, there is shown a screen display 10 generated by apparatus according to the present invention. The screen display 10 appears on terminal screen after the designer/user has run a critical path analysis with a critical path analyzer running on an associated computer. An equivalent permanent copy of the display 10, of course, may be produced from the display 10 with the use of a printing device. In the right portion of the display 10 appears a path list window 12 for displaying a list of signal paths determined to be critical by the analyzer. The paths are indicated by numbered rows and include data such as the source and destination pins for the path, whether the path signal arrived early or late relative to the clock signal for the destination register, the delay through the path, the number of instances in the path, etc. Unlike prior analyzers, however, all the critical paths are collected in this common location, window 12, for view by the user. If more paths exist than are shown in the window 12, the window may be expanded by selecting and moving arrows 14 via conventional control means such as a touch screen, pointer and mouse, or cursor and keyboard, etc.

A critical path may be selected from the path list window 12 via the control means for display of the path in its entirety apart from the schematic sheets. Upon its selection, a critical path is displayed in a path context window 16. As shown in FIG. 2, the path context window has a number of display portions of variable width for displaying path portions from separate schematic sheets. Together these display portions display a signal path in its entirety in a screen display such as window 16. For exmple, with path 2 selected from window 12, a first display portion 18a graphically displays in isolation a path portion appearing on sheet 1 of filename ADD.sub.-- DET apart from the schematic sheet, as indicated by a sheet identifier in the upper left corner of the display portion. The display portion 18a is defined by a path boundary 19 indicating the beginning of the path and a separator 20a indicating a transition to another schematic sheet. Within the display portion 18a are shown the instances and nets comprising the path portion. Also included is other data for the user, such as the name of the primary input, the circuit and commercial designations for the instance and the cumulative signal delay along the path after each instance.

A second display portion 18b adjacent to the first portion 18a continues the signal path 2 by displaying a second path portion in isolation apart from its schematic sheet. Separator 20a, situated between the two display portions, is constructed of "down" arrows to indicate a transition to another sheet at a lower design level. A sheet identifier in the upper left corner of the display portion indicates that the path portion is found on sheet 1 of filename DECODE. This schematic, as will be described, shows the internal design of a decoder found in sheet 1 of filename ADD.sub.-- DET. To assist the user in determining that this chip is the source of the path portion, a symbol 22 for the component is displayed in the display portion 18b adjacent to the path portion. Display portion 18b is bounded on its right by separator 20b. Because the following path portion continues on a higher level schematic sheet, separator 20b is constructed of "up" arrows to indicate the upward transition. If the following path portion had continued on an equal level schematic sheet, separator 20b would have indicated so with a vertical, line.

A third display portion 18c adjacent to the second portion continues the signal path 2 and displays the final path portion in isolation apart from its schematic sheet up to the path's termination at a destination register 24. The information displayed within the final display portion is of similar type to the information displayed in the other display portions. Also displayed is the cumulative signal delay tPath through the path relative to a reference and the clock delay tCLK for register 24 relative to the reference. As shown in display portion 18c, tPath equals 203.0 nanoseconds and tCLK equals 200.0 nanoseconds. The signal in path 2 thus arrives late, 3 nanoseconds after the clock signal for register 24. This information is also shown in the path list window 12 as the slack time.

The number of display portions depends on the number of schematic sheets crossed in the arrangement of components on each schematic sheet. The width of each display portion depends upon the number of instances within each portion and the length of each net between each instance. The entire signal path, regardless of the number of display portions, may be displayed within the path context window 16. If the signal path exceeds the size of the window 16, the control means can be employed for actuating arrows 26 to scroll the path horizontally.

The path window 16 also includes a prolog display portion 18d adjacent to the left side of the path boundary 19. Display portion 18d includes filename and sheet name headers 28 and 30, respectively, and a stub net 32 that connects to the input pin of the selected path.

Prior analyzers, by contrast, can only show one path portion at a time, highlighted within its respective schematic sheet. To view the entire path, the user must search through each schematic sheet at each relevant design level to trace the entire path.

To view the actual schematic sheets that contain the selected signal path in context, the user selects a path portion from path context window 16, again via conventional control means. Upon selection of a path portion, the corresponding schematic sheet is displayed in a separate schematic sheet display such as view sheet window 34. In FIG. 2, view sheet window 34a shows sheet 1 of ADD.sub.-- DET that includes the first and final path portions of path 2. View sheet window 34b shows sheet 1 of DECODE and displays the internal gate circuitry of the decoder chip, represented by symbol 22. The decoder chip, it can now be seen, is represented in sheet 1 of ADD.sub.-- DET as a functional block. At the lower design level in sheet 1 of DECODE, the individual gates, input pins, and output pins of the decoder chip are displayed.

To assist the user in detecting the selected path in the view sheet windows, the selected path is displayed in contrasting indicia to the screen display by highlighting the path against the background of the schematic sheet. The highlighting may be done both in the path context window 16 and in view sheet windows 34a, 34b if either is open for view.

FIG. 3 illustrates that multiple path context windows 16 and 16' can be simultaneously displayed if so desired. A path context window is closed and the displayed path removed by the user via the control means.

The screen display 10 and its features heretofore described is generated by source code written in C++. A copy of the code is attached as Appendix A. The source code uses data from graphics, connectivity, and path data structures, to be described, to generate the screen display. The source code refers to many ancillary functions and classes for data access and drawing functions. Although the source code for these functions is not included to maintain a focus on the invention, one skilled in the art could easily generate such code from each function's name. For example, the function new.sub.-- picture creates a window to draw in; the function init.sub.-- point marks an initial point for drawing; the function terminal.sub.-- point terminates a line for drawing, etc.

The algorithm employed in the source code for generating the screen display 10 is best understood by reference to the following pseudo-code. It will be recognized by those skilled in the art that equivalent algorithms could be so employed for generating the screen display 10. In reading the pseudo-code, the following should be noted. The operators!=, ==, =, represent "not equal to,""equal to," and "is assigned," respectively. Constant values are capitalized. The string "//" precedes comments. Procedure invocations are identified by the suffix "()." All procedures are found in an explicit procedure block. Parameters to a procedure are found within the "()." Indentation within a procedure block is significant. The procedures include the following:

path.sub.-- list produces the path list window 12 (also referred to as the graphical context window);

path.sub.-- context produces the path context window 16;

drawProlog produces the prolog to the path within window 16, including the filename and sheet name headers 22 and 24;

drawSheetBoundary draws boundaries between path portions;

drawInst draws instances within the selected path;

drawNet draws nets within the selected path;

view.sub.-- selected.sub.-- sheet creates a view of the schematic sheet that contains the selected object, i.e., component;

select places the supplied object into the list of selected objects;

hilite changes the indicia against the background of the screen display to highlight the object as displayed in various windows on the display; and

identify.sub.-- object returns the object that is represented by the graphics that are closest to the graphical point provided to it in the provided window.

Referring now to FIG. 4, both the pseudo-code and source code assume the existence of three data structures: a graphics structure 36, a connectivity structure 38, and a path structure 40. The graphics structure 36 and connectivity structure 38 are generated by means such as a schematic editor previously described in response to the input from the designer. A transform program 42 within the schematic editor transforms the data from the graphics structure 36 into data for the connectivity structure 38. A critical path analyzer 44 communicates with the connectivity structure 38 to define paths and determine which paths are critical. Path means such as path structure 40 then accept data from the analyzer 44 defining critical signal paths and stores the paths by reference to input-output pin pairs. All of the above data structures 36, 38, 40, the transformer 42 and analyzer 44 are known and understood in the art. A display generator 46 communicates with each of the data structures to obtain data for generating the path context window 16, the path list window 12, and other features of the display screen 10.

Considering the data structures in more detail, the path structure 40, also referred to as thePath, serves as a source of data for the procedure path.sub.-- context(). The connectivity structure 38 stores data describing the instances and nets connected to each pin. In the pseudo-code, this structure is referred to as theCKT and is the source of data for the function inst(). This function returns the instance connected to the supplied pin from the connectivity structure. The graphics structure 28 contains data on the location and graphic appearance of each instance, net, and pin in the circuit. In the pseudo-code, this structure is referred to as theCKTinfo and serves as the source of data for several functions. The function sheet() returns a identifier for the sheet on which the supplied instance or pin appears. The function location() returns the x,y location of the supplied pin relative to the symbol origin. The function symbol() returns the graphics for the symbol of the supplied instance.

The following functions also exist for generating the view sheet windows such as 34a and 34b from data within the graphics structure 36. The function owning.sub.-- inst(object) returns the parent instance in the hierarchy for this object, i.e., the instance which contains the sheet that contains the object. An object is an instance, net, or pin. The function net.sub.-- object(net, sheetId) returns a graphical object identifier for the given net on the given sheet. This graphical object highlights the net in the view window. The function object(graphical objectId, inst, sheetId) returns the object that is represented on the display by the supplied graphical objectId. The instance and sheetId parameters are required because the given graphical object can represent many different instances, nets, or pins if the sheet is part of a component that is used more than once in the circuit design.

The procedure path.sub.-- list is a means for producing in the screen display 10 a list of the critical signal paths, as determined by the critical path analyzer 36. For each critical path, a single text line is built describing the path and displaying the textual description as the net line in the window 12. From window 12, a critical path such as path 2 can be selected for display in its entirety in path context window 16.

The procedure path.sub.-- context is the main procedure of the display generator and generates the path context window and associated features by invoking the procedures drawProlog, drawInst, and drawNet. These procedure blocks comprise the display generator 46 for producing a display of the signal path contained entirely within path context window 16.

Initially, the procedure path.sub.-- context seeks a value for the variable next.sub.-- entry.sub.-- point upon selection by the user of a critical path. This variable tracks the point for boundaries such as path boundary 19 or separators 20a or 20b, or the leftmost point at which a net or instance in the path is drawn. The assignment statement containing the variable invokes the procedure drawProlog in order to obtain the initial point value, picture.sub.-- origin. The procedure drawProlog initially draws the filename and sheet name headers 22 and 24 at a predetermined distance to the left of the picture origin point. DrawProlog in turn invokes the procedure drawSheetBoundary which evaluates the x coordinate of picture.sub.-- origin for a boundaryType. The procedure drawSheetBoundary is a separator generator means for producing the boundaries and separators for display portions and also is a sheet identifier means for generating the sheet identifiers or labels for identifying each new sheet. If the boundaryType equals PROLOG, a path boundary 19 to the prolog is drawn. If the boundaryType equals DOWN, UP or SAME, the appropriate separator 20 is drawn. The sheet and filename labels are also drawn for a new sheet. On the initial pass through drawSheetBoundary, the boundaryType is equal to PROLOG and boundary 19 is drawn. The procedure drawProlog continues by drawing the stub net 32 if the first pin in the path is the input pin. Procedure drawProlog then returns the variable picture.sub.-- origin as the value for next.sub.-- entry.sub.-- point. Next.sub.-- entry.sub.-- point now contains the point at which the prolog net exited the prolog segment.

After initializing the variables prevPin and prevInst to identifiers NOPIN and NOINST, the procedure path.sub.-- context enters a for loop that checks each pin in the selected path to determine which separators 20, instances, and nets should be drawn. The for loop includes a first if statement that determines if the present path pin and the previous path pin are connected to the same instance or if the previous pin equals NOPIN. If either condition is satisfied, an instance is drawn according to the procedure drawInst and the variable next.sub.-- entry.sub.-- point is assigned a new value equal to exit.sub.-- point. The next if statement determines if the present instance and previous instance are on separate schematic sheets and if the previous instance is not equal to NOINST. If both conditions are satisfied, a boundary is drawn according to the procedure drawSheetBoundary and new labels for the filename and sheet name are drawn on the new schematic sheet.

The procedure DrawNet draws nets between instances. It first sets a variable exit.sub.-- point equal to the net's desired length. The net is then drawn from the entry.sub.-- point to the exit.sub.-- point, named if desired, and the signal delay information from the net is illustrated. The net information is also placed in a highlight table to provide a means of contrasting the net with the background of the screen display when the corresponding net is selected. The value of variable exit.sub.-- point is then returned to the procedure path.sub.-- context for next.sub.-- entry.sub.-- point. Each following pin is now evaluated in the for loop. Where the schematic sheet for the next instance is different, the procedure SheetBoundary is invoked.

The procedure drawInst draws instances. It is similar in operation to drawNet. The variable exit.sub.-- point is set equal to a desired width for the instance. The procedure then draws a symbol for the instance centered between the entry and exit points. Net stubs are added to the entry and exit points and label information for the instance, such as a circuit description and commercial designation, are added. This data is also stored in a highlight table for contrasting it with a background of the screen display 10. The procedure then returns the value of the variable exit.sub.-- point to the procedure path.sub.-- context as the next.sub.-- entry.sub.-- point.

In subsequent passes through the for loop in procedure path.sub.-- context, the instances, nets, and boundaries are drawn as set forth in the procedure. Invocations to the procedure drawSheetBoundary, drawInst, and drawNet continue, with the labels for each new sheet drawn in drawSheetBoundary. When the last instance is encountered in drawInst, the total path delay information is added to the path context window 16.

The procedure view.sub.-- selected.sub.-- sheet(object) is a schematic sheet generator means responsive to a selection of a portion of the displayed signal path for producing displays such as view sheet windows 34a and 34b. It creates a window in the display that contains a schematic sheet, such as 34a, with representations of the nets, instances, and pins of the design. The procedure first stores the value of the sheet identifier and the parent instance such as component 22 of the sheet into a structure called theView. It then creates a window to display the schematic sheet and saves the sheet identifier in theView. The procedure then displays the schematic sheet in the window and returns theView structure to a standard calling procedure. The calling procedure is not outlined here, since it is a standard command processing procedure, known in the art and its description would only detract from focus on the invention.

The procedure select tells the display generator 46 which object, such as a path, path portion or component, has been selected by the user for display. It maintains a list of selected objects and provides for highlighting their displayed representation(s). The procedure first adds the object to the list of objects that are currently selected. Then it enters the first of two for loops. The first loop crosses all displayed view windows and calls the procedure hilite() to highlight the displayed representation of the object in the view window. The second for loop highlights the selected path in the path context window.

The procedure hilite(), as described, causes the displayed representation of an object to stand out from the background of the screen display. There are two versions of the procedure, one for the view window and one for the path context window. They are different in implementation, but their functions are similar. The path context window version highlights the path within the path context window. It assumes that a structure is available from the window itself (the highlight table referred to in the path.sub.-- context procedure) that can return a list of graphical objects that are the displayed representation of the objects. The for loop then loops across each of the objects and changes their display. The view window version obtains its information on objects to highlight from different sources, depending upon the type of the object that is to be highlighted. If it is a net, the procedure calls the net.sub.-- object() function of theCktInfo. If it is an instance, the procedure calls the symbol() function. If it is a pin, the procedure calls the location() function.

The identify.sub.-- object procedure is used to convert a point on the display screen into a design object. This supports the selection operation that allows positioning a cursor on the displayed representation of a design object in order to select it. It also has a view window version and a path context window version. The view window version communicates with a function in theCktInfo that correlates graphical object identifiers to design objects. As described in the pseudo-code, the version determines which of the graphical objects on the sheet is closest to the point and then asks for the corresponding design object.

The path context window version works differently. The path context window is a concatenation of vertical segments as can be seen in examining the source code. The left and right x coordinates of each segment of the path context are known. The procedure includes a for loop that loops across each of the segments of the path context window 16. For each segment, an if statement tests to see if the x coordinate of the supplied point is within the boundaries of the segment. If the x coordinate is within the boundaries, then a second if statement tests to see if this is an instance segment or a net segment. If it is a net segment (the else clause of the if), the associated net is chosen as the object to return. If it is an instance segment, a further test must be done. This further test is required because an instance segment contains both a symbol for the instance and possibly two net stubs that connects its entry/exit points with the pins of the symbol. In this particular algorithm, if the x coordinate is to the left of the symbol, it will return the input net; if it is to the right of the symbol, it will return the output net; otherwise it returns the instance associated with the segment. Finally, if the for loop completes without returning anything then the NULL.sub.-- OBJECT is returned signaling that no object could be identified at the provided location.

Having illustrated and described the principles of the invention in a preferred embodiment, it should be apparent to those skilled in the art that the invention can be modified in arrangement and detail without departing from such principles. We claim all modifications coming within the spirit and scope of the following claims.