Method and apparatus for graphically presenting an integrated circuit design

[0002] The present invention relates to circuit design tools. More particularly, the present invention relates to graphical representations of circuit designs described in terms of high-level description language code.

[0003] High-level integrated circuit (IC) description languages such as VHDL and Verilog® are commonly used to design circuits. One embodiment of VHDL is described in greater detail in “IEEE Standard VHDL Language Reference Manual,” ANSI Std. 1076-1993, Published Jun. 6, 1994. One embodiment of Verilog® is described in greater detail in IEEE Standard 1364-1995. These high-level IC description languages allow a circuit designer to design and simulate circuits by using high-level code to describe the structure and/or behavior of the circuit being designed.

[0004] The high-level IC description language code is used to produce a netlist that describes an interconnection of circuit components that provide the desired functionality. The netlist can then be used to develop the layout and ultimately fabricate an integrated circuit IC having the functionality of the designed circuit. The netlist can also be used for emulation purposes.

[0005] The high-level IC description language code can be used to describe a standalone IC designs or a functional components of a larger IC design. Rather than redesigning circuits for use with new applications, existing circuit designs described in terms of high-level IC description language code can be modified. Modification of existing code can be advantageous, for example, when the existing circuit is used in a new environment or as a part of a larger IC design where inputs and/or outputs are slightly different than in the originally designed application. However, modification of code corresponding to an existing circuit design without the original circuit designer can be difficult because the code may not be well documented or may be extensive and confusing. Therefore, modification of existing circuit design code can be time consuming and difficult.

[0006] Circuit designers often communicate the structural and behavioral characteristics of circuit designs in terms of block diagrams, state diagrams and flow charts. These representations are more intuitive and are better suited to communicate the functionality of a circuit than high-level IC description language code. For at least this reason, high-level IC description language code is not effective for communicating circuit designs.

[0007] What is needed is a tool that helps decipher existing high-level IC description language code.

[0008] A method and apparatus for graphical representation of high-level IC description language code is described. The IC description language code describing an IC design is analyzed. Representation information corresponding to one or more of a block diagram of functional blocks of the IC design, a state diagram of a state machine, and a flow chart of an operational flow of the IC design is extracted from the high-level IC description language code. A graphical representation of the IC design based on the extracted representation information is generated.

[0009] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

[0010] FIG. 1 is one embodiment of a computer system suitable for use to practice the present invention.

[0011] FIG. 2 is one embodiment of a flow diagram for providing a graphical representation of a block diagram of structural blocks of an IC design based on its high-level IC description language code.

[0012] FIGS. 3a-3care one embodiment of a block diagram of a functional block of an IC design generated from its high-level IC description language code.

[0013] FIG. 4 is one embodiment of a flow diagram for providing a graphical representation of a state diagram of a state machine of an IC based on its high-level IC description language code.

[0014] FIGS. 5a-5dare one embodiment of a state diagram of a state machine of an IC design generated from its high-level IC description language code.

[0015] FIG. 6 is one embodiment of a flow diagram for providing a graphical representation of a flow chart of an operational flow of an IC design based on its high-level IC description language code.

[0016] FIGS. 7a-7bare one embodiment of a flow chart of an operational flow of an IC design generated from its high-level IC description language code.

[0017] A method and apparatus for graphical representation of high-level IC description language code is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the present invention.

[0018] Briefly, the present invention analyzes high-level IC description language code, such as VHDL and Verilog®, of an integrated circuit (IC) design and generates graphical representations of the IC design based on the code analyzed. The graphical representations can include one or more of the following: 1) a block diagram of functional blocks; 2) a state diagram of a state machine; and 3) a flow chart of an operation al flow of the IC. Graphical representations provide more understandable representations of circuits described by the high-level IC description language code than the code itself. Because high-level IC description language code can be difficult to decipher by one other than the creator of the code, graphical representations, whether structural or behavioral, provide for easier modification of the code than would otherwise be possible.

[0019] FIG. 1 is one embodiment of a computer system suitable for use to practice the present invention. Computer system 100 includes bus 101 or other communication means for communicating information, and processor 102 coupled with bus 101 for processing information. Computer system 100 further includes random access memory (RAM) or other dynamic storage device 104 (referred to as main memory), coupled to bus 101 for storing information and instructions to be executed by processor 102. Main memory 104 also can be used for storing temporary variables or other intermediate information during execution of instructions by processor 102. Computer system 100 also includes read only memory (ROM) and/or other static storage device 106 coupled to bus 101 for storing static information and instructions for processor 102. Data storage device 107 is coupled to bus 101 for storing information and instructions.

[0020] Data storage device 107 such as a magnetic disk or optical disc and corresponding drive can be coupled to computer system 100. Computer system 100 can also be coupled via bus 101 to display device 121, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. Alphanumeric input device 122, including alphanumeric and other keys, is typically coupled to bus 101 for communicating information and command selections to processor 102. Another type of user input device is cursor control 123, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 102 and for controlling cursor movement on display 121.

[0021] One embodiment of the present invention is related to the use of computer system 100 to provide graphical representation of an IC design based on its high-level IC description language code. According to one embodiment, graphical representation is provided by computer system 100 in response to processor 102 executing sequences of instructions contained in memory 104. Instructions are provided to main memory 104 from a storage device, such as magnetic disk, CD-ROM, DVD, via a remote connection (e.g., over a network), etc. In alternative embodiments, hard-wired circuitry can be used in place of or in combination with software instructions to implement the present invention. Thus, the present invention is not limited to any specific combination of hardware circuitry and software instructions.

[0022] Overview Of Block Diagram Extraction

[0023] FIG. 2 is one embodiment of a flow diagram for providing a graphical representation of a block diagram of structural blocks of an IC design based on its high-level IC description language code. The block diagram provides a structural model of the circuit described by the high-level IC description language code. In the following description, analysis of code is described with respect to VHDL code; however any high-level IC description language can be used. In one embodiment, Verilog® code is converted to VHDL code prior to analysis and extraction of a block diagram.

[0024] In VHDL, “entity” statements describe components that can be represented as blocks in a block diagram. Inputs and outputs related to entities are described as “ports”. In one embodiment, the present invention identifies “architecture” statements that contain instances of “entity” statements or a “structural architecture.” For example

[0025] entity cpu_interface is

[0026] port( . . . );

[0027] end entity cu_interface;

[0028] architecture struct of cpu_interface is

[0029] . . .

[0030] components declarations corresponding to instanced entities

[0031] component register

[0032] port( . . . );

[0033] . . .

[0034] component instantiations corresponding to instances and wires

[0035] I0: register

[0036] port map (do=>clk, . . . );

[0037] I1: register

[0038] port map (d0=>sig, . . . );

[0039] end struct;

[0040] Architectures can be hierarchical in that an individual architecture statement can include one or more subsystems described as one or more architectures. High-level IC description languages other than VHDL are analyzed in a similar manner for equivalent statements that describe structural relationships.

[0041] The VHDL code is analyzed and structural groupings that can be represented as blocks in a block diagram are determined, 210. In one embodiment, blocks can have hierarchical relationships. For example, a block in a high-level block diagram can further include one or more sub-blocks. The sub-blocks and the inter-relationship between the sub-blocks can be shown, for example, when a user clicks a high-level block. Of course, other embodiments for describing a hierarchical relationship can also be used.

[0042] Because graphical representation of a block diagram is a logical description rather than a physical description or physical layout of components, space optimization is not important. This allows blocks to be placed within the graphical representation in a manner that allows optimal space utilization. In one embodiment, a structural relationship having 5-10 blocks is assumed; however, any number of blocks can be used. The present invention is not limited to use with code that can be represented by a small number of blocks.

[0043] In one embodiment, placement of blocks is a logically distinct operation from routing of connections between blocks. This allows placement of blocks without routing of connections between blocks. In one embodiment, the general flow of connections between blocks is from left to right with inputs on the left side of blocks and outputs on the right side of the blocks. Of course, other flows, for example, right to left, top to bottom, etc. can also be used. In order to provide left to right flow in the block diagram, placement and routing as described below can be used.

[0044] Placement of blocks is performed based on the block information extracted in the high-level IC description language, 220. In one embodiment, each block is assigned a “mass” that is based on inputs to the block that are outputs from other blocks. The outputs of each block are not used in determining the mass of the block.

[0045] The blocks are placed in columns based on the mass assigned to each block. In one embodiment, blocks with the least mass are placed in the left-most column and columns are progressively filled from left to right with each column having blocks with a higher mass than the column to the immediate left until each block is placed in a column. The result is one or more columns each of which contains blocks having equal mass.

[0046] In one embodiment, placement of blocks is accomplished according to the following pseudocode:

[0047] set all unplaced block masses to 0; //blocks have 0 mass and are unplaced

[0048] while(unplaced blocks exist){

[0049] for (all unplaced blocks){

[0050] increment block mass by 1 for each input from another unplaced

[0051] block; //determine mass for a block

[0052] }

[0053] identify block(s) of lowest mass as a column;

[0054] remove column from unplaced block set;

[0055] }

[0056] END

[0057] In other words, blocks are assigned a mass based on input from other blocks and the blocks with the lowest mass are placed in a column. Masses are recalculated as columns are removed, until there are no blocks not placed in a column.

[0058] Channels are used to route connections between blocks, 230. As used herein, a channel refers to the graphical spacing sufficient to show a connection (e.g., wire). In one embodiment, vertical channels between blocks are allocated such that each wire connecting two particular blocks has a vertical channel and at least two horizontal channels between the blocks and the vertical channel. In one embodiment, blocks are placed horizontally such that no more than one block occupies a horizontal channel. The horizontal placement allows channels above and below each block as well as output lines to each block as necessary.

[0059] In one embodiment the number of connections between blocks is used to determine the placement of the blocks relative to each other. For example, one vertical channel per output from the first column, plus one vertical channel per input of the second column plus enough extra space to make connections visually distinct is provided.

[0060] By providing both horizontal and vertical channels for wires, routing of wires can be accomplished without segments of wires overlapping. Wires may intersect at single points, but no wire segments are co-incident at multiple consecutive points. Routing is complicated by the presence of rippers, which are points at which the second wire branches off of the first wire. In order to handle rippers properly, additional vertical channels are allocated for each ripper.

[0061] In one embodiment, routing of wires is accomplished in two phases. One phase routes wires that flow forward through the block diagram (e.g., left to right). The second phase routes wires that provide feedback (e.g., right to left). It is important to note that the order of the phases is not important.

[0062] In one embodiment, when routing wires in a forward direction, routing starts at the bottom of the diagram. If a wire end is farther down the block diagram than the start of the wire, two route points are set in the first available vertical channel to the right of the start of the wire. A connection is then routed from the output of the first block to the first route point to the second route point to the input of the second block.

[0063] When routing feedback wires, routing starts at the top of the block diagram. If a wire end is farther up than the start of the wire and the wire has not been routed, two route points are set occupying the next available vertical channel to the right of the start of the wire. A connection is then routed from the output of the first block to the first route point to the second route point to the input of the second block.

[0064] After blocks have been placed and connections have been routed, ports and incidental information are placed, 240. Ports indicate input to and output from the circuit design. Incidental information includes declarations included in the code, signal names, etc.

[0065] FIGS. 3a-3care one embodiment of a block diagram of a functional block of an IC design generated from its high-level IC description language code. More specifically, FIG. 3ais one embodiment of blocks placed in block diagram 300 according to the present invention. The example of FIG. 3aplaces four blocks in three columns; however, any number of blocks in any number of columns can be supported.

[0066] In the example of FIG. 3a, block 320 has five inputs with no inputs from other blocks, blocks 330 and 340 have four inputs with two inputs from other blocks and block 350 has three inputs all of which come from other blocks. For simplicity of explination, the source of an input to a block is not shown in FIG. 3a.

[0067] In one embodiment, because block 320 has the smallest number of inputs from other blocks of the blocks being placed, block 320 is placed in the first column (labeled 302). In one embodiment, the blocks are placed starting at the top of the column and proceeding downward such that each subsequently placed block is below the previously placed block(s); however, other types of placement, such as bottom to top placement can also be used.

[0068] Blocks 330 and 340, having four inputs two from other blocks, are placed in the second column (labeled 304) and below block 320. Placing blocks below other blocks in previous columns provides horizontal channels for routing of connections between blocks, if necessary. Blocks 330 and 340 are placed in the same column because blocks 330 and 340 have the same number of inputs (the same mass). Block 340 is shown vertically below block 330; however, block 330 can be placed below block 340.

[0069] Block 350 is placed in the third column (labeled 306) below blocks 330 and 340. Block 350 has three inputs from other blocks and therefore has greatest mass of the blocks in block diagram 300. The block with the least mass is placed in the left-most column so that the inputs from input ports (not shown in FIG. 3a) have connections that travel the shortest distance and thereby simplify block diagram 300.

[0070] FIG. 3bis one embodiment of the block diagram of FIG. 3ahaving connections between blocks routed according to the present invention. In one embodiment, routing points are placed in block diagram prior to connections being drawn between blocks. The description of FIG. 3bdoes not include a description of all routing points for block diagram in order to simplify description of routing according to the present invention.

[0071] Input ports 322 provide input signals to block 320, input ports 332 provide input signals to block 330. Input ports 342 provides input signals to block 340. Output ports 324 receive output signals from block 320, output ports 334 receive output signals from block 330 and output port 344 receives output signals from block 340.

[0072] Routing points 380 and 382 describe a connection between block 320 and block 330. In one embodiment, block diagram in divided into multiple horizontal channels and multiple vertical channels. To describe a simple connection between an output of block 320 and an input of block 330, routing point 380 is placed in the same horizontal channel as the output of block 320 that is being routed. Routing point 380 defines the vertical channel that is used to route the output of block 320. In one embodiment, the first vertical channel that allows a signal name (not shown in FIG. 3b) to be associated with the horizontal portion of the connection is used.

[0073] Routing point 382 defines the horizontal channel between the vertical channel defined by routing points 380 and 382 and the corresponding input to block 330. Similarly, routing points 370 and 372 define a connection between an output of block 320 and an input of block 340.

[0074] Routing points 360 and 364 define connections between an input port and blocks 320, 330 and 340. Connection point 360 defines a “ripper.” A ripper is a point at which a single connection is split into multiple connections. Similarly routing point 362 defines a ripper.

[0075] Routing points 390, 392, 394 and 396 define a feedback loop from the output of block 350 to the input of block 340. In one embodiment, the feedback lines use horizontal channels above the blocks to which feedback is being provided. Alternatively, horizontal channels below the blocks can be used.

[0076] FIG. 3cis one embodiment of the block diagram of FIG. 3bwith the addition of declaration and signal definition fields. In one embodiment, declaration field 398 contains variable declarations from the high-level IC description language code. For example, declaration field 398 can include “FOR ALL” statements. Similarly, signal definition field 399 contains signal types. For example, a clock signal can be defined as a standard logic element. In one embodiment, fields 398 and 399 are placed in a margin of block diagram 300. For example, the top and left margins can be used for fields 398 and 399. Alternatively, the bottom margin can be used for fields 398 and 399. Of course, additional fields can also be provided.

[0077] Overview Of State Diagram Extraction

[0078] FIG. 4 is one embodiment of a flow diagram for providing a graphical representation of a state diagram of a state machine of an IC based on its high-level IC description language code. In one embodiment, the present invention provides the graphical description of the state machine described in the high-level IC description language in the form of the state diagram. Extraction of the state machine can be accomplished as described in U.S. patent application Ser. No. 09/140,633 filed Aug. 26, 1998, entitled “RECOGNITION OF A STATE MACHINE IN A HIGH-LEVEL DESCRIPTION LANGUAGE,” which is assigned to the corporate assignee of the present invention and hereby incorporated by reference.

[0079] The high-level IC description language code describing state machine to is analyzed to determine the number of states, 410. In one embodiment, the state diagram is generally circular with evenly spaced states; however, other layouts can also be used. Based on the number of states and the size of the circle to be used the spacing between states is determined, 420.

[0080] In one embodiment, the start or initial state is placed at the top of the state diagram, 430. If a reset condition is included in the state machine, a reset loop can be attached to the start state; however, a reset condition is not necessary. The remaining states are placed around the circle in an appropriate order, 440.

[0081] In one embodiment, this state that logically follows the start state is placed to the right of the start state such that the states flow in a clockwise manner. Of course, a counter-clockwise or non-circular state layout can also be used. In many state machines states proceed sequentially for all or most of the state machine operation. When only a single state follows the start state, that state is placed adjacent to the start state. Placement of states continues in a similar manner.

[0082] After the states have been placed, arcs representing state transitions are routed, 450. In one embodiment, arcs that connect sequential states are routed on the outside of the circle on which the states are placed. Arcs that describe a feedback operation or that skip states are routed on the inside of the circle. Alternatively, sequential transitions can be routed on the inside and circle and other transitions can be routed on the outside of the circle.

[0083] FIGS. 5a-5dare one embodiment of a state diagram of a state machine of an IC design generated from its high-level IC description language code. More specifically, FIG. 5ais one embodiment of a generally circular layout of a state diagram according to the present invention. The dotted line describes the circular nature of state diagram 500 and is not necessarily included in state diagram 500.

[0084] State 510 is the starting state for state diagram 500. In one embodiment, state 510 is placed at the top of state diagram 500. Alternatively, state 510 can be placed in a location other than at the top of state diagram 500.

[0085] FIG. 5bis one embodiment of state diagram 500 having states placed in a generally circular manner. In one embodiment, states are placed such that transitions occur in a clockwise manner starting from start state 510 at the top of state diagram 500. For example, state 520 follows state 510 during normal operation of the corresponding state machine. States 530, 540 and 550 are placed in a similar manner. In one embodiment, the states of state diagram 500 are placed equidistant from each other; however, other placement schemes can also be used. It is important to note that the state diagram as generated by the present invention is not limited to any particular number of states.

[0086] FIG. 5cis one embodiment of state diagram 500 having transition arcs routed between states. In one embodiment, transition arcs between adjacent states are routed outside of the state diagram circle. State transitions between non-adjacent states are routed inside of the state diagram circle. Of course, other routing schemes can also be used.

[0087] Arc 511 indicates a reset condition that causes the associated state machine to remain in state 510. Reset conditions are known in the art and not discussed in any greater detail except as it pertains the present invention. Reset conditions are optional and not required for all state machines. Arc 513 indicates a transition from state 510 to state 520 and is routed outside of the state circle.

[0088] Arc 521 indicates that a condition exists that causes the state machine to remain in state 520 during the existence of the condition. Arc 525 indicates a transition between state 520 and state 550. Because arc 525 indicates a transition between non-adjacent states, arc 525 is routed inside the state diagram circle. Arcs 523, 531, 541 and 551 indicate transitions between adjacent states and are routed outside of the state diagram circle.

[0089] FIG. 5dis one embodiment of state diagram 500 with condition and other labels according to the present invention. State diagram 500 includes condition labels 512, 514, 522, 524, 526, 532, 542 and 552 that describe the conditions that cause the state transitions indicated by the respective associated arcs.

[0090] Text field 590 provides various textual descriptions associated with state diagram 500. For example, text field 590 can include package lists, global actions, concurrent statement, declarations and signal status statements.

[0091] Overview Of Flow Chart Extraction

[0092] FIG. 6 is one embodiment of a flow diagram for providing a graphical representation of a flow chart of an operational flow of an IC design based on its high-level IC description language code. In one embodiment, the present invention provides graphical description of the flow chart and describing high-level IC description language code. Typically, the high-level IC description language code is used to build an abstract syntax tree in a programming language such as C or C++.

[0093] The tree contains objects which represent VHDL Processes or Verilog Initial/Always statements. The syntax tree can be recursive in that objects can contain other objects. In one embodiment, the present invention uses Architecture and Module declarations and Concurrent statements and associated Process statements to generate the flow chart corresponding to the VHDL code.

[0094] Boxes are created that correspond to each high-level discussion language statement, 620. For example, action boxes, decision boxes, wait boxes can be used to represent high-level IC description language statements.

[0095] The boxes are then placed in a logical manner that represents the high-level IC description language code to a user, 630. In one embodiment of flow chart direction is top-down. Further, decision boxes are laid out so that the true branch starts at the bottom and the false branch is to the right of the score corresponding decision box. This is known as “top-down asymmetric” placement.

[0096] In one embodiment, placement starts with the start box. Each high-level IC description language code segment contains one start box. The start box is placed in the top of the flow diagram at a predetermined location. The next box in the flow chart is placed below the start box with the centers vertically aligned. Placement of boxes continues to similar manner.

[0097] Placement of boxes is asymmetric because action boxes decision boxes etc. are vertically aligned by their centers and true branches of decision boxes are similarly vertically aligned. False branches are placed to the right of the main flow. Before placing boxes the maximum width of each box is determined. Maximum width allows boxes to be placed without overlap, which can lead to a confusing flow chart. Maximum width is determined for each boxes in a branch prior to placement of the branch.

[0098] After the boxes have been placed, connections between the boxes are routed, 640. In one embodiment, connections consist of arrows showing the flow between boxes. Connections representing feedback loops are placed to the left of the boxes in the loop connecting the last box in the loop to the first box in loop. After notes have been placed and connections have been routed, any related text not included in boxes is placed on the flow chart, 650.

[0099] FIGS. 7a-7bare one embodiment of a flow chart of an operational flow of an IC design generated from its high-level IC description language code. In one embodiment, all flow chart boxes are generated prior to placement of the boxes. During the box generation process, boxes are placed in a common location so that the boxes visually appear to overlap until placed.

[0100] FIG. 7ais one embodiment of flow chart boxes placed according to the present invention. In one embodiment, boxes are placed starting with start box 700 at the top of the flow diagram. The next box in flow chart 790 is placed vertically below start box 700 with the centers of the two boxes vertically aligned. In the example of FIG. 7a, a decision box labeled 710 is placed below start box 700; however, any type of flow diagram box can be used to follow start box 700.

[0101] Because box 710 is a decision box, the flow of flow chart 790 branches at decision box 710. In one embodiment, true branches are placed vertically below the corresponding decision box and false branches are placed to the left of the corresponding decision box. In the example of FIG. 7a, box 720 is the true branch corresponding to decision box 710 and box 730 is the false branch corresponding to decision box 710. Boxes 735, 740, 750, 760 and 770 are placed in a similar manner.

[0102] In one embodiment, in order to provide placement of boxes such that boxes do not overlap, a maximum width is determined for each column of boxes. The width of each box is determined based on the text and other representations associated with the box. The width for the widest box in each column is the maximum width of the column. Columns of boxes are placed such that the maximum width of each column does not overlap the maximum width of an adjacent column.

[0103] FIG. 7bis one embodiment of flow chart 790 having flow connectors. The flow connectors indicate a flow through flow chart 790 in the manner described above. Flow indicators for loops are placed to the left of the boxes in the loop. For example, boxes 735, 740 and 750 comprises a loop in the example of FIG. 7b. Thus, the flow indicator from box 750 to box 735 is placed to the left of boxes 735, 740 and 750.

[0104] After boxes have been placed and flow indicators routed, textual descriptions (not shown in FIG. 7b) are placed in flow chart 790. For example, the actions of each box of flow chart 790 can be included within each box. Also, true and false indicators can be placed with each branch from a decision box. Other text, such as architecture declarations, concurrent statements, sensitivity lists and process declarations can be placed on flow chart 790 so as not to overlap the boxes of flow chart 790.

[0105] In the foregoing specification, the present invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.