Method, system and program product supporting presentation of a simulated or hardware system including configuration entities Number:7,386,825 from the United States Patent and Trademark Office (PTO) owispatent

Title: Method, system and program product supporting presentation of a simulated or hardware system including configuration entities

Abstract: Within a display device, a respective one of a plurality of design graphical representations is displayed for each of a plurality of hierarchically arranged design entity instances within a simulated system. The design entity instances include a particular design entity instance containing a latch that is represented by a particular design graphical representation. A configuration entity instance associated with the particular design entity is identified within a configuration database associated with the simulated system. The configuration entity instance has a plurality of different settings that each reflects a value of the latch. Within the display device, a configuration graphical representation of the configuration entity instance is presented in association with the particular design graphical representation corresponding to the particular design entity instance. In addition, a current setting of the configuration entity instance is presented concurrently with the configuration graphical representation.

Patent Number: 7,386,825 Issued on 06/10/2008 to Roesner,   et al.

---

Inventors:	Roesner; Wolfgang (Austin, TX), Williams; Derek Edward (Austin, TX)
Assignee:	International Business Machines Corporation (Armonk, NY)
Appl. No.:	10/902,628
Filed:	July 29, 2004

---

Current U.S. Class:	716/11 ; 345/418; 345/619
Field of Search:	716/4,5,11 345/418,619

---

References Cited [Referenced By]

---

U.S. Patent Documents

5809283	September 1998	Vaidyanathan et al.
5870588	February 1999	Rompaey et al.
5933356	August 1999	Rostoker et al.
5995736	November 1999	Aleksic et al.
6173435	January 2001	Dupenloup
6321369	November 2001	Heile et al.
6341361	January 2002	Basto et al.
6385757	May 2002	Gupta et al.
6581191	June 2003	Schubert et al.
6584598	June 2003	Rao et al.
6618839	September 2003	Beardslee et al.
6691301	February 2004	Bowen
6701501	March 2004	Waters et al.
6826732	November 2004	Hunt et al.
6829753	December 2004	Lee et al.
6836877	December 2004	Dupenloup
6941527	September 2005	Roesner et al.
6959428	October 2005	Broberg et al.
6983456	January 2006	Poznanovic et al.
6993729	January 2006	Nelson et al.
7036106	April 2006	Wang et al.
7039894	May 2006	Roesner et al.
7062418	June 2006	Lee et al.
7062745	June 2006	Roesner et al.
7062746	June 2006	Roesner et al.
7076751	July 2006	Nixon et al.
7080346	July 2006	Roesner et al.
7080347	July 2006	Hunt et al.
7096434	August 2006	Roesner et al.
7134098	November 2006	Roesner et al.
2002/0123873	September 2002	Roesner et al.
2002/0128809	September 2002	Roesner et al.
2003/0037305	February 2003	Chen et al.
2003/0101039	May 2003	Gabele et al.
2003/0125915	July 2003	Gabele et al.
2003/0135354	July 2003	Gabele et al.
2003/0191621	October 2003	Gabele et al.
2003/0191869	October 2003	Williams et al.
2005/0010880	January 2005	Schubert et al.
2005/0114805	May 2005	Novakovsky et al.
2005/0149309	July 2005	Nelson et al.
2005/0257178	November 2005	Daems et al.
2006/0004558	January 2006	Nelson et al.
2006/0026548	February 2006	Roesner et al.

Primary Examiner: Whitmore; Stacy
Attorney, Agent or Firm: Gerhardt; Diana R. Dillon & Yudell LLP

---

Claims

---

What is claimed is:

1. A method of presenting a simulated system, said method comprising: with a display device, displaying a respective one of a plurality of design graphical representations for each of a plurality of hierarchically arranged design entity instances within the simulated system, said plurality of design entity instances including a particular design entity instance containing a latch that is represented by a particular design graphical representation; identifying, within a configuration database associated with the system, a configuration entity instance associated with said particular design entity, wherein said configuration entity instance has a plurality of different settings that each reflects a value of the latch; with the display device, presenting, in association with the particular design graphical representation corresponding to the particular design entity instance, a configuration graphical representation of said configuration entity instance; with the display device, presenting a current setting of said configuration entity instance concurrently with the configuration graphical representation; storing within the configuration database at least one data structure defining said configuration entity instance and said association between said configuration entity instance and said particular design entity instance; storing in said at least one data structure a controlling value set for said configuration entity instance, wherein said controlling value set indicates settings affecting presentation of information regarding said configuration entity instance; and in response to a request to present at least a partial state of the simulated system, presenting a state of at least one other configuration entity instance based upon said configuration database and excluding from presentation a current setting of the configuration entity instance by reference to said at least one data structure in said configuration database.

2. The method of claim 1, wherein said excluding from presentation comprises always excluding from presentation said current setting of said configuration entity instance based upon a keyword in said configuration database.

3. The method of claim 1, and further comprising: displaying a user-controllable graphical pointer within said display device; and modifying a presentation of said simulated system within said display device in response to user selection of a configuration graphical representation utilizing the graphical pointer.

4. A method of presenting a simulated system, said method comprising: with a display device, displaying a respective one of a plurality of design graphical representations for each of a plurality of hierarchically arranged design entity instances within the simulated system, said plurality of design entity instances including a particular design entity instance containing a latch that is represented by a particular design graphical representation; identifying, within a configuration database associated with the system, a configuration entity instance associated with said particular design entity, wherein said configuration entity instance has a plurality of different settings that each reflects a value of the latch; with the display device, presenting, in association with the particular design graphical representation corresponding to the particular design entity instance, a configuration graphical representation of said configuration entity instance; with the display device, presenting a current setting of said configuration entity instance concurrently with the configuration graphical representation; and wherein said step of displaying a respective one of a plurality of design graphical representations for each of a plurality of hierarchically arranged design entity instances comprises presenting design graphical representations for only selected design entity instances and excluding from presentation a design graphical representation for at least one other design entity instance in response to a region parameter.

5. A method of presenting a simulated system, said method comprising: with a display device, displaying a respective one of a plurality of design graphical representations for each of a plurality of hierarchically arranged design entity instances within the simulated system, said plurality of design entity instances including a particular design entity instance containing a latch that is represented by a particular design graphical representation; identifying, within a configuration database associated with the system, a configuration entity instance associated with said particular design entity, wherein said configuration entity instance has a plurality of different settings that each reflects a value of the latch; with the display device, presenting, in association with the particular design graphical representation corresponding to the particular design entity instance, a configuration graphical representation of said configuration entity instance; and with the display device, presenting a current setting of said configuration entity instance concurrently with the configuration graphical representation; wherein said design entity instances are hierarchically arranged in at least three levels, wherein said displaying comprises concurrently displaying fewer than all of said levels.

6. The method of claim 5, and further comprising: displaying a user-controllable graphical pointer within said display device; and modifying which of said levels are displayed within said display device in response to selection of a design graphical representation utilizing a graphical pointer.

7. A data processing system for presenting a simulated system, said data processing system comprising: a display device; processing resources; and data storage coupled to the processing resources and including at least one database representing said simulated system and a presentation program executable by the processing resources to present a graphical representation of said simulated system within said display device, said presentation program including: means for displaying within the display device a respective one of a plurality of design graphical representations for each of a plurality of hierarchically arranged design entity instances within the simulated system, said plurality of design entity instances including a particular design entity instance containing a latch that is represented by a particular design graphical representation; means for identifying, within said database, a configuration entity instance associated with said particular design entity, wherein said configuration entity instance has a plurality of different settings that each reflects a value of the latch; means for presenting, within the display device, a configuration graphical representation of said configuration entity instance in association with the particular design graphical representation corresponding to the particular design entity instance; and means for presenting, within the display device, a current setting of said configuration entity instance concurrently with the configuration graphical representation; wherein: said at least one database includes a configuration database storing at least one data structure defining said configuration entity instance and said association between said configuration entity instance and said particular design entity instance, said at least one data structure indicating a controlling value set for said configuration entity instance, wherein said controlling value set indicates settings affecting presentation of information regarding said configuration entity instance; and said presentation program further comprises means, responsive to a request to present at least a partial state of the simulated system, for presenting a state of at least one other configuration entity instance based upon said configuration database and for excluding from presentation a current setting of the configuration entity instance by reference to said at least one data structure in said configuration database.

8. The data processing system of claim 7, wherein said means for excluding from presentation comprises means for always excluding from presentation said current setting of said configuration entity instance based upon a keyboard in said configuration database.

---

Description

---

CROSS-REFERENCE TO RELATED APPLICATION

The present application is related to U.S. patent application Ser. No. 10/902,595, which is assigned to the assignee of the present invention and incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates in general to designing, simulating and configuring digital devices, modules and systems, and in particular, to methods and systems for computer-aided design, simulation, and configuration of digital devices, modules and systems described by a hardware description language (HDL) model.

2. Description of the Related Art

In a typical digital design process, verifying the logical correctness of a digital design and debugging the design (if necessary) are important steps of the design process performed prior to developing a circuit layout. Although it is certainly possible to test a digital design by actually building the digital design, digital designs, particularly those implemented by integrated circuitry, are typically verified and debugged by simulating the digital design on a computer, due in part to the time and expense required for integrated circuit fabrication.

In a typical automated design process, a circuit designer enters into an electronic computer-aided design (ECAD) system a high-level description of the digital design to be simulated utilizing a hardware description language (HDL), such as VHDL, thus producing a digital representation of the various circuit blocks and their interconnections. In the digital representation, the overall circuit design is frequently divided into smaller parts, hereinafter referred to as design entities, which are individually designed, often by different designers, and then combined in a hierarchical manner to create an overall model. This hierarchical design technique is very useful in managing the enormous complexity of the overall design and facilitates error detection during simulation.

The ECAD system compiles the digital representation of the design into a simulation model having a format best suited for simulation. A simulator then exercises the simulation model to detect logical errors in the digital design.

A simulator is typically a software tool that operates on the simulation model by applying a list of input stimuli representing inputs of the digital system. The simulator generates a numerical representation of the response of the circuit to the input stimuli, which response may then either be viewed on the display screen as a list of values or further interpreted, often by a separate software program, and presented on the display screen in graphical form. The simulator may be run either on a general-purpose computer or on another piece of electronic apparatus specially designed for simulation. Simulators that run entirely in software on a general-purpose computer are referred to as "software simulators," and simulators that run with the assistance of specially designed electronic apparatus are referred to as "hardware simulators."

As digital designs have become increasingly complex, digital designs are commonly simulated at several levels of abstraction, for example, at functional, logical and circuit levels. At the functional level, system operation is described in terms of a sequence of transactions between registers, adders, memories and other functional units. Simulation at the functional level is utilized to verify the high-level design of digital systems. At the logical level, a digital system is described in terms of logic elements such as logic gates and flip-flops. Simulation at the logical level is utilized to verify the correctness of the logic design. At the circuit level, each logic gate is described in terms of its circuit components such as transistors, impedances, capacitances, and other such devices. Simulation at the circuit level provides detailed information about voltage levels and switching speeds.

In order to verify the results of any given simulation run, custom-developed programs written in high-level languages such as C or C++, referred to as a reference model, are written to process input stimuli (also referred to as test vectors) to produce expected results of the simulation run. The test vector is then run against the simulation execution model by the simulator. The results of the simulation run are then compared to the results predicted by the reference model to detect discrepancies, which are flagged as errors. Such a simulation check is known in the verification art as an "end-to-end" check.

In modern data processing systems, especially large server-class computer systems, the number of latches that must be loaded to configure the system for operation (or simulation) is increasing dramatically. One reason for the increase in configuration latches is that many chips are being designed to support multiple different configurations and operating modes in order to improve manufacturer profit margins and simplify system design. For example, memory controllers commonly require substantial configuration information to properly interface memory cards of different types, sizes, and operating frequencies.

A second reason for the increase in configuration latches is the ever-increasing transistor budget within processors and other integrated circuit chips. Often the additional transistors available within the next generation of chips are devoted to replicated copies of existing functional units in order to improve fault tolerance and parallelism. However, because transmission latency via intra-chip wiring is not decreasing proportionally to the increase in the operating frequency of functional logic, it is generally viewed as undesirable to centralize configuration latches for all similar functional units. Consequently, even though all instances of a replicated functional unit are frequently identically configured, each instance tends to be designed with its own copy of the configuration latches. Thus, configuring an operating parameter having only a few valid values (e.g., the ratio between the bus clock frequency and processor clock frequency) may involve setting hundreds of configuration latches in a processor chip.

Conventionally, configuration latches and their permitted range of values have been specified by error-prone paper documentation that is tedious to create and maintain. Compounding the difficulty in maintaining accurate configuration documentation and the effort required to set configuration latches is the fact that different constituencies within a single company (e.g., a functional simulation team, a laboratory debug team, and one or more customer firmware teams) often separately develop configuration software from the configuration documentation. As the configuration software is separately developed by each constituency, each team may introduce its own errors and employ its own terminology and naming conventions. Consequently, the configuration software developed by the different teams is not compatible and cannot easily be shared between the different teams.

In addition to the foregoing shortcomings in the process of developing configuration code, conventional configuration software is extremely tedious to code. In particular, the vocabulary used to document the various configuration bits is often quite cumbersome. For example, in at least some implementations, configuration code must specify, for each configuration latch bit, a full latch name, which may include fifty or more ASCII characters. In addition, valid binary bit patterns for each group of configuration latches must be individually specified.

Another problem encountered in the simulation and debugging of simulated and hardware digital systems is that the state of the simulated or hardware digital system is difficult to present in a convenient format. Conventionally, a person that is debugging a digital system will obtain a raw "dump" of the values of the thousands of latches, registers or configuration constructs within the digital system. The dump will then be processed manually or utilizing a script to remove large amount of "uninteresting" data, presumably leaving a manageable collection of data (which may be further parsed and/or transformed) that will aid the user in debugging the hardware system.

Although this convention technique of ascertaining the state of a digital design reduces the difficulty in parsing and interpreting the results of a system "dump," the individuals responsible for debugging the design are often unaware of the details of the underlying latches and configuration constructs and are therefore left to "reverse engineer" much of the design to understand its operation, or seek assistance from the original design team. Moreover, because the names of the signals and latches within a design often change between revisions of the design, the scripts and other debugging tools developed to interpret the state of the system and facilitate debugging cannot be reused for multiple designs.

In view of the foregoing, the present invention appreciates that it would be useful and desirable to provide an improved method of configuring and presenting the state of a digital system described by an HDL model, particularly one that supports the selective presentation of configuration information in accordance with designers' or other users' preferences.

SUMMARY OF THE INVENTION

Improved methods, systems, and program products for specifying and presenting the configuration of a digital system, such as an integrated circuit or collection of interconnected integrated circuits, are disclosed. According to one method, a respective one of a plurality of design graphical representations is displayed within a display device for each of a plurality of hierarchically arranged design entity instances within a simulated system. The design entity instances include a particular design entity instance containing a latch that is represented by a particular design graphical representation. A configuration entity instance associated with the particular design entity is identified within a configuration database associated with the simulated system. The configuration entity instance has a plurality of different settings that each reflects a value of the latch. Within the display device, a configuration graphical representation of the configuration entity instance is presented in association with the particular design graphical representation corresponding to the particular design entity instance. In addition, a current setting of the configuration entity instance is presented concurrently with the configuration graphical representation.

All objects, features, and advantages of the present invention will become apparent in the following detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. However, the invention, as well as a preferred mode of use, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 is a high level block diagram of a data processing system that may be utilized to implement the present invention;

FIG. 2 is a diagrammatic representation of a design entity described by HDL code;

FIG. 3 illustrates an exemplary digital design including a plurality of hierarchically arranged design entities;

FIG. 4A depicts an exemplary HDL file including embedded configuration specification statements in accordance with the present invention;

FIG. 4B illustrates an exemplary HDL file including an embedded configuration file reference statement referring to an external configuration file containing a configuration specification statement in accordance with the present invention;

FIG. 5A is a diagrammatic representation of an LDial primitive in accordance with the present invention

FIG. 5B depicts an exemplary digital design including a plurality of hierarchically arranged design entities in which LDials are instantiated in accordance with the present invention;

FIG. 5C illustrates an exemplary digital design including a plurality of hierarchically arranged design entities in which an LDial is employed to configure signal states at multiple different levels of the design hierarchy;

FIG. 5D is a diagrammatic representation of a Switch in accordance with the present invention;

FIG. 6A is a diagrammatic representation of an IDial in accordance with the present invention;

FIG. 6B is a diagrammatic representation of an IDial having a split output in accordance with the present invention;

FIG. 7A is a diagrammatic representation of a CDial employed to control other Dials in accordance with the present invention;

FIG. 7B depicts an exemplary digital design including a plurality of hierarchically arranged design entities in which a CDial is employed to control lower-level Dials utilized to configure signal states;

FIG. 7C is a diagrammatic representation of a Register in accordance with the present invention;

FIG. 8 is a high level flow diagram of a model build process utilized to produce a simulation executable model and associated simulation configuration database in accordance with the present invention;

FIG. 9A illustrates a portion of a digital design illustrating the manner in which a traceback process implemented by a configuration compiler detects inverters in the signal path between a configured signal and an associated configuration latch;

FIG. 9B is a high level flowchart of an exemplary traceback process implemented by a configuration compiler in accordance with a preferred embodiment of the present invention;

FIG. 10 is a high level logical flowchart of an exemplary method by which a configuration compiler parses each signal or Dial identification within a configuration specification statement in accordance with a preferred embodiment of the present invention;

FIG. 11A depicts a diagrammatic representation of a Dial group;

FIG. 11B illustrates an exemplary simulation model including Dials grouped in multiple hierarchically arranged Dial groups;

FIG. 12A depicts an exemplary embodiment of a simulation configuration database in accordance with the present invention;

FIG. 12B is a more detailed view of an exemplary simulation configuration database including data structures representing Dials and Registers in accordance with the present invention;

FIG. 13 is a high level logical flowchart of a illustrative method by which a configuration database is expanded within volatile memory of a data processing system in accordance with the present invention;

FIG. 14 is a block diagram depicting the contents of volatile system memory during a simulation run of a simulation model in accordance with the present invention;

FIG. 15 is a high level logical flowchart of an exemplary method of locating one or more Dial instance data structure (DIDS) in a configuration database that are identified by a instance qualifier and dialname qualifier supplied in an API call;

FIG. 16A is a high level logical flowchart of an illustrative method of reading a Dial instance in an interactive mode during simulation of a digital design in accordance with the present invention;

FIG. 16B is a high level logical flowchart of an exemplary method of reading a Dial group instance in an interactive mode during simulation of a digital design in accordance with the present invention;

FIG. 17A is a high level logical flowchart of an illustrative method of setting a Dial instance in an interactive mode during simulation of a digital design in accordance with the present invention;

FIG. 17B is a high level logical flowchart of an exemplary method of setting a Dial group instance in an interactive mode during simulation of a digital design in accordance with the present invention;

FIG. 18A is a high level logical flowchart of an illustrative method of setting a Dial instance or Dial group instance in a batch mode during simulation of a digital design in accordance with the present invention;

FIG. 18B is a more detailed flowchart of an end_phase API called within the process shown in FIG. 18A;

FIG. 18C is a block diagram of a data processing system environment in which a program may be utilized to access and modify a configuration database in order to specify phasing of the application of defaults;

FIG. 19 is a block diagram depicting an exemplary laboratory testing system in accordance with the present invention;

FIG. 20 is a more detailed block diagram of an integrated circuit chip within a data processing system forming a portion of the laboratory testing system of FIG. 19;

FIG. 21 is a high level flow diagram of an illustrative process for transforming a simulation configuration database to obtain a chip hardware database suitable for use in configuring a hardware realization of a digital design;

FIG. 22A is a high level logical flowchart of an exemplary method of transforming a configuration database to obtain a chip hardware database in accordance with the present invention;

FIG. 22B depicts an illustrative embodiment of a latch data structure within a chip hardware database following the transformation process illustrated in FIG. 22A;

FIG. 23A is a high level logical flowchart of an exemplary method of loading a hardware configuration database from non-volatile storage into volatile memory that supports use of the hardware configuration database with digital systems of any arbitrary size or configuration;

FIG. 23B illustrates an exemplary embodiment of a hardware configuration database of a digital system in accordance with one embodiment of the present invention;

FIG. 24 is a high level logical flowchart of an exemplary method of identifying, by reference to a hardware configuration database, one or more Dial instances or Dial group instances in a digital system that are relevant to an API call;

FIG. 25 is a high level logical flow diagram of an exemplary process by which a hardware configuration database developed during laboratory development and testing of system firmware can be compressed for commercial deployment;

FIGS. 26A-26C together form a high level logical flowchart of an illustrative method of compressing a hardware configuration database utilizing a software compression tool in accordance with the present invention;

FIG. 27 is a graphical representation of the contents of an exemplary configuration database including both Dials and read-only Dials in accordance with the present invention;

FIGS. 28A-28B respectively illustrate the inclusion of read-only parent fields within Dial instance data structures and latch data structures of a configuration database in order to support read-only Dials and read-only Dial groups in accordance with one embodiment of the present invention;

FIG. 29 is a high level logical flowchart of an exemplary method of expanding a configuration database containing RDial and/or RDial groups into volatile memory;

FIG. 30 is a high level flow diagram of an exemplary process for analyzing a selected state of a hardware system, and in particular, a failure state of a hardware system, in accordance with the present invention;

FIG. 31 is a high level logical flowchart of an exemplary method by which the chip analyzer tool of FIG. 30 generates chip configuration reports and simulation setup files utilized to analyze hardware failures in accordance with the present invention;

FIG. 32 depicts an exemplary embodiment of a configuration database supporting the selective presentation of configuration entity instances, such as Dials, Dial groups, and Registers, in accordance with the present invention;

FIG. 33 is a high level logical flowchart an exemplary process for selectively presenting the settings of configuration entity instances describing the state of a simulated or hardware system;

FIG. 34A illustrates an exemplary Graphical User Interface (GUI) for presenting a simulated or hardware system in accordance with the present invention;

FIG. 34B depicts a view of system presented within the exemplary GUI of FIG. 34A in which the displayed design hierarchy depth is limited in accordance with the present invention;

FIG. 34C illustrates a view of system presented within the exemplary GUI of FIG. 34A demonstrating the manner in which the design hierarchy can be intuitive traversed in accordance with the present invention;

FIG. 34D depicts a view of system presented within the exemplary GUI of FIG. 34A demonstrating the manner in which the additional levels of configuration hierarchy can be exposed in accordance with the present invention;

FIG. 34E illustrates a view of system presented within the exemplary GUI of FIG. 34A in which the configuration entity instances are selectively omitted from presentation based upon configuration database settings in accordance with the present invention; and

FIG. 34F depicts a view of system presented within the exemplary GUI of FIG. 34A in which configuration entity instances having varying degrees of relevance are displayed in a graphically distinct manner in accordance with the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENT

The present invention employs a configuration specification language and associated methods, systems, and program products for configuring and controlling the setup of a digital system (e.g., one or more integrated circuits or a simulation model thereof). In at least one embodiment, configuration specifications for signals in the digital system are created in HDL code by the designer responsible for an associated design entity. Thus, designers at the front end of the design process, who are best able to specify the signal names and associated legal values, are responsible for creating the configuration specification. The configuration specification is compiled at model build time together with the HDL describing the digital system to obtain a configuration database that can then be utilized by downstream organizational groups involved in the design, simulation, and hardware implementation processes.

With reference now to the figures, and in particular with reference to FIG. 1, there is depicted an exemplary embodiment of a data processing system in accordance with the present invention. The depicted embodiment can be realized, for example as a workstation, server, or mainframe computer.

As illustrated, data processing system 6 includes one or more processing nodes 8a-8n, which, if more than one processing node 8 is implemented, are interconnected by node interconnect 22. Processing nodes 8a-8n may each include one or more processors 10, a local interconnect 16, and a system memory 18 that is accessed via a memory controller 17. Processors 10a-10m are preferably (but not necessarily) identical and may comprise a processor within the PowerPC.TM. line of processors available from International Business Machines (IBM) Corporation of Armonk, N.Y. In addition to the registers, instruction flow logic and execution units utilized to execute program instructions, which are generally designated as processor core 12, each of processors 10a-10m also includes an on-chip cache hierarchy that is utilized to stage data to the associated processor core 12 from system memories 18.

Each of processing nodes 8a-8n further includes a respective node controller 20 coupled between local interconnect 16 and node interconnect 22. Each node controller 20 serves as a local agent for remote processing nodes 8 by performing at least two functions. First, each node controller 20 snoops the associated local interconnect 16 and facilitates the transmission of local communication transactions to remote processing nodes 8. Second, each node controller 20 snoops communication transactions on node interconnect 22 and masters relevant communication transactions on the associated local interconnect 16. Communication on each local interconnect 16 is controlled by an arbiter 24. Arbiters 24 regulate access to local interconnects 16 based on bus request signals generated by processors 10 and compile coherency responses for snooped communication transactions on local interconnects 16.

Local interconnect 16 is coupled, via mezzanine bus bridge 26, to a mezzanine bus 30. Mezzanine bus bridge 26 provides both a low latency path through which processors 10 may directly access devices among I/O devices 32 and storage devices 34 that are mapped to bus memory and/or I/O address spaces and a high bandwidth path through which I/O devices 32 and storage devices 34 may access system memory 18. I/O devices 32 may include, for example, a display device, a keyboard, a graphical pointer, and serial and parallel ports for connection to external networks or attached devices. Storage devices 34 may include, for example, optical or magnetic disks that provide non-volatile storage for operating system, middleware and application software. In the present embodiment, such application software includes an ECAD system 35, which can be utilized to develop, verify and simulate a digital circuit design in accordance with the methods and systems of the present invention.

Simulated digital circuit design models created utilizing ECAD system 35 are comprised of at least one, and usually many, sub-units referred to hereinafter as design entities. Referring now to FIG. 2, there is illustrated a block diagram representation of an exemplary design entity 200 which may be created utilizing ECAD system 35. Design entity 200 is defined by a number of components: an entity name, entity ports, and a representation of the function performed by design entity 200. Each design entity within a given model has a unique entity name (not explicitly shown in FIG. 2) that is declared in the HDL description of the design entity. Furthermore, each design entity typically contains a number of signal interconnections, known as ports, to signals outside the design entity. These outside signals may be primary input/outputs (I/Os) of an overall design or signals connected to other design entities within an overall design.

Typically, ports are categorized as belonging to one of three distinct types: input ports, output ports, and bi-directional ports. Design entity 200 is depicted as having a number of input ports 202 that convey signals into design entity 200. Input ports 202 are connected to input signals 204. In addition, design entity 200 includes a number of output ports 206 that convey signals out of design entity 200. Output ports 206 are connected to a set of output signals 208. Bi-directional ports 210 are utilized to convey signals into and out of design entity 200. Bi-directional ports 210 are in turn connected to a set of bi-directional signals 212. A design entity, such as design entity 200, need not contain ports of all three types, and in the degenerate case, contains no ports at all. To accomplish the connection of entity ports to external signals, a mapping technique, known as a "port map", is utilized. A port map (not explicitly depicted in FIG. 2) consists of a specified correspondence between entity port names and external signals to which the entity is connected. When building a simulation model, ECAD software 35 is utilized to connect external signals to appropriate ports of the entity according to a port map specification.

As further illustrated in FIG. 2, design entity 200 contains a body section 214 that describes one or more functions performed by design entity 200. In the case of a digital design, body section 214 contains an interconnection of logic gates, storage elements, etc., in addition to instantiations of other entities. By instantiating an entity within another entity, a hierarchical description of an overall design is achieved. For example, a microprocessor may contain multiple instances of an identical functional unit. As such, the microprocessor itself will often be modeled as a single entity. Within the microprocessor entity, multiple instantiations of any duplicated functional entities will be present.

Each design entity is specified by one or more HDL files that contain the information necessary to describe the design entity. Although not required by the present invention, it will hereafter be assumed for ease of understanding that each design entity is specified by a respective HDL file.

With reference now to FIG. 3, there is illustrated a diagrammatic representation of an exemplary simulation model 300 that may be employed by ECAD system 35 to represent a digital design (e.g., an integrated circuit chip or a computer system) in a preferred embodiment of the present invention. For visual simplicity and clarity, the ports and signals interconnecting the design entities within simulation model 300 have not been explicitly shown.

Simulation model 300 includes a number of hierarchically arranged design entities. As within any simulation model, simulation model 300 includes one and only one "top-level entity" encompassing all other entities within simulation model 300. That is to say, top-level entity 302 instantiates, either directly or indirectly, all descendant entities within the digital design. Specifically, top-level entity 302 directly instantiates (i.e., is the direct ancestor of) two instances, 304a and 304b, of the same FiXed-point execution Unit (FXU) entity 304 and a single instance of a Floating Point Unit (FPU) entity 314. FXU entity instances 304, having instantiation names FXU0 and FXU1, respectively, in turn instantiate additional design entities, including multiple instantiations of entity A 306 having instantiation names A0 and A1, respectively.

Each instantiation of a design entity has an associated description that contains an entity name and an instantiation name, which must be unique among all descendants of the direct ancestor entity, if any. For example, top-level entity 302 has a description 320 including an entity name 322 (i.e., the "TOP" preceding the colon) and also includes an instantiation name 324 (i.e., the "TOP" following the colon). Within an entity description, it is common for the entity name to match the instantiation name when only one instance of that particular entity is instantiated within the ancestor entity. For example, single instances of entity B 310 and entity C 312 instantiated within each of FXU entity instantiations 304a and 304b have matching entity and instantiation names. However, this naming convention is not required by the present invention as shown by FPU entity 314 (i.e., the instantiation name is FPU0, while the entity name is FPU).

The nesting of entities within other entities in a digital design can continue to an arbitrary level of complexity, provided that all entities instantiated, whether singly or multiply, have unique entity names and the instantiation names of all descendant entities within any direct ancestor entity are unique with respect to one another.

Associated with each design entity instantiation is a so called "instantiation identifier". The instantiation identifier for a given instantiation is a string including the enclosing entity instantiation names proceeding from the top-level entity instantiation name. For example, the design instantiation identifier of instantiation 312a of entity C 312 within instantiation 304a of FXU entity 304 is "TOP.FXU0.B.C". This instantiation identifier serves to uniquely identify each instantiation within a simulation model.

As discussed above, a digital design, whether realized utilizing physical integrated circuitry or as a software model such as simulation model 300, typically includes configuration latches utilized to configure the digital design for proper operation. In contrast to prior art design methodologies, which employ stand-alone configuration software created after a design is realized to load values into the configuration latches, the present invention introduces a configuration specification language that permits a digital designer to specify configuration values for signals as a natural part of the design process. In particular, the configuration specification language of the present invention permits a design configuration to be specified utilizing statements either embedded in one or more HDL files specifying the digital design (as illustrated in FIG. 4A) or in one or more external configuration files referenced by the one or more HDL files specifying the digital design (as depicted in FIG. 4B).

Referring now to FIG. 4A, there is depicted an exemplary HDL file 400, in this case a VHDL file, including embedded configuration statements in accordance with the present invention. In this example, HDL file 400 specifies entity A 306 of simulation model 300 and includes three sections of VHDL code, namely, a port list 402 that specifies ports 202, 206 and 210, signal declarations 404 that specify the signals within body section 214, and a design specification 406 that specifies the logic and functionality of body section 214. Interspersed within these sections are conventional VHDL comments denoted by an initial double-dash ("--"). In addition, embedded within design specification 406 are one or more configuration specification statements in accordance with the present invention, which are collectively denoted by reference numerals 408 and 410. As shown, these configuration specification statements are written in a special comment form beginning with "--##" in order to permit a compiler to easily distinguish the configuration specification statements from the conventional HDL code and HDL comments. Configuration specification statements preferably employ a syntax that is insensitive to case and white space.

With reference now to FIG. 4B, there is illustrated an exemplary HDL file 400' that includes a reference to an external configuration file containing one or more configuration specification statements in accordance with the present invention. As indicated by prime notation ('), HDL file 400' is identical to HDL file 400 in all respects except that configuration specification statements 408, 410 are replaced with one or more (and in this case only one) configuration file reference statement 412 referencing a separate configuration file 414 containing configuration specification statements 408, 410.

Configuration file reference statement 412, like the embedded configuration specification statements illustrated in FIG. 4A, is identified as a configuration statement by the identifier "--##". Configuration file reference statement 412 includes the directive "cfg_file", which instructs the compiler to locate a separate configuration file 414, and the filename of the configuration file (i.e., "file00"). Configuration files, such as configuration file 412, preferably all employ a selected filename extension (e.g., ".cfg") so that they can be easily located, organized, and managed within the file system employed by data processing system 6.

As discussed further below with reference to FIG. 8, configuration specification statements, whether embedded within an HDL file or collected in one or more configuration files 414, are processed by a compiler together with the associated HDL files.

In accordance with a preferred embodiment of the present invention, configuration specification statements, such as configuration specification statements 408, 410, facilitate configuration of configuration latches within a digital design by instantiating one or more instances of a configuration entity referred to herein generically as a "Dial." A Dial's function is to map between an input value and one or more output values. In general, such output values ultimately directly or indirectly specify configuration values of configuration latches. Each Dial is associated with a particular design entity in the digital design, which by convention is the design entity specified by the HDL source file containing the configuration specification statement or configuration file reference statement that causes the Dial to be instantiated. Consequently, by virtue of their association with particular design entities, which all have unique instantiation identifiers, Dials within a digital design can be uniquely identified as long as unique Dial names are employed within any given design entity. As will become apparent, many different types of Dials can be defined, beginning with a Latch Dial (or "LDial").

Referring now to FIG. 5A, there is depicted a representation of an exemplary LDial 500. In this particular example, LDial 500, which has the name "bus ratio", is utilized to specify values for configuration latches in a digital design in accordance with an enumerated input value representing a selected ratio between a component clock frequency and bus clock frequency.

As illustrated, LDial 500, like all Dials, logically has a single input 502, one or more outputs 504, and a mapping table 503 that maps each input value to a respective associated output value for each output 504. That is, mapping table 503 specifies a one-to-one mapping between each of one or more unique input values and a respective associated unique output value. Because the function of an LDial is to specify the legal values of configuration latches, each output 504 of LDial 500 logically controls the value loaded into a respective configuration latch 505. To prevent conflicting configurations, each configuration latch 505 is directly specified by one and only one Dial of any type that is capable of setting the configuration latch 505.

At input 502, LDial 500 receives an enumerated input value (i.e., a string) among a set of legal values including "2:1", "3:1" and "4:1". The enumerated input value can be provided directly by software (e.g., by a software simulator or service processor firmware) or can be provided by the output of another Dial, as discussed further below with respect to FIG. 7A. For each enumerated input value, the mapping table 503 of LDial 500 indicates a selected binary value (i.e., "0" or "1") for each configuration latch 505.

With reference now to FIG. 5B, there is illustrated a diagrammatic representation of a simulation model logically including Dials. Simulation model 300' of FIG. 5B, which as indicated by prime notation includes the same design entities arranged in the same hierarchical relation as simulation model 300 of FIG. 3, illustrates two properties of Dials, namely, replication and scope.

Replication is a process by which a Dial that is specified in or referenced by an HDL file of a design entity is automatically instantiated each time that the associated design entity is instantiated. Replication advantageously reduces the amount of data entry a designer is required to perform to create multiple identical instances of a Dial. For example, in order to instantiate the six instances of LDials illustrated in FIG. 5B, the designer need only code two LDial configuration specification statements utilizing either of the two techniques illustrated in FIGS. 4A and 4B. That is, the designer codes a first LDial configuration specification statement (or configuration file reference statement pointing to an associated configuration file) into the HDL file of design entity A 306 in order to automatically instantiate LDials 506a0, 506a1, 506b0 and 506b1 within entity A instantiations 306a0, 306a1, 306b0 and 306b1, respectively. The designer codes a second LDial configuration specification statement (or configuration file reference statement pointing to an associated configuration file) into the HDL file of design entity FXU 304 in order to automatically instantiate LDials 510a and 510b within FXU entity instantiations 304a and 304b, respectively. The multiple instances of the LDials are then created automatically as the associated design entities are replicated by the compiler. Replication of Dials within a digital design can thus significantly reduce the input burden on the designer as compared to prior art methodologies in which the designer had to individually enumerate in the configuration software each configuration latch value by hand. It should be noted that the property of replication does not necessarily require all instances of a Dial to generate the same output values; different instances of the same Dial can be set to generate different outputs by providing them different inputs.

The "scope" of a Dial is defined herein as the set of entities to which the Dial can refer in its specification. By convention, the scope of a Dial comprises the design entity with which the Dial is associated (i.e., the design entity specified by the HDL source file containing the configuration specification statement or configuration file reference statement that causes the Dial to be instantiated) and any design entity contained within the associated design entity (i.e., the associated design entity and its descendents). Thus, a Dial is not constrained to operate at the level of the design hierarchy at which it is instantiated, but can also specify configuration latches at any lower level of the design hierarchy within its scope. For example, LDials 510a and 510b, even though associated