A technique for hierarchical display of control and dataflow graphs allowing a user to view hierarchically filtered control and dataflow information related to a design. The technique employs information inherent in the design description and information derived from design synthesis to identify "modules" of the design and design hierarchy. The user can specify a level of detail to be displayed for any design element or group of design elements. Any CDFG (control and dataflow graph) object can be "annotated" with a visual attribute or with text to indicate information about the design elements represented by the object. For example, block size, interior color, border color, line thickness, line style, etc., can be used to convey quantitative or qualitative information about a CDFG object. Examples of information which can be used to "annotate" objects include power dissipation, propagation delay, the number of HDL statement represented, circuit area, number of logic gates, etc. The user is able to expand and/or compress CDFG blocks either "in-place" on a higher level CDFG display or to be displayed in isolation. Simulation-related data can also be used to annotate the CDFG. By viewing CDFG's (particularly annotated CDFG's) for a variety of trial designs, a problem-solving user can gain quick insight into the effects and effectiveness of various design choices.

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

A system for interactive design, synthesis and simulation of an electronic system allowing a user to design a system either by specification of a behavioral model in a high level language such as VHDL or by graphical entry. The user can view full or partial simulation and design results simultaneously, on a single display window. The synthesis process uses a systematic technique to map and enforce consistency of the semantics imbedded in the intent of the original, high-level descriptions. The design activity is generally a series of transformations operating upon various levels of design representations. At each level, the design can be simulated and reviewed in schematic diagram form. The simulation results can be displayed immediately adjacent to signal lines on the diagram to which they correspond. In one embodiment, design rule violations are processed by an expert system to suggest possible corrections or alterations to the design which will eliminate the design rule violations. Schematic diagram and simulation displays showing those portions of the electronic system and simulated signal patterns which are related to the design rule violations are used to help the user identify and appropriately correct problems in the design.

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

An authoring environment for creating and/or editing user interface elements such as widgets used in a unified interest layer. The authoring environment facilitates creation of widgets that have a consistent appearance and mechanism, and allows third-party developers to easily create widgets that have a look and feel that is consistent with a predefined set of widgets.

Widget authoring and editing environment

A user-activatable dashboard (also referred to as a unified interest layer) contains any number of user interface elements, referred to herein as “widgets,” for quick access by a user. In response to a command from a user, the dashboard is invoked and the widgets are shown on the screen. The user can activate the dashboard at any time, causing the dashboard to temporarily replace the existing user interface display on the user's screen. Once the dashboard has been activated, the user can interact with any or all of the widgets, and can configure the dashboard by adding, deleting, moving, or configuring individual widgets as desired. When the user wishes to return to the normal user interface he or she was working with, the user issues a command causing the dashboard to be dismissed. Once the dashboard has been dismissed, the previous user interface state is restored, allowing the user to resume normal interactions with the operating system.

Unified interest layer for user interface

A methodology for generating structural descriptions of complex digital devices from high-level descriptions and specifications is disclosed. The methodology uses a systematic technique to map and enforce consistency of the semantics imbedded in the intent of the original, high-level descriptions. The design activity is essentially a series of transformations operating upon various levels of design representations. At each level, the intended meaning (semantics) and formal software manipulations are captured to derive a more detailed level describing hardware meeting the design goals. Important features of the methodology are: capturing the users concepts, intent, specification, descriptions, constraints and trade-offs; architectural partitioning; what-if analysis at a high level; sizing estimation; timing estimation; architectural trade-off; conceptual design with implementation estimation; and timing closure. The methodology includes using estimators, based on data gathered over a number of realized designs, for partitioning and evaluating a design prior to logic synthesis. From the structural description, a physical implementation of the device is readily realized. Techniques are described for estimating ancillary parameters of the device (such as device cost, production speed, production lead time, etc.), at early, high level stages of the design process (e.g., at the system, behavioral, and register transfer level stages). The techniques can be applied to optimize the design characteristics other than measurable physical characteristics, such as those deriving from project time and cost constraints.

Method and system for creating and validating low level description of electronic design

A system for providing a simple, easy to learn and flexible means of creating user interfaces to products under development without the need of a programming language or the need to learn a large set of complicated commands. The Visual Software Engineering ("VSE") system of the invention uses a simple concept of defining both input to and output from graphical objects in an object-oriented system by providing examples of what the user desires the graphical object to do. This technique is referred to herein as "animation by example". In accordance with this process, the user creates a user interface by drawing the user interface with a graphics editor and then defining the output behavior (i.e., graphics manipulation) of the user interface components by showing each state or frame as an animation. This is accomplished by changing the object using a graphic editor function such as move or rotate and storing each of the frames with the object as a behavior state. Just as with defining the output, the input is defined by giving the graphic object an example of what type of input to look for, and once it finds that input, it tells the object which frame to output or change to. Application code can then drive the animation or read the input by accessing the frame numbers assigned to each of the example frames.

Visual software engineering system and method for developing visual prototypes and for connecting user code to them

Disclosed is a schematic capture and design verification system wherein the graphic symbol linked to a component is separated from the model used to simulate the component. Each component has a graphics symbol linked to a link or scion page. The link page also contains a list of all models that can be used with the component. The system allows a model to be selected for each component in a schematic, and allows the model to be changed at any time. The system also allows the models for all components to be changed with a single command. The user enters a schematic into the system, then selects a model for each component used in the schematic. After a model has been selected for each component, the user requests the system to build a netlist that describes the schematic to a simulator or other analysis or synthesis tool. In building the netlist, parameters are extracted from the link page for each component and included in the netlist to be used by the simulator. When a different simulation is desired by the user, the user instructs the system to change the model linked to the components to a new model suitable to the second simulator. The system then builds a new netlist, using parameters specific to the new model and the second simulator.

Schematic capture method having different model couplers for model types for changing the definition of the schematic based upon model type selection

A system for designing, testing, and employing graphical computer code includes a graphics editor for creating a graphical display. The graphical display is made up of a plurality of graphical objects constructed by the graphics editor. A translator creates a high-level computer language code of the graphical object. The translator is connected to the graphics editor. A compiler receives the high level computer language code from the translator.

System and method of designing, testing, and employing graphical computer code

Disclosed is a schematic capture and design verification system wherein the graphic symbol (402) linked to a component is separated from the model (422, 426) used to simulate the component. Each component has a graphics symbol (402) linked to a link or scion page (404). The link page (404) also contains a list of all models that can be used with the component. The system allows a model to be selected (406) for each component in a schematic, and allows the model to be changed at any time. The system also allows the models for all components to be changed with a single command. The user enters a schematic (602) into the system, then selects a model for each component used in the schematic. After a model has been selected for each component, the user requests the system to build a netlist that describes the schematic to a simulator or other analysis or synthesis tool. In building the netlist (616), parameters are extracted from the link page for each component and included in the netlist to be used by the simulator. When a different simulation is desired by the user, the user instructs the system to change the model linked to the components to a new model suitable to the second simulator. The system then builds a new netlist, using parameters specific to the new model and the second simulator.

Michael T. Juran

Papers

Visual software engineering system and method for developing visual prototypes and for connecting user code to them

Schematic capture method having different model couplers for model types for changing the definition of the schematic based upon model type selection

System and method of designing, testing, and employing graphical computer code

Common symbol library architecture