US5937190A - Architecture and methods for a hardware description language source level analysis and debugging system - Google Patents

Architecture and methods for a hardware description language source level analysis and debugging system Download PDF

Info

Publication number
US5937190A
US5937190A US08/417,147 US41714795A US5937190A US 5937190 A US5937190 A US 5937190A US 41714795 A US41714795 A US 41714795A US 5937190 A US5937190 A US 5937190A
Authority
US
United States
Prior art keywords
circuit
parse
computer
text
text description
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
US08/417,147
Other languages
English (en)
Inventor
Brent Gregory
Trinanjan Chatterjee
Jing C. Lin
Srinivas Raghvendra
Emil Girczyc
Paul Estrada
Andrew Seawright
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Synopsys Inc
Original Assignee
Synopsys Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/253,470 external-priority patent/US6132109A/en
Application filed by Synopsys Inc filed Critical Synopsys Inc
Priority to US08/417,147 priority Critical patent/US5937190A/en
Priority to JP7526539A priority patent/JPH09512115A/ja
Priority to EP95916412A priority patent/EP0755544A1/fr
Priority to CA002185908A priority patent/CA2185908A1/fr
Priority to AU22920/95A priority patent/AU2292095A/en
Priority to PCT/US1995/004660 priority patent/WO1995027948A1/fr
Assigned to SYNOPSYS, INC. reassignment SYNOPSYS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GREGORY, BRENT, GRICZYC, EMIL, LIN, JING C., RAGHVENDRA, SRINIVAS, CHATTERJEE, TRINANJAN, ESTRADA, PAUL, SEAWRIGHT, ANDREW
Assigned to SYNOPSYS, INC. reassignment SYNOPSYS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GREGORY, BRENT, GRICZYC, EMIL, LIN, JING C., RAGHVENDRA, SRINIVAS, CHATTERJEE, TRINANJAN, ESTRADA, PAUL, SEAWRIGHT, ANDREW
Publication of US5937190A publication Critical patent/US5937190A/en
Application granted granted Critical
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G06F30/3308—Design verification, e.g. functional simulation or model checking using simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/323—Translation or migration, e.g. logic to logic, hardware description language [HDL] translation or netlist translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2119/00—Details relating to the type or aim of the analysis or the optimisation
    • G06F2119/06—Power analysis or power optimisation

Definitions

  • This invention relates to the field of computer aided design for digital circuits, and particularly to analyzing and debugging digital circuits constructed from HDL source text using logic or behavioral synthesis.
  • a digital circuit designer needs to ensure that the digital circuit performs the correct function subject to many design constraints. For example, the digital circuit should perform the correct computation in the proper amount of time. The area that the digital circuit occupies on a semiconductor die should remain within certain bounds. The power that the digital circuit consumes while operating should also remain within specified bounds. To be economically manufacturable, the digital circuit should be testable. An economically useful digital circuit should not take too long to design, manufacture, test or use.
  • the digital circuit design process typically involves translating the designer's sometimes incipient thoughts about the function and constraints into the tooling necessary to produce a working digital circuit. For example, producing a full-custom semiconductor chip requires producing masks that define the deposition of chemicals into a substrate as well as producing test patterns that exercise the final product. As another example of tooling, producing a field programmable gate array requires generating the bit pattern to be downloaded into the chip to specify the configuration of the architecture.
  • Computer Aided Design (CAD) tools facilitate the iterative translation of the designer's developing thoughts into the tooling required to produce a working digital circuit that satisfies the design constraints.
  • debugging The process of iteratively adjusting a design to meet its constraints is called debugging.
  • the process of identifying various properties of different parts of a digital circuit is called analysis. In order to debug a digital circuit, the designer must first analyze the circuit to ascertain where problems occur.
  • the typical historical model of the digital design process using conventional CAD tools for a semiconductor chip is as follows. The designer first conceives of a particular function to implement, as well as constraints such as timing or area that the implementation must meet. Next, historically, the designer mentally transforms the desired function into a high level generic technology circuit consisting of components such as gates, adders, registers and RAMs.
  • mapping creates a mapped circuit.
  • the mapped circuit includes parts from a software representation of a specific technology library which is supplied by a silicon vendor.
  • the schematic shows how more primitive functional elements, such as gates or transistors, connect together to form more sophisticated functions such as arithmetic logic units.
  • modern schematic capture tools allow the designer to divide the design hierarchically into interconnected pieces, and then allow the user to specify the details of each of the pieces separately. For example, Design Architect by Mentor Graphics of Wilsonville, Oreg. provides these schematic capture functions.
  • CAD tools such as those indicated above, can then take the connections in the schematic and other information to evaluate the mapped circuit and to specify the tooling necessary to construct the circuit.
  • Such tools evaluate the mapped circuit in many ways.
  • commercial CAD tools often have a simulator that predicts the response of the mapped circuit to designer specified input patterns.
  • QuickSim II by Mentor Graphics of Wilsonville, Oreg. is a commonly used simulator.
  • Another common CAD tool is a path delay analyzer that identifies the longest timing path in a mapped circuit design. DesignTime by Synopsys, Inc. of Mountain View, Calif. is a tool that provides path delay analysis.
  • the concept of analyzing a mapped circuit design historically refers to the process by which a digital circuit designer specified a particular implementation with a schematic capture tool, and then used various circuit evaluation tools to verify that the implementation did what the digital circuit designer wanted. For example, the designer would use a simulator to determine if the mapped circuit produced appropriate outputs from specified inputs. The designer could use the path delay analyzer to determine whether the current design was fast enough to meet the timing constraints. The layout tools could inform the designer whether the design meets the area constraints.
  • the designer When a particular design did not meet the designer's constraints, the designer then modified the design. For example, if the mapped circuit was too slow, the designer identified the part of the mapped circuit that was too slow, and revised it to increase performance. If the mapped circuit was too large, then the designer revised the mapped circuit to use fewer or smaller components. If the mapped circuit did not behave as required, the designer changed the components and the interconnections to produce the correct function. Because the conventional CAD tools began the analysis with the mapped circuit, the timing or area problems could be readily identified to the designer. Because the designer specified the structure of the mapped circuit, the designer could thoughtfully make adjustments. However, the CAD tools were limited in their ability to identify functional problems because the designer had mentally performed the transformation from desired function to mapped circuit. In other words the CAD tools included structural information about the digital circuit, but did not include data concerning the high level functionality of the digital circuit.
  • Logic synthesis was developed to provide the designer with an automatic mechanism to translate a hardware description language (HDL) description of a desired function to a structural description of a digital circuit that performed the desired function.
  • HDL hardware description language
  • Logic synthesis begins with the designer describing the desired function using VHDL, Verilog, or any other logic synthesis source language, to specify the behavior. This allows the designer to specify the digital circuit at a higher level, and allows the CAD tools to assist the designer in defining the functionality of the digital circuit.
  • a software translator then converts that description into generic technology structures that directly correspond statement by statement with the designer's description.
  • mapping replaces the generic technology structures with structures from a specific technology library.
  • Technology libraries are provided by silicon vendors to specify the types of parts which the vendor can manufacture.
  • Technology libraries include specific information regarding the functionality and physical characteristics such as area and delay of gates which can be built by the silicon vendor.
  • Technology libraries are designed to work with synthesis systems. A synthesis system can use a technology library to choose available gates from which the silicon vendor can fabricate the digital circuit.
  • the transformations performed by the logic optimizer usually modify the structure that was present in the pre-optimization circuit. This results in a mapped circuit that is not easily recognized by the designer.
  • the fact that the designer generally can not readily recognize the original function performed by the mapped circuit makes analyzing optimized mapped circuits difficult.
  • Conventional evaluation tools can determine the timing or area problems in the mapped circuit, but the designer often can not relate those problems easily to the HDL source specification. Theoretically, the designer could manually determine what part of the HDL specification caused the problem. With that insight, the designer could make the desired changes at the HDL specification, and resynthesize the entire digital circuit. If the designer's problem occurred in a part of the mapped circuit that passed through the optimizer with few changes, manual backtracking might work. However, the optimization process generally makes many changes, making it either difficult or impossible to backtrack because many points in the original generic technology circuit do not exist in the mapped circuit.
  • the designer can directly modify the mapped circuit produced by the synthesis software. However, this does not allow the designer to resynthesize the design from the HDL specification because the designer's logic changes is overwritten by subsequent translation and optimization steps. This reduces the value gained by using the synthesis approach to design.
  • Source to Gates allowed the designer to trace between HDL source and schematics.
  • Source to Gates did not prove useful because its ability to trace post synthesis mapped structures to the HDL source was limited to optimization invariant circuit structures that were present in the HDL source.
  • Source to Gates did allow the designer to trace between schematics of the generic technology circuit and the HDL source, this feature was not particularly useful because it required viewing of the generic technology circuit which was not directly meaningful to the designer and no analysis link to the source was provided.
  • Source to Gates stores text location in terms of row and column numbers. Thus, when tracing from a schematic to HDL text, Source to Gates only hilights the first character of the appropriate parse node. There is no indication of the range of the parse node.
  • Exact match mode forces the user to place the cursor on the first character of a parse node in order to enable tracing to the schematic. Closest match mode searches forwards and backwards in the text to find the closest traceable character. In this mode, the user does not know exactly what will be traced.
  • Another method for minimizing the backtracking problem in the analysis of an optimized mapped circuit is to partition the design into hierarchical components, and translate and optimize the smaller pieces. Because the translation and optimization tools generally do not traverse primary inputs and outputs, the HDL description can be correlated with a particular resulting mapped sub-circuit, thus reducing the size of the backtracking problem.
  • repartitioning has the disadvantage that the designer may have to rewrite functionally correct, but nonetheless problematic, HDL source code to isolate the troublesome parts of the mapped circuit.
  • this approach will greatly limit the optimizer's ability to reduce the area and increase the speed of the resulting circuits because the optimizer will be constrained by the designer's partition.
  • FIG. 1 shows an overview of the conventional process for designing, analyzing, and debugging digital circuits specified with a Hardware Description Language (HDL).
  • HDL Hardware Description Language
  • the process begins with the designer writing HDL source code 100.
  • a typical language used for specifying digital circuits is VHDL which is described in the IEEE Standard VHDL Language Reference Manual available from the Institute of Electrical and Electronic Engineers in Piscataway, N.J., which is hereby incorporated by reference.
  • VHDL stands for Very high speed integrated circuit Hardware Description Language.
  • Verilog is described in Hardware Modeling with Verilog HDL by Eliezer Sternheim, Rajvir Singh, and Yatin Trivedi, published by Automata Publishing Company, Palo Alto, Calif., 1990, which is hereby incorporated by reference.
  • Verilog is also described in the Verilog Hardware Description Language Reference Manual (LRM), version 1.0, November 1991, which is published by Open Verilog International, and is hereby incorporated by reference.
  • LRM Verilog Hardware Description Language Reference Manual
  • the examples used in this document are in VHDL, but the principles readily apply to other circuit specification languages.
  • the designer After writing a HDL description of a desired function, the designer then simulates the function 101 embedded in the description with a HDL simulator.
  • a functional simulator is VHDL System Simulator that is available from Synopsys, Inc. of Mountain View, Calif.
  • the functional simulator allows the designer to determine whether the circuit produces correct values in response to inputs without regard to timing, area or power constraints.
  • a functional simulator can perform function-only simulation relatively quickly, thus enabling the designer to determine that the circuit will produce the desired output.
  • the designer If the designer believes that the digital circuit described by the HDL source provides the correct function, the designer specifies constraints for the synthesis process 103, e.g. maximum clocking periods, total circuit area, and maximum power. This part of the process is described in Design Compiler Family Reference Manual, Version 3.1a, which is available from Synopsys, Inc. of Mountain View, Calif. and is hereby incorporated by reference. Examples of Computer Aided Design software that use constraint specification are Synergy by Cadence, and Autologic by Mentor Graphics, and Design Compiler by Synopsys.
  • the designer then proceeds to synthesize 104 a mapped circuit from the HDL description produced in the writing HDL 100 step.
  • This step involves translating the HDL source description into an initial generic technology circuit that corresponds directly with the statements in the source HDL.
  • An example of software that performs this function is described in the VHDL Compiler Reference Manual, Version 3.1a, which is available from Synopsys, and is hereby incorporated by reference.
  • the initial generic technology circuit is then optimized into a mapped circuit that meets the performance constraints established in step 103. Prior to optimization, it is a straight-forward task to identify which element of the initial generic technology circuit corresponds to what part of the HDL source code. Conventionally, because of the extensive manipulations performed during the optimization process, such identification after optimization becomes almost impossible except at registers and module interface boundaries.
  • FIG. 2 shows the intermediate data structures involved in the synthesis process 104.
  • the synthesis process begins with HDL source 900.
  • the translator creates a data structure called a parse tree 901 that represents the organizational structure of the HDL.
  • the translator then turns the parse tree into an initial generic technology circuit 902.
  • U.S. patent application 07/632,439 filed on Dec.
  • An optimizer is used to produce the mapped circuit 903 from the initial generic technology circuit 902.
  • the optimization process is explained in "Logic Synthesis Through Local Transformations” by J. Darringer, W. Joyner, L. Berman, and L. Trevillyan in the IBM Journal of Research and Development, volume 25, number 4, July 1981, pages 272-280, which is hereby incorporated by reference. It is also explained in “LSS: A System for Production Logic Synthesis” by J. Darringer, D. Brand, J. Gerbi, W. Joyner, and L. Trevillyan in the IBM Journal of Research and Development, volume 28, number 5, September 1984, pages 537-545, which is hereby incorporated by reference. It is also explained in “MIS: A Multiple-Level Logic Optimization System” by R.
  • One approach to optimization is to group one or more logic elements together, and replace those elements with a functionally equivalent collection of elements that has better characteristics than the collection of elements replaced. This results in an intermediate circuit that is functionally equivalent to the original. This intermediate circuit can then have some or all of its elements grouped for another replacement.
  • the process can be performed on either generic technology or mapped logic circuits. The process is repeated until the optimizer meets the constraints imposed in step 103 of FIG. 1, or is unable to make any further improvement.
  • the components of the initial generic technology circuit fall into two groups: those components that must be preserved through the optimization process, and those that can be replaced with functional equivalents.
  • a logic optimizer may replace a block of boolean logic with another block so long as function is maintained.
  • the designer can then analyze the mapped circuit 105 using conventional analysis tools, as shown in FIG. 1. For example, the designer could estimate the area that the mapped circuit consumes or what the longest delay path is in the mapped circuit. This analysis can identify problems to the designer.
  • the analysis report 904 is often a text document, as shown in FIG. 1.
  • the designer After identifying timing, area, testing or power problems with the analysis tools, the designer then adjusts the mapped circuit to fix these problems 108. Ideally, the designer goes back to the HDL where the function is specified and make adjustments there. However, because it is currently hard to identify the specific places in the source HDL that led to the problem, modifying the appropriate part of the HDL is currently not an effective debugging technique. The designer can usually identify which hierarchical module contains some of the problem. The designer can then manually rewrite that module to create more primary inputs and outputs to examine. This is very time consuming and is generally done as a last resort. A method for automatically adding additional primary inputs and outputs is needed to make this approach practical. Alternatively, the designer could adjust the constraints 103 and synthesize the mapped circuit 104 again to see if the problem is alleviated.
  • analyzing a digital circuit involves having the designer repeatedly (1) determine a particular characteristic or property that the designer wants to know about, such as area, timing or power, (2) identify a kind of analysis that will provide information about that characteristic, (3) instruct the CAD system to perform that analysis, (4) display the results of that analysis, and (5) gain insight into the desired characteristic from the display. The designer is interested in completing these steps as quickly as possible.
  • Digital circuit CAD tools have historically facilitated this goal by making the instruction and display steps computationally efficient. To improve response times, digital circuit CAD tools have often tightly coupled the software that performed the analysis to the software that performed the display function. This was often done by having the display software depend heavily on the data structure used to process or store the results of the analysis.
  • timing analysis often reveals the portions of the mapped circuit that are too slow. Reviewing this analysis historically has involved examining the schematic and tracing the critical path. However, as described previously, the schematic may have little to do with the designer's HDL source specification of the digital circuit. Thus, the conventional analysis method does not relate the mapped circuit problem to its HDL source. Therefore, it is not easy for the designer to know what HDL to change to meet the design constraints.
  • HDL synthesis can simplify the task of digital circuit design by allowing the designer to specify the required function in an HDL textual description without specifying the details of the mapped circuit implementation.
  • the designer can use conventional mapped circuit analysis tools to determine characteristics of the mapped circuit. Conventional analysis will describe such things as the area consumed by different parts of the mapped circuit, or what the longest delay path is through the circuit. Using these analysis results, the designer can then identify which portions of the mapped circuit are problematic. However, because the optimization portion of synthesis often transforms the design substantially, it is difficult, if not impossible, except in certain special cases, to relate specific portions of the mapped circuit to the HDL source that generated those portions. This inability to trace the mapped circuit analysis results easily to the HDL source represents a substantial barrier for analyzing circuits efficiently. Thus, there has been a need for a system which allows the designer to analyze a digital circuit design in terms of the source HDL.
  • An aspect of the present invention provides a method for displaying the results of synthesized circuit analysis visually near the HDL source specification that generated the circuit.
  • Circuit analysis provides information about the characteristics of each portion of the synthesized circuit.
  • An aspect of the present invention relates the analysis results of each portion of the synthesized circuit to the particular part of the HDL specification that generated that circuit portion. This permits the designer to modify the part of the HDL specification that is responsible for problems identified by circuit analysis.
  • the synthesis process works by translating HDL source code into an initial circuit. Each point in the initial circuit corresponds directly with a particular construct in the HDL source. A final, more efficient circuit is constructed from the initial circuit by logic optimization. Connecting the results of the analysis to the source requires identifying points in the final circuit that be traced directly to the initial circuit. Circuit analysis results corresponding to these invariant points in the circuit can therefore be directly related to the appropriate part of the HDL source, and thus can be displayed near that part.
  • Another aspect of the present invention provides a method for introducing additional points in the design that remain traceable through the optimization process without requiring reorganization or modification of the HDL source.
  • the present invention provides these additional points, for example, by artificially injecting primary inputs or outputs into the initial circuit, and noting where in the HDL source these points came from.
  • the present invention provides a method for linking information gleaned from evaluating and analyzing a synthesized circuit to the source code that produced the circuit.
  • the present invention establishes the link by providing a designer with the ability to mark the synthesis source code in the places that the designer wants to be able to debug.
  • the designer marks the source code with a particular text phrase, such as "probe", along with some additional optional information.
  • the translator generates a circuit the provides the same function as it did without the "probe" statement, but adds additional information or components to the initial circuit that indicate that certain components should not be replaced during optimization.
  • the circuit analysis results corresponding to any unreplaced components that are in the final circuit will be directly and traceably related to those components in the initial circuit. Because those components are traceably related to the source HDL, the results are traceably related to the source HDL, and therefore be displayed near the appropriate portion of the HDL. Allowing for the interjection of unreplaced components by the designer facilitates debugging without rewriting the designer's original hierarchical design or manually backtracking through the optimization process.
  • the designer can assign a priority level to each probe to help manage the debugging process. These priority levels could then be used to activate or deactivate selected probes as a group.
  • An activated probe would establish a link through the synthesis process to facilitate debugging.
  • An inactive probe would have no effect on the synthesis process, and would not establish a debugging link.
  • Establishing many links would provide the designer with a large degree of debugging information, but could limit the ability of the synthesis process to provide a good circuit. Establishing too few links may not provide enough guidance to the designer to resolve circuit problems.
  • the present invention allows a designer to make more effective use of logic synthesis and reduce the complexity of the circuit debugging process.
  • An aspect of the present invention provides a method and system for processing requests from designers about the characteristics associated with the HDL synthesis source specifying a circuit, and displaying the results of circuit analysis with a consistent set of display tools that are not intimately tied to the data structure used for the circuit analysis.
  • Designing a chip involves constructing different representations for a circuit. Some of these representations, such as a synthesis description language are relatively compact and contain primarily functional information. Other representations, such as a gate level net list, contain correspondingly more information, such as the specific types of components to be used. Still other representations, such as a layout description, contain even more information, such as the specific location of the components on the chip.
  • the different representations can be partitioned into domains with each domain containing circuit representations with a common structure.
  • the tool builder can develop domain dependent display tools for examining the state of the design in that domain.
  • the tool builder can also develop tools that evaluate or analyze the state of the circuit in a particular domain. Display tools showing the circuit structure in one domain can obtain information related to analysis obtained in another domain by the forward and backward linkages.
  • the designer can inquire about the characteristics related to a specific part of the design by first examining part of the design in one domain with a display tool.
  • This domain is the inquiry domain. After identifying a relevant portion of the design in the inquiry domain, the designer selects a constituent piece of the design to evaluate, and makes an inquiry about that piece. This information constitutes a query.
  • the display tool forwards the identification of the object in the inquiry domain and an identifier indicating the requested analysis or evaluation to a data manager.
  • the data manager determines the domain that would contain the relevant analysis results. If those results do not yet exist, the data manager invokes the appropriate analysis tool to compute those results, which then may be cached in the data manager.
  • the data manager locates the related object in the analysis domain. From the related object, the appropriate information is passed back to the display tool where the designer can see it displayed appropriately.
  • One aspect of the present invention provides display tools that are not dependent on the structure of the domain in which the analysis is actually performed.
  • Another aspect of the invention provides analysis tools that are not dependent on the structure of the display domain.
  • Another aspect of the invention is to allow the different display and analysis tools to remain independent from one another.
  • the display tools can maintain their independence by relaying all of their queries through a central data manager.
  • the central data manager performs both domain mapping and analysis tool selection for each query issued by a display tool. Thus, neither the display tools nor the analysis tools need to be aware of the source or destination of any query.
  • One aspect of the present invention provides a selection manager which communicates a circuit selection made in one display tool to all of the display tools in the system.
  • the selection manager allows the designer to select a circuit object via a display object in a display tool, and then to view an alternate display of the circuit object in an alternate display tool. For example, a circuit object can be selected using a histogram display, and then that circuit object can be viewed using a text display.
  • One aspect of the present invention simplifies digital circuit analysis before optimization.
  • the direct relationship between the translated circuit and the HDL text is leveraged to allow the designer to improve the translated circuit by improving the HDL.
  • An aspect of the present invention allows the designer to obtain characterizations of attributes such as area and timing of parts of the translated circuit and then to relate automatically selected translated circuit parts to the source HDL from which they were created.
  • the HDL Analysis System has several advantages over prior art systems such as Source to Gates.
  • the HDL text browser uses the text to parse node links described earlier to draw a box around the entire selected parse node. Such boxes are drawn both when the cursor is moved across the display of the HDL text, as well as when a portion of the text is selected. The boxes around the HDL text are much easier to see, and indicate the entire range of the source for the selected circuit object.
  • the HDL Analysis System creates many more links than simply between HDL source and schematics. As described previously, many display and analysis tools can be linked to the HDL source. Additional display and analysis tools allow many different kinds of digital circuit analysis to be performed, rather than simply viewing the schematic.
  • One aspect of the present invention allows a designer to relate circuit analysis results visually and quickly back to the text that produced the portion of the circuit that was responsible for those results. This is achieved by the maintaining the parse tree generated during the translation portion of synthesis, and establishing a bidirectional relationship between a parse node and the circuit elements synthesized from that parse node.
  • the present invention provides for storing the parse tree node number with each created circuit element, and storing a list of created circuit elements with each parse node.
  • One aspect of the present invention allows the designer to display a numerical physical characteristic of a circuit element near a reference to the portion of the source HDL text responsible for that circuit element. This is achieved by maintaining references between the parse nodes derived from the text and the circuit elements synthesized from the parse nodes.
  • the kinds of physical characteristics the designer would want to know about are the area used by the circuit, the time delay from an input or a clock edge to a particular pin on a cell, the number of gates forming part of the design, the number of logic levels from an input to a particular net, or the power dissipated by one or more cells.
  • ⁇ display techniques supported are a stacked bar graph, a histogram, text, a path display, a logic inspector, a selection inspector, and a virtual schematic.
  • text display techniques supported are hilighting, different fonts, different colors, and different sizes.
  • FIG. 1 A flow diagram showing an earlier synthesis-analysis process.
  • FIG. 2 shows intermediate data structures and domains involved in the synthesis process.
  • FIG. 3 shows the general design and debugging process in accordance with the present invention.
  • FIG. 4 shows the relationship between HDL text and the mapped logic which makes up a mapped circuit.
  • FIG. 5 shows how mapped and GTech circuit structures are related to HDL tokens.
  • FIG. 6 shows how HDL text is related to mapped and GTech circuit structures.
  • FIG. 7 shows how probe statements are translated.
  • FIG. 8 shows how a primary input/primary output pair is created.
  • FIG. 9 illustrates a parse tree associated with some text.
  • FIG. 10 illustrates a text representation of the parse tree" using " ⁇ " to mark the beginning of a node and " ⁇ " to mark the end of a node.
  • FIG. 11 An example of VHDL source with no probes.
  • FIG. 12 A parse tree corresponding to the source fragment in FIG. 11.
  • FIG. 13 shows the HDL source of FIG. 11 as a text array.
  • FIG. 14 shows the text array of FIG. 13 with embedded brace " ⁇ " characters surrounding each portion of the text that forms a parse node.
  • FIG. 15 shows the annotated text array of FIG. 14 with each left brace " ⁇ " numbered.
  • FIG. 16 The VHDL source in FIG. 11 with a statement probe inserted.
  • FIG. 17 shows the text of FIG. 16 as a linear array of characters with parse node braces inserted.
  • FIG. 18 shows the HDL source of FIG. 11 with an improper probe directive.
  • FIG. 19 shows the brace representation of FIG. 18.
  • FIG. 20 shows some HDL source with a pair of embedded block probe directives.
  • FIG. 21 shows the brace representation for the HDL source of FIG. 20.
  • FIG. 22 Translation of the source in FIG. 16 according to the present invention.
  • FIG. 23 An alternative method of implementing probes in accordance with the present invention.
  • FIG. 24 A second alternative method of implementing probes in accordance with the present invention.
  • FIG. 25 A third alternative method of implementing probes in accordance with the present invention.
  • FIG. 26 shows a GTech circuit with an optimization invariant circuit structure implemented as a primary output.
  • FIG. 27 shows the mapped circuit resulting from the GTech circuit of FIG. 26.
  • FIG. 28 A GTech circuit arising from the conventional translation of the source fragment in FIG. 11.
  • FIG. 29 An optimized mapped circuit created from the GTech circuit of FIG. 25.
  • FIG. 30 An optimized mapped circuit derived from the GTech circuit of FIG. 22.
  • FIG. 31 An example of a display relating information found from analysis of the optimized mapped circuit of FIG. 30 to the source HDL.
  • FIG. 32 shows some VHDL source without probe directives using two process blocks.
  • FIG. 33 Conventional translation of the source in FIG. 32 into a GTech circuit.
  • FIG. 34 An optimized mapped circuit derived from the GTech circuit of FIG. 33.
  • FIG. 35 An example of a display relating data found from analysis of the optimized mapped circuit of FIG. 30 to the source VHDL showing that information can only be related to the highest level in the description.
  • FIG. 36 The VHDL source from FIG. 32 with a block probe directive installed.
  • FIG. 37 A GTech circuit generated by translating the VHDL source of FIG. 36.
  • FIG. 38 The mapped circuit obtained by optimizing the GTech circuit of FIG. 37.
  • FIG. 39 An example of a display relating data found from analysis of the optimized mapped circuit of FIG. 38 to the source VHDL showing information related to the block probes.
  • FIG. 40 shows the components of the HDL Analysis Tool.
  • FIG. 41 shows how the selection manager processes the selection.
  • FIG. 42 shows how the Data Manager processes a query.
  • FIG. 43 shows a stacked bar graph display of mapped circuit information.
  • FIG. 44 shows a stacked bar graph display of mapped circuit information showing the relative contribution of one of the sub-blocks in FIG. 43.
  • FIG. 45 shows a stacked bar graph display of mapped circuit information showing the relative contribution of one of the sub-blocks in FIG. 44.
  • FIG. 46 shows a histogram display of mapped circuit timing information.
  • FIG. 47 shows a text display of HDL source code and GTech circuit information related to that source code.
  • FIG. 48 shows a virtual schematic display showing the inputs and outputs associated with a particular part of VHDL source code.
  • FIG. 49 shows another virtual schematic display tracing the output of the display in FIG. 48.
  • FIG. 50 shows another virtual schematic display tracing the output of the display in FIG. 49.
  • FIG. 51 shows the Path Browser window.
  • FIG. 52 shows the logic inspector displaying a graphical representation of logic created by the logic inspector.
  • FIG. 53 Display of the transitive fan in trace of a particular signal in the source HDL in accordance with the present invention.
  • FIG. 54 Display of the primary inputs reached from transitive fan-in trace of a particular signal in the source HDL in accordance with the present invention.
  • FIG. 55 shows the stacked bar graph displaying component counts for the AMD2910A.
  • FIG. 56 shows the stacked bar graph displaying component counts for the STACK -- BLK module of the AMD2910A.
  • FIG. 57 shows the HDL text browser with the source code for the STACK -- BLK hilighted.
  • FIG. 58 shows an example of the relationship between the text description, the parse tree, the circuit and the display of a circuit analysis result in accordance with the present invention.
  • FIG. 59 shows the details of the circuit used in FIG. 58.
  • FIG. 60 shows an example of the inter-domain selection relationship.
  • FIG. 61 shows the communication flow as the designer analyzes a specific design.
  • the present invention comprises a novel method for analyzing a digital circuit using the HDL source description from which the digital circuit was created.
  • the following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements.
  • Various modifications to the preferred embodiment will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention.
  • the present invention is not intended to be limited to the embodiment shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
  • the present implementation is a software system which is implemented using conventional techniques such as message passing, object oriented design, and opaque data structures. These concepts are described in many books on programming. Two such publications are Fundamentals of Programming Languages by Ellis Harowitz, 2nd Edition, published by Computer Science Press in 1984, ISBN 0-88175-004-2 and Programming in C++ by Stephen Dewhurst and Kathy Stark, published Prentice Hall in 1989, ISBN 0-13-723156-3.
  • HDL Synthesis creates a mapped circuit netlist description from an HDL description of the digital circuit's functionality.
  • the present invention extends an HDL Synthesis tool. The following sections describe the structures created while synthesizing the mapped circuit, and how the mapped circuit is created.
  • a digital circuit is a physical piece of hardware.
  • the outputs of a digital circuit are a function of its inputs.
  • a property of a digital circuit is its functionality.
  • Another property of a digital circuit is the area required to build it.
  • Another property of a digital circuit is the amount of time required after a signal has been applied to its inputs for its outputs to contain a valid value. Properties such as area and delay are called constraints.
  • constraints such as area and delay are called constraints.
  • the design of a digital circuit can be represented or specified in different ways within the memory of a computer system.
  • Each type of digital circuit representation is called a domain.
  • Different domains contain different amounts of information regarding the physical structure of a circuit. Domains which contain more information regarding the structure of the circuit require more of the computer's memory and require more of the computer's time to construct and manipulate.
  • a representation of a digital circuit is treated as if the representation were the actual digital circuit. Some representations contain enough information to build a version of the digital circuit. This section describes the different representations of digital circuits which are used in CAD systems as a digital circuit is being designed.
  • Domains are used to store different representations of a digital circuit design in a CAD system.
  • the designer In going through the digital circuit design process, the designer, through the CAD system, manipulates and transforms digital data in one domain into other digital data in a new domain.
  • Many digital circuit analysis tools are designed to work with a specific domain. For example, the timing verifier works in the mapped logic domain. Because more detailed domains are larger and slower to manipulate, it is desirable to manipulate the circuit in less detailed domains where possible. The following paragraphs describe what a domain is and the different domains used in the HDL Digital Circuit Analysis Tool.
  • a domain is a software representation of digital circuit design data that includes common structural characteristics. Each domain represents a particular level of abstraction of the digital circuit design information. Some common domains include an HDL source domain, a generic technology domain, which is also known Is a GTech domain, a gate domain, a layout domain. In addition, other domains may be possible.
  • the digital circuit design data in one domain can be the result of a transformation of digital circuit design data from another domain using digital circuit design tools, such as a logic synthesizer, and libraries of components.
  • the intermediate data structures shown in FIG. 2 are all members of various domains.
  • the source domain contains the HDL source files that the designer creates in step 100 of FIG. 1 or step 150 of FIG. 3. Circuit representations in this domain may also be called HDL source.
  • the HDL source 900 is also shown in FIG. 2.
  • the source domain also contains the parse tree 901 and symbol table generated during the translation step of logic synthesis. Although the HDL text and the parse tree are different representations of the circuit, they are in the same domain because they contain the same information about the structure of the digital circuit. However, it is necessary to establish efficient links between the HDL text and the parse tree. A method for accomplishing this will be described later.
  • the digital circuit design representation contains information about the desired function of the digital circuit without reference to digital circuit topology. Although it is possible to explicitly instantiate technology dependent components in the source domain, the source domain generally does not reference a specific technology provided by a silicon vendor.
  • the generic technology, or GTech, domain contains the initial generic technology circuit 902 that arises from the translation step of the synthesis process, as shown in step 104 of FIG. 1 or step 154 of FIG. 3. Circuit representations in this domain may also be called the GTech circuit.
  • VHDL compiler by Synopsys, Inc. of Mountain View, Calif. is a tool that creates GTech circuits.
  • Data stored in the generic technology domain contains information about the topology of the digital circuit, but does not have information about the specific technology to be used. Thus, GTech circuits do not have exact timing or area data. However, one can characterize the timing and area of a GTech circuit by ascertaining the logic levels and component counts of the GTech circuit respectively.
  • the logic levels of a path in a GTech circuit is the number of 2 input GTech gates used to construct the logic comprising the path.
  • the component count of a GTech circuit is the number of 2 input GTech gates used to construct the GTech circuit.
  • the gate, or mapped logic, domain contains the mapped circuit 903 that arises after the mapping step of the synthesis process. Circuit representations in this domain may also be called mapped circuits. Design Compiler by Synopsys, Inc. of Mountain View, Calif. is a tool that creates mapped circuits.
  • the data in the gate domain contains information about how components are connected together. However, in the gate domain, a particular technology from a specific silicon vendor is specified, thus providing information about the physical characteristics of the components used to implement the desired function. It is in this domain that preliminary timing, area, power, testability, and other calculations of step 105 of FIG. 1 and FIG. 3 can be made.
  • the layout domain contains information about the geometric placement of the components on the chip substrate and the connections between the components. Circuit representations in this domain may also be called the laid out circuit. Cell3 Ensemble by Cadence of San Jose, Calif. creates laid out circuits.
  • the digital circuit design information in the layout domain is obtained from the digital circuit design information in the gate domain by using placement and routing tools.
  • the digital circuit design information within a domain is a collection of interconnected objects, with the objects and the connections possessing certain characteristics.
  • the objects may include the text of the HDL source code or the nodes of the parse tree constructed from the source code or the entries in the symbol table.
  • the objects may include software representations of the individual gates or other library parts or the connections between them.
  • Subsequent sections describe how intra-domain relationships are established and maintained.
  • Objects in different domains can be related to each other using links discussed in subsequent sections.
  • objects in the source domain can be related to objects in the generic technology domain by tracking the parse node which creates each translated gate.
  • the system leverages the intradomain links to allow the designer to perform analysis in one domain and view it in another.
  • a digital circuit is an interconnected collection of parts. Parts may also be called cells.
  • the digital circuit receives signals from external sources at points called primary inputs.
  • the digital circuit produces signals for external destinations at points called primary outputs.
  • Each part receives input signals and computes output signals.
  • Each part has one or more pins for receiving input signals and producing output signals.
  • pins have a direction. Most pins are either input pins which are called loads, or output pins, which are called drivers. However, some pins may be bidirectional pins which are both inputs and outputs. Bidirectional pins must be handled specially by algorithms which manipulate digital circuit designs. Usually one of two strategies is used for bidirectional pins; either they are treated as both an input pin and an output pin, or they are disallowed by the algorithm in question. In this case, the algorithm cannot manipulate that part of the circuit.
  • One or more pins from one or more parts are connected together with a net.
  • Each net establishes an electrical connection among the connected pins, and allows the parts to interact with each other.
  • Pins are also connected to primary inputs and primary outputs with nets.
  • parts may be said to be “connected” to nets, but it is actually pins on the parts which are connected to the nets.
  • Pins, cells, nets and ports may all be referred to as circuit elements.
  • One or more circuit elements form a circuit element set.
  • a digital circuit can be specified hierarchically. Some or all of the parts in the digital circuit may themselves be digital circuits composed of more interconnected parts.
  • the pins of the high level part become the primary inputs and primary outputs for the digital circuit comprising the lower level parts. If a high level part is composed of lower level parts, it is called a level of hierarchy.
  • a hierarchical digital circuit specification must terminate with primitive parts.
  • Primitive parts are not specified as a GTech circuit, but with a fixed definition provided by the GTech specification or model maker.
  • the definition for a primitive part specifies the logical function performed by the part. Typically, these parts are functionally simple, such as nand gates, or gates, inverters, or flip-flops. Some primitive parts perform a more sophisticated function, such as addition. In some cases, the primitive part performs a very sophisticated function, such as a microprocessor.
  • the GTech specification or logic model supplier describes the functionality and characteristics of the primitive parts. This may include, but is not limited to, the logic performed by the primitive part.
  • mapped circuit specifications must also terminate with primitive parts.
  • the primitive parts are supplied by a semi-conductor vendor and are stored in a technology library.
  • Each part in a semi-conductor vendor technology library contains a description of its function, as well as physical characteristics such as area, timing and power usage.
  • Primitive parts in both the GTech and mapped domains are also known as cells.
  • Digital Circuit Synthesis consists of translating an HDL description into a netlist with equivalent functionality and then optimizing that netlist to create an improved mapped circuit with the same functionality. The following sections describe this process in more detail.
  • the conventional translation portion of the synthesis process first converts the HDL text into a parse tree. This is done using conventional parsing techniques such as those described in Compilers, Principles, Techniques and Tools by Alfred V. Aho, Ravi Sethi and Jeffery D. Ullman.
  • a parse tree represents the functional relationships established by the HDL text. Various nodes on the parse tree correspond to functions.
  • the translator then constructs an initial GTech circuit using the parse tree as the guide to selecting the appropriate primitive parts and establishing nets among the pins of those parts.
  • the initial GTech circuit will also be hierarchically specified as required by the parse tree.
  • every character in the HDL text is related to a node in the parse tree, and every parse node is directly related to a net or a part or a primary input or a primary output in the initial GTech circuit.
  • each variable declared in the HDL will correspond to a net in the GTech circuit.
  • registers specified in the HDL will correspond to flip-flops or other memory elements in the GTech circuit.
  • the conventional translation process produces initial GTech circuits that, if mapped directly to a technology library and built, would be slow and large. To remedy this, the translation process is followed by an optimization process to create a mapped circuit with superior characteristics than the initial GTech circuit, but that performs the same function as the initial GTech circuit.
  • the conventional optimization process proceeds generally as described below.
  • Optimizing a GTech circuit includes improving the structure of the initial GTech circuit as well as mapping the logic in the initial GTech circuit into gates available in the specified technology library. Circuit improvement algorithms may function in either the GTech or the mapped logic domains. Therefore, mapping may occur at different points in the optimization process. Conventional logic optimization tools generally perform some logic improvement both before and after the GTech circuit is mapped. The following paragraphs describe a general approach to improving the logic in either a GTech or a mapped circuit. For readability, the following description of the optimization process describes optimizing GTech circuits. However, the same optimization techniques are applied to mapped circuits as well.
  • the optimization process identifies one or more parts in the GTech circuit. This may include identifying all of the parts of the GTech circuit. Those interconnected parts collectively form an identified GTech sub-circuit.
  • the identified GTech sub-circuit has inputs and outputs.
  • An identified GTech sub-circuit output is a net that connects an output pin of a part in the identified GTech sub-circuit to an input pin of a part not in the identified GTech sub-circuit or to a primary output.
  • An identified GTech sub-circuit input is a net that connects a primary input or an output pin of a part not in the identified GTech sub-circuit to an input pin of a part in the identified GTech sub-circuit.
  • the identified GTech sub-circuit therefore computes one or more outputs from one or more inputs.
  • the optimization process devises a new GTech sub-circuit that performs the same function as the identified GTech sub-circuit.
  • the new GTech sub-circuit has the same inputs and the same outputs as the identified GTech sub-circuit.
  • the new GTech sub-circuit should be better than the identified GTech sub-circuit in some measurable manner. For example, if the designer is seeking to construct a digital circuit with the smallest area possible, then the new GTech sub-circuit provided by the optimization process should use fewer gates than the identified GTech sub-circuit. If the designer seeks speed, the new GTech sub-circuit should have a faster timing estimate than the identified GTech sub-circuit.
  • the identified GTech sub-circuit is sometimes replaced with a new GTech sub-circuit that has worse characteristics than the identified GTech sub-circuit.
  • the measurable criterion used may be a surrogate for the actually desired measurement. For example, a designer may want to minimize area of an entire digital circuit being placed on a chip.
  • the optimization process may estimate the actual new GTech sub-circuit area by counting the number of gates, or adding up an area estimate for each GTech part where the area estimate comes from the GTech part library. Obtaining a more accurate measurement generally requires further analysis of the mapped circuit.
  • the optimization process replaces the identified GTech sub-circuit with the improved GTech sub-circuit.
  • Replacement means deleting the parts associated with the identified GTech sub-circuit.
  • the new GTech sub-circuit's inputs are connected to the same nets that were connected to the identified GTech sub-circuit's inputs.
  • the new GTech sub-circuit's outputs are connected to the same nets as the identified GTech sub-circuit's outputs. This results in an intermediate GTech circuit.
  • the optimization process then repeats these three steps on the intermediate GTech circuit until an appropriate termination condition arises. For example, the process could terminate when no further improvement was made, or the total number of iterations reached a specified number. If necessary, the GTech circuit is mapped, and the optimization process may be repeated on the mapped circuit.
  • optimizers generally do not eliminate registers and defined memory elements such as latches and flip-flops.
  • the translation process typically creates a part in the initial GTech circuit for each bit of a register defined by the HDL text. These initial parts have a one-to-one correspondence with final library parts which are chosen by the optimization process. Therefore, partial analysis results associated with the register (such as its area) or nets connected to the register relate directly to those in the initial GTech circuit. Furthermore, the final register can be related back to the HDL which caused it to be created.
  • optimizers generally do not eliminate primary inputs and primary outputs. Therefore, post optimization primary inputs and outputs can be related back to pre-optimization parts.
  • optimizers generally do not optimize across levels of hierarchy. If a GTech circuit contains a part that is implemented as another GTech circuit, then the optimization process will optimize the GTech circuit within that lower level part separately from the rest of the GTech circuit at the higher level. Hierarchy is also respected in mapped circuits.
  • the optimizer can be instructed not to "touch" a given cell or net.
  • this instruction is called "dont -- touch.”
  • dont -- touch is a command which refers to a particular cell or net in the GTech or mapped circuit.
  • dont -- touch is an attribute in the HDL language which refers to a part which is instantiated in the source HDL. Cells or nets which are labeled dont -- touch are not changed in any way by the optimizer.
  • the goal of synthesis is to create a mapped circuit netlist description from a high level description of the digital circuit.
  • the mapped circuit must meet a set of design constraints.
  • an HDL is used to specify the high level description. It is desirable to analyze the final result in terms of the original source description.
  • Analysis of the digital circuit can be done in many ways. Generally, analysis involves taking a digital circuit and computing a numerical characteristic of that digital circuit or of parts in the GTech or mapped circuit or of nets connecting parts in the GTech or mapped circuit. The intermediate results of that analysis are often associated with parts or nets or both in the GTech or mapped circuit. For example, one way to estimate the area of a mapped circuit is to add up the areas of each of the parts in the mapped circuit. The area of each primitive part can be found in the library of primitive parts provided by the semiconductor vendor. The area of a hierarchical part is obtained by applying this area summing technique recursively.
  • the propagation delay through a mapped circuit is determined by first computing the longest delay from the primary inputs to each pin in the mapped circuit. This associates delay information with each pin in the mapped circuit. For a hierarchical part, the information could be consolidated to be the delay from each input of the part to each output of the same part.
  • Results such as area or propagation delay refer to the optimized mapped circuit. If a problem is discovered in analyzing such results, it is useful to ascertain which portion of the HDL description caused the problematic mapped circuit structure to be synthesized.
  • the following sections describe how the relationships between the source HDL, the parse tree, the translated GTech circuit, and the optimized mapped circuit are created and used. These relationships form the basis for HDL source level digital circuit analysis and debugging. Once these relationships are established, digital circuit analysis tools can be linked to the source HDL to assist the designer in analyzing and modifying the HDL.
  • This section provides an overview of how the relationship between the source HDL text and the mapped circuit is established. Each of the links will be described in more detail in subsequent sections.
  • FIG. 4 shows the relationship between HDL text and the mapped circuit.
  • the HDL text 3610 is the source representation of the digital circuit.
  • the parse tree 3620 is ccreated by parsing 3654 the HDL text in accordance with conventional computer parsing methods.
  • each node in the parse tree is assigned a unique numerical id called the parse tree node number which is used to identify the node.
  • Both the HDL text and the parse tree belong to the source domain.
  • the generic logic, or GTech domain 3630, representation of the digital circuit is created by translating 3664 the parse tree.
  • the mapped domain 3640 representation of the digital circuit is created by optimizing 3674 the generic logic.
  • Link 3652 indicates that the HDL text 3610 can be related to the parse tree 3620 by traversing the parse tree to find the node which represents the relevant text.
  • Link 3656 indicates that the parse tree 3620 can be related to the HDL text 3610.
  • One technique for relating particular pieces of text with corresponding parts of a parse tree is described in a co-pending application by Gregory entitled “Method and Apparatus for Context Sensitive Displays", filed on Jun. 3, 1994 as U.S. application Ser. No. 08/253,453, which is hereby incorporated by reference.
  • Another embodiment for this stores the file offset of the start and end of each parse node.
  • Another embodiment stores the line and column number from the source HDL in the parse node.
  • Link 3662 indicates that the parse tree 3620 can be related to the GTech domain 3630 by storing a list of cell ids created from each parse node with the representation of that parse node.
  • Link 3666 indicates that the GTech domain 3630 can be related to the parse tree 3620 by storing the parse tree node number with each cell that is created in translation.
  • Link 3672 indicates that the GTech domain 3630 can be related to the mapped domain 3640 by relating optimization invariant digital circuit structures. Optimization invariant structures in the GTech domain 3630 have a one to one correspondence with structures in the mapped domain 3640. Therefore, link 3672 can be implemented by searching for a structure of the same type with the same name in the optimized mapped circuit.
  • An alternate embodiment of tracking optimization invariant structures comprises assigning a unique reference number to each translated GTech circuit structure and then retaining this unique reference number in the corresponding optimized mapped circuit structure.
  • Link 3676 indicates that the mapped domain 3640 can be related to the GTech domain 3630 by relating optimization invariant digital circuit structures. This link is imlemented using the same method as link 3672.
  • the synthesized digital circuit can be related back to the HDL text.
  • mapped or GTech circuit analysis results can be shown near the related source HDL.
  • Relating an analysis result back to the source HDL is a several step process.
  • the partial analysis result is associated with a part or a net in the final mapped circuit. That part or net is related to a part or net in the initial GTech circuit.
  • this relationship is easily established because that net or part did not change during the optimization process. In other circumstances, this relationship is very difficult or impossible to establish. Note however that it is always possible to establish the relationship between the GTech circuit and the source HDL.
  • FIG. 5 shows how a mapped circuit structure can be related to the source HDL.
  • a mapped circuit structure is selected for tracing.
  • the method checks to see if the mapped structure was derived from, and can therefore be traced to, an optimization invariant GTech circuit structure. If that mapped circuit structure is not traceable, then the process terminates. In one embodiment, a message might be issued to the user that the mapped circuit structure is not traceable. If the structure is traceable, step 3520 relates the mapped circuit structure to the pre-optimization GTech circuit structure which created it. As described previously, this is possible because the mapped circuit structure directly corresponds to a pre-optimization GTech structure with link 3676 of FIG. 4.
  • Step 3530 relates the pre-optimization structure to the parse node from which it was translated. This is possible because the pre-optimization structure contains a record of the parse node from which it was created. This relationship is shown link 3666 of FIG. 4. Finally, step 3540 relates the parse node back to the source HDL token(s) using link 3656 shown in FIG. 4. The details of the method for establishing the parse tree to text link are described in a later section.
  • FIG. 5 shows the method for tracing from mapped circuit structure back to HDL source text. It is also possible to begin the method shown in FIG. 5 at step 3520 when one is tracing from GTech circuit structures rather than from mapped circuit structures.
  • FIG. 4 it is possible to trace from HDL text to a GTech or to a mapped circuit structure.
  • the method is the reverse of that shown in FIG. 5, and uses link 3652, link 3662, and link 3672 from FIG. 4.
  • a method for tracing from HDL text to either a GTech or a mapped circuit structure is shown in FIG. 6.
  • step 5620 the selected HDL text is related to the appropriate parse node. This is possible by using link 3652 of FIG. 4.
  • Step 5630 relates the parse node to the appropriate GTech part(s). As described previously, this is possible because the parse node is annotated during translation with a record of the GTech part(s) it creates. This annotation is indicated by link 3662 of FIG. 4.
  • step 5640 the program checks to see whether it is possible to trace from each GTech part to a mapped part. This tracing, as shown by link 3672 of FIG. 4, is possible if the GTech part remains invariant during optimization. If the GTech part remains optimization invariant, then the procedure returns a mapped part for each GTech part. Otherwise it terminates at step 5650.
  • mapped circuit structures back to the HDL if there is a 1 to 1 correspondence to GTech for them.
  • GTech circuit structures are preserved by typical optimizers, these parts might not exist in sufficient numbers to derive a sufficient correspondence between the source HDL and the optimized mapped circuit in some cases.
  • the distribution of where these parts are located in the mapped circuit might not correspond to the parts of the mapped circuit requiring analysis. Therefore, it might be necessary for the designer to specify additional parts of the HDL which can be traced to the final mapped circuit.
  • An aspect of the present invention uses "probe" directives in the source HDL to specify the creation of additional optimization invariant parts in the GTech circuit.
  • Probe directives instruct the translator software to construct an initial GTech circuit with certain points in the GTech circuit marked so that those points are preserved during the subsequent optimization process.
  • the usual optimization invariant structures will also be preserved during optimization.
  • the following sections describe how an HDL description of a digital circuit with probes is synthesized and the resulting mapped circuit is analyzed. An example showing how probes guide the construction of the mapped circuit and allow analysis information to be related to the HDL source text is then provided.
  • probe directives cause optimization invariant structures to be inserted into the mapped circuit.
  • the following sections describe different types of probe directives as well as a method for enabling and disabling probe directives without modifying the HDL source text.
  • a probe directive is a single text string that is a comment in the HDL language.
  • the probe directive begins with characters that indicate the beginning of a comment. In VHDL, this is a "--". In Verilog, this is "//”.
  • the next word is a keyword that indicates to the translator that this comment is a translator directive, and not a mere comment. In one embodiment, this keyword is "Synopsys”.
  • a probe declaration is indicated with the phrase "probe -- statement”. After the probe declaration comes an optional search string that is used to identify the type of nets in the GTech circuit to insert optimization invariant GTech circuit structures.
  • Probe strength is an aspect of the present invention which provides a convenient method of activating or deactivating groups of probes. In one embodiment, probe strength is indicated using a numerical value from 1 to 5. This feature will be described further in a later section.
  • a basic type of probe directive is a statement probe.
  • Statement probes use the syntax described above, but do not include any search string.
  • a statement probe selects the first parse node following it.
  • a block probe is defined by two text strings.
  • the first text string is the block starting string. Like the statement probe, it begins with a comment starting symbol and a keyword.
  • the keyword is followed by the phrase "begin -- block -- probe”. This phrase is followed by an optional search string. This phrase is followed by an optional string with probe strength information.
  • the second text string is the block ending string. In one embodiment, the keyword is followed by the phrase "end -- block -- probe”.
  • the begin block probe/end block probe phrase pair cause all of the statements between the begin and end phrases to be probed. Details of how block probes are implemented will be explained later.
  • Multi-probes are implemented by using statement probes and block probes with search strings.
  • Search strings are text descriptions that are used to choose the nodes or nets to probe.
  • the search string is used to select particular types of nets associated with the GTech circuit parts.
  • multiplexors are commonly used to implement conditional expressions.
  • the multiplexor control lines are linked to GTech circuit structures associated with the condition, and the data lines are linked to GTech circuit structures associated with the alternatives.
  • a search string such as "all -- mux -- controls" could probe the nets that are connected to multiplexor control lines. This would allow the designer to gain insight about the conditions. Following is an example of a multi probe which selects all mux controls in the VHDL language:
  • the mapped circuit produced when probes are used most likely will be different from the mapped circuit that occurs when probes are not used. Because probes interfere with the ability of the optimizer to produce higher quality mapped circuits, the designer generally will only use them when the designer needs to gather particular information.
  • a designer may insert many probe directives into the HDL source at various times to discover the characteristics of different parts of the mapped circuit. As the design process progresses, the designer should require fewer probes.
  • One of the tasks that the designer faces is then managing the probes as the debugging needs change. One way to do this is for the designer to add and remove the text of each probe directive as required. This burdens the designer with a tedious text editing chore.
  • An aspect of the present invention use a probe strength field in the probe directive in the HDL source text.
  • the designer specifies a processing strength. All probe directives with a probe strength greater than the processing strength are treated as active probes and therefore should be processed. All other probe directives are ignored. This means that a designer can set the probe strength to a small value in the detailed portions of the design, and then set the probe strength to a larger value at higher level portions of the design.
  • the designer would get a mapped circuit with fewer probes, and provide the optimizer with greater flexibility, but corresponding less information directly related to the source text. Specifying a smaller processing strength would increase the number of probes, but would also impact the mapped circuit.
  • probe strength field is to modify the translation process shown in FIG. 7.
  • the parse nodes corresponding to probe directives are marked.
  • the probe directive's strength can be extracted from the text and compared with the specified processing strength. A probe directive lacking the requisite strength is simply ignored.
  • Another method would involve attaching the probe strength to the nets that get marked, and allowing the optimization process to select probe nets with probe strength less than or equal to the processing strength.
  • the probe directive could include a specification field that contained text.
  • the designer could specify a text search condition.
  • Such a condition could include a regular expression used for defining text searches. The synthesis process would then process probe directives that satisfy the condition, and ignore probe directives that do not satisfy the condition.
  • FIG. 3 shows the general design and debugging process in accordance with the present invention.
  • the designer writes HDL with probe directives 150.
  • the probe directives identify the places in the resulting mapped circuit that the designer might wish to examine.
  • the designer might not initially know where probes will be required until later in the design process.
  • the probes have no impact on functionality so functional simulation 101 and functional repair 102 proceed as before.
  • the designer also constrains synthesis 103 as before.
  • Synthesizing with probes 154 differs from conventional synthesis 104 in the translation step.
  • that translator creates an optimization invariant structure at that point in the GTech circuit.
  • the optimizer then produces a new mapped circuit with additional optimization invariant structures.
  • the probed portions of the HDL source are treated as both primary inputs and primary outputs during translation and optimization. Alternate embodiments of implementing probe directives are described later.
  • the mapped circuit analysis step 105 proceeds as before. After analysis, the tool then uses information developed during translation to relate the results of the analysis to the HDL source as indicated by step 120.
  • step 121 With the information gleaned from the probes, the designer can now identify problems and evaluate solutions that directly change the HDL, as shown in step 121.
  • the mapped circuit is fabricated in step 106.
  • FIG. 7 shows a method of implementing probe directives.
  • the process begins in step 4110 by constructing a parse tree from the HDL source text using conventional parsing techniques.
  • the data structure representation of the parse tree should efficiently link the characters in the text to the parse node containing those characters, and additionally, it should efficiently allow identifying the characters associated with a parse node.
  • One technique for relating particular pieces of text with corresponding parts of a parse tree is described in a co-pending application by Gregory entitled “Method and Apparatus for Context Sensitive Displays", filed on Jun. 3, 1994 as U.S. application Ser. No. 08/253,453, which is hereby incorporated by reference.
  • step 4120 the parse nodes corresponding to various probe directives are marked.
  • probe directives There are three types of probe directives: statement probes, block probes, and multi probes.
  • Multi probes can be transformed into zero or more statement or block probes and then treated as such. This transformation will be described in a later section; this section assumes that multi probes have been previously transformed.
  • a statement probe is a single text string.
  • the parse node that "follows" the single text string is the parse node to mark.
  • a block probe consists of two text strings: a begin block statement and an end block statement. In general terms, the parse nodes "between" the begin block and end block statements are the parse nodes to mark.
  • step 4130 the unprobed GTech circuit is constructed from the marked parse tree constructed in step 4120 using conventional techniques, such as those described in the references incorporated earlier.
  • the GTech circuit translation process also constructs a list of parts and nets associated with each parse node.
  • step 4140 step 4140, step 4150, and step 4160, optimization invariant GTech circuit structures are added for each marked parse node.
  • One approach to adding an optimization invariant GTech circuit structure is to create a primary input and a primary output. The following paragraphs will elaborate on how this is done. Additional methods for creating optimization invariant circuit structures will be described in a later section. Note that the digital circuit functionality is preserved by connecting that primary input and primary output at the next higher hierarchical level. Therefore, in step 4135, an additional level of hierarchy is added if the digital circuit does not have a higher level of hierarchy and there are marked parse nodes.
  • step 4140 all of the parts that were created from marked parse nodes are marked. Thus, some parts are marked.
  • nets associated with the marked parts are marked. These marked nets will be broken by new primary input/primary output pairs in order to form optimization invariant GTech circuit structures.
  • the nets to mark are identified as follows. First, note that the marked parts form a GTech sub-circuit.
  • the GTech sub-circuit has input nets and output nets.
  • a particular net is a GTech sub-circuit input net if the particular net is connected both to an input pin of a part in the GTech sub-circuit and to an output pin of a part not in the GTech sub-circuit or to a primary input.
  • a particular net is a GTech sub-circuit output if the particular net is connected both to an output pin of a part in the GTech sub-circuit and to an input pin of a part not in the GTech sub-circuit or to a primary output.
  • the behavior of the GTech sub-circuit can be observed.
  • marking the nets associated with the marked parts to allow the insertion of optimization invariant GTech circuit structures.
  • One choice involves marking only the input nets to the GTech sub-circuit.
  • Another choice involves marking only the output nets to the GTech sub-circuit.
  • a third choice involves marking both the GTech sub-circuit's input nets and output nets.
  • a fourth choice involves selecting nets that meet a search criterion defined in the search string portion of the probe directive.
  • One of the preceding options is chosen for marking the nets. Then, each of the marked parts is examined. The order in which the marked parts are examined is unimportant. Any nets which are connected to the part and which meet the marking criterion are marked. There is no significance to marking a net more than once.
  • an optimization invariant GTech circuit structure replaces each net marked in step 4150.
  • There are several choices for creating such a structure for a marked net As mentioned previously, one choice involves creating a new primary input and a new primary output for each marked net. Another choice involves creating only a primary output. Another choice involves attaching the net to a register. Another choice involves attaching a property or a characteristic to the net that instructs the optimizer not to modify the net. Another choice involves creating a new optimization part which is marked so that the optimizer will not modify it during optimization. This part has one input pin and one output pin. The net is then split into two parts. One part remains connected to all of the input pins on the original net and is also connected to the output pin of the new part. The other part remains connected to all of the output pins on the original net and is also connected to the input pin of the new part.
  • FIG. 8 shows how a new primary input/primary output pair is created for each marked net.
  • step 3810 a new primary input and a new primary output are created.
  • step 3820 an input net is created and attached to the new primary input.
  • An output net is also created and attached to the new primary output.
  • step 3830 because the GTech circuit being processed is part of a hierarchical design with a higher level, the new primary input and the new primary output are connected together with a new net at the higher level in the design.
  • the input and output nets are connected to the existing GTech ciruit.
  • the output net is connected to every primary input connected to the marked net.
  • the output net is also connected to any output (or driver) pins that are connected to the marked net. Note that if net marking was chosen to mark only output nets from the marked GTech sub-circuit, then the output net will be connected to the pins connected to the marked net that belong to parts that are not in the marked GTech sub-circuit.
  • the input net is connected to every primary output connected to the marked net.
  • the input net is also connected to any input (or load) pins that are connected to the marked net. Note that if net marking was chosen to mark only output nets from the marked GTech sub-circuit, then the input net will be connected to the pins connected to the marked net that belong to parts that are in the marked GTech sub-circuit.
  • step 3840 the method shown may treat bidirectional pins as either input or output pins. However, all bidirectional pins should be treated in the same way.
  • Comment 401 in FIG. 16 is a probe directive which causes statement 402 to be probed.
  • the parse tree for the VHDL source is constructed in step 4110 of FIG. 7, and is shown in FIG. 12.
  • step 4120 the probe parse nodes are marked. In this case, node 1004 of FIG. 12 is marked.
  • the parse tree is translated using conventional methods. The resulting GTech circuit is shown in FIG. 28.
  • step 4135 a level of hierarchy is added if necessary. For the purpose of this example, it is assumed that a level of hierarchy exists above the circuit fragment shown.
  • step 4140 the parts and nets from the marked parse node are marked. In this case, net 280 is marked, because it was created from statement 402.
  • step 4150 nets associated with marked parts are marked. Since there is only a marked net, no additional nets are marked.
  • step 4160 an optimization invariant circuit structure is added for each marked net.
  • a primary input and primary output pair will be added as shown in FIG. 8.
  • the resulting GTech circuit is shown in FIG. 22.
  • a new primary input 203 and primary output 221 are created in step 3810.
  • input net 223 and output net 222 are created in step 3820, and connected to primary input 203 and primary output 221 respectively.
  • primary input 203 and primary output 221 are connected at a higher level of hierarchy.
  • the input net 223 and output net 222 are connected to the rest of the GTech circuit.
  • Input net 223 is connected to all of the driver pins that were connected to net 280. In this case, input net 223 is connected to driver pin 224 on nor gate 233.
  • Output net 222 is connected to all of the load pins that were connected to net 280. In this case, output net 222 is connected to load pin 225 on multiplexor 231.
  • This section contains specific details of how the links between the domains are established and maintained.
  • HDL source is first parsed to create a parse tree.
  • the nodes in the parse tree must be linked back to the original HDL source in order to enable tracing from the HDL source to the mapped circuit. This section describes how the parse tree to HDL source relationship is established and used.
  • Parsing involves creating a parse tree from an array of text in accordance with the rules of a language.
  • Co-pending application by Gregory entitled “Method and Apparatus for Context Sensitive Displays", filed on Jun. 3, 1994 as U.S. application Ser. No. 08/253,453 provides an overview of the parsing process and provides an efficient data structure for relating text and parse nodes. This section explains how to use the relationship between text and parse nodes. In particular, a method to relate a probe directive to the appropriate parse node is discussed.
  • FIG. 9 illustrates a parse tree associated with some text.
  • the parse tree consists of nodes 39100, 39101, 39102, 39103, 39104, 39105, and 39106.
  • the characters 3901 through 39013 represent generic characters. Using conventional parsing methods, characters are grouped into parse nodes. When parsing is complete, characters are associated with the parse node they define. In this example, characters 3901, 3902, 3903, 3904, 3905 and 3906 are associated with node 39102. Characters 3907 and 3908 are associated with node 39103. Characters 3909, 3910 and 3911 are associated with node 39105 and characters 3912 and 3913 are associated with node 39106.
  • FIG. 10 illustrates a text representation of the parse tree using " ⁇ " to mark the beginning of a node and " ⁇ " to mark the end of a node.
  • This representation is called a parse array.
  • left brace 3930 and right brace 3940 together contain all of the text and nodes associated with node 39100.
  • Left brace 3931 and right brace 3941 demarcate the text and nodes associated with node 39101.
  • Left brace 3932 and right brace 3942 demarcate the text associated with node 39102.
  • Left brace 3933 and right brace 3943 demarcate the text associated with node 39103.
  • Left brace 3934 and right brace 3944 demarcate the text associated and nodes with node 39104.
  • Left brace 3935 and right brace 3945 demarcate the text associated with node 39105.
  • Left brace 3936 and right brace 3946 demarcate the text associated with node 39106.
  • pairs of left and right braces are nested within each other.
  • brace 3933 and brace 3943 are nested within brace 3931 and brace 3941. They are also nested within brace 3930 and brace 3940.
  • characters may be surrounded by multiple pairs of braces.
  • character 3907 is surrounded by all three of the pairs of braces mentioned above.
  • brace 3933 and brace 3943 make up the innermost pair of braces which surround character 3907.
  • the concepts of leftmost and rightmost are also useful.
  • An array is considered to be a contiguous list of characters, the first of which is the leftmost character of the array. Each successive character is considered to be to the right of its predecessor. The last character in the array is the rightmost character of the array.
  • a character is considered to be “leftmost” if it is the character furthest to the left which fills a condition.
  • a character is considered to be “rightmost” if it is the character furthest to the right which fills a condition.
  • brace 3943 is the leftmost right brace to the right of character 3907.
  • FIG. 11 shows an example of HDL source.
  • FIG. 12 shows the parse tree which is generated from this source.
  • FIG. 13 shows the same HDL source as a text array.
  • FIG. 14 shows the text array of FIG. 13 with embedded brace " ⁇ ⁇ " characters surrounding each portion of the text that forms a parse node.
  • FIG. 15 shows the annotated text array with each left brace " ⁇ " numbered.
  • a computer program treats arrays as contiguous lists of characters. The characters " ⁇ n" and “ ⁇ t” indicate newline and tab characters respectively.
  • FIG. 15 shows an alternate representation of the characters as "X" as explained in co-pending U.S. application by Gregory filed on Jun. 3, 1994 as U.S. application Ser. No. 08/253,453.
  • the figures in this application will show the actual characters, although the technique explained in co-pending U.S. application, by Gregory filed on Jun. 3, 1994 as U.S. application Ser. No. 08/253,453 may be used to improve the performance and memory requirements of the system.
  • character 4132 the "o" in “or” will be traced to its corresponding parse node.
  • the parse node containing character 4132 is determined. This is the parse node that begins with brace 4307, since it is the parse node corresponding to the innermost braces containing character 4132.
  • the parse node number is determined. This is done by counting the number of left braces which precede brace 4307. Since there are 7 left braces prior to brace 4307, it represents node number 7. Note that this number is the same number that is calculated by performing a preorder traversal of the original parse tree and numbering each node as it is traversed.
  • Locating the text which corresponds to a given parse node uses the same data structures.
  • the number of the parse node is ascertained.
  • the number of the parse node of interest is stored with the parse node.
  • the number of the parse node of interest is calculated from the parse tree by performing a preorder traversal and numbering each node as it is traversed.
  • the number of the parse node is calculated from the parse array as described above.
  • the number of the parse node is available because it has been previously stored.
  • the associated text is found by counting left braces in the parse array until the correct number is reached. Any text between the correct left brace and its balancing right brace is related to the parse node.
  • the or expression can be found by counting to the seventh brace, brace 4307 (starting from 0), in the annotated text array.
  • probe directives are comments within the HDL language. During conventional lexical analysis and parsing, comments are discarded by the lexical analyzer or the parser. Therefore, probe directives must be parsed specially in order to determine which parse nodes are affected by each probe directive. This section describes how probe directives modify the parse tree. The modified parse tree is used to determine where additional optimization invariant structures must be created during translation.
  • the parse node associated with a statement probe corresponds to the HDL statement following the statement probe.
  • One way to implement this is to determine the parse node associated with the text immediately following a statement probe using the text-to-node mapping previously described, and mark that node. This is possible because the parse array contains all of the characters in the source text.
  • the parse array embeds the parse node boundaries into the text.
  • the probe directives can be identified by scanning the parse array after it has been built. They are then used to mark the appropriate parse nodes.
  • FIG. 12, FIG. 16, FIG. 17, and FIG. 11 illustrate processing probe directives with an example.
  • FIG. 12 shows an HDL code fragment.
  • FIG. 16 shows the same HDL code fragment containing a statement probe 401.
  • FIG. 17 shows the text of FIG. 16 as a linear array of characters with parse node braces inserted.
  • FIG. 11 shows the parse tree.
  • a conventional text searching technique such as used in the "grep" command in UNIX can identify character 4450 as the first character of the statement probe.
  • the text-to-node mapping will identify the parse node beginning at brace 4304 as the first parse node following the statement probe. This parse node is the node whose opening left brace is the first left brace to the right of the probe directive beginning at character 4450.
  • FIG. 18 and FIG. 19 illustrate a situation that, in one embodiment, should be treated as an error. If the text of a statement probe does not immediately precede an HDL statement, then there is no next statement to select. The HDL text in FIG. 18 illustrates this situation.
  • Statement probe directive 4520 should be treated as an error.
  • FIG. 19 shows a brace representation of the situation. This error occurs whenever a right brace " ⁇ " is located after the probe directive text and before the next left brace " ⁇ ". Brace 4660 is such a brace.
  • One method of dealing with this situation is to stop processing probe directives. Another method of handling this situation is to ignore the probe.
  • a message can be sent to the designer by the HDL analysis system describing the problem and the action taken.
  • An alternate embodiment would use statement probes to select the HDL statement preceding the text of the probe. This would require that the parse node immediately preceding the probe directive be marked. This parse node can be found by finding the first right brace " ⁇ " to the left of the text of the probe directive. The corresponding left brace " ⁇ " for this right brace is then identified and the parse node number is ascertained from this left brace as described previously.
  • probe directives which select the preceding text is that the probe directive must follow all lines of a complex statement.
  • Block probe directives are defined by a starting text string and an ending text string.
  • the starting and ending text strings are processed in a very similar manner to statement probes.
  • the parse nodes to mark for block probes are found as follows. Identify the parse node immediately following the starting text string of the probe directive with the text-to-node mapping described earlier, and call this parse node the starting parse node. Identify the parse node preceding the ending text string with the text-to-node mapping described earlier, and call this parse node the ending parse node.
  • the parse node which contains the starting probe directive and the parse node which contains the ending probe directive.
  • the containing node is the parse node whose defining braces are the innermost pair of braces which fully enclose the probe directive. If the starting probe directive and the ending probe directive are not contained by the same node, then a logical error has occurred.
  • Probe directive 4750 is the starting block probe directive.
  • Probe directive 4760 is the ending block probe directive.
  • the innermost containing parse node for both starting block probe directive 4750 and ending block probe directive 4760 is the parse node defined by starting brace 4800.
  • a parse node is the innermost containing parse node for a probe directive if its left brace is before the probe directive, and its right brace is the leftmost right brace which comes after the probe directive but has its matching left brace before the probe directive.
  • brace 4845 is the leftmost right brace to the right of starting block probe directive 4750 which has its matching left brace before starting block probe directive 4750. Brace 4845 is also the leftmost right brace to the right of ending block probe directive 4760 which has its matching left brace before ending block probe directive 4760. Thus, this is a legal pair of block probe directives.
  • those parse nodes and all parse nodes which fall between the starting and ending parse nodes are marked.
  • the marked parse nodes are processed as described previously. For example, in one embodiment, the outputs of the logic block defined by the block probe will be preserved by optimization invariant structures.
  • One troublesome situation that might arise is that the text-to-parse-node mapping identifies different containing parse nodes when applied to the starting block probe directive and the ending block probe directive. This situation arises if the begin and end block probe directives are not placed within different syntactic blocks. Another troublesome situation occurs if the starting block probe directive is not placed immediately before a parse node or the ending block probe directive is not placed immediately after a parse node. In one embodiment, processing stops once an erroneous situation is detected. In another embodiment, the offending probe directives are ignored. In one embodiment, a message can be sent to the designer describing the problem and the action taken.
  • a Multi-probe is a statement probe or a block probe with a search string which further specifies which logic is to be probed.
  • a multi-probe uses the phrase "multi-probe" following the keyword.
  • the parse nodes associated with a multi-probe directive are identified using the methods described earlier if either a statement probe or a block probe is used. These parse nodes will be referred to as the initial parse node selection.
  • the search string is used to mark some, or possibly all, parse nodes in the initial parse node selection.
  • the marked parse nodes are then processed as before.
  • the parse node types are defined by the particular HDL language.
  • One use for the search string is to select parse nodes of a particular type. For example, the search string "all assignments" would result in marking the assignment parse nodes in the initial parse node selection.
  • Another search string is "all statement sequences". This indicates that the parse nodes that correspond to the first and last statements in each statement sequence of the original selection are probed. Statement sequences are defined in the VHDL Language Reference Manual.
  • the search string is used to specify which nets connected to the marked parts are marked. Recall that marked nets will be broken with optimization invariant structures. For example, the search string "all -- mux -- controls" indicates that the nets controlling muxes should be marked in the initial selection. This will cause all of the mapped mux controls to be linked to the HDL source after optimization.
  • Probe directives can be used to selectively group blocks of logic so that the effects of such logic blocks can be observed.
  • another search string is "all case statements”. This marks all parse nodes corresponding to case statements.
  • a further search string is "all subroutine calls” which marks the parse nodes corresponding to subroutine calls.
  • FIG. 22 shows an example of extracting both a primary input as well as a primary output.
  • Another method of creating an initial GTech circuit with optimization invariant GTech circuit structures corresponding to the probe directives involves modifying the identification step in the optimization process.
  • a net or a part corresponding to a probe directive is "marked.”
  • the identification step in the optimization process is changed to allow only "unmarked” nets or parts to be modified during optimization.
  • the marking is implemented by attaching additional information to the net list prepared during the translation process.
  • a marked net can be divided into an input net and an output net as before, and a new part added that connects the nets. This part is given a property that it may not be deleted during optimization.
  • FIG. 23 and FIG. 24 show two example of a GTech circuit with optimization invariant structures.
  • Net 391 is a marked net which cannot be modified during optimization.
  • Part 270 is a marked part which cannot be modified during optimization.
  • the disadvantage to marking a net as not modifiable is that if the net cannot change, then the total number of input and output pins on the net must remain the same. This means that none of the parts which are attached to the net can be deleted or combined during optimization.
  • Another method of creating an initial GTech circuit with optimization invariant GTech circuit structures corresponding to the probe directives involves creating only a primary output at a higher level in the hierarchy.
  • a sample GTech circuit with a primary output extracted is shown in FIG. 25.
  • the method shown in FIG. 8 created both a primary input and a primary output. If only a primary output but no primary input is extracted, the marked net does not need to be divided into an input net and an output net. However, this technique might lead to unpredictable results during optimization.
  • Part 4201 computes function f, and produces an output on net 4220.
  • Part 4202 computes function g.
  • Net 4220 is marked and probed by attaching only a primary output.
  • the optimizer may effectively proceed by producing a mapped sub-circuit as shown in FIG. 27. For example, such a mapped sub-circuit might be produced if the optimizer is attempting to minimize the critical path.
  • part 4200 is a replica of part 4201, and computes f, which drives net 4220 as before.
  • Part 4201 and part 4202 have been combined by the optimizer to produce part 4203, which computes h, a combination of f and g.
  • FIG. 11, FIG. 12, FIG. 25, FIG. 29, FIG. 16, FIG. 22, FIG. 30, FIG. 31, FIG. 32, FIG. 33, FIG. 34, FIG. 35, FIG. 36, FIG. 37, and FIG. 38 illustrate by example how probe directives work and how the mapped circuit analysis information is displayed to a user.
  • the examples use VHDL as the source language. The principles illustrated do not depend on the particular language. For example, the system works with Verilog as well.
  • FIG. 11 shows a text editor window 300 containing an example of a VHDL code fragment 400 that does not contain any probe directives.
  • the code fragment shown in FIG. 11 is repeated below:
  • FIG. 12 shows a graphical representation of the parse tree constructed while translating the source code in FIG. 11.
  • the "if" statement in VHDL has three parts: a condition, a VHDL statement to process when the condition is true; and a VHDL statement to process when the condition is false.
  • the condition is dealt with in the tree descending from node 1001.
  • the true condition is handled by the tree descending from node 1004.
  • the false condition is handled by the tree descending from node 1010.
  • the assignments represented by nodes 1004 and 1010 are used to link the signal values represented by node 1005 and node 1011 to their functions represented in the trees descending from nodes 1006 and 1012 respectively.
  • VHDL fragment translates into the GTech circuit of FIG. 25 using conventional synthesis translation techniques described earlier.
  • Inputs A, B, and C are schematically represented by the connectors 200, 201, and 202.
  • the "if” statement translates into multiplexor 231.
  • the condition “(C and B)” would translate into and gate 232.
  • the "true” condition translates into nor gate 233 while the “false” condition translates into inverter 230.
  • FIG. 29 shows a mapped circuit optimized from the GTech circuit of FIG. 25.
  • the logic function that this code fragment really performs is not(B).
  • the designer can not obtain much information about the internal timing information descending from the fragment. For example, if the designer needed to know when the value of not(A or B) was computed to help analyze some other aspect of the design, then the designer would not be able to deduce that information from the resulting analysis of the circuit in FIG. 28.
  • FIG. 16 shows a probe directive 401 inserted into the source description.
  • the code fragment is repeated below:
  • VHDL VHDL
  • "--" begins a comment.
  • the word “Synopsys” immediately after the "--” indicates that this is not an ordinary comment, but rather a directive to the translator or other part of the computer aided design tool environment.
  • the word “probe -- statement” indicates that the subsequent VHDL statement should be processed by the translator so that it will be possible to relate subsequently obtained analysis information to this point in the HDL representation of the digital circuit.
  • FIG. 22 shows a GTech circuit produced by a translator from the code fragment shown in FIG. 16 with the probe directive.
  • the parse tree produced with the probe directive is the same as before, namely the tree of FIG. 12. However, the probe directive will cause the signal represented by node 1005 to behave as both a primary output and a primary input.
  • the translator adds temporary input 203 and new temporary output 221 while creating the GTech circuit of FIG. 22 from the parse tree.
  • the translator connects the new temporary input to the new output at a higher level in the net list produced from translating the whole specification. This effectively makes this internal node visible at a higher level in the design hierarchy.
  • FIG. 30 shows the mapped circuit of FIG. 22 after optimization.
  • the optimizer is not permitted to optimize GTech circuits past the boundaries established by the probe directive. This means that nor gate 233 of FIG. 22 would be transformed into nor gate 253 of the optimized mapped circuit.
  • the optimization process begins with a GTech circuit that does not have timing or area information associated with the GTech components. After the optimization process, the mapped components do have area and timing information associated with them. Therefore, nor gate 233 in FIG. 22 is not "the same" as nor gate 253 in FIG. 30.
  • FIG. 31 shows the relation of timing information to the HDL source text through a special text window 301. For example, suppose a critical path analysis tool determined that it took 1.0 nanoseconds to produce temporary output 221 of FIG. 30 after a clock edge arrived at a flip-flop somewhere else in the mapped circuit. By using the fact that temporary output 221 came from this line of the source, the timing result 500 can be displayed next to the appropriate line of the output.
  • FIG. 32, FIG. 33, FIG. 34, FIG. 35, FIG. 36, FIG. 37, FIG. 38, and FIG. 39 show another way to use probes to evaluate the performance of blocks of HDL code.
  • FIG. 32 shows a text window with an HDL entity described. This text has no probe directives inserted, and the code is repeated below.
  • VHDL source code model The function of this VHDL source code model is to compute whether a new interrupt of a particular priority should be serviced given priority over the interrupt being serviced.
  • a request for a processor interrupt arrives on inputs new -- request 3!, new -- request 2!, or new -- request 1!.
  • the input current -- level 1:0! indicates the priority level of the interrupt currently being serviced. If the request for an interrupt comes in on a higher level input than the current level of the interrupt being serviced, then the should -- service output is set. Otherwise, it is set low.
  • This source code computes the interrupt service request in two steps. First, it determines the level of the highest pending interrupt request in the process labeled decode. Second, it compares that level with the current interrupt level.
  • FIG. 33 shows the GTech circuit resulting from translating the VHDL source.
  • FIG. 34 shows the mapped circuit that results from optimizing the GTech circuit in FIG. 33.
  • FIG. 35 shows a special text window that summarizes some of the performance information about the mapped circuit.
  • the analysis tool can provide information about the design as viewed from the inputs. For example, one analysis tool would provide an estimate of the area of the design by counting gates. Another analysis tool would compute the longest delay through the entire design. The designer could compare this information with the designer's requirements to determine if this mapped circuit is too big or too slow. The optimization process blurred the distinction between the decode function and the compare function. It is not feasible for a designer to determine the area or the delay associated with each function.
  • the designer would insert "block probes” textually near the definition of the decoding and comparing processes, as shown in the text window of FIG. 36. This would probe all signals entering or leaving the sequence of HDL code delineated by the begin block and end block statements. When translated, the probed HDL becomes the GTech circuit of FIG. 37. The translator would create temporary inputs 2010 and 2011, and temporary outputs 2000 and 2001, much as it did with the statement probe.
  • the optimizer transforms the GTech circuit of FIG. 37 into the mapped circuit of FIG. 38. This allows the analysis tools to compute timing and area characteristics of both parts of the mapped circuit. A special purpose display tool can then display, for example, timing and area analysis, as shown in FIG. 39.
  • the decoding mapped circuit is approximately the same size and delay as the comparator mapped circuit.
  • the previous sections describe how the HDL source can be related to the GTech or mapped circuit. Once the HDL source to GTech or mapped circuit relationship has been established, GTech or mapped circuit analysis tools can use this link to enable the designer to analyze the GTech or mapped circuit while viewing the source HDL. This section describes how an HDL source level analysis system is built using a variety of GTech and mapped circuit analysis tools which are linked back to the HDL source.
  • the system is designed to support any number of GTech and mapped circuit analysis tools.
  • the system includes a central data manager. This data manager receives analysis queries from user level analysis tools, determines which analysis tool can respond to the query, and communicates the response to the appropriate user level display tool(s). Note also that the system uses the GTech or mapped circuit to text link to display the portion of the HDL text corresponding to the part of the GTech or mapped circuit which is relevant to the current query.
  • the HDL source text, a representation of the parse tree, the GTech circuit, and the mapped circuit are all simultaneously resident in the computer's memory.
  • HDL Advisor User Guide Version 3.3a, which is available from Synopsys, Inc. of Mountain View, Calif. and is hereby incorporated by reference.
  • the HDL Advisor has a central data manager.
  • the central data manager supports two types of tools; display tools and analysis tools.
  • Each display tool can display data in a certain format.
  • the HDL Advisor includes a stacked bar graph display tool, a histogram display tool, and a text display tool, among others.
  • Each analysis tool can answer queries about a certain property of a digital circuit.
  • the HDL Advisor includes a timing verifier which can perform timing analysis on a mapped circuit.
  • the central data manager coordinates communication between the display tools and the analysis tools.
  • the HDL Advisor remembers the current selection.
  • the user makes a selection by using an input device such as a keyboard or mouse to indicate one or more display objects on the screen.
  • Display objects are displayed in display tools and may have many different graphical representations. For example, a bar in a histogram, a fragment of text, or a drawing of a GTech gate are all display objects.
  • Display objects are drawn by display tools to represent circuit objects. Each display tool maintains the correlation between each display object that it draws and the underlying circuit object.
  • Circuit objects include any representation of a digital circuit structure in any domain. For example, a process statement, a GTech gate, and a mapped pin are all circuit objects which can be selected via a corresponding display object.
  • Display objects represent circuit objects in a specific domain.
  • display objects can be used to select a circuit object in multiple domains.
  • ports can be selected in the source domain by selecting the line of HDL text which defines the port, in the GTech domain by selecting the symbol for the GTech port, or in the mapped domain by choosing the symbol for the mapped port.
  • Chosen display objects are called the visual selection.
  • the underlying circuit objects they represent are called the circuit selection.
  • the HDL Advisor includes a selection manager which communicates the circuit selection to multiple display tools in multiple domains. The selection manager will be described further in a later section.
  • FIG. 58 shows the relationship between the text description of a digital system, the parse tree derived from that text description, the circuit synthesized from the parse tree, and a visual display of a circuit analysis result.
  • the text description 6003 comprises a sequence of characters 6003.
  • the parse tree 6004 comprises parse nodes 6010, 6011, 6012, 6013, and 6014, and is constructed by parsing the text description 6003.
  • the parse tree is stored.
  • a relationship between the text and the parse nodes is maintained as indicated by relationship 6018.
  • the digital circuit 5900 shown in FIG. 59 is synthesized from the parse tree 6004.
  • the digital circuit 5900 consists of circuit elements.
  • Digital circuit 5900 includes input ports 6030, 6031, 6032, 6033, 6034, and 6035, and output ports 6036 and 6037.
  • the digital circuit also includes cells 6040, 6041, 6042, 6043, 6044, and 6045.
  • the cells include input pins 6050, 6051, 6052, 6053, 6054, 6055, 6056, 6057, 6058, 6059, 6060, 6061, and 6062.
  • the cells include output pins 6070, 6071, 6072, 6073, 6074, and 6075.
  • the digital circuit also includes nets 6080, 6081, 6082, 6083, 6084, 6085, 6086, 6087, 6088, 6089, 6090, and 6091.
  • parse node 6011 is related to grouping 6020.
  • Parse node 6013 is related to grouping 6021.
  • Parse node 6014 is related to grouping 6022.
  • Parse node 6012 is related to grouping 6023, and parse node 6010 is related to digital circuit 5900.
  • Analysis tools can be used to associate numerical circuit analysis results with the circuit elements. For example, if the circuit is in the G-Tech domain, then each net could have the number of logic levels from input port to that net. If each cell in this example was one gate, then net 6090 is 1 logic level from an input, while net 6091 is 3 logic levels from an input port.
  • the gate count is another example of G-Tech analysis. Suppose each cell has one gate. Groupings 6020, 6021, and 6022 each have two gates. Grouping 6023 has 4 gates. Similar results can be obtained in the mapped circuit domain.
  • the analysis tool could generate the results for all of the relevant circuit elements upon inquiry or the results could be stored with the circuit element or cached in the system.
  • Analysis results are displayed in a window 6095 on a computer screen 5420.
  • the size or display characteristics of a display object 6097 can be set by the numerical circuit analysis results.
  • the designer can choose a display object in window 6095 that is linked to a parse node.
  • the text description could be in VHDL.
  • the window 6095 could have a list of VHDL processes near or coincident with visual display object 6097.
  • the designer selects a visual object corresponding to part of the text or a parse node.
  • the designer also selects a type of analysis desired.
  • the system then identifies the corresponding circuit group from the selected parse node using relationship 6019. For example, suppose the designer selects parse node 6012 and wants to know the gate count. The gate count will be obtained for corresponding circuit grouping 6023.
  • the system then aggregates the results attached to the circuit elements to produce a aggregated result associated with the circuit grouping.
  • the aggregation comprises adding up the gates in the circuit grouping. For circuit group 6023, this is 4.
  • the aggregation function would be the maximum value on a net or pin within the circuit grouping.
  • the aggregated result could then be used to set the display characteristics of a display object. For instance, the height of a rectangle corresponding to parse node 6012 in a stacked bar graph could be set to the number of gates in circuit grouping 6023 divided by the number of gates in the whole design. This would permit a designer to determine what fraction of the gates in a design were attributable to a parse node, and hence to the source HDL text. Visually relating the design characteristics to the source text responsible for those characteristics quickly and efficiently represents dramatically improves designer productivity.
  • FIG. 60 illustrates the structure of an inter-domain selection.
  • text 6103 is parsed to obtained the parse tree comprising nodes 6110, 6111, 6112, 6113, 6114, and 6115.
  • the digital circuit is synthesized in accordance with the parse tree.
  • the digital circuit in this example has ports 6130, 6131, 6132, 6133, and 6134. It has cells 6140, 6141, 6142, and 6143. It has input pins 6150, 6151, 6152, 6153, 6154, 6155, 6156, 6157 and 6158. It has output pins 6170, 6171, 6172, 6173, 6174 and 6175.
  • text string 6102 corresponds with parse node 6112 which corresponds with a circuit element using relationship 6196.
  • the corresponding circuit element is cell 6140.
  • Inter-domain selection involves choosing a display object linked to a circuit object in one domain, and changing the display characteristics of another display object that is linked to a circuit object in another domain where the two circuit objects are related by the parse node-circuit relationship.
  • display object 6104 is in window 6100. It is linked to cell 6104. This type of linking would be found with the path browser tool.
  • the designer could select display object 6104, and change the display characteristics of text string 6102 displayed in window 6101 using relationship 6196. This type of linking simplifies the designer's job of finding the source code corresponding to problematic paths in a digital circuit.
  • FIG. 40 shows the components of the HDL Advisor.
  • the Designer 520 uses conventional input tools such as a keyboard 5410 or a mouse 5411 to interact with display tools which appear on a computer screen 5420.
  • display tools There can be any number of display tools in the HDL Advisor.
  • a stacked bar graph display 5430 and an HDL display 5440 are shown specifically.
  • the stacked bar graph display 5430 and the HDL display 5440 will be described in further detail in a later section. This section describes how these display tools interact with the other components of the system. Additional display tools behave in a similar manner.
  • the histogram display 5430 and the HDL display 5440 each send queries to and receive responses from the central data manager 125.
  • the data manager 125 uses analysis tools to assist in processing queries. Any number of analysis tools may be registered with the data manager 125. For the sake of clarity, two sample analysis tools are shown, a logic levels analysis tool 5470, and a timing verifier 5480. A method for processing queries is shown in FIG. 42.
  • Display tools also communicate with the selection manager 5460 regarding which circuit object or circuit objects the user selects. This process is shown in FIG. 41.
  • the data manager 125 includes a domain mapper 5450.
  • the domain mapper takes as input a circuit object in a source domain, the initial domain, and a target domain and finds the corresponding circuit object in the target domain. This process is shown in FIG. 4 and FIG. 5.
  • the HDL Advisor enables diverse display and analysis tools to communicate with one another.
  • a data manager is central to the system. It performs several functions. Most importantly, the data manager allows display tools to pose a query in a particular domain and receive an answer in the same domain even though the answer is computed in a different domain. Thus, the role of the data manager is to function as both a domain mapper and as a message coordinator between the display and analysis tools.
  • the data manager can break complex queries into series of simpler queries. It ascertains which analysis tool can answer a given query. To enhance performance, the data manager contains a cache of recently posed queries and the answers. This section describes how the data manager is built, and how display and analysis tools are connected to it.
  • the data manager uses global ids to identify objects.
  • a global id is a number.
  • a global id can be passed with a domain to the data manager. The data manager will attempt to return an object in the passed domain which corresponds to the global id.
  • the data manager uses the global id as an index into a table to look up a circuit object in a domain. The data manager uses the domain mapping capability described earlier to map the circuit object to the desired domain.
  • FIG. 42 shows how the data manager processes a query 4910.
  • a query contains an indicator as to what type of query this is (e.g. area, power), a list of circuit objects being queried, a flag indicating if the result of the query is to be cached, and a function for aggregating the results of processing this query for each circuit object. Aggregating is the process of combining multiple results into a single result.
  • An aggregate function is a function which is used to combine the results of subqueries. Subqueries are discussed with step 4940.
  • the aggregate function is determined by the query and can be stored in a table with the query. For instance, area queries are aggregated by summing the area results produced by subqueries. Longest delay queries are aggregated by finding the maximum result returned from the set of queries.
  • the type of query is provided to the display tool by the data manager when the display tool is registered. Registration of display tools will be discussed further in a later section.
  • the query is created by a display tool interface in response to an action from the designer 520.
  • the query arrives as a message from a display tool, and will be answered by one of the registered analysis tools. Note that the query may arrive in one domain, be processed in another, and the response sent in the original domain.
  • the domain in which the query is issued is referred to as the initial domain.
  • the domain in which the query can be processed is referred to as the target domain. Neither the display nor the analysis tool need know about the domain transformation.
  • Step 4920 determines the initial and target domains for the query.
  • the initial domain is the domain in which the objects passed in the query are represented.
  • the target domain is determined by the type of the query.
  • the target domain for each query is stored in a table which is indexed by the type of the query. For instance, a timing query can be answered using information contained in the gate domain.
  • a logic level query which can be used to analyze paths in a translated circuit, can be answered using information contained in the GTech domain.
  • Step 4920 also sets the aggregate function for the query.
  • Step 4930 maps the circuit objects in the query from the initial to the target domain. This mapping is done by mapping through consecutive domains as described previously and shown in FIG. 4 and FIG. 5.
  • Step 4940 subdivides the query in the target domain. This is necessary if the circuit objects in the query are composed of multiple circuit objects. Note that the circuit objects in the query are subdivided varies with the type of the query. For example, suppose the query is finding the area of an HDL "process" circuit object. Since a process is made up of many logic components, the query must find the area of each of these components and add them together. This subdivision is implemented by keeping a table of routines that is indexed by the type of query. Each routine in the table takes a circuit object in the target domain for this type of query and returns a list of circuit objects in the same domain which have been subdivided if necessary.
  • Loop 4950 loops over each subdivided query.
  • Arrow 4955 is the return branch of the loop.
  • Step 4960 checks to see if the result of the given subdivided query on the given circuit object is in a cache of query results.
  • branch 4963 causes step 4970 to be processed and the result is retrieved from the results cache.
  • branch 4966 causes step 4975 to be processed and an analysis tool is selected for this subdivided query.
  • the query is sent to the analysis tool and a result is returned.
  • Step 4990 caches the query and its result if the cache flag was set in the original query. Note that the only purpose of caching results is to improve performance. In another embodiment, results may be cached, and the cache checked, at different points in the process. For instance, results might be cached after the results are aggregated in step 4980.
  • Step 4980 aggregates the results of all of the subdivided queries. Aggregating the results of the subqueries combines them to produce a single result which will be returned for the original query. The results are aggregated using the aggregate function in the query.
  • Step 4985 maps the aggregated result from the target domain to the initial domain. This mapping is done by mapping through consecutive domains as described previously and shown in FIG. 5.
  • Result 4995 is a message which is sent from the data manager to the display tool which originally requested the result.
  • the selection manager uses intra-domain mapping to track circuit selection in multiple domains.
  • a message is sent to the selection manager indicating the corresponding selected circuit object.
  • the selection manager then broadcasts information regarding the current circuit selection to all of the display tools.
  • Each display tool uses the circuit selection information to select the correct display object within its display.
  • the selection manager can communicate the circuit selection in any domain by using the intra-domain mapping capability. By communicating information about the circuit selection, the selection manager allows the user to easily find a circuit object of interest using one type of display tool, and then further examine that circuit object using another display tool.
  • FIG. 41 shows how the selection manager handles the circuit selection.
  • the designer 520 uses an input device 5510 such as a keyboard or mouse to make a visual selection within a display tool 5520.
  • the display tool 5520 notifies the selection manager 5460 of the circuit selection.
  • the selection manager 5460 broadcasts the circuit selection to each of the available display tools 5560.
  • the selection is broadcast using a list of one or more global ids.
  • Each display tool may optionally ask the data manager 125 to map the global ids to circuit objects in a particular domain.
  • display tool 5560 sends a query to data manager 125 requesting the GTech value of the broadcast global ids. The data manager then returns the requested GTech objects to display tool 5560.
  • circuit selection tracking can be grouped into three main categories: identifying a circuit selection in a non-text display tool and viewing a visual selection of that circuit selection in the HDL source, identifying an HDL source construct and viewing a visual selection of that circuit selection in a non-text display tool, and the "follow selected" in HDL source feature.
  • the stacked bar graph display then communicates the corresponding circuit selection in the GTech domain to the selection manager 5460.
  • the selection manager uses the domain manager 5450 to map the circuit selection to supported domains. The relationships and process of mapping between domains was shown in FIG. 4, FIG. 5, and FIG. 6. Thus, the selection manager determines the source domain parse node which represents the selected primary output.
  • the selection manager then broadcasts the id of the parse node and the HDL display 5440 receives the parse node id of the circuit selection. Selecting a display object, and thus the corresponding circuit object, in the HDL display 5440 and viewing it in the GTech display is accomplished in the same manner.
  • the follow selected feature causes a display such as the HDL text display 5440 to track the GTech or mapped circuit structure being analyzed by the designer 520 in another display such as the stacked bar graph display 5430.
  • this feature enables the HDL text display 5440 to always show the current HDL source.
  • the designer can examine a GTech or mapped circuit structure, and simultaneously view the HDL source from which the GTech or mapped circuit structure was created.
  • This feature assists HDL source level digital circuit analysis by automatically linking conventional analysis to the HDL source.
  • the selection manager broadcasts the selection, the HDL text display requests the appropriate circuit object in the source domain and visually selects the corresponding display object.
  • the HDL text display 5440 will scroll the text display to make the selected text appear in the HDL text display window.
  • a special case occurs for the selection manager and for the display tools if no specific circuit object is selected.
  • the selection manager and display tools assume that the designer desires information about the entire design being analyzed by the HDL Advisor.
  • the first selection which the selection manager broadcasts when a design is loaded into the computer memory used by the HDL Advisor is the entire design.
  • the information specifying the design is represented in binary form.
  • information about that design must be presented in a form that can be understood by the human, such as by a visual display on a monitor.
  • the designer 520 must also have a way to manipulate the design information, such as by keyboard and mouse.
  • Display tools such as 5430 and 5440 provide a mechanism for that interaction.
  • One way to take advantage of the structure is to design particular display tools to communicate with a particular domain in the data manager.
  • many display tools interact with multiple domains. For example, a stacked bar graph, which will be described in a later section, can communicate information regarding both area, which concerns the gate domain, and gate count, which concerns the GTech domain. Regardless of whether a display tool is tuned to display information from a particular domain, each display tool uses the data manager to gather the information which it displays.
  • each display tool interacts with the data manager by communicating messages back and forth. These messages involve specifying a circuit object in a domain and some related query to perform on that circuit object.
  • a display tool is able to display a display object which represents a circuit object and store a list of queries that can be answered for that circuit object, although the display tool does not answer those queries.
  • the data manager in contrast, is able to provide the display tool with circuit objects and process queries associated with objects. In one embodiment, at start-up time the data manager also provides each display tool with a list of queries which can be answered. This allows new analysis tools to be added to the system more easily. Information about available analysis is stored centrally in the data manager, rather than duplicated in each display tool.
  • Display tools communicate with the data manager through display tool interfaces.
  • the purpose of a display tool interface is to provide a layer of data abstraction to the display tool. This allows the display tool to be as generic as possible. For example, a stacked bar graph, which will be discussed in a later section, can analyze different digital circuit properties, including, for example, area and power usage.
  • a display tool interface frames queries concerning the specific type of data which the tool is displaying. Thus, the tool only needs to be able to frame general queries and the display tool interface will translate each query into one which the data manager can understand.
  • the display tool is unaware of how its queries are answered.
  • each display tool registers itself with the data manager when the system is initialized. At this time, the data manager informs the display tool of all of the queries to which it can respond.
  • Display tool interfaces send messages to the data manager requesting information about digital circuit structures in a given domain, and receive responses.
  • the data manager responds to a query in the same domain, regardless of which domain an analysis tool used to compute the answer. For example, suppose that a source text display tool wants to know the arrival time for a particular parse node.
  • the source text display tool sends a message to the data manager with the parse node and the request for an arrival time. If the information is available, the data manager responds with the same parse node and the actual arrival time.
  • display tools also communicate with a selection manager to inform the selection manager when a circuit object is selected when the user interacts with that display tool.
  • Analysis tools are used to process information contained within a domain. In general terms, there are two kinds of analysis that one might want to perform in a given domain.
  • Conventional kind of analysis tools take one or more circuit objects in a domain, and computes characteristics associated with those circuit objects. For example, in the gate domain, a timing analyzer is used to compute the delay times and slacks to various parts of the mapped circuit. The timing analyzer determines the time that the data signal on an output pin will become valid after a clock edge.
  • a logic levels analysis tool computes the longest path of chained 2 input gates through the GTech circuit.
  • an area analysis tool computes the area required to build the mapped circuit.
  • a component count analysis tool computes the number of 2-input gates that would be used if the GTech circuit were implemented with 2 input gates only.
  • Another kind of analysis involves summarizing the characteristics associated with a particular group of circuit objects. For example, estimating the total area in a mapped circuit at the gate level involves summing the area associated with each component and connection.
  • analysis tool For an analysis tool to summarize characteristics of circuit objects, the analysis tool requires information about the structure of the circuit objects and the connections between them. Therefore, analysis tools are associated with a particular domain. For example, a timing verifier 5480 deals with the mapped domain, while a logic levels analysis tool 5470 deals with the GTech domain.
  • analysis tools communicate with the data manager 125 by messages.
  • the data manager provides the analysis tool with one or more circuit objects, and the analysis tool returns one or more characteristics of those circuit objects or a summary of the characteristics of those circuit objects, or both.
  • Analysis tools perform three kinds of interactions with the data manager. First, each analysis tool registers itself with the data manager when the system is initialized. Registration consists of informing the data manager what kinds of queries and in which domain a tool can answer. For example the timing verifier can answer timing queries in the gate domain. Later, the analysis tool can receive and answer queries.
  • the data manager is responsible for ascertaining which analysis tool can respond to a given query.
  • the data manager is responsible for posing queries in the correct domain for the analysis tool.
  • the data manager uses the relationships between domains to translate queries to the correct domain for the analysis tool. For example, consider a query concerning the arrival time of a signal on an output port specified in the HDL source.
  • a timing verifier is registered with the data manager. The data manager will ascertain that the timing verifier can provide arrival times, and will determine which port in the gate domain corresponds to the port specified in the HDL source. The data manager will then send a message to the timing verifier asking for the arrival time on that port.
  • the timing verifier determines the arrival time, and then sends a return message indicating the arrival time of the port in the gate domain.
  • the analysis tool is not aware of the source of the query, or of the fact that domain mapping may occur. It simply answers the query in the domain which it understands.
  • An aspect of the present invention allows for meaningful digital circuit analysis in the GTech domain. Because the GTech circuit is a direct translation of the HDL source, the quality of the HDL source is directly related to the quality of the GTech circuit. By determining which parts of the GTech circuit are problematic, and improving the source responsible for those parts of the GTech circuit, the start point for optimization will be improved. As it is difficult to predict the effect that optimization will have on a translated GTech circuit, it is important to create the best possible GTech circuit before optimization. When the original GTech circuit is of good quality, there are fewer choices that the optimizer must make. This causes the final result to be more reliable, and probably of better quality because the optimizer has a much smaller range of changes to make.
  • GTech -- GateCount requests the gate count that a GTech part would require if mapped to simple logic gates. This gate count can be used to analyze the initial area required before optimization.
  • GTech -- LogicLevels Another possible query type which requests the number of levels of logic that a longest path in a GTech circuit would require if mapped to simple logic gates.
  • GTech analysis uses the intra-domain mapping capability to select structures in the gate domain, relate those structures to the GTech domain, and then perform analysis in the GTech domain where complete HDL source to GTech circuit mapping is available.
  • An example of this sort of analysis is start/end mode in the Path Browser window, which will be discussed further in a later section.
  • the design includes representations in the source, GTech, and gate domains.
  • the designer 520 selects a display object to evaluate by selecting some text, such as the decode: process statement in the text of FIG. 36.
  • HDL text selection uses the text to parse node relationship described earlier. Methods for text selection will be described further in a later section.
  • the text to parse node mapping is used to determine the parse node which represents the selected text, and the parse tree node number is sent to the selection manager.
  • the designer 520 of FIG. 40 then obtains a display tool such as the stacked bar graph display 5430. Next, he obtains a visual representation of an aspect of the design, for example, in the source domain using the HDL text display 5440.
  • the display tool 5440 displays the text of an HDL source file. The example described in this section is shown in FIG. 32, FIG. 33, FIG. 34, FIG. 35, FIG. 36, FIG. 37, FIG. 38, and FIG. 39.
  • the designer 520 also selects a type of analysis to be performed from the available choices.
  • One approach is that the designer 520 selects it from a menu or a push button.
  • Another approach would be to have the designer 520 select it before selecting the text. In this example, assume that the designer 520 asks for the area of the gates which make up of the decode process.
  • the parse tree node number and the query type comprise a query that is sent to the data manager 125.
  • the desired analysis concerns the area of the gates that make up the selected parse node.
  • the data manager 125 can identify that the required information is in the gate domain.
  • the data manager 125 computes the area corresponding to the identified parse node.
  • the data manager does this by using the inter-domain mapping shown in FIG. 5 to identify the gates in the gate domain that correspond to that parse node.
  • the designer 520 wants to know what the area of one of the processes is, and the designer 520 used probe points to segregate the design to permit the intra domain mapping to the gate level.
  • the initial query sent to the data manager concerns the area of a VHDL process statement in the source domain.
  • the data manager ascertains that an area query must be answered in the mapped domain. Therefore, the data manager uses the intra-domain mapping capability to find the gates related to the process statement.
  • the data manager determines that the query must be divided into a subquery for each gate. In this situation, the data manager determines that the total area for the process can be computed by summing the area value for each gate.
  • each gate has several characteristics associated with it. One of these characteristics is area.
  • the data manager chooses an area analysis tool 5480 which can answer queries regarding gate area.
  • area analysis tool 5480 determines the area of a gate by looking up the area value for the gate in a technology library.
  • the technology library is provided by the semiconductor vendor who manufactures the physical gate.
  • area analysis tool 5480 For each subquery, area analysis tool 5480 then produces a numerical value for the area that is sent back to data manager 125. Each area value is the area of one of the gates corresponding to the process. The data manager then aggregates the area values returned by each subquery by adding them together.
  • the final area result is then sent to HDL text display tool 5440 which can display the result directly or use it to modify the display characteristics in the display tools.
  • the flexibility of the architecture shown in FIG. 40 permits multiple display tools.
  • the display tools relate digital circuit analysis information about parts of the GTech or mapped circuit to the source text that generates those parts. This section describes a number of display tools but by no means all display tools. An example is used to clarify the use of the display tools.
  • display tools are able to display resuits in one domain that are computed in another domain.
  • the designer is able to use a tool such as the stacked bar graph described below to investigate a design attribute such as gate count.
  • the designer can then view the source HDL from which the part of interest was synthesized. For example the designer can use the stacked bar graph to find a portion of the mapped circuit which has a high gate count. This mapped circuit portion can then be associated with the source HDL.
  • FIG. 43, FIG. 44, FIG. 45, FIG. 46, FIG. 47, FIG. 48, FIG. 49, and FIG. 50 show display techniques for displaying digital circuit analysis data.
  • FIG. 43, FIG. 44, FIG. 45, FIG. 46, FIG. 47, FIG. 48, FIG. 49, and FIG. 50 show the display tools displaying an AMD2910A design.
  • the source and resulting mapped circuit is described in Introduction to HDL-Based Design Using VHDL, by Steve Carlson, published in 1991, which is hereby incorporated by reference. This book is available from Synopsys, Inc., 700 East Middlefield Road, Mountain View, Calif. 94043-4033.
  • the display tools are further described in the HDL Advisor User Guide, Version 4.0a Beta Draft, which is available from Synopsys, Inc. of Mountain View, Calif. and is hereby incorporated by reference.
  • the HDL source for the AMD2910A design is partitioned into multiple files. A separate parse tree is created for each of the files according to conventional parsing techniques. Each parse tree is linked to the HDL source and to the GTech circuit created from it according to the methods described above.
  • the HDL source for the AMD2910A design infers levels of design hierarchy. The levels of hierarchy are linked to one another according to conventional techniques such as those used in Design Compiler produced by Synopsys Inc., in Mountain View, Calif.
  • FIG. 43 shows a stacked bar graph displaying information about the relative contributions of parts of the HDL source.
  • a design written in an HDL is described hierarchically, with higher level modules containing lower level modules. At a particular level in the hierarchy, the designer might want to know the characteristics of the modules visible at that level.
  • the stacked bar graph of FIG. 43 shows relative areas associated with different parts of the design.
  • At the highest level of the AMD 2910A there are five functional sub-blocks: CNTL -- BLK, MUX -- OUT -- BLK, REG -- BLK, UPC -- BLK, and STACK -- BLK.
  • the names of these blocks are shown in the display object list area 2610 of window 2600.
  • the total measured area is displayed at the bottom of the window.
  • the total area of the mapped circuit is shown as 1964.0 gates.
  • the characteristic is area. However, other characteristics such as power and time can be similarly displayed.
  • Each of the sub-blocks has a measured characteristic which is shown by text statements 2680 through 2684.
  • CNTL -- BLK uses 74.00 gates, which is 3.8% of the total as shown by statement 2680.
  • MUX -- OUT -- BLK occupies 148.00 gates, which is 7.5% of the total as shown by statement 2681.
  • REG -- BLK occupies 225.00 gates, which is 11.5% of the total as shown by statement 2682.
  • UPC -- BLK occupies 237.00 gates, which is 12.1% of the total as shown by statement 2683.
  • STACK -- BLK occupies 1280.00 gates, which is 65.2% of the total as shown by statement 2684.
  • a stacked bar graph is constructed by drawing a graphical box corresponding to each functional sub-block with the size of the box proportional to the percentage of the sub-block's characteristic to the total characteristic. This is shown with boxes 2630 through 2634.
  • the stacked bar graph display of FIG. 43 can be constructed without reference to the physical nature of the particular characteristic. Therefore, power, timing, or another characteristic can be displayed by the same software.
  • the data manager need only transfer the names of circuit objects, the numerical value associated with those circuit objects to the display tool, and a global id which the display tool can use to initiate further queries and update the selection manager.
  • each box such as box 2630 through box 2634, forming part of the stacked bar graph is a selectable button.
  • the user can "push" the button using conventional pointing and clicking techniques and gain information about the sub-block associated with the box.
  • FIG. 44 shows the result of the user selecting the sub-block MUX -- OUT -- BLK box by selecting box 2631.
  • the sub-block MUX -- OUT -- BLK itself contains two sub-blocks, OUT -- BLK and MUX -- BLK.
  • the total measured characteristic 2620 changes to 148.00 to reflect the size of MUX -- OUT -- BLK.
  • the sub-block OUT -- BLK has 49.00 gates representing 33.1% of the area of MUX -- OUT -- BLK, as indicated by statement 2780.
  • the sub-block MUX -- BLK has 99.00 gates representing 66.9% of the area of MUX -- OUT -- BLK, as indicated by statement 2781.
  • This information is also shown graphically by box 2731.
  • the window also shows the current location in the hierarchy with a path statement 2705.
  • statements such as statement 2780 could also act as buttons to change levels.
  • FIG. 45 shows the information displayed if the designer selects MUX -- BLK to see how the 99.00 gates are allocated.
  • the selection manager is updated with the current circuit selection.
  • the profiler allows the designer to quickly select a portion of the design which meets certain characteristics, as well as to view overall statistics for the design.
  • the histogram display of FIG. 46 provides a designer with information about the extent of problems in the design. For example, one aspect of the performance of a mapped circuit is the longest delay along any path from the output of one flip-flop to the input of another.
  • a timing verifier can determine arrival and required times throughout the mapped circuit. At any point in the mapped circuit, the arrival time can be determined relative to a clock edge by measuring the longest path from all registers affected by the clock to the point within the mapped circuit. Similarly, required times may be computed relative to a clock edge by measuring the longest path from the point in the mapped circuit to a register affected by the clock.
  • the timing verifier can determine the worst slack for each point within the mapped circuit by subtracting arrival from required times for each possible combination of relevant clock edges. The smallest, or most negative result can be considered the worst slack for that point in the mapped circuit.
  • the Design Compiler Reference Manual V3.1a from Synopsys describes timing analysis, and is hereby incorporated by reference. If any node has a negative slack time, then the timing constraint has not been met. If only a few nodes are have negative slacks, or the negative slacks are close to zero, then the designer might have a small problem that can be fixed by tuning a portion of the design. However, if many nodes have negative slacks or the slack times are large, then the designer faces a substantial design problem.
  • the histogram tool of FIG. 46 can provide guidance on the extent of a problem facing a designer.
  • the histogram display uses conventional histogram creation techniques.
  • the histogram tool displays the distribution of a numerical characteristic of the GTech or mapped circuit and allows a user to see a list of display objects representing circuit objects having that characteristic.
  • the example in FIG. 46 shows timing analysis for the AMD 2910A.
  • the histogram display tool forms a query asking the data manager about the desired attribute, in this case the slack time, of circuit objects in the design.
  • the data manager uses a timing analyzer to compute the slack times at several points in the circuit.
  • the mapped circuit nodes with similar slack times are grouped into categories, counted, and a histogram is created.
  • Histogram-list window 2900 contains two sub-windows: the histogram window 2920 and the list window 2910.
  • the histogram window 2920 contains bars 2930 through 2937 with one bar per range of values. The height of the bars indicates the number of nets that fall into that range. If the user selects one of the bars, the list window 2910 shows the list of names that identify the nets that are in that range. Individual items in the list display can be selected, as indicated by selected item 2915.
  • the selection manager is updated as the designer explores the design. For example, the circuit object with the least amount of slack time can be found by creating a slack histogram and viewing the display objects which make up the worst range of values. The designer can then use other display tools to gain more information about the selected circuit object.
  • FIG. 47 shows HDL Browser which is also called the HDL text display window.
  • the HDL Browser provides textual display of HDL source code that annotates that source code with additional information.
  • text display window 3000 contains three smaller windows.
  • Text window 3010 contains the source text.
  • Select window 3040 shows GTech or mapped circuit information related to text that has been selected.
  • Cursor window 3030 shows GTech or mapped circuit information related to text that is under the cursor.
  • Column report 3060 shows GTech or mapped circuit information associated with lines of the text.
  • the select window and cursor window are independent windows and not contained within the HDL browser.
  • selecting text can be done with the usual window based text selection mechanisms. For example, the designer could move a cursor to the relevant portion of the screen and push a button. Alternately, the designer could drag the cursor across an extended portion of text to be selected.
  • An alternate embodiment allows the designer to select all of the text corresponding to a parse node with a single visual selection.
  • the designer indicates the initial point or the visual selection as usual by moving the cursor and clicking a button.
  • the text window 3010 constructs a text box 3020 around the entire parse node represented by the text at which the cursor is pointing.
  • the text window draws a box around all of the text represented by the first parse node which fully contains the text.
  • the text display window shows the visual selection by drawing a box around all of the text representing the selected parse node.
  • One fast method of determining the limits of text box 3020 uses the parse tree representation described in co-pending U.S. application by Gregory entitled “Method and Apparatus for Context Sensitive Displays" filed on Jun. 3, 1994 as U.S. application Ser. No. 08/253,453.
  • cursor window 3030 shows a gate count of the GTech circuit parts associated with the display object under the cursor.
  • Select window 3040 shows information associated with selected text.
  • the size and font of the selected text 1050 is changed.
  • One fast method of determining the limits of selected text 1050 would be to use the parse tree representation described in co-pending U.S. application by Gregory entitled “Method and Apparatus for Context Sensitive Displays", filed on Jun. 3, 1994 as U.S. application Ser. No. 08/253,453.
  • the select window 3040 shows detailed information about the HDL construct MEM PSH -- PTR! 3050.
  • Statement 3080 shows the type of HDL construct that the selected circuit object is--in this case, the construct is an array index.
  • Statement 3083 shows the estimated area of the construct in the G-Tech domain 1510, here 530 area units.
  • Statement 3084 shows the length of the longest path in levels of logic from a register to the gates that implement the construct, here 18 gates.
  • Statement 3081 shows the parse tree node number.
  • a detailed list 3082 shows the netlist components in the G-Tech domain implementing the construct 3050. For each component in this list, the following information is displayed: the component's netlist instance name 3087, the type of netlist component 3088 (reference name), its contribution to the total area estimate 3089, and the class of netlist component 3090 e.g. cell, pin, net, or port. Other information could be displayed at the designer's option.
  • Column report 3060 shows information associated with each line.
  • the column report is showing the area associated with the HDL constructs on each line.
  • the virtual schematic display shown in FIG. 48 provides the designer with the ability to find the HDL source that provides inputs to and takes outputs from another point in the HDL source.
  • the virtual schematic display has a virtual schematic window 3100 which has three window regions: an input region 3110, a current region 3120, and an output region 3130.
  • the designer uses the cursor to indicate selected text 3150 in the current region. This selected text 3150 corresponds to a GTech circuit object 3151 (not shown) in the data manager.
  • GTech circuit object 3151 has inputs and outputs.
  • the data manager then links the input region 3110 to those portions of the HDL source text that show where the inputs of GTech circuit object 3151 originated.
  • the input "DATA" comes from an input to the module MULTIPLEXOR as indicated by input argument 3145.
  • the data manager also links the output region 3130 to those portions of the HDL source text that show where the outputs of GTech circuit object 3151 go to.
  • output "Z" goes to the output of module MULTIPLEXOR.
  • FIG. 49 shows the changes that occur in the regions.
  • the text of the output region now moves to the current region 3120.
  • the text of the output region changes to show synthesis source text corresponding to circuit objects driven by output argument 3155.
  • output argument 3155 drives another output at the next level module boundary, as shown by output argument 3156.
  • Input region 3110 changes to show all of the places in the source text that set or define the selected output argument 3155.
  • there are five text sources for output argument 3155 as shown in windows 3271, 3272, 3273, 3274, and 3275.
  • the originally selected statement 3150 is shown again in window 3272.
  • FIG. 50 shows the results of pursuing the output argument 3156.
  • the high level module definition appears in the current region 3120 while the input region 3110 displays the module interface shown in the current region of FIG. 49.
  • Inputs can be pursued in the same manner as outputs. Note that by selecting circuit objects via display objects in the virtual schematic the designer is updating the selection manager so the HDL Browser window is also updated as the GTech fan-in and fan-out is analyzed.
  • the collection of all of the points in a circuit leading to a particular point is referred to as the transitive fan-in of that point.
  • the collection of all of the points in a circuit that depend on the value of a particular point is the transitive fan-out.
  • the preceding example showed how to trace transitive fan-in and transitive fan-out using the virtual schematic.
  • the designer might need to consider the impact that a change in one part of the design would have other parts of the design. If the designer is considering changing the source HDL, the designer would find it useful to identify how the proposed change will influence the resulting GTech circuit.
  • the designer wishes to change a particular function in the source HDL. The designer will find it useful to determine all of the inputs to that function or all of the outputs to that function to see how the change will affect the remainder of the GTech circuit. While tracing all of the inputs (or outputs) of a particular part of the source HDL is a difficult task using only the HDL source, using the direct correspondence between the HDL and the initial GTech circuit formed during translation makes it possible to highlight the inputs (or outputs) in the source HDL.
  • the logic inspector window displays the transitive fan-in logic to selected endpoints in the design. This logic is calculated from the GTech representation of the design.
  • the logic inspector window displays the inputs that are used to compute a value within the design, the initial boolean structure implied by the HDL source, and the probable effect of boolean minimization after optimization.
  • Boolean minimization can be invoked from the logic inspector window to show the potential reduction of the original logic structure, which is based on logic level or component count reduction goals before logic optimization. Note that a portion of the GTech circuit is isolated for boolean minimization when the transitive fanin of an endpoint is selected.
  • the designer chooses the "New Logic" option in the logic inspector by choosing a menu item or pushing a button.
  • the logic inspector causes logic corresponding to the current circuit selection to be created as follows. First, the logic inspector determines the current circuit selection in the GTech domain by querying the selection manager. The selection manager sends the logic inspector a GTech circuit object. The logic inspector may limit the logic created by asking the designer to specify the bit position in the circuit selection from which to create the logic.
  • the logic inspector queries the data manager to compute all of the circuit objects which make up the transitive fan-in for the selected circuit object.
  • the logic inspector then asks the data manager to send the group GTech parts to a logic optimizer.
  • the logic optimizer optimizes the logic represented by the GTech parts and returns a string which represents the logic equations produced after the logic has been optimized. Note that the optimizer attempts to improve the GTech logic using standard optimization techniques such as those described above, but does not map it.
  • the designer can specify the optimization effort used when optimizing the logic.
  • the logic inspector displays the string returned as a schematic.
  • FIG. 52 shows the logic inspector displaying a graphical representation of logic created by the logic inspector. This logic was optimized using a medium level of effort. The optimization effort level determines the complexity of the optimization strategies which are invoked.
  • the schematics displayed by the logic inspector represent GTech boolean logic, rather than mapped circuit structures.
  • a property of GTech boolean logic is that simple gates such as AND, OR, NAND, and NOR gates do not differentiate between their inputs. Thus, there is no need to route signals between such gates. Therefore, the logic inspector symbol generator is very fast because it simply draws a gate for each operator in the boolean equation. The gates are connected directly to one another, creating complex gates which represent the boolean equation.
  • the logic inspector symbol generator creates complex symbols from boolean equations using a two step process. First, the symbol generator traces from each input to the outputs it drives in order to compute the size of the gates driving each symbol. Next, the symbol generator starts at the output of the equation and works backwards. Each boolean expression is displayed as a simple logic gate. As the symbol generator works backwards it places new gates directly behind the previous level. The gates are placed far enough apart so that there is room to place the driving gates before them. When the terminals of the equation are reached, they are simply connected to the pins of the last layer of logic. Note that the same terminal may be added to more than one pin, without needing to route the signal represented by the terminal from a single port.
  • FIG. 51 shows the path browser window displaying a path in a GTech representation of the AMD 2910A.
  • the path browser window enables the designer to explore graphically the connections in the design.
  • This window displays a single path in the design, including all of the fan-in and fan-out logic of the elements along the path.
  • the paths may be displayed in either the GTech or the gate domain. Connectivity implications of the HDL source can be understood by using the intra-domain mapping capability to relate any point on a GTech path to the source HDL.
  • the path browser window shows the fanout of drivers on the displayed path. An example of this is GTech part 5240. Showing fanouts allows the designer to view the effect of loading on the path.
  • the path browser window also shows the fanin onto the path. An example of this is GTech gate 5230. Levels of hierarchy are displayed as boxes 5220 around logic on the path. Levels of hierarchy are important because they might influence the optimizer's ability to improve the GTech or mapped circuit.
  • the path browser window is interactive. By clicking on a display object in the path browser window, the user can expand that display object to show all of the inputs to and outputs from the circuit object represented by that display object. GTech part 5210 has been expanded in this manner. Clicking on a logic element also updates the circuit selection stored in the selection manager. An alternate path can be displayed by choosing a new pin or port and using that pin or port as the startpoint for another GTech or mapped path.
  • start/end mode further leverages the intra-domain mapping capability.
  • Start/End mode allows the designer to choose a path in the mapped logic domain.
  • the start and end points of the path are mapped to the GTech domain using the intra-domain mapping.
  • the GTech timing verifier then computes the longest path in the GTech circuit between the start and end points.
  • the path is displayed in the HDL text. This process allows the designer to perform timing analysis in the original HDL and to improve the timing characteristics of the design at the source level.
  • the path browser window displays a graphical representation of a path through the digital circuit arising from an HDL.
  • the path might be composed of either GTech or mapped logic components.
  • the architecture of the HDL Advisor allows any number of digital circuit analysis tools to be registered to answer queries.
  • analysis tools includes:
  • This section describes an example using the three part architecture described in preceding sections.
  • This example uses an AMD2910A design.
  • the source and resulting mapped circuit is described in Introduction to HDL-Based Design Using VHDL, by Steve Carlson, published in 1991, which is hereby incorporated by reference.
  • This book is available from Synopsys, Inc., 700 East Middlefield Road, Mountain View, Calif. 94043-4033.
  • the AMD2910A design has been loaded into the HDL Advisor as described in the HDL Advisor User Guide, Version 4.0a Beta Draft, which is available from Synopsys, Inc. of Mountain View, Calif. and is hereby incorporated by reference.
  • the designer wishes to evaluate the component count of a GTech design before synthesis and then identify the portions of the HDL code that consume a large number of components.
  • FIG. 55 shows the stacked bar graph displaying component counts for the AMD2910A.
  • the designer first opens the stacked bar graph display window using a conventional method such as choosing a menu item. The designer then clicks on the Component Count icon 5720 in the stacked bar graph display. The data that appears in this display shows the distribution of the segments within the "CORE" design of the AMD2910A. Notice that the display is partitioned in terms of the HDL source. Each section of the stacked bar graph represents a circuit object in the source domain. Analysis is done in the GTech domain, but the results are grouped by objects in the source domain.
  • the designer sees that the majority of the components are used in the "STACK -- BLK" component. This is indicated by the display object, in this case a large bar, representing the components in the STACK -- BLK 5710.
  • the designer now wishes to obtain further information regarding the distribution of the components within the STACK -- BLK.
  • the designer selects display object representing the STACK -- BLK 5710 by clicking on it.
  • the designer looks deeper into the STACK -- BLK by clicking the PUSH IN icon 5730.
  • An alternate method of simultaneously selecting the display object and looking deeper is to double click on the display object.
  • FIG. 56 shows the stacked bar graph displaying component counts for the stack module of the AMD2910A.
  • the HDL text browser displays the HDL source which instantiated the STACK -- BLK.
  • FIG. 57 shows the HDL text browser with the source code for the STACK -- BLK 5910 hilighted By hilighting the source code for the STACK -- BLK, the HDL text browser is indicating both that the STACK -- BLK circuit object is selected, and also providing a convenient mechanism for the user to see the selected display object.
  • the designer selects the largest single element bar in the STACK -- BLK display 5820.
  • This bar represents a variable array index in the GTech circuit.
  • the HDL Browser highlights the HDL source code for the variable array index, and the designer may consider if the construct could be rewritten to reduce the component count. For example, the array size may be reduced, or the data may be extracted with a shift operation which consumes less components. Alternatively, the designer can select other large bars in the STACK -- BLK so he can consider rewriting their related source HDL.
  • This tool architecture helps the circuit designer by graphically displaying important design characteristics, such as component count, and providing the designer with a simple mechanism to display the portion of the HDL source that is responsible for the particular characteristics.
  • FIG. 61 shows the communication flow as the designer analyzes the design.
  • the designer 520 uses the stacked bar graph display tool 5430 which is also shown in shown in FIG. 55 to display a stacked bar graph of the component counts of the entire GTech circuit.
  • the stacked bar graph display tool 5430 appears in a conventional window on the screen of a computer.
  • the stacked bar graph display tool 5430 issues a query to the data manager 125 to find the component counts of all of the circuit objects which make the entire design.
  • the data manager 125 there is a special global id called the ⁇ design -- id> which represents the entire design.
  • finding component counts for the entire design is a two step process.
  • the stacked bar graph display tool (-- --) 5430 issues a query 6403 to the data manager 125 asking for a list of the components which make up the design in the source domain.
  • the query 6403 has the following fields: ("composition", ⁇ design -- id>!, False, Null).
  • "Composition” is the type of query and indicates that the query is requesting the circuit objects which make up the objects in the object list, which is ⁇ design -- id>!. False indicates that the results should not be cached.
  • Null is the aggregation function because none is needed for a composition query.
  • the data manager 125 then computes the answer to the query 6403.
  • the data manager 125 determines that a composition query 6403 can be anwered by a composition analysis tool 6400 which operates in the GTech domain.
  • the data manager 125 uses the domain mapper to map the ⁇ design -- id> from the source domain to a circuit object in the GTech domain. Note that analysis tools do not use global id's, but rather circuit objects in a domain.
  • the data manager 125 then sends the composition analysis tool 6400 a query 6406 to find the composition of the design.
  • the query 6406 has the following fields: ("composition", ⁇ design>, False, Null).
  • composition is the type of query and indicates that the query is requesting the circuit objects which make up the design, which is indicated by ⁇ design>. False indicates that the results should not be cached. Null is the aggregation function because none is needed for a composition query.
  • the composition analysis tool 6400 then traverses the GTech circuit, finds the composition of the design, and returns the data manager 125 a message 6409 with the result.
  • the message 6409 is: message ("composition -- result", ⁇ CNTL -- BLK>, ⁇ MUX -- OUT -- BLK>, ⁇ UPC -- BLK>, ⁇ REG -- BLK>, ⁇ STACK -- BLK>!).
  • the data manager 125 determines global ids for each of these objects.
  • the data manager 125 uses the objects as indices into a table to look up the global ids. In another embodiment, the global ids are stored on the objects. The data manager 125 then sends the stacked bar graph 5430 a response 6412 to the query.
  • the return message is message ("composition -- result", ⁇ CNTL -- BLK -- ID>, ⁇ MUX -- OUT -- BLK -- ID>, ⁇ UPC -- BLK -- ID>, ⁇ REG -- BLK -- ID>, ⁇ STACK -- BLK -- ID>!).
  • the stacked bar graph display tool 5430 issues a query 6415 to the data manager 125 asking for the component count of each of the circuit objects in the composition list.
  • the query 6415 has the following fields: ("component -- count", ⁇ CNTL -- BLK -- ID>, ⁇ MUX -- OUT -- BLK -- ID>, ⁇ UPC -- BLK -- ID>, ⁇ REG -- BLK -- ID>, ⁇ STACK -- BLK -- ID>!, False, Sum).
  • Component -- count is the type of query and indicates that the query is requesting the circuit objects which make up the objects in the object list, ⁇ CNTL -- BLK -- ID>, ⁇ MUX -- OUT -- BLK -- ID>, ⁇ UPC -- BLK -- ID>, ⁇ REG -- BLK -- ID>, ⁇ STACK -- BLK -- ID>!. False indicates that the results should not be cached.
  • Sum is the aggregation function because a component count result is aggregated by summing the results of subqueries. In one embodiment, sum is chosen as the aggregation function by looking up the component -- count query type in a table.
  • the data manager 125 then computes the answer to the query 6415.
  • the data manager 125 determines that a component -- count query can be answered by a component count analysis tool 5470 which operates in the GTech domain.
  • the data manager 125 uses the domain mapper to map the objects in the object list from the source domain to a circuit object in the GTech domain.
  • the data manager 125 then creates a subquery for each of the objects in the object list.
  • the first subquery 6418 has the following fields: ("component -- count", ⁇ CNTL -- BLK>, False, Sum).
  • Component -- count is the type of query and indicates that the query is requesting the circuit objects which make up the CNTL -- BLK, which is indicated by ⁇ CNTL -- BLK>. False indicates that the results should not be cached. Sum is the aggregation function because component count results are aggregated by summing the component counts together.
  • the component count analysis tool 5470 then traverses the GTech circuit, finds the component count of each element in the CNTL -- BLK, sums all of the component counts together, and returns the data manager 125 a message 6421 with the result.
  • the message 6421 is: message ("component -- count -- result", 119.0).
  • the data manager 125 issues a series of subqueries 6424 for each of the objects in the object list and the component count analysis tool 5470 sends response messages 6427.
  • the data manager 125 then sends the stacked bar graph a response to the original query.
  • the return message 6430 is message("composition -- result", 119.0, 124.0, 194.0, 294.0, 1978.0 !).
  • the stacked bar graph display uses these number to create the stacked bar graph shown in FIG. 55.
  • the designer selects the display object representing the STACK -- BLK to obtain more information about this part of the design.
  • the stacked bar graph sends the selection manager 5460 a message 6433 indicating the new selection.
  • the message 6433 is message ("selection -- set", ⁇ STACK -- BLK -- ID>).
  • the selection manager 5460 in turn broadcasts the selection to all of the display tools using a message.
  • the message 6436 is message( "selection", ⁇ STACK -- BLK -- ID>).
  • One of the recipients of this message 6436 is the HDL text browser 5440.
  • the HDL text browser 5440 sends a message 6439 to the data manager 125 to get the selection as a source domain circuit object.
  • the message 6439 is: message ("GetGlobalId", ⁇ STACK -- BLK -- ID>!, Source).
  • the data manager 125 returns a message 6440 to the HDL text browser 5440 which includes the global id which represents the STACK -- BLK in the source domain.
  • the HDL text browser 5440 then sends a message 6441 to the data manager 125 requesting the parse tree node number corresponding to the global id.
  • the message 6441 is: message ("GlobalIdToLocalID", ⁇ STACK -- BLK -- ID>!).
  • the data manager 125 returns a message 6442 which includes the parse tree node number corresponding to the ⁇ STACK -- BLK -- ID> to the HDL text browser 5440.
  • the HDL text browser 5440 then hilights the text which corresponds to the parse tree node represented by the parse tree node number.
  • the text is hilighted by drawing a darker background for it as shown in FIG. 57.
  • the designer now obtains further information regarding the distribution of the elements within the STACK -- BLK and the stacked bar graph display changes to show the component counts of modules within the STACK -- BLK.
  • the stacked bar graph display determines the composition and the component -- count of the STACK -- BLK module.
  • the stacked bar graph 5430 sends the data manager 125 a query 6445 ("composition", ⁇ STACK -- BLK -- ID>!, False, Null).
  • the data manager 125 determines the answer to the query 6445.
  • the data manager 125 determines that a composition query can be answered by a composition analysis tool 6400 which operates in the GTech domain.
  • the data manager 125 uses the domain mapper to map the ⁇ STACK -- BLK -- ID> from the source domain to a circuit object in the GTech domain.
  • the data manager 125 then sends the composition analysis tool 6400 a query 6448 to find the composition of the STACK -- BLK.
  • the query 6448 has the following fields: ("composition”, ⁇ STACK -- BLK>, False, Null) "composition" is the type of query and indicates that the query 6448 is requesting the circuit objects which make up the STACK -- BLK, which is indicated by ⁇ STACK -- BLK>. False indicates that the results should not be cached. Null is the aggregation function because none is needed for a composition query.
  • the composition analysis tool 6400 then traverses the GTech circuit, finds the composition of the STACK -- BLK, and returns the data manager 125 a message 6451 with the result.
  • the message 6451 is: message ("composition -- result", ⁇ Bool -- mem>, ⁇ Bool>, ⁇ Sel -- MEM>, ⁇ Bool -- STK -- DATA>, . . . !).
  • the data manager 125 After converting from objects to global id's, the data manager 125 sends the stacked bar graph 5430 a response to the query.
  • the return message 6454 is message ("composition -- result", ⁇ Bool -- Mem -- ID>, ⁇ Bool -- ID>, ⁇ Sel -- MEM -- ID>, ⁇ Bool -- STK -- DATA -- ID>, . . .
  • ⁇ Bool -- Mem -- ID>, ⁇ Bool -- ID>, ⁇ Sel -- MEM -- ID>, ⁇ Bool -- STK -- DATA -- ID>, . . . ! is a partial list of the elements in the STACK -- BLK. The other global ids are omitted for clarity.
  • the stacked bar graph display tool 5430 issues a query 6457 to the data manager 125 asking for the component count of each of the circuit objects in the composition list.
  • the query 6457 has the following fields: ("component -- count", ⁇ Bool -- Mem -- ID>, ⁇ Bool -- ID>, ⁇ Sel -- MEM -- ID>, ⁇ Bool -- STK -- DATA -- ID>, . . . !, False, Source, Sum).
  • the data manager 125 answers the component count query 6457 for this new object list using the component count analysis tool 5470 in the same fashion as described above.
  • the stacked bar graph display 5430 uses the returned results to create the stacked bar graph shown in FIG. 56.
  • the designer 520 selects the largest single element bar 5810 in the STACK -- BLK display.
  • the selection manager 5460 communicates the new selection to the HDL text display 5440 in the same fashion as described above.
  • the HDL text display 5440 then highlights the HDL source code for the variable array index.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Design And Manufacture Of Integrated Circuits (AREA)
US08/417,147 1994-04-12 1995-04-03 Architecture and methods for a hardware description language source level analysis and debugging system Expired - Lifetime US5937190A (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US08/417,147 US5937190A (en) 1994-04-12 1995-04-03 Architecture and methods for a hardware description language source level analysis and debugging system
JP7526539A JPH09512115A (ja) 1994-04-12 1995-04-12 ハードウエア記述言語ソースレベル分析のためのアーキテクチャおよび方法ならびにデバッギングシステム
EP95916412A EP0755544A1 (fr) 1994-04-12 1995-04-12 Architecture et procedes pour l'analyse au niveau de la source d'un langage de description de materiel, et systeme de mise au point correspondant
CA002185908A CA2185908A1 (fr) 1994-04-12 1995-04-12 Architecture et procedes pour l'analyse au niveau de la source d'un langage de description de materiel, et systeme de mise au point correspondant
AU22920/95A AU2292095A (en) 1994-04-12 1995-04-12 Architecture and methods for a hardware description language source level analysis and debugging system
PCT/US1995/004660 WO1995027948A1 (fr) 1994-04-12 1995-04-12 Architecture et procedes pour l'analyse au niveau de la source d'un langage de description de materiel, et systeme de mise au point correspondant

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US22614794A 1994-04-12 1994-04-12
US08/253,470 US6132109A (en) 1994-04-12 1994-06-03 Architecture and methods for a hardware description language source level debugging system
US08/417,147 US5937190A (en) 1994-04-12 1995-04-03 Architecture and methods for a hardware description language source level analysis and debugging system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US08/253,470 Continuation-In-Part US6132109A (en) 1994-04-12 1994-06-03 Architecture and methods for a hardware description language source level debugging system

Publications (1)

Publication Number Publication Date
US5937190A true US5937190A (en) 1999-08-10

Family

ID=27397572

Family Applications (1)

Application Number Title Priority Date Filing Date
US08/417,147 Expired - Lifetime US5937190A (en) 1994-04-12 1995-04-03 Architecture and methods for a hardware description language source level analysis and debugging system

Country Status (6)

Country Link
US (1) US5937190A (fr)
EP (1) EP0755544A1 (fr)
JP (1) JPH09512115A (fr)
AU (1) AU2292095A (fr)
CA (1) CA2185908A1 (fr)
WO (1) WO1995027948A1 (fr)

Cited By (98)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6080201A (en) * 1998-02-10 2000-06-27 International Business Machines Corporation Integrated placement and synthesis for timing closure of microprocessors
US6167561A (en) * 1998-06-08 2000-12-26 Synopsis, Inc. Method and apparatus for entry of timing constraints
US6216258B1 (en) * 1998-03-27 2001-04-10 Xilinx, Inc. FPGA modules parameterized by expressions
US6237129B1 (en) 1998-03-27 2001-05-22 Xilinx, Inc. Method for constraining circuit element positions in structured layouts
US6240376B1 (en) 1998-07-24 2001-05-29 Mentor Graphics Corporation Method and apparatus for gate-level simulation of synthesized register transfer level designs with source-level debugging
US6243851B1 (en) 1998-03-27 2001-06-05 Xilinx, Inc. Heterogeneous method for determining module placement in FPGAs
US6243848B1 (en) * 1996-10-09 2001-06-05 Bull S.A. Process for analyzing complex structures and system for implementing a process of this type
US6260182B1 (en) 1998-03-27 2001-07-10 Xilinx, Inc. Method for specifying routing in a logic module by direct module communication
US20010016935A1 (en) * 2000-02-09 2001-08-23 Shinya Furusawa System and method for verifying hardware description
US6292925B1 (en) 1998-03-27 2001-09-18 Xilinx, Inc. Context-sensitive self implementing modules
US6317860B1 (en) * 1996-10-28 2001-11-13 Altera Corporation Electronic design automation tool for display of design profile
US6336087B2 (en) * 1998-07-24 2002-01-01 Luc M. Burgun Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging
US6336209B1 (en) * 1998-06-17 2002-01-01 Fuji Xerox, Co., Ltd Information processing system that processes portions of an application program using programmable logic circuits
US6430732B1 (en) 1998-03-27 2002-08-06 Xilinx, Inc. Method for structured layout in a hardware description language
US6442562B1 (en) * 2000-03-15 2002-08-27 International Business Machines Corporation Apparatus and method for using incomplete cached balance sets to generate incomplete or complete cached balance sets and balance values
US20020123873A1 (en) * 2000-12-29 2002-09-05 International Business Machines Corporation Signal override for simulation models
US20020147576A1 (en) * 2001-04-09 2002-10-10 Yu-Chin Hsu System for characterizing simulated circuit logic and behavior
US20020172210A1 (en) * 2001-05-18 2002-11-21 Gilbert Wolrich Network device switch
US6493648B1 (en) * 1999-08-16 2002-12-10 Sequence Design, Inc. Method and apparatus for logic synthesis (inferring complex components)
US20030018460A1 (en) * 2001-07-20 2003-01-23 Chun-Chih Yang Method to preserve comments of circuit simulation text file
US20030028630A1 (en) * 2001-07-31 2003-02-06 Gerhard Bischof Method and system for processing topology data and geometry data of networks
US6519755B1 (en) * 1999-08-16 2003-02-11 Sequence Design, Inc. Method and apparatus for logic synthesis with elaboration
US20030046052A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Simulating a logic design
US20030046054A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Providing modeling instrumentation with an application programming interface to a GUI application
US20030046051A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Unified design parameter dependency management method and apparatus
US20030046640A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Generating a logic design
US20030046053A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Logic simulation
US20030046652A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Gate estimation process and method
US20030046641A1 (en) * 2001-08-29 2003-03-06 Fennell Timothy J. Representing a simulation model using a hardware configuration database
WO2003021493A2 (fr) * 2001-08-29 2003-03-13 Intel Corporation (A Delaware Corporation) Affichage d'informations lie a une structure logique
US20030069724A1 (en) * 1999-11-30 2003-04-10 Bridges2Silicon, Inc. Method and system for debugging an electronic system using instrumentation circuitry and a logic analyzer
US6557160B2 (en) * 1999-12-21 2003-04-29 Khalil Shalish Correlation of behavioral HDL signals
US20030083858A1 (en) * 2001-10-29 2003-05-01 Honeywell International Inc. Incremental automata verification
US6581191B1 (en) 1999-11-30 2003-06-17 Synplicity, Inc. Hardware debugging in a hardware description language
US20030135355A1 (en) * 2002-01-17 2003-07-17 Wheeler William R. Modeling a logic design
US20030145311A1 (en) * 2002-01-25 2003-07-31 Wheeler William R. Generating simulation code
US20030200540A1 (en) * 2002-04-18 2003-10-23 Anoop Kumar Method and apparatus for integrated instruction scheduling and register allocation in a postoptimizer
US20030208747A1 (en) * 2002-05-06 2003-11-06 Sun Microsystems, Inc. Method for debugging an integrated circuit
US20040015825A1 (en) * 2001-01-31 2004-01-22 Mikito Iwamasa Method and computer program product for localizing an interruption structure included in a hierarchical structure of a specification
US6684381B1 (en) * 2000-09-29 2004-01-27 Hewlett-Packard Development Company, L.P. Hardware description language-embedded regular expression support for module iteration and interconnection
US20040024779A1 (en) * 2002-07-31 2004-02-05 Perry Ronald N. Method for traversing quadtrees, octrees, and N-dimensional bi-trees
US6697773B1 (en) 1998-05-19 2004-02-24 Altera Corporation Using assignment decision diagrams with control nodes for sequential review during behavioral simulation
US20040049753A1 (en) * 2002-09-10 2004-03-11 Matsushita Electric Industrial Co., Ltd. System for estimating performance of integrated circuit in register transfer level
US20040111713A1 (en) * 2002-12-06 2004-06-10 Rioux Christien R. Software analysis framework
US6766504B1 (en) * 2002-08-06 2004-07-20 Xilinx, Inc. Interconnect routing using logic levels
US20040143809A1 (en) * 2003-01-22 2004-07-22 Cowan Joseph W. Net segment analyzer for chip CAD layout
US6823497B2 (en) 1999-11-30 2004-11-23 Synplicity, Inc. Method and user interface for debugging an electronic system
US20050010880A1 (en) * 1999-11-30 2005-01-13 Bridges2Silicon, Inc. Method and user interface for debugging an electronic system
US20050015755A1 (en) * 2003-07-18 2005-01-20 Agere Systems Incorporated System and method for automatically generating a hierarchical register consolidation structure
US20050055612A1 (en) * 2003-08-22 2005-03-10 Takamitsu Yamada Design supporting apparatus
EP1569144A2 (fr) * 2004-02-27 2005-08-31 NEC Electronics Corporation Système, procédé et program pour la visualization des correspondences entre la description comportemental et de bas niveau d'un circuit intégré
US20050229154A1 (en) * 2001-02-23 2005-10-13 Complementsoft Llc System and method for generating and maintaining software code
US6961690B1 (en) * 1998-05-19 2005-11-01 Altera Corporation Behaviorial digital simulation using hybrid control and data flow representations
US20060095250A1 (en) * 2004-11-03 2006-05-04 Microsoft Corporation Parser for natural language processing
US7072818B1 (en) * 1999-11-30 2006-07-04 Synplicity, Inc. Method and system for debugging an electronic system
US7076751B1 (en) * 2003-01-24 2006-07-11 Altera Corporation Chip debugging using incremental recompilation
US20060159710A1 (en) * 1989-02-15 2006-07-20 Witold Cieplak Pertussis toxin gene:cloning and expression of protective antigen
US7093224B2 (en) 2001-08-28 2006-08-15 Intel Corporation Model-based logic design
US20060277293A1 (en) * 2005-06-06 2006-12-07 Chagoly Bryan C Enabling and disabling byte code inserted probes based on transaction monitoring tokens
US20060277028A1 (en) * 2005-06-01 2006-12-07 Microsoft Corporation Training a statistical parser on noisy data by filtering
US20070006125A1 (en) * 2001-04-20 2007-01-04 Gutberlet Peter P Hierarchical presentation techniques for a design tool
US7206967B1 (en) 2004-02-09 2007-04-17 Altera Corporation Chip debugging using incremental recompilation and register insertion
US20070113211A1 (en) * 2005-11-17 2007-05-17 Lizheng Zhang Efficient statistical timing analysis of circuits
US7222315B2 (en) 2000-11-28 2007-05-22 Synplicity, Inc. Hardware-based HDL code coverage and design analysis
US20070124717A1 (en) * 2005-11-30 2007-05-31 Freescale Semiconductor, Inc. Method and program product for protecting information in EDA tool design views
US7240303B1 (en) 1999-11-30 2007-07-03 Synplicity, Inc. Hardware/software co-debugging in a hardware description language
US20070168741A1 (en) * 2005-11-17 2007-07-19 International Business Machines Corporation Method, system and program product for facilitating debugging of simulation results obtained for an optimized simulation model of a device design having hierarchically-connected components
US7380226B1 (en) * 2004-12-29 2008-05-27 Cadence Design Systems, Inc. Systems, methods, and apparatus to perform logic synthesis preserving high-level specification
US7539900B1 (en) 2003-07-29 2009-05-26 Altera Corporation Embedded microprocessor for integrated circuit testing and debugging
US20090142736A1 (en) * 1998-12-22 2009-06-04 Accenture Global Services Gmbh Goal Based System Utilizing a Table Based Architecture
US20090293032A1 (en) * 2003-05-09 2009-11-26 Levent Oktem Method and apparatus for circuit design and retiming
US20090307639A1 (en) * 2008-06-10 2009-12-10 Oasis Tooling, Inc. Methods and devices for independent evaluation of cell integrity, changes and origin in chip design for production workflow
US7660778B1 (en) * 1998-12-22 2010-02-09 Accenture Global Services Gmbh Runtime program analysis tool for a simulation engine
US20100083228A1 (en) * 2008-09-30 2010-04-01 International Business Machines Corporation Mapping a Class, Method, Package, and/or Pattern to a Component
US20100153899A1 (en) * 2008-12-16 2010-06-17 Mcelvain Kenneth S Methods and apparatuses for designing logic using arithmetic flexibility
US20100251201A1 (en) * 2009-03-26 2010-09-30 Altera Corporation Interactive simplification of schematic diagram of integrated circuit design
US7827510B1 (en) 2002-06-07 2010-11-02 Synopsys, Inc. Enhanced hardware debugging with embedded FPGAS in a hardware description language
US20100318965A1 (en) * 2009-06-16 2010-12-16 International Business Machines Corporation Computing system with compile farm
US20100325611A1 (en) * 2009-06-18 2010-12-23 Hudson Iii Duncan G Providing Target Specific Information for Textual Code at Edit Time
US20110047522A1 (en) * 2009-05-21 2011-02-24 Dane Mark W P Hardware Description Language Editing Engine
US8099271B2 (en) 1999-11-30 2012-01-17 Synopsys, Inc. Design instrumentation circuitry
US20120117524A1 (en) * 2010-11-05 2012-05-10 International Business Machines Corporation Reusable structured hardware description language design component
US8447581B1 (en) * 2009-09-15 2013-05-21 Xilinx, Inc. Generating simulation code from a specification of a circuit design
US8613080B2 (en) 2007-02-16 2013-12-17 Veracode, Inc. Assessment and analysis of software security flaws in virtual machines
US20140156703A1 (en) * 2012-11-30 2014-06-05 Altera Corporation Method and apparatus for translating graphical symbols into query keywords
US20140282315A1 (en) * 2013-03-14 2014-09-18 Synopsys, Inc. Graphical view and debug for coverage-point negative hint
US20140344345A1 (en) * 2005-05-26 2014-11-20 Citrix Systems, Inc. Systems and methods for using an http-aware client agent
US20150106776A1 (en) * 2001-10-24 2015-04-16 Cypress Semiconductor Corporation Techniques for generating microcontroller configuration information
US9122825B2 (en) 2011-06-10 2015-09-01 Oasis Tooling, Inc. Identifying hierarchical chip design intellectual property through digests
US9286063B2 (en) 2012-02-22 2016-03-15 Veracode, Inc. Methods and systems for providing feedback and suggested programming methods
US20170147720A1 (en) * 2015-11-25 2017-05-25 Synopsys, Inc. Annotating isolated signals
US9948608B2 (en) 2006-08-03 2018-04-17 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US10268798B2 (en) 2015-09-22 2019-04-23 International Business Machines Corporation Condition analysis
US10489541B1 (en) * 2017-11-21 2019-11-26 Xilinx, Inc. Hardware description language specification translator
USD921651S1 (en) * 2019-06-17 2021-06-08 Tata Consultancy Services Limited Display screen with animated graphical user interface
USD921650S1 (en) * 2019-06-17 2021-06-08 Tata Consultancy Services Limited Display screen with animated graphical user interface
USD922401S1 (en) * 2019-06-17 2021-06-15 Tata Consultancy Services Limited Display screen with animated graphical user interface
USD922400S1 (en) * 2019-06-13 2021-06-15 Tata Consultancy Services Limited Display screen with animated graphical user interface

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6152612A (en) * 1997-06-09 2000-11-28 Synopsys, Inc. System and method for system level and circuit level modeling and design simulation using C++
US6477698B1 (en) 1999-11-09 2002-11-05 Khalil Shalish Encapsulation of HDL process descriptions to provide granularity at the process level
CN113778811A (zh) * 2021-09-28 2021-12-10 重庆邮电大学 基于深度卷积迁移学习软件系统故障监测方法及系统

Citations (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4546435A (en) * 1980-06-24 1985-10-08 Herbert Frank P Graphic computer system and keyboard
US4667290A (en) * 1984-09-10 1987-05-19 501 Philon, Inc. Compilers using a universal intermediate language
US4703435A (en) * 1984-07-16 1987-10-27 International Business Machines Corporation Logic Synthesizer
US4827427A (en) * 1987-03-05 1989-05-02 Hyduke Stanley M Instantaneous incremental compiler for producing logic circuit designs
US4852173A (en) * 1987-10-29 1989-07-25 International Business Machines Corporation Design and construction of a binary-tree system for language modelling
US4866663A (en) * 1987-02-13 1989-09-12 Sanders Associates, Inc. Simulation system
US4868770A (en) * 1987-12-02 1989-09-19 Analogy, Inc. Simulation results enhancement method and system
US4882690A (en) * 1985-09-26 1989-11-21 Hitachi, Ltd. Incremental logic synthesis method
US4907180A (en) * 1987-05-04 1990-03-06 Hewlett-Packard Company Hardware switch level simulator for MOS circuits
US4942536A (en) * 1985-04-19 1990-07-17 Hitachi, Ltd. Method of automatic circuit translation
US4942615A (en) * 1987-02-20 1990-07-17 Fujitsu Limited Gate processor arrangement for simulation processor system
US4967386A (en) * 1988-04-22 1990-10-30 Hitachi, Ltd. Simulation method for modifiable simulation model
US4970664A (en) * 1988-06-10 1990-11-13 Kaiser Richard R Critical path analyzer with path context window
US5111413A (en) * 1989-03-24 1992-05-05 Vantage Analysis Systems, Inc. Computer-aided engineering
US5146583A (en) * 1987-09-25 1992-09-08 Matsushita Electric Industrial Co., Ltd. Logic design system for creating circuit configuration by generating parse tree from hardware description language and optimizing text level redundancy thereof
US5191541A (en) * 1990-05-14 1993-03-02 Sun Microsystems, Inc. Method and apparatus to improve static path analysis of digital circuits
US5191646A (en) * 1986-11-20 1993-03-02 Hitachi, Ltd. Display method in software development support system
US5265254A (en) * 1991-08-14 1993-11-23 Hewlett-Packard Company System of debugging software through use of code markers inserted into spaces in the source code during and after compilation
US5282148A (en) * 1989-05-23 1994-01-25 Vlsi Technology, Inc. Method and apparatus for the design and fabrication of integrated circuits employing logic decomposition algorithms for the timing optimization of multilevel logic
US5282146A (en) * 1990-05-02 1994-01-25 Kabushiki Kaisha Toshiba Test assistant system for logical design process
US5329471A (en) * 1987-06-02 1994-07-12 Texas Instruments Incorporated Emulation devices, systems and methods utilizing state machines
US5335191A (en) * 1992-03-27 1994-08-02 Cadence Design Systems, Inc. Method and means for communication between simulation engine and component models in a circuit simulator
US5377997A (en) * 1992-09-22 1995-01-03 Sierra On-Line, Inc. Method and apparatus for relating messages and actions in interactive computer games
US5437037A (en) * 1992-06-05 1995-07-25 Mega Chips Corporation Simulation using compiled function description language
US5446900A (en) * 1992-07-24 1995-08-29 Microtec Research, Inc. Method and apparatus for statement level debugging of a computer program
US5452239A (en) * 1993-01-29 1995-09-19 Quickturn Design Systems, Inc. Method of removing gated clocks from the clock nets of a netlist for timing sensitive implementation of the netlist in a hardware emulation system
US5541849A (en) * 1990-04-06 1996-07-30 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including estimation and comparison of timing parameters
US5544066A (en) * 1990-04-06 1996-08-06 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including estimation and comparison of low-level design constraints
US5544067A (en) * 1990-04-06 1996-08-06 Lsi Logic Corporation Method and system for creating, deriving and validating structural description of electronic system from higher level, behavior-oriented description, including interactive schematic design and simulation
US5544068A (en) * 1993-03-09 1996-08-06 Hitachi, Ltd. System and method for optimizing delays in semiconductor circuits
US5553002A (en) * 1990-04-06 1996-09-03 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, using milestone matrix incorporated into user-interface
US5555201A (en) * 1990-04-06 1996-09-10 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including interactive system for hierarchical display of control and dataflow information
US5557531A (en) * 1990-04-06 1996-09-17 Lsi Logic Corporation Method and system for creating and validating low level structural description of electronic design from higher level, behavior-oriented description, including estimating power dissipation of physical implementation

Patent Citations (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4546435A (en) * 1980-06-24 1985-10-08 Herbert Frank P Graphic computer system and keyboard
US4703435A (en) * 1984-07-16 1987-10-27 International Business Machines Corporation Logic Synthesizer
US4667290A (en) * 1984-09-10 1987-05-19 501 Philon, Inc. Compilers using a universal intermediate language
US4942536A (en) * 1985-04-19 1990-07-17 Hitachi, Ltd. Method of automatic circuit translation
US4882690A (en) * 1985-09-26 1989-11-21 Hitachi, Ltd. Incremental logic synthesis method
US5191646A (en) * 1986-11-20 1993-03-02 Hitachi, Ltd. Display method in software development support system
US4866663A (en) * 1987-02-13 1989-09-12 Sanders Associates, Inc. Simulation system
US4942615A (en) * 1987-02-20 1990-07-17 Fujitsu Limited Gate processor arrangement for simulation processor system
US4827427A (en) * 1987-03-05 1989-05-02 Hyduke Stanley M Instantaneous incremental compiler for producing logic circuit designs
US4907180A (en) * 1987-05-04 1990-03-06 Hewlett-Packard Company Hardware switch level simulator for MOS circuits
US5329471A (en) * 1987-06-02 1994-07-12 Texas Instruments Incorporated Emulation devices, systems and methods utilizing state machines
US5146583A (en) * 1987-09-25 1992-09-08 Matsushita Electric Industrial Co., Ltd. Logic design system for creating circuit configuration by generating parse tree from hardware description language and optimizing text level redundancy thereof
US4852173A (en) * 1987-10-29 1989-07-25 International Business Machines Corporation Design and construction of a binary-tree system for language modelling
US4868770A (en) * 1987-12-02 1989-09-19 Analogy, Inc. Simulation results enhancement method and system
US4967386A (en) * 1988-04-22 1990-10-30 Hitachi, Ltd. Simulation method for modifiable simulation model
US4970664A (en) * 1988-06-10 1990-11-13 Kaiser Richard R Critical path analyzer with path context window
US5111413A (en) * 1989-03-24 1992-05-05 Vantage Analysis Systems, Inc. Computer-aided engineering
US5282148A (en) * 1989-05-23 1994-01-25 Vlsi Technology, Inc. Method and apparatus for the design and fabrication of integrated circuits employing logic decomposition algorithms for the timing optimization of multilevel logic
US5557531A (en) * 1990-04-06 1996-09-17 Lsi Logic Corporation Method and system for creating and validating low level structural description of electronic design from higher level, behavior-oriented description, including estimating power dissipation of physical implementation
US5541849A (en) * 1990-04-06 1996-07-30 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including estimation and comparison of timing parameters
US5555201A (en) * 1990-04-06 1996-09-10 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including interactive system for hierarchical display of control and dataflow information
US5553002A (en) * 1990-04-06 1996-09-03 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, using milestone matrix incorporated into user-interface
US5544067A (en) * 1990-04-06 1996-08-06 Lsi Logic Corporation Method and system for creating, deriving and validating structural description of electronic system from higher level, behavior-oriented description, including interactive schematic design and simulation
US5544066A (en) * 1990-04-06 1996-08-06 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including estimation and comparison of low-level design constraints
US5282146A (en) * 1990-05-02 1994-01-25 Kabushiki Kaisha Toshiba Test assistant system for logical design process
US5191541A (en) * 1990-05-14 1993-03-02 Sun Microsystems, Inc. Method and apparatus to improve static path analysis of digital circuits
US5265254A (en) * 1991-08-14 1993-11-23 Hewlett-Packard Company System of debugging software through use of code markers inserted into spaces in the source code during and after compilation
US5335191A (en) * 1992-03-27 1994-08-02 Cadence Design Systems, Inc. Method and means for communication between simulation engine and component models in a circuit simulator
US5437037A (en) * 1992-06-05 1995-07-25 Mega Chips Corporation Simulation using compiled function description language
US5446900A (en) * 1992-07-24 1995-08-29 Microtec Research, Inc. Method and apparatus for statement level debugging of a computer program
US5377997A (en) * 1992-09-22 1995-01-03 Sierra On-Line, Inc. Method and apparatus for relating messages and actions in interactive computer games
US5452239A (en) * 1993-01-29 1995-09-19 Quickturn Design Systems, Inc. Method of removing gated clocks from the clock nets of a netlist for timing sensitive implementation of the netlist in a hardware emulation system
US5544068A (en) * 1993-03-09 1996-08-06 Hitachi, Ltd. System and method for optimizing delays in semiconductor circuits

Non-Patent Citations (29)

* Cited by examiner, † Cited by third party
Title
"7A Programming the User Interface," Manual of Symbolics, Inc., 4 New England Tech Center, 555 Virginia Road, Concord, MA 01742, title page, pp. iii-v and pp. 1-134, Sep. 1986.
7A Programming the User Interface, Manual of Symbolics, Inc., 4 New England Tech Center, 555 Virginia Road, Concord, MA 01742, title page, pp. iii v and pp. 1 134, Sep. 1986. *
Brian Ebert et al., "SeeSaw: A Verilog Synthesis Viewer," pp. 55-60, 2nd Annual International Verilog HDL Conference, Design Excellence for Today and Tomorrow; Santa Clara, CA, Mar. 22-24, 1993, sponsored by Open Verilog, Int.
Brian Ebert et al., SeeSaw: A Verilog Synthesis Viewer, pp. 55 60, 2nd Annual International Verilog HDL Conference, Design Excellence for Today and Tomorrow; Santa Clara, CA, Mar. 22 24, 1993, sponsored by Open Verilog, Int. *
D. E. Thomas et al., "Algorithmic and Register-Transfer Level Synthesis: The System Architect's Workbench," pp. 257-274, publication date unknown.
D. E. Thomas et al., Algorithmic and Register Transfer Level Synthesis: The System Architect s Workbench, pp. 257 274, publication date unknown. *
Design Analyzer Reference, Text Viewer, V.3.1, Mar. 1994. *
HDC Computer Corporation, FirstApps User s Guide, pp. 112 116, copyright 1992. *
HDC Computer Corporation, FirstApps User's Guide, pp. 112-116, copyright 1992.
Joseph S. Lis et al., VHDL Synthesis Using Structured Modeling, pp. 606 609; 26th ACM/IEEE Design Automation Conference ; Las Vegas Convention Center, Jun. 25, 1989, Proceedings 1989. *
Joseph S. Lis et al., VHDL Synthesis Using Structured Modeling, pp. 606-609; 26th ACM/IEEE Design Automation Conference©; Las Vegas Convention Center, Jun. 25, 1989, Proceedings 1989.
Louis Trevillyan, "An Overview of Logic Synthesis Systems," 1987, pp. 166-172.
Louis Trevillyan, An Overview of Logic Synthesis Systems, 1987, pp. 166 172. *
Printout of Web Page for Centerline, Code Center, Release 4, Nov. 1994. *
Pure Software Inc., Pure Coverage Data Sheet (Web Page), copyright 1996. *
Pure Software Inc., Purify, Finding Run Time Memory Errors (Web Page), copyright 1996. *
Pure Software Inc., Purify, Finding Run-Time Memory Errors (Web Page), copyright 1996.
Pure Software Inc., Quantify Data Sheet (Web Page), copyright 1996. *
Reed Hastings et al., Pure Software, Inc., Purify, Usenix White Paper on Purify (Web Page), copyright 1996. *
Sougata Mukherjea et al., Applying Algorothm Animation Techniques for Program Tracing, Debugging, and Understanding; Proceedings 15th International Conference on Software Engineering, May 17, 1993, Baltimore, MD, pp. 456 465. *
Sougata Mukherjea et al., Applying Algorothm Animation Techniques for Program Tracing, Debugging, and Understanding; Proceedings 15th International Conference on Software Engineering, May 17, 1993, Baltimore, MD, pp. 456-465.
Timothy Kam, et al., "Comparing Layouts with HDL Models: A Formal Verification Technique," 1992, pp. 588-591.
Timothy Kam, et al., Comparing Layouts with HDL Models: A Formal Verification Technique, 1992, pp. 588 591. *
Weiss, Ray, "ASIC's forcing logic synthesis' hand," Electronic Engineering Times, n516, T16 (pp. 1-2), Dec. 12, 1988.
Weiss, Ray, "Designers moving toward high-level logic representation via logic synthesis--Logic synthesis edging up design hierarchy," Electronic Engineering Times, n526, 81 (pp. 1-10), Feb. 6, 1989.
Weiss, Ray, "Synopsys fine-tunes logic synthesis," Electronic Engineering Times, n534, 138 (pp. 1-3), Apr. 17, 1989.
Weiss, Ray, ASIC s forcing logic synthesis hand, Electronic Engineering Times, n516, T16 (pp. 1 2), Dec. 12, 1988. *
Weiss, Ray, Designers moving toward high level logic representation via logic synthesis Logic synthesis edging up design hierarchy, Electronic Engineering Times, n526, 81 (pp. 1 10), Feb. 6, 1989. *
Weiss, Ray, Synopsys fine tunes logic synthesis, Electronic Engineering Times, n534, 138 (pp. 1 3), Apr. 17, 1989. *

Cited By (166)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060159710A1 (en) * 1989-02-15 2006-07-20 Witold Cieplak Pertussis toxin gene:cloning and expression of protective antigen
US6243848B1 (en) * 1996-10-09 2001-06-05 Bull S.A. Process for analyzing complex structures and system for implementing a process of this type
US6317860B1 (en) * 1996-10-28 2001-11-13 Altera Corporation Electronic design automation tool for display of design profile
US6080201A (en) * 1998-02-10 2000-06-27 International Business Machines Corporation Integrated placement and synthesis for timing closure of microprocessors
US6408422B1 (en) 1998-03-27 2002-06-18 Xilinx, Inc. Method for remapping logic modules to resources of a programmable gate array
US6216258B1 (en) * 1998-03-27 2001-04-10 Xilinx, Inc. FPGA modules parameterized by expressions
US6237129B1 (en) 1998-03-27 2001-05-22 Xilinx, Inc. Method for constraining circuit element positions in structured layouts
US6243851B1 (en) 1998-03-27 2001-06-05 Xilinx, Inc. Heterogeneous method for determining module placement in FPGAs
US6260182B1 (en) 1998-03-27 2001-07-10 Xilinx, Inc. Method for specifying routing in a logic module by direct module communication
US6457164B1 (en) 1998-03-27 2002-09-24 Xilinx, Inc. Hetergeneous method for determining module placement in FPGAs
US6292925B1 (en) 1998-03-27 2001-09-18 Xilinx, Inc. Context-sensitive self implementing modules
US6430732B1 (en) 1998-03-27 2002-08-06 Xilinx, Inc. Method for structured layout in a hardware description language
US6697773B1 (en) 1998-05-19 2004-02-24 Altera Corporation Using assignment decision diagrams with control nodes for sequential review during behavioral simulation
US7231337B1 (en) 1998-05-19 2007-06-12 Altera Corporation Using assignment decision diagrams with control nodes for sequential review during behavioral simulation
US6961690B1 (en) * 1998-05-19 2005-11-01 Altera Corporation Behaviorial digital simulation using hybrid control and data flow representations
US6167561A (en) * 1998-06-08 2000-12-26 Synopsis, Inc. Method and apparatus for entry of timing constraints
US6336209B1 (en) * 1998-06-17 2002-01-01 Fuji Xerox, Co., Ltd Information processing system that processes portions of an application program using programmable logic circuits
US6336087B2 (en) * 1998-07-24 2002-01-01 Luc M. Burgun Method and apparatus for gate-level simulation of synthesized register transfer level design with source-level debugging
US6240376B1 (en) 1998-07-24 2001-05-29 Mentor Graphics Corporation Method and apparatus for gate-level simulation of synthesized register transfer level designs with source-level debugging
US7660778B1 (en) * 1998-12-22 2010-02-09 Accenture Global Services Gmbh Runtime program analysis tool for a simulation engine
US20090142736A1 (en) * 1998-12-22 2009-06-04 Accenture Global Services Gmbh Goal Based System Utilizing a Table Based Architecture
US8429112B2 (en) 1998-12-22 2013-04-23 Accenture Global Services Limited Goal based system utilizing a table based architecture
US6493648B1 (en) * 1999-08-16 2002-12-10 Sequence Design, Inc. Method and apparatus for logic synthesis (inferring complex components)
US6519755B1 (en) * 1999-08-16 2003-02-11 Sequence Design, Inc. Method and apparatus for logic synthesis with elaboration
US7065481B2 (en) * 1999-11-30 2006-06-20 Synplicity, Inc. Method and system for debugging an electronic system using instrumentation circuitry and a logic analyzer
US20050125754A1 (en) * 1999-11-30 2005-06-09 Schubert Nils E. Hardware debugging in a hardware description language
US6823497B2 (en) 1999-11-30 2004-11-23 Synplicity, Inc. Method and user interface for debugging an electronic system
US7069526B2 (en) 1999-11-30 2006-06-27 Synplicity, Inc. Hardware debugging in a hardware description language
US20050010880A1 (en) * 1999-11-30 2005-01-13 Bridges2Silicon, Inc. Method and user interface for debugging an electronic system
US7072818B1 (en) * 1999-11-30 2006-07-04 Synplicity, Inc. Method and system for debugging an electronic system
US7240303B1 (en) 1999-11-30 2007-07-03 Synplicity, Inc. Hardware/software co-debugging in a hardware description language
US8099271B2 (en) 1999-11-30 2012-01-17 Synopsys, Inc. Design instrumentation circuitry
US20030069724A1 (en) * 1999-11-30 2003-04-10 Bridges2Silicon, Inc. Method and system for debugging an electronic system using instrumentation circuitry and a logic analyzer
US20060195822A1 (en) * 1999-11-30 2006-08-31 Beardslee John M Method and system for debugging an electronic system
US6904577B2 (en) 1999-11-30 2005-06-07 Synplicity, Inc. Hardware debugging in a hardware description language
US6581191B1 (en) 1999-11-30 2003-06-17 Synplicity, Inc. Hardware debugging in a hardware description language
US7356786B2 (en) 1999-11-30 2008-04-08 Synplicity, Inc. Method and user interface for debugging an electronic system
US7506286B2 (en) * 1999-11-30 2009-03-17 Synopsys, Inc. Method and system for debugging an electronic system
US20030182642A1 (en) * 1999-11-30 2003-09-25 Schubert Nils Endric Hardware debugging in a hardware description language
US20030154459A1 (en) * 1999-12-21 2003-08-14 Khalil Shalish Correlation of behavioral HDL signals
US6557160B2 (en) * 1999-12-21 2003-04-29 Khalil Shalish Correlation of behavioral HDL signals
US7185308B2 (en) 1999-12-21 2007-02-27 Khalil Shalish Correlation of behavioral HDL signals
US20010016935A1 (en) * 2000-02-09 2001-08-23 Shinya Furusawa System and method for verifying hardware description
US6442562B1 (en) * 2000-03-15 2002-08-27 International Business Machines Corporation Apparatus and method for using incomplete cached balance sets to generate incomplete or complete cached balance sets and balance values
US6684381B1 (en) * 2000-09-29 2004-01-27 Hewlett-Packard Development Company, L.P. Hardware description language-embedded regular expression support for module iteration and interconnection
US20070198959A1 (en) * 2000-11-28 2007-08-23 Schubert Nils E Hardware-based HDL code coverage and design analysis
US7222315B2 (en) 2000-11-28 2007-05-22 Synplicity, Inc. Hardware-based HDL code coverage and design analysis
US7836416B2 (en) 2000-11-28 2010-11-16 Synopsys, Inc. Hardware-based HDL code coverage and design analysis
US20020123873A1 (en) * 2000-12-29 2002-09-05 International Business Machines Corporation Signal override for simulation models
US7092864B2 (en) * 2000-12-29 2006-08-15 International Business Machines Corporation Signal override for simulation models
US20040015825A1 (en) * 2001-01-31 2004-01-22 Mikito Iwamasa Method and computer program product for localizing an interruption structure included in a hierarchical structure of a specification
US7086037B2 (en) * 2001-01-31 2006-08-01 Kabushiki Kaisha Toshiba Method and computer program product for localizing an interruption structure included in a hierarchical structure of a specification
US20050229154A1 (en) * 2001-02-23 2005-10-13 Complementsoft Llc System and method for generating and maintaining software code
US7110936B2 (en) * 2001-02-23 2006-09-19 Complementsoft Llc System and method for generating and maintaining software code
US20060111888A1 (en) * 2001-02-23 2006-05-25 Complementsoft Llc System and method for generating and maintaining software code
US7031899B2 (en) * 2001-04-09 2006-04-18 Novas Software, Inc. System for characterizing simulated circuit logic and behavior
US20020147576A1 (en) * 2001-04-09 2002-10-10 Yu-Chin Hsu System for characterizing simulated circuit logic and behavior
US8522197B2 (en) 2001-04-20 2013-08-27 Mentor Graphics Corporation Hierarchical presentation techniques for a design tool
US20070006125A1 (en) * 2001-04-20 2007-01-04 Gutberlet Peter P Hierarchical presentation techniques for a design tool
US7844944B2 (en) * 2001-04-20 2010-11-30 Mentor Graphics Corporation Hierarchical presentation techniques for a design tool
US20020172210A1 (en) * 2001-05-18 2002-11-21 Gilbert Wolrich Network device switch
US7082104B2 (en) 2001-05-18 2006-07-25 Intel Corporation Network device switch
US20030018460A1 (en) * 2001-07-20 2003-01-23 Chun-Chih Yang Method to preserve comments of circuit simulation text file
US20030028630A1 (en) * 2001-07-31 2003-02-06 Gerhard Bischof Method and system for processing topology data and geometry data of networks
US7093224B2 (en) 2001-08-28 2006-08-15 Intel Corporation Model-based logic design
US20030046053A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Logic simulation
US20030046640A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Generating a logic design
US6983427B2 (en) 2001-08-29 2006-01-03 Intel Corporation Generating a logic design
US20030046652A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Gate estimation process and method
WO2003021493A2 (fr) * 2001-08-29 2003-03-13 Intel Corporation (A Delaware Corporation) Affichage d'informations lie a une structure logique
WO2003021493A3 (fr) * 2001-08-29 2004-03-18 Intel Corp Affichage d'informations lie a une structure logique
US7107201B2 (en) 2001-08-29 2006-09-12 Intel Corporation Simulating a logic design
US20030046641A1 (en) * 2001-08-29 2003-03-06 Fennell Timothy J. Representing a simulation model using a hardware configuration database
US20030046051A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Unified design parameter dependency management method and apparatus
US20030046054A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Providing modeling instrumentation with an application programming interface to a GUI application
US20030046052A1 (en) * 2001-08-29 2003-03-06 Wheeler William R. Simulating a logic design
US7073156B2 (en) 2001-08-29 2006-07-04 Intel Corporation Gate estimation process and method
US7130784B2 (en) 2001-08-29 2006-10-31 Intel Corporation Logic simulation
US6859913B2 (en) 2001-08-29 2005-02-22 Intel Corporation Representing a simulation model using a hardware configuration database
US10466980B2 (en) 2001-10-24 2019-11-05 Cypress Semiconductor Corporation Techniques for generating microcontroller configuration information
US20150106776A1 (en) * 2001-10-24 2015-04-16 Cypress Semiconductor Corporation Techniques for generating microcontroller configuration information
US20030083858A1 (en) * 2001-10-29 2003-05-01 Honeywell International Inc. Incremental automata verification
US6957178B2 (en) 2001-10-29 2005-10-18 Honeywell International Inc. Incremental automata verification
US20030135355A1 (en) * 2002-01-17 2003-07-17 Wheeler William R. Modeling a logic design
US7197724B2 (en) 2002-01-17 2007-03-27 Intel Corporation Modeling a logic design
US20030145311A1 (en) * 2002-01-25 2003-07-31 Wheeler William R. Generating simulation code
US20030200540A1 (en) * 2002-04-18 2003-10-23 Anoop Kumar Method and apparatus for integrated instruction scheduling and register allocation in a postoptimizer
US7007271B2 (en) * 2002-04-18 2006-02-28 Sun Microsystems, Inc. Method and apparatus for integrated instruction scheduling and register allocation in a postoptimizer
US20030208747A1 (en) * 2002-05-06 2003-11-06 Sun Microsystems, Inc. Method for debugging an integrated circuit
US7055135B2 (en) * 2002-05-06 2006-05-30 Sun Microsystems, Inc. Method for debugging an integrated circuit
US7827510B1 (en) 2002-06-07 2010-11-02 Synopsys, Inc. Enhanced hardware debugging with embedded FPGAS in a hardware description language
US20040024779A1 (en) * 2002-07-31 2004-02-05 Perry Ronald N. Method for traversing quadtrees, octrees, and N-dimensional bi-trees
US6868420B2 (en) * 2002-07-31 2005-03-15 Mitsubishi Electric Research Laboratories, Inc. Method for traversing quadtrees, octrees, and N-dimensional bi-trees
US6766504B1 (en) * 2002-08-06 2004-07-20 Xilinx, Inc. Interconnect routing using logic levels
US20040049753A1 (en) * 2002-09-10 2004-03-11 Matsushita Electric Industrial Co., Ltd. System for estimating performance of integrated circuit in register transfer level
US20040111713A1 (en) * 2002-12-06 2004-06-10 Rioux Christien R. Software analysis framework
US8365155B2 (en) 2002-12-06 2013-01-29 Veracode, Inc. Software analysis framework
US7051322B2 (en) 2002-12-06 2006-05-23 @Stake, Inc. Software analysis framework
US8789027B2 (en) 2002-12-06 2014-07-22 Veracode, Inc. Software analysis framework
US9286041B2 (en) 2002-12-06 2016-03-15 Veracode, Inc. Software analysis framework
US20100306749A1 (en) * 2002-12-06 2010-12-02 Rioux Christien R Software Analysis Framework
US6817004B2 (en) * 2003-01-22 2004-11-09 Lsi Logic Corporation Net segment analyzer for chip CAD layout
US20040143809A1 (en) * 2003-01-22 2004-07-22 Cowan Joseph W. Net segment analyzer for chip CAD layout
US7076751B1 (en) * 2003-01-24 2006-07-11 Altera Corporation Chip debugging using incremental recompilation
US7530046B1 (en) 2003-01-24 2009-05-05 Altera Corporation Chip debugging using incremental recompilation
US8949757B2 (en) 2003-05-09 2015-02-03 Synopsys, Inc. Circuit design and retiming
US8429583B2 (en) * 2003-05-09 2013-04-23 Synopsys, Inc. Circuit design and retiming
US20090293032A1 (en) * 2003-05-09 2009-11-26 Levent Oktem Method and apparatus for circuit design and retiming
US20050015755A1 (en) * 2003-07-18 2005-01-20 Agere Systems Incorporated System and method for automatically generating a hierarchical register consolidation structure
US7500228B2 (en) * 2003-07-18 2009-03-03 Agere Systems Inc. System and method for automatically generating a hierarchical register consolidation structure
US7539900B1 (en) 2003-07-29 2009-05-26 Altera Corporation Embedded microprocessor for integrated circuit testing and debugging
US20050055612A1 (en) * 2003-08-22 2005-03-10 Takamitsu Yamada Design supporting apparatus
US7506279B2 (en) * 2003-08-22 2009-03-17 Ricoh Company, Ltd Design supporting apparatus capable of checking functional description of large-scale integrated circuit to detect fault in said circuit
US7206967B1 (en) 2004-02-09 2007-04-17 Altera Corporation Chip debugging using incremental recompilation and register insertion
EP1569144A3 (fr) * 2004-02-27 2006-05-03 NEC Electronics Corporation Système, procédé et program pour la visualization des correspondences entre la description comportemental et de bas niveau d'un circuit intégré
US20050193360A1 (en) * 2004-02-27 2005-09-01 Nec Electronics Corporation Circuit design support system, circuit design support method, and program
EP1569144A2 (fr) * 2004-02-27 2005-08-31 NEC Electronics Corporation Système, procédé et program pour la visualization des correspondences entre la description comportemental et de bas niveau d'un circuit intégré
US7370297B2 (en) 2004-02-27 2008-05-06 Nec Electronics Corporation Method, system, and computer program for validating correspondence information between behavior and lower level description of a circuit design
US20060095250A1 (en) * 2004-11-03 2006-05-04 Microsoft Corporation Parser for natural language processing
US7970600B2 (en) 2004-11-03 2011-06-28 Microsoft Corporation Using a first natural language parser to train a second parser
US7380226B1 (en) * 2004-12-29 2008-05-27 Cadence Design Systems, Inc. Systems, methods, and apparatus to perform logic synthesis preserving high-level specification
US20140344345A1 (en) * 2005-05-26 2014-11-20 Citrix Systems, Inc. Systems and methods for using an http-aware client agent
US9692725B2 (en) * 2005-05-26 2017-06-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US20060277028A1 (en) * 2005-06-01 2006-12-07 Microsoft Corporation Training a statistical parser on noisy data by filtering
US20080307418A1 (en) * 2005-06-06 2008-12-11 International Business Machines Corporation Enabling and Disabling Byte Code Inserted Probes Based on Transaction Monitoring Tokens
US7464161B2 (en) 2005-06-06 2008-12-09 International Business Machines Corporation Enabling and disabling byte code inserted probes based on transaction monitoring tokens
US20060277293A1 (en) * 2005-06-06 2006-12-07 Chagoly Bryan C Enabling and disabling byte code inserted probes based on transaction monitoring tokens
US8032627B2 (en) 2005-06-06 2011-10-04 International Business Machines Corporation Enabling and disabling byte code inserted probes based on transaction monitoring tokens
US7350171B2 (en) 2005-11-17 2008-03-25 Lizheng Zhang Efficient statistical timing analysis of circuits
US20070168741A1 (en) * 2005-11-17 2007-07-19 International Business Machines Corporation Method, system and program product for facilitating debugging of simulation results obtained for an optimized simulation model of a device design having hierarchically-connected components
US20070113211A1 (en) * 2005-11-17 2007-05-17 Lizheng Zhang Efficient statistical timing analysis of circuits
US20070124717A1 (en) * 2005-11-30 2007-05-31 Freescale Semiconductor, Inc. Method and program product for protecting information in EDA tool design views
US7437698B2 (en) 2005-11-30 2008-10-14 Freescale Semiconductor, Inc. Method and program product for protecting information in EDA tool design views
US9948608B2 (en) 2006-08-03 2018-04-17 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US8613080B2 (en) 2007-02-16 2013-12-17 Veracode, Inc. Assessment and analysis of software security flaws in virtual machines
US8266571B2 (en) 2008-06-10 2012-09-11 Oasis Tooling, Inc. Methods and devices for independent evaluation of cell integrity, changes and origin in chip design for production workflow
US7685545B2 (en) 2008-06-10 2010-03-23 Oasis Tooling, Inc. Methods and devices for independent evaluation of cell integrity, changes and origin in chip design for production workflow
US20090307639A1 (en) * 2008-06-10 2009-12-10 Oasis Tooling, Inc. Methods and devices for independent evaluation of cell integrity, changes and origin in chip design for production workflow
US8166077B2 (en) * 2008-09-30 2012-04-24 International Business Machines Corporation Mapping a class, method, package, and/or pattern to a component
US20100083228A1 (en) * 2008-09-30 2010-04-01 International Business Machines Corporation Mapping a Class, Method, Package, and/or Pattern to a Component
US8843862B2 (en) 2008-12-16 2014-09-23 Synopsys, Inc. Method and apparatus for creating and changing logic representations in a logic design using arithmetic flexibility of numeric formats for data
US20100153899A1 (en) * 2008-12-16 2010-06-17 Mcelvain Kenneth S Methods and apparatuses for designing logic using arithmetic flexibility
US8898618B2 (en) * 2009-03-26 2014-11-25 Altera Corporation Interactive simplification of schematic diagram of integrated circuit design
US20100251201A1 (en) * 2009-03-26 2010-09-30 Altera Corporation Interactive simplification of schematic diagram of integrated circuit design
US20110047522A1 (en) * 2009-05-21 2011-02-24 Dane Mark W P Hardware Description Language Editing Engine
US8589875B2 (en) * 2009-06-16 2013-11-19 International Business Machines Corporation Computing system with compile farm
US20100318965A1 (en) * 2009-06-16 2010-12-16 International Business Machines Corporation Computing system with compile farm
US20100325611A1 (en) * 2009-06-18 2010-12-23 Hudson Iii Duncan G Providing Target Specific Information for Textual Code at Edit Time
US8479156B2 (en) * 2009-06-18 2013-07-02 National Instruments Corporation Providing target specific information for textual code at edit time
US8447581B1 (en) * 2009-09-15 2013-05-21 Xilinx, Inc. Generating simulation code from a specification of a circuit design
US20120117524A1 (en) * 2010-11-05 2012-05-10 International Business Machines Corporation Reusable structured hardware description language design component
US8332787B2 (en) * 2010-11-05 2012-12-11 International Business Machines Corporation Reusable structured hardware description language design component
US9122825B2 (en) 2011-06-10 2015-09-01 Oasis Tooling, Inc. Identifying hierarchical chip design intellectual property through digests
US9286063B2 (en) 2012-02-22 2016-03-15 Veracode, Inc. Methods and systems for providing feedback and suggested programming methods
US20140156703A1 (en) * 2012-11-30 2014-06-05 Altera Corporation Method and apparatus for translating graphical symbols into query keywords
US10606977B2 (en) 2013-03-14 2020-03-31 Synopsys, Inc. Graphical view and debug for coverage-point negative hint
US9727678B2 (en) * 2013-03-14 2017-08-08 Synopsys, Inc. Graphical view and debug for coverage-point negative hint
US20140282315A1 (en) * 2013-03-14 2014-09-18 Synopsys, Inc. Graphical view and debug for coverage-point negative hint
US10268798B2 (en) 2015-09-22 2019-04-23 International Business Machines Corporation Condition analysis
US10417372B2 (en) * 2015-11-25 2019-09-17 Synopsys, Inc. Annotating isolated signals
US20170147720A1 (en) * 2015-11-25 2017-05-25 Synopsys, Inc. Annotating isolated signals
US10489541B1 (en) * 2017-11-21 2019-11-26 Xilinx, Inc. Hardware description language specification translator
USD922400S1 (en) * 2019-06-13 2021-06-15 Tata Consultancy Services Limited Display screen with animated graphical user interface
USD921650S1 (en) * 2019-06-17 2021-06-08 Tata Consultancy Services Limited Display screen with animated graphical user interface
USD921651S1 (en) * 2019-06-17 2021-06-08 Tata Consultancy Services Limited Display screen with animated graphical user interface
USD922401S1 (en) * 2019-06-17 2021-06-15 Tata Consultancy Services Limited Display screen with animated graphical user interface

Also Published As

Publication number Publication date
WO1995027948A1 (fr) 1995-10-19
EP0755544A1 (fr) 1997-01-29
JPH09512115A (ja) 1997-12-02
CA2185908A1 (fr) 1995-10-19
AU2292095A (en) 1995-10-30

Similar Documents

Publication Publication Date Title
US5937190A (en) Architecture and methods for a hardware description language source level analysis and debugging system
US6132109A (en) Architecture and methods for a hardware description language source level debugging system
US6378123B1 (en) Method of handling macro components in circuit design synthesis
US6295636B1 (en) RTL analysis for improved logic synthesis
US6205572B1 (en) Buffering tree analysis in mapped design
US6263483B1 (en) Method of accessing the generic netlist created by synopsys design compilier
US6289498B1 (en) VDHL/Verilog expertise and gate synthesis automation system
US6292931B1 (en) RTL analysis tool
US6173435B1 (en) Internal clock handling in synthesis script
US6836877B1 (en) Automatic synthesis script generation for synopsys design compiler
US5801958A (en) Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including interactive system for hierarchical display of control and dataflow information
US5870308A (en) Method and system for creating and validating low-level description of electronic design
US6457164B1 (en) Hetergeneous method for determining module placement in FPGAs
US5572436A (en) Method and system for creating and validating low level description of electronic design
US5557531A (en) Method and system for creating and validating low level structural description of electronic design from higher level, behavior-oriented description, including estimating power dissipation of physical implementation
US6292925B1 (en) Context-sensitive self implementing modules
US5497334A (en) Application generator for use in verifying a hierarchical circuit design
US5544066A (en) Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including estimation and comparison of low-level design constraints
Eles et al. System synthesis with VHDL
US5541849A (en) Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including estimation and comparison of timing parameters
US5553002A (en) Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, using milestone matrix incorporated into user-interface
US6216252B1 (en) Method and system for creating, validating, and scaling structural description of electronic device
US5528508A (en) System and method for verifying a hierarchical circuit design
US6216258B1 (en) FPGA modules parameterized by expressions
US5481473A (en) System and method for building interconnections in a hierarchical circuit design

Legal Events

Date Code Title Description
AS Assignment

Owner name: SYNOPSYS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GREGORY, BRENT;CHATTERJEE, TRINANJAN;LIN, JING C.;AND OTHERS;REEL/FRAME:007956/0828;SIGNING DATES FROM 19950720 TO 19950821

AS Assignment

Owner name: SYNOPSYS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GREGORY, BRENT;CHATTERJEE, TRINANJAN;LIN, JING C.;AND OTHERS;REEL/FRAME:007842/0858;SIGNING DATES FROM 19950720 TO 19950821

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY