Logic simulation

BACKGROUND

0001This invention relates to logic simulation.

0002Logic designs for computer chips typically include combinatorial elements and state elements. Combinatorial elements, such as AND gates and OR gates, combine two or more logic states to produce an output. State elements, such as latches and flip-flops (FFs), hold a logic state for a period of time, usually until receipt of an external clock signal.

SUMMARY

0003Logic simulation includes storing a first state to identify in a simulation of a logic design whether a node included in the logic design has a logic high value Logic simulation also includes storing a second state to identify in simulation of the logic design whether the node has a logic low value and storing a third state to identify in simulation of the logic design whether the node has an undefined state. The logic simulation determines an output of the node in simulation of the logic design based on the first state, the second state, and the third state.

0004Computer languages exist which allow designers to simulate logic designs, including combinatorial and state elements, prior to forming the logic on silicon. Examples of such languages include Verilog and Very High-Level Design Language (VHDL). Using these languages, a designer can write code to simulate a logic design and execute the code in order to determine if the logic design performs properly.

0005In simulating the logic design, the code can perform two state simulation and/or four state simulation. In two state simulation, the code models two logic states: one and zero. In four state simulation, the code models the one and zero logic states handled during two state simulation, an undefined state, and a high impedance state. Two state simulation can quickly execute and detect errors in high and low logic states in the logic design while four state simulation can detect design problems when signals in the logic design are not initialized (e.g., are undefined) or driven by other logic (e.g., have high impedance).

0006Standard computer languages may also be used to simulate a logic design. One example of a standard computer language that may be used is C++.

DESCRIPTION OF DRAWINGS

0007<figref idref="DRAWINGS">FIG. 1</figref> is a flowchart showing a process of simulating operation of a logic design.

0008<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of a logic design containing individual state and combinatorial elements.

0009<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of an alternative logic design containing state and combinatorial elements.

0010<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart showing a process of performing three state simulation initialization checks.

0011<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart showing a process of handling forced nodes in cycle-based simulation.

0012<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram of a computer system on which the processes of <figref idref="DRAWINGS">FIGS. 1</figref>, <b>4</b>, and/or <b>5</b> may be performed.

DESCRIPTION

0013Referring to <figref idref="DRAWINGS">FIG. 1</figref>, a process <b>100</b> illustrates an example of simulating operation of a hardware circuit or logic design represented by a block diagram using three state simulation. The process <b>100</b> may be implemented using a computer program running on a computer or other type of machine as described in more detail below.

0014By using three state simulation, the process <b>100</b> can model a state at a node in the block diagram as a logic high (e.g., a one), as a logic low (e.g., a zero), or as an undefined value. (A logic high may be a zero if a logic low is a one.) In this way, the process <b>100</b> can perform simulation as in a traditional two state simulation with logic high and low states while detecting undefined states (improperly reset or improperly initialized designs) quickly, accurately, and early in the logic design and simulation process. Upon detection of an undefined state, the logic designer can change the logic design so as to get the state properly initialized, and so forth.

0015Each block in the block diagram may represent individual elements or combinations of elements. For example, <figref idref="DRAWINGS">FIG. 2</figref> shows a graphical representation of a logic design <b>200</b> containing combinatorial logic elements <b>202</b>, <b>204</b>, <b>206</b>, and <b>208</b> and state logic elements <b>210</b> and <b>212</b>. In the logic design <b>200</b>, each block represents a single combinatorial element (e.g., multiplexors <b>206</b> and <b>208</b>) or state elements (e.g., FFs <b>210</b> and <b>212</b>). By contrast, in logic design <b>300</b> (<figref idref="DRAWINGS">FIG. 3</figref>), the functionality of several combinatorial elements is contained in a single combinatorial block <b>302</b> and the function of several state elements is contained in a single state block <b>304</b>.

0016Once the graphical representation of the logic design has been completed <b>102</b> (e.g., <figref idref="DRAWINGS">FIGS. 2 and 3</figref>), the process <b>100</b> performs <b>104</b> an error check on the design to determine if there are any problems with the design. For example, the process <b>100</b> may determine if there are any unterminated or inconsistent connections in the design. If any such problems are detected, the process <b>100</b> can issue an error message to a logic designer. The error message may specify the nature of the problem and its location within the logic design. The logic designer is then given the opportunity to correct the problem before the process <b>100</b> moves forward.

0017The process <b>100</b> writes <b>106</b> a design wirelist in computer code that simulates the logic design with each of the graphic elements.

0018Referring to <figref idref="DRAWINGS">FIG. 3</figref>, for example, the process <b>100</b> associates computer code with the combinatorial logic element <b>302</b> to define its function and with state logic element <b>304</b> to define its function. Furthermore, the process <b>100</b> knows which nodes are subject to three state simulation processing (those nodes between logic elements) and tags those nodes as tri-state nodes in the computer code. The same associating and tagging is true for the logic elements of <figref idref="DRAWINGS">FIG. 2</figref>. The computer code can be generated using any generation process.

0019For example, the process <b>100</b> may include receiving intermediate computer code (e.g., an application-specific code such as C++ or Verilog) for each graphic element written by the logic designer. Assuming that there are no problems in the design or that the problems have been corrected, the process <b>100</b> may generate standard simulation code for the design in any kind of computer code, such as C++, Verilog, VHDL, and other similar codes.

0020Once the process <b>100</b> has computer code that simulates the logic design, the process <b>100</b> performs <b>108</b> three state simulation initialization checks for the logic elements included in the logic design. In executing the code in the simulation, the process <b>100</b> checks each tri-state signal (those signals on wires that connect tri-state drivers as tagged in the code) to make sure that two (or more) drivers are not driving at the same time on any bit of a tri-state signal. The process <b>100</b> checks every bit position of the tri-state signal, e.g., each wire driving a logic device, to make sure that at least one tri-state driver is enabled, e.g., that a signal exists on the wire. Any bit of the signal that is not driven by one driver is flagged as not being driven or as multiply driven.

0021Referring to <figref idref="DRAWINGS">FIG. 4</figref>, a tri-state process <b>400</b> illustrates an example of how the process <b>100</b> may perform such three state simulation initialization checks. The tri-state process <b>400</b> begins <b>402</b> by executing the computer code starting at the beginning of the code. In other words, the simulation is performed in a cycle-based, code-ordered fashion as a single call model, running through the code once and establishing all states in the coded logic design.

0022The tri-state process <b>400</b> may store state information in a database. If the code is in a language with inheritance capabilities such as C++, the tri-state process <b>400</b> can enable the code compiler to handle the large number of states that may result from a given logic model. That is, the state of an initial logic gate may be defined as a class (e.g., a C++ class). The states of the logic gates that depend from the initial logic gate may refer back to the state of the initial logic gate without actually including data for the state of the initial logic gate. This way, if the state of a subsequent gate depends on the state of a preceding gate, it is possible to obtain the state of the preceding gate without actually adding more data to the database.

0023When the tri-state process <b>400</b> encounters <b>404</b> a tri-state signal in the code, the tri-state process <b>400</b> determines <b>406</b> if two (or more) drivers are driving any bit of the signal. If so, then a potential contention exists on the wire line, so the output of the tri-state signal has an undefined state. The tri-state process <b>400</b> sets <b>408</b> the undefined bit for that signal, indicating an undefined state for that signal. The tri-state process <b>400</b> continues <b>410</b> executing the code. Alternatively, the tri-state process <b>400</b> may terminate or suspend the simulation upon detection of the undefined state and issue <b>412</b> an error message to the logic designer as described above. The logic designer fixes the problem and the tri-state process <b>400</b> can resume simulation of the logic design at the point of termination or at the beginning of the code.

0024If two (or more) drivers do not drive the signal, then the tri-state process <b>400</b> determines <b>414</b> if any source drives the signal. If not, then the tri-state process <b>400</b> can deduce on the fly that the signal has a high impedance state. The tri-state process <b>400</b> may not hold information in a bit on the high impedance state, but, if it does, it sets <b>416</b> a high-impedance bit for that signal. Whether the tri-state process <b>400</b> sets a high impedance bit or not, the tri-state process <b>400</b> may continue <b>410</b> executing the code or may issue <b>412</b> an error message as described above.

0025If less than two drivers but more than zero drivers drive the signal, then one driver drives the signal. The tri-state process <b>400</b> sets <b>418</b> the appropriate one of the logic high and logic low states for the signal, logic high for a signal state of one and logic low for a signal state of zero. The tri-state process <b>400</b> continues <b>410</b> executing the code as described above.

0026Referring again to <figref idref="DRAWINGS">FIG. 1</figref>, after performing the three state simulation initialization checks, the process <b>100</b> determines <b>110</b> if the checks were successful. The checks are successful if the process <b>100</b> does not detect any undefined states. If the checks were unsuccessful, then the process <b>100</b> ends until another design is entered <b>102</b>, e.g., until the logic designer modifies the logic design to try to fix the detected state initialization error or errors. (If the process <b>100</b> terminates the checks upon detecting an undefined state and/or a high impedance state, then the process <b>100</b> knows that the checks were not successful and ends until another design is entered.)

0027If the checks were successful, then the process <b>100</b> may perform <b>112</b> another check or checks, such as four state simulation. Four state simulation typically involves simulating the logic design using four bits to represent four logic states: logic high, logic low, undefined, and high impedance. Performing four state simulation can help refine the initialization model deemed successful under the previously performed three state simulation. The process <b>100</b> need not perform the four state simulation or any other checks after three state simulation.

0028The process <b>100</b> can also determine <b>114</b> if the four state simulation was successful. In other words, the process <b>100</b> determines if any states are tagged as undefined and/or as high impedance. This check can be performed, for example, after the four state simulation. If the checks were unsuccessful, then the process <b>100</b> ends until another design is entered as described above. If the checks were successful, then the process ends <b>116</b>, indicating that the logic design is properly initialized.

0029In executing the code during simulation, the process <b>100</b> performs logic computations, e.g., AND operations for AND gates, and attempts to store results of the logic computations in memory. Memory is typically divided into pages (sometimes called virtual memory pages), each page including a defined amount of data (usually expressed in bytes) corresponding to code. If a page is write-protected, then the process <b>100</b> cannot write the result to memory, resulting in an error.

0030The process <b>100</b> may use the fact that pages can be write-protected to handle forced results. A result is forced if the logic designer, typically for purposes of simulation, defines the result to be a particular value regardless of the actual result of a logic computation.

0031While executing the code, the process <b>100</b> could check each node to determine if the node has a forced value. This determination, however, can slow down the simulation and use valuable processing resources. Instead, the process <b>100</b> may identify forced nodes while writing the design wirelist and set access rights for the page or pages including those forced nodes as write-protected. Then, when the process <b>100</b> executes the code, forced nodes may be identified by an attempt to write to a write-protected memory page rather than by a slower node-by-node evaluation of forced values.

0032Referring to <figref idref="DRAWINGS">FIG. 5</figref>, a force process <b>500</b> illustrates an example of how the process <b>100</b> may handle storage of logic results and forced nodes during cycle-based simulation. In generating the code for simulation, the memory page or pages associated with any forced nodes included in the logic design are write-protected. In this way, the force process <b>500</b> can identify which nodes are forced by encountering storage errors as further described below. The force process <b>500</b> may be used in any cycle-based simulation.

0033The force process <b>500</b> may perform <b>502</b> a logic computation and attempt <b>504</b> to store the result of the logic computation in memory. If storage cannot occur for some reason, the force process <b>500</b> generates an exception indicating an error condition. If the force process <b>500</b> does not generate an exception in attempting to store the result in the memory page, then the force process <b>500</b> stores <b>506</b> the result in memory and continues <b>508</b> executing the code.

0034If the force process <b>500</b> does generate an exception, then the force process <b>500</b> calls or executes an exception handler to interrogate the system to determine the reason for the exception. A plurality of exception handlers may be available to the force process <b>500</b>, each exception handler capable of handling a particular type of exception, e.g., write access errors, invalid memory address, etc. Typically, exception handlers are accessed in a predetermined order, where the exception is passed from one exception handler to the next until the exception reaches the exception handler capable of handling that particular type of exception. In this example, the force process <b>500</b> first passes the exception to a first exception handler capable of handling write access errors.

0035The first exception handler determines <b>510</b> if the exception was generated because of a write access problem. If not, then the first exception handler passes <b>512</b> the exception to the next exception handler according to the predetermined order. This exception handler either handles the exception or passes the exception to the next exception handler, and so on until the exception reaches the appropriate exception handler and is handled.

0036If the error was generated because of a write access problem, then the first exception handler handles the exception. The first exception handler knows which instruction in the code caused the exception because the instruction that caused the force process <b>500</b> to generate the exception is usually included in the exception. The first exception handler stores <b>514</b> this instruction, as yet unexecuted, at the top of a non-write protected memory page. This memory page is typically a memory page that does not include any of the code being executed by the process <b>100</b> and may be a page set aside for use by the first exception handler. Immediately following this instruction in the memory page, the first exception handler inserts <b>516</b> an illegal instruction that will always generate an exception when executed. The first exception handler also unprotects <b>518</b> the original write-protected memory page where the force process <b>500</b> tried to store the result.

0037The force process <b>500</b> then redirects code execution to start execution <b>520</b> at the top of the memory page used by the first exception handler. The originally failed instruction executes and because the original memory page is no longer write-protected, the force process <b>500</b> can write the result to the original memory page. In this way, the force process <b>500</b> can execute the instruction as if the artificially forced value was not present and therefore simulate operation of the logic design as it would actually be executed in hardware to increase the chances of finding initialization errors during this simulation.

0038The memory page continues executing with the illegal instruction, which generates an exception. This exception passes to an exception handler that determines <b>522</b> if the force process <b>500</b> wrote to the original memory page.

0039If the force process <b>500</b> did store the result in the original memory page, then the force process <b>500</b> concludes that the value at that node is forced because the page was write-protected, indicating that at least one value stored in that page is forced, and because the result changed from that stored value. Thus, the force process <b>500</b> rewrites <b>524</b> the original value (the presumably forced value) back into the original memory page.

0040The force process <b>500</b> also re-protects <b>526</b> the original memory page so as to catch any later attempts to overwrite a forced value stored in the original memory page.

0041After re-protecting the original memory page, the force process <b>500</b> starts <b>528</b> executing code at the original memory page at the instruction following the instruction that generated the original exception.

0042If the force process <b>500</b> did not store the result in the original memory page, then the force process <b>500</b> concludes that the value at that node is not forced. In other words, an exception was properly generated because the force process <b>500</b> attempted to write the result into a write-protected memory page, but the page was write-protected for a reason other than because the result at that node is forced, e.g., another node value mapped to that page is forced. The force process <b>500</b> thus leaves the page as is, re-protects <b>526</b> the original memory page, and starts <b>528</b> executing code at the original memory page at the instruction following the instruction that generated the original exception.

0043Thus, in this scenario where the exception was properly generated but the value was determined to not be forced, the force process <b>500</b> performed some ultimately unnecessary operations, particularly those involving the additional memory page. However, as memory pages are usually quite small (on the order a few kilobytes) and as not many nodes are forced in logic designs (if any are at all), the computation in the force process <b>500</b> is typically much less than the computation involved in checking every node for a forced value.

0044<figref idref="DRAWINGS">FIG. 6</figref> shows a computer <b>600</b> for performing simulations using the process <b>100</b>, the tri-state process <b>400</b>, and the force process <b>500</b>. Computer <b>602</b> includes a processor <b>604</b>, a memory <b>606</b>, and a storage medium <b>608</b> (e.g., a hard disk). Storage medium <b>608</b> stores data <b>610</b> which defines a logic design, a graphics library <b>612</b> for implementing the logic design, intermediate code <b>614</b> and simulation code <b>616</b> that represents the logic design, logic simulator programs <b>618</b> (e.g., event-driven and/or cycle-based), and machine-executable instructions <b>620</b>, which are executed by processor <b>604</b> out of memory <b>606</b> to perform the process <b>100</b>, the tri-state process <b>400</b>, and the force process <b>500</b> on data <b>610</b>.

0045The process <b>100</b>, the tri-state process <b>400</b>, and the force process <b>500</b>, however, are not limited to use with the hardware and software of <figref idref="DRAWINGS">FIG. 6</figref>; they each may find applicability in any computing or processing environment. The process <b>100</b>, the tri-state process <b>400</b>, and/or the force process <b>500</b> may be implemented in hardware, software, or a combination of the two. The process <b>100</b>, the tri-state process <b>400</b>, and/or the force process <b>500</b> may be implemented in computer programs executing on programmable computers or other machines that each includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. Program code may be applied to data entered using an input device, such as a mouse or a keyboard, to perform the process <b>100</b>, the tri-state process <b>400</b>, and/or the force process <b>500</b> and to generate a simulation.

0046Each such program may be implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language. The language may be a compiled or an interpreted language.

0047Each computer program may be stored on an article of manufacture, such as a storage medium or device (e.g., CD-ROM, hard disk, or magnetic diskette), that is readable by a general or special purpose programmable machine for configuring and operating the machine when the storage medium or device is read by the machine to perform the process <b>100</b>. The process <b>100</b>, the tri-state process <b>400</b>, and the force process <b>500</b> may also be implemented as a machine-readable storage medium, configured with a computer program, where, upon execution, instructions in the computer program cause the machine to operate in accordance with the process <b>100</b>, the tri-state process <b>400</b>, and the force process <b>500</b>.

0048The invention is not limited to the specific embodiments set forth above. For example, the process <b>100</b> is not limited to simulating only combinatorial and state logic elements. Other logic elements may be simulated. The process <b>100</b>, the tri-state process <b>400</b>, and the force process <b>500</b> are not limited to the computer languages set forth above, e.g., Verilog, C++, and VHDL. It may be implemented using any appropriate computer language. Elements of the processes presented may be executed in a different order than that shown to produce an acceptable result.

0049Other embodiments not described herein are also within the scope of the following claims.