Simulation Tools

Defifinitions  

Again we’ll start with some basic design tool terms and definitions.  

● Event driven logic simulation tools see the world as a series of discrete events.  

● Mixed language simulation allows the use of multiple languages, such as  Verilog and VHDL.  

● Logic synthesis is a process in which a program is used to automatically convert a high-level textual representation of a design (specififi ed using an HDL  at the register transfer level (RTL) of abstraction) into equivalent registers and Boolean equations. A synthesis tool automatically performs simplififi cations and  minimizations and eventually outputs a gate-level netlist.  

● Physically aware synthesis means taking actual placement information associated with the various logical elements in the design, using this information to  estimate accurate track delays, and using these delays to fifi ne-tune the placement and perform other optimizations.  

● Retiming is a term used in the context of physical synthesis and is based on the  concept of balancing out positive and negative slacks throughout the design,  where positive slack refers to a path with some delay available that you’re not  using, and negative slack refers to a path that is using more delay than is available to it.  

● Replication is similar to retiming, but focuses on breaking up long interconnect.  

● Resynthesis uses the physical placement information to perform local optimizations on critical paths by means of operations like logic restructuring, reclustering, substitution, and possible elimination of gates and wires.  

● Formal verififi cation means using rigorous mathematical techniques and tools  that employ such techniques to verify designs. In the not-so-distant past, this  term was considered synonymous with equivalency checking.

Design engineers typically need to use a tremendous variety of tools to capture , verify , synthesize , and implement their designs. In this chapter we’ll focus  on some of the more significant contenders in the context of FPGA designs.  

Event-driven Logic Simulators  

Logic simulation is currently one of the main verification tools in the design  (or verification) engineer’s arsenal. The most common form of logic simulation is known as event driven because, perhaps not surprisingly, these tools see  the world as a series of discrete events. As an example, consider a very simple  circuit comprising an OR gate driving both a BUF (buffer) gate and a brace of  NOT (inverting) gates, as shown in Figure 7-1 .   

Just to keep things simple, let’s assume that NOT gates have a delay of 5  picoseconds (ps), BUF gates have a delay of 10 ps, and OR gates have a delay  of 15 ps. On this basis, let’s consider what will happen when a signal change  occurs on one of the input pins ( Figure 7-2 ).   

Internally, the simulator maintains something called an event wheel onto  which it places events that are to be “ actioned ” at some time in the future.  When the first event occurs on input in1 at a time we might refer to as t 1 , the  simulator looks to see what this input is connected to, which happens to be our OR gate. We are assuming that the OR gate has a delay of 15 ps, so the   simulator sc hedules an event on the output of the OR gate—a rising (0 to 1)  transition on wire w1 —for 15 ps in the future at time t₂ .   

The simulator then checks if any further actions need to be performed at  the current time (t 1 ), then it looks at the event wheel to see what is to occur  next. In the case of our example, the next event happens to be the one we just  scheduled at time t 2 , which was for a rising transition on wire w1 . At the same  time as the simulator is performing this action, it looks to see what wire w1 is  connected to, which is BUF gate g2 and NOT gate g₃ .   

As NOT gate g3 has a delay of 5 ps, the simulator schedules a falling (1 to  0) transition on its output, wire w2 , for 5 ps in the future at time t 3 . Similarly,  as BUF gate g2 has a delay of 10 ps, the simulator schedules a rising (0 to 1)  transition on its output, output out1 , for 10 ps in the future at time t 4 . And so it goes until all of the events triggered by the initial transition on input in1 have  been satisfied.  

—Technology Trade-offs—  

● The advantage of this event-driven approach is that simulators based on  this technique can be used to represent almost any form of design, including synchronous and asynchronous circuits, combinatorial feedback loops,  and so forth. These simulators also offer extremely good visibility into the  design for debugging purposes, and they can evaluate the effects of delayrelated narrow pulses and glitches that are very difficult to find using other  techniques (see also the discussions on delays in the next section). The big  disadvantage associated with these simulators is that they are extremely  compute-intensive and correspondingly slow.

In the early days, event-driven digital logic simulators were simple tools that  output results in the form of a textual (tabular) file. They evolved to a bit more  advanced form, outputting results as graphical waveforms. Still later, the creators of digital simulators started to experiment with more sophisticated languages that could describe logical functions at higher levels of abstraction such  as RTL. As the industry-standard HDLs such as Verilog and VHDL started to  appear, they had the advantage that the same language could be used to represent both the functionality of the circuit and the testbench. (See also the discussions on special verification languages like e in the “ Verification in General ”  section later in this chapter.)   

Also, standard file formats for capturing simulation output results, such  as the value change dump (VCD) format, started to appear on the scene. This  facilitated third-party EDA companies creating sophisticated waveform display  and analysis tools that could work with the outputs from multiple simulators.  Similarly, innovations like the standard delay format (SDF) specification facilitated third-party EDA companies ’ creating sophisticated timing analysis tools  that could evaluate circuits, generate timing reports highlighting potential problems, and output SDF files that could be used to provide more accurate timing  simulations (see also the discussion on alternative delay formats below).

Logic Values and Different Logic Value Systems   

The minimum set of logic values required to represent the operation of binary  logic gates is 0 and 1. The next step is the ability to represent unknown values, for which we typically use the character X . These unknown values may  be used to represent a variety of conditions, such as the contents of an uninitialized register or the clash resulting from two gates driving the same wire  with opposing logical values. And it’s also nice to be able to represent high-  impedance values driven by the outputs of tri-state gates, for which we typically use the character Z .

But the 0, 1, X , and Z states are only the tip of the iceberg. More advanced  logic simulators have ways to associate different drive strengths with the outputs of different gates. This is combined with ways in which to resolve and  represent situations where multiple gates are driving the same wire with different logic values of different strengths. Just to make life fun, of course, VHDL  and Verilog handle this sort of thing in somewhat different ways.

Mixed-language Simulation   

The problem with having two industry-standard languages like Verilog and  VHDL is that it’s not long before you find yourself with different portions of  a design represented in different languages. Anything you design from scratch  will obviously be written in the language du jour favored by your company.  However, problems can arise if you wish to reuse legacy code that is in the  other language. Similarly, you may wish to purchase blocks of IP from a third  party, but this IP may be available only in the language you aren’t currently using yourself. And there’s also the case where your company merges with,  commences a joint project with, another company, where the two companies  are entrenched in design flows using disparate languages.   There have historically been several flavors of mixed-language simulation ,  as described below:

● One technique used in the early days was to translate the “ foreign ” language (the one you weren’t using) into the language you were working  with. This was painful to say the least because the different languages supported different logic states and language constructs (even similar language  statements had different semantics). The result was that when you simulated  the translated design, it rarely behaved the way you expected it to, so this  approach is rarely used today.  

● Another technique was to have both a VHDL simulator and a Verilog simulator and to cosimulate the two simulation kernels. In this case the performance of the ensuing simulation was sadly lacking because each kernel  was forever stopping while it waited for the other to complete an action.  Thus, once again, this approach is rarely used today.

● The optimum solution is to have a single-kernel simulator that supports  designs represented as a mixture of VHDL and Verilog blocks. All of the  big boys in EDA have their own version of such a tool, and some go far  beyond anything envisaged in the past because they can support multiple  languages such as Verilog, SystemVerilog, VHDL, SystemC, and PSL  (where PSL is introduced in more detail in the “ Formal verification ” section in this chapter).

Alternative Delay Formats   

How you decide to represent delays in the models you are creating for use with  an event-driven simulator depends on two things:  

a. the delay modeling capabilities of the simulator itself and  

b. where in the flow (and with what tools) you intend to perform your timing  analysis.   

A very common scenario is for static timing analysis (STA) to be performed  externally from the simulation. In this case, logic gates (and more complex  statements) may be modeled with zero (0 timebase unit) delays or unit (1 time base unit) delays, where the term timebase unit refers to the smallest time segment recognized by the simulator.

Alternatively, we might associate more sophisticated delays with logic gates  (and more complex statements) for use in the simulation itself. The first level  of complexity is to separate rising delays from falling delays at the output from  the gate (or more complex statement). For historical reasons, a rising (0-to-1)  delay is often referred to as LH (standing for “ low-to-high ” ). Correspondingly,  a falling (1-to-0) delay may be referred to as HL (meaning “ high-to-low ” ). For  example, consider what happens if we were to apply a 12 ps positive-going  (0-1-0) pulse to the input of a simple buffer gate with delays of LH = 5 ps and  HL = 8 ps ( Figure 7-3 ).   

Not surprisingly, the output of the gate rises 5 ps after the rising edge is  applied to the input, and it falls 8 ps after the falling edge is applied to the input.  The really interesting point is that, due to the unbalanced delays, the 12 ps  input pulse has been stretched to 15 ps at the output of the gate, where the additional 3 ps reflect the difference between the LH and HL values. Similarly, if  a n egative-going 12 ps (1-0-1) pulse were applied to the input of this gate, the  corresponding pulse at the output would shrink to only 9 ps (try sketching this  out on a piece of paper for yourself).   

In addition to LH and HL delays, simulators also support minimum:typical: maximum (min:typ:max) values for each delay. For example, consider a p ositivegoing pulse of 16 ps presented to the input of a buffer gate with rising and falling  delays specified as 6:8:10 ps and 7:9:11 ps, respectively ( Figure 7-4 ).   

This range of values is intended to accommodate variations in the operating conditions such as temperature and voltage. It also covers variations in the manufacturing process because some chips may run slightly faster or slower  than others of the same type. Similarly, gates in one area of a chip (e.g., an  ASIC or an FPGA) may switch faster or slower than identical gates in another  area of the chip. (See also the discussions on timing analysis, particularly  dynamic timing analysis, later in this chapter.) 

Insider Info  

In the early days, all of the input-to-output delays associated with a multi-input  gate (or more complex statement) were identical. For example, consider a 3-input  AND gate with an output called y and inputs a, b, and c. In this case, any LH  and HL delays would be identical for the paths a-to-y, b-to-y, and c-to-y. Initially,  this didn’t cause any problems because it matched the way in which delays were  specified in data books. Over time, however, data books began to specify individual input-to-output delays, so simulators had to be enhanced to support this  capability.

Another point to consider is what will happen when a narrow pulse is  applied to the input of a gate (or more complex statement). By “ narrow ” we  mean a pulse that is smaller than the propagation delay of the gate. The first  logic simulators were largely targeted toward simple ICs implemented in  t ransistor-transistor logic (TTL) being used at the circuit board level. These  chips typically rejected narrow pulses, so that’s what the simulators did. This  became known as the inertial delay model. As a simple example, consider two  positive-going pulses of 8 ps and 4 ps applied to a buffer gate whose min:typ: max rising and falling delays are all set to 6 ps ( Figure 7-5 ).   

By comparison, logic gates implemented in later technologies such as emittercoupled logic (ECL) would pass pulses that were narrower than the p ropagation  delay of the gate. To accommodate this, some simulators were equipped with a mode called the transport delay model. Once again, consider two positive-going  pulses of 8 ps and 4 ps applied to a buffer gate whose min:typ:max rising and  falling delays are all set to 6 ps ( Figure 7-6 ).

The problem with both the inertial and transport delay models is that they  only provide for extreme cases, so the creators of some simulators started to  experiment with more sophisticated narrow-pulse handling techniques, such as  the three-band delay model . In this case, each delay may be qualified with two  values called r (for “ reject ” ) and p (for “ pass”), specified as percentages of the  total delay. For example, assume we have a buffer gate whose min:typ:max  delays have all been set to 6 ps qualified by r and p values of 33 percent and 66  percent, respectively ( Figure 7-7 ).   

Any pulses presented to the input that are greater than or equal to the p value will propagate; any pulses that are less than the r value will be completely rejected; and any pulses that fall between these two extremes will be  propagated as a pulse with an unknown X value to indicate that they are ambiguous because we don’t know whether they will propagate through the gate  in the real world. (Setting both r and p to 100 percent equates to an inertial  delay model, while setting them both to 0 percent reflects a pure transport  delay model.)

Cycle-based Simulators  

An alternative to the event-driven approach is to use a cycle-based simulation  technique. This is particularly well suited to pipelined designs in which “ islands ”  of combinational logic are sandwiched between blocks of registers ( Figure 7-8 ).

In this case, a cycle-based simulator will throw away any timing information associated with the gates forming the combinational logic and convert  this logic into a series of Boolean operations that can be directly implemented  using the CPU’s logical machine code instructions.

—Technology Trade-offs—  

● Given an appropriate circuit with appropriate activity, cycle-based simulators may offer significant run-time advantages over their event-driven  counterparts. The downside , however, is that they typically only work with  0 and 1 logic values (no X or Z values, and no drive strength representations). Also, cycle-based simulators can’t represent asynchronous logic or  combinatorial feedback loops.  These days it’s rare to see anyone using a pure cycle-based simulator. However,  several event-driven simulators have been augmented to have hybrid capabilities. In this case, if you instruct the simulator to aim for extreme performance  (as opposed to timing accuracy), it will automatically handle some portions  of the circuit using an event-driven approach and other portions using cyclebased techniques.

Choosing a Logic Simulator   

Choosing a logic simulator is, as with anything else in engineering, a balancing act. Here are some things to consider:  

1. Think about whether you require mixed-language capability . If you are a  small startup, you may be planning to use only one language, but remember that any IP you decide to purchase down the road may not be available  in this language. Having a solution that can work with VHDL, Verilog, and  SystemVerilog would be a good start, and if it can also handle SystemC  along with one or more formal verification languages, then it will probably  stand you in good stead for some time to come.  

2. Generally speaking, performance is the number-one criterion for most  folks. The trick here is how to determine the performance of a simulator  without being bamboozled. The only way to really do this is to have your  own benchmark design and to run it on a number of simulators. Creating a  good benchmark design is a nontrivial exercise, but it’s much better than  using a design supplied by an EDA vendor (because such a design will be  tuned to favor their solution, while delivering a swift knee to the metaphorical groins of competing tools).  

3. However, there’s more to life than raw performance. You also need to look  for a good interactive debugging solution such that when you detect  a problem, you can stop the simulator and poke around the design. All  si mulators are not created equal in this department. In some cases, even  if the simulator does let you do what you want, you may have to jump  through hoops to get there. So the trick here is—after running your performance benchmark—bring up the same circuit with a known bug and see  how easy it is (and how long it takes) to detect and isolate the little rapscallion. In reality, some simulators that give you the performance you require  do such a poor job in this department that you are obliged to use third-party  postsimulation analysis tools.  

4. Another thing to consider is the capacity of the simulator . The tools supplied by the big boys in EDA essentially have no capacity limitations, but  simulators from smaller vendors might be based on ported 32-bit code  if you were to look under the hood. Of course, if you are only going to  work with smaller designs (say, equivalent to 500,000 gates or less), then  you will probably be okay with the simulators supplied by the FPGA vendors (these are typically “ lite ” versions of the tools supplied by the  big EDA vendors).

Of course, you will have your own criteria in addition to the topics raised  above, such as the quality of the code coverage and performance analysis provided by the various tools. These used to be the province of specialist thirdparty tools, but most of the larger simulators now provide some level of integrated code coverage and performance analysis in the simulation environment  itself. However, different simulators offer different feature sets (see also the  discussions on code coverage and performance analysis in the “ Miscellaneous ”  section later in this chapter).