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.