Logic simulation: Difference between revisions

Revision as of 12:54, 3 January 2012

Revision as of 23:26, 17 May 2012

Line 1:

{{Redirect|Functional simulation|the simulation of program functionality|High-level emulation}}

'''Logic simulation''' is the use of a computer program to [[simulate]] the operation of a [[digital circuit]]. Logic simulation is the primary tool used for verifying the logical correctness of a hardware design. In many cases logic simulation is the first activity performed in the process of taking a hardware design from concept to realization. Modern [[hardware description language]]s are both simulatable and [[Logic synthesis|synthesizable]].

'''Logic simulation''' is the use of [[Computer simulation|simulation software]] to predict the behavior of [[digital circuit]]s and [[hardware description language]]s. Simulation can be performed at varying degrees of [[Abstraction (computer science)|physical abstraction]], such as at the [[SPICE|transistor level]], [[digital circuit|gate level]], [[register transfer level]] (RTL), or behavioral level.

== Levels of abstraction ==

==Use in verification and validation==

Because simulation is a general technique, a hardware design can be simulated at a variety of levels of abstraction. Often it is useful to simulate a model at several levels of abstraction in the same simulation run. The commonly used levels of abstraction are [[digital circuit|gate level]], [[register transfer level]] (RTL), and behavioral (or algorithmic) level. However, it is possible to incorporate lower levels like [[SPICE|transistor level]] or even lower physical levels as well as higher levels such as transaction levels or ___domain-specific levels.

Logic simulation may be used as part of the [[Verification and validation|verification]] process in designing hardware.

==Advantages of logic simulation ==

Simulations have the advantage of providing a familiar look and feel to the user in that it is constructed from the same language and symbols used in design. By allowing the user to interact directly with the design, simulation is a natural way for the designer to get feedback on their design.

Simulation is the key activity in the design [[Verification and validation|verification]] process. That is not to say that it is an ideal process. It has some positive attributes:

*It is a natural way for the designer to get feedback about their design. Because it is just running a program – the design itself – the designer interacts with it using the vocabulary and abstractions of the design. There is no layer of translation to obscure the behavior of the design.

*The level of effort required to debug and then verify the design is proportional to the maturity of the design. That is, early in the design’s life, bugs and incorrect behavior are usually found quickly. As the design matures, it takes longer to find the errors. This is beneficial early in the design process. It becomes more problematic later.

*Simulation is completely general. Any hardware design can be simulated. The only limits are time and computer resources.

Prospective way to accelerate logic simulation is using [[distributed computing|distributed]] and [[parallel computation]]s. <ref> Software system for distributed [[event-driven]] logic simulation. Ladyzhensky Y.V., Popoff Y.V. Proceedings of IEEE East-West Design & Test Workshop(EWDTW'05). IEEE EWDTW, 2005, p.119-122 ISBN 966-659-113-8 </ref>

== LimitationsLength of logic simulation ==

*The level of effort required to debug and then verify the design is proportional to the maturity of the design. That is, early in the design’s life, bugs and incorrect behavior are usually found quickly. As the design matures, itthe takessimulation longerwill require more time and resources to findrun, theand errors will take progressively longer to be found. This is beneficialparticularly earlyproblematic when simulating components for modern-day systems; every component that changes state in a single clock cycle on the designsimulation process.will Itrequire becomesseveral moreclock problematiccycles to latersimulate.

On the negative side, simulation has two drawbacks, one of which is glaring:

*There is (usually) no way to know when you are done. It is not feasible to completely test, via simulation, all possible states and inputs of any non-trivial system.

*Simulation can take an inordinately large amount of computing resources, since typically it uses a single processor to reproduce the behavior of many (perhaps millions of) parallel hardware processes.

A straightforward approach to this issue may be to emulate the circuit on a [[field-programmable gate array]] instead. [[Formal verification]] can also be explored as an alternative to simulation, although a formal proof is not always possible.

Every design project must answer the question “have we simulated enough to find all the bugs?” and every project manager has taped out his design knowing that the truthful answer to that question is either “no” or “I don’t know”. It is this fundamental problem with simulation that has caused so much effort to be spent looking for both tools to help answer the question and [[Formal verification|formal alternatives to simulation]].

ProspectiveA prospective way to accelerate logic simulation is using [[distributed computing|distributed]] and [[parallel computation]]s. <ref> Software system for distributed [[event-driven]] logic simulation. Ladyzhensky Y.V., Popoff Y.V. Proceedings of IEEE East-West Design & Test Workshop(EWDTW'05). IEEE EWDTW, 2005, p.119-122 ISBN 966-659-113-8 </ref>

[[Code coverage]], functional coverage and logic coverage tools have all been developed to help gauge the completeness of simulation testing. None are complete solutions, though they all help. Formal alternatives have been less successful. Just like in the general software world, where proving programs correct has proven intractable, formal methods for verifying hardware designs have still not proven general enough to replace simulation. That is not surprising, since it is the same problem.

To help gauge the thoroughness of a simulation, tools exist for assessing [[code coverage]], functional coverage and logic coverage tools.

The second drawback motivates most of the research and development in simulation. That is, simulation is always orders of magnitude slower than the system being simulated. If a hardware system runs at 1GHz, a simulation of that system might run at 10-1000 Hz, depending on the level of the simulation and the size of the system. That is a slowdown of from 10⁶ to 10⁸! Consequently, many people have spent a lot of time and effort finding ways to speed up logic simulation. The straightforward approach is to emulate the circuits on [[FPGA]]. FPGAs are the fine-grain supercomputers, intentionally designed for logic simulation. The emulation is only 10 times slower than the circuit implemented in true silicon ([[ASIC]]). Though, a lot of information is lost from observation -- only external I/O is available.

== Event simulation versus cycle simulation ==

Line 29 ⟶ 23:

[[Discrete event simulation|Event simulation]] allows the design to contain simple timing information – the delay needed for a signal to travel from one place to another. During simulation, signal changes are tracked in the form of events. A change at a certain time triggers an event after a certain delay. Events are sorted by the time when they will occur, and when all events for a particular time have been handled, the simulated time is advanced to the time of the next scheduled event. How fast an event simulation runs depends on the number of events to be processed (the amount of activity in the model).

While event simulation can provide some feedback regarding signal timing, it is not a replacement for [[static timing analysis]].

In cycle simulation, it is not possible to specify delays. A cycle-accurate model is used, and every gate is evaluated in every cycle. Cycle simulation therefore runs at a constant speed, regardless of activity in the model. Optimized implementations may take advantage of low model activity to speed up simulation by skipping evaluation of gates whose inputs didn't change.

WhileIn eventcycle simulation, canit provideis somenot feedbackpossible regardingto signalspecify timingdelays. A cycle-accurate model is used, itand every gate is notevaluated in every cycle. Cycle simulation therefore runs at a replacementconstant forspeed, [[staticregardless timingof analysis]]activity in the model. Optimized implementations may take advantage of low model activity to speed up simulation by skipping evaluation of gates whose inputs didn't change. In comparison to event simulation, cycle simulation tends to be faster, to scale better, and to be better suited for hardware acceleration / emulation.

However, chip design trends point to event simulation gaining relative performance due to activity factor reduction in the circuit (due to techniques such as [[clock gating]] and [[power gating]], which are becoming much more commonly used in an effort to reduce power dissipation). In these cases, since event simulation only simulates necessary events, performance may no longer be a disadvantage over cycle simulation. Event simulation also has the advantage of greater flexibility, handling design features difficult to handle with cycle simulation, such as [[asynchronous logic]] and incommensurate clocks. Due to these considerations, almost all commercial logic simulators have an event based capability, even if they primarily rely on cycle based techniques.

== Summary ==

Line 37 ⟶ 33:

Considering both the advantages and disadvantages of logic simulation, it really is quite a good tool for verifying the correctness of a hardware design. Despite its drawbacks, simulation remains the first choice for proving correctness of a design before fabrication, and its value has been well established.

<ref> Electronic Design Automation For Integrated Circuits Handbook, by Lavagno, Martin, and Scheffer, ISBN 0-8493-3096-3, a survey of the field of EDA. The above summary was derived, with permission, from Volume I, Chapter 16, Digital Simulation, by John Sanguinetti.</ref>

== Functional simulation ==

For functional simulation of program source code, see [[Emulator#Functional_simulators|Emulator]].

== See also==

* [[Logic synthesis]]

* [[Logisim]]

* [[List of Verilog simulators]]