In the race to improve product quality and decrease development time and cost, software simulators have had a dramatic effect. Initially, simulators reduced the need for hardwired prototypes along with their associated expense and delay. But prototypes aren't dead yet. Recently engineers have begun using them again for several classes of design. The prototyping revival results from the increasing complexity of today's designs, the inability of engineers to get suitable simulation models, and advances in programmable logic.
Programmable logic offers densities exceeding 50,000 gates, performance at speeds beyond 125 MHz, and lower-density chips that start at less than $10. As a result, engineers don't have to rely on cumbersome software simulations or poor test coverage. Today, whether to prototype or simulate depends on three factors:
How extensively you test your design's function is directly proportional to how complex the design is and how many problems you expect to find. Are you simply testing the digital implementation of the design, or are you also testing architectural or algorithmic concepts? In the majority of designs, software simulation is better for testing implementation because the implementation can be broken into submodules. These submodules, with a limited number of I/O, are relatively easy to understand and test. However, architectures and algorithms are much harder to test with current software simulators, because they don't allow you to study the designs' response to unpredictable and asynchronous stimuli.
In these cases, software simulation is often impractical. Most would agree, for example, that there is little need to prototype an address decoder, because its operation is fairly simple. Although prototyping provides an absolute check of its operation, careful scrutiny using simulation is adequate for most cases. On the other hand, testing new disk-caching algorithms is entirely different. Without a prototype that you can barrage with data to test the algorithms' effectiveness, you have little real-world data to evaluate the design. In this case, a prototype is well worth the extra effort, because the more-complex design is more likely to contain errors.
Another aspect of risk is the consequences of mistakes. The probability of making a mistake in designing an address decoder is low. However, if that decoder is part of a complex ASIC with a two-month fabrication cycle, you may elect to build a prototype. In this case, whether to prototype is not based on the probability of a mistake but on its consequences.
To help assess risk, you should ask yourself these questions:
If your answer to any of these questions is no, then you should consider building a prototype.
If you evaluate your risks and decide that a software simulation is appropriate, you next need to decide if your simulator tools are adequate. How will you create and enter the test vectors? Entering vectors for software simulations has always been difficult, time-consuming, and tedious. Nearly all simulators allow you to enter vectors both graphically and through standard text languages. These methods are adequate if the input is a simple or repetitive pattern. However, complex patterns and non-recurring patterns are more troublesome.
Video signals, for instance, pose a huge challenge. While the timing components of video, such as the horizontal and vertical sync pulses, are relatively easy to describe, pixels are much more difficult. Even a relatively simple 480x640-pixel frame contains 307,200 pixels. Each pixel contains at least an eight-bit word, though in many cases, it contains a 32-bit word. Further complicating the video problem: each pixel is updated 60 times a second.
You can easily create vectors to simulate simple pictures like boxes or alternating bit patterns with conventional methods, but these patterns are unlike the actual video data a design may have to handle. In these instances, prototypes can have a substantial advantage. You can easily provide complex video inputs from a wide range of sources, including cameras, VCRs, and even commercial broadcasts.
With either a simulator or a prototype, your next hurdle is to evaluate the design's response to the input vectors. At this point, your need to deal with complex data is even more apparent. A design that processes video images will have a video output. However, no current software simulator can process video as quickly as a hard-wired prototype and display it in real or near-real time. And if a simulator could display video outputs that fast, imagine trying to look at traditional simulator vector outputs and translate the vectors into a virtual picture within your mind. Alternatively, you could write a C-code interface to convert the simulator's output into images, but that would be cumbersome.
To complicate the problem further, many algorithms for video design take advantage of some real-world, real-time effects. One common example is the persistence of an image on the brain for several nanoseconds after the image has actually disappeared from sight. Evaluating the suitability of a design that uses different persistence times would be impossible with software simulators. You actually need to view the video directly in real time to evaluate the effects of varying persistence.
Another weakness of software simulators is in the amount of interaction they allow between you and your design. Software simulation requires you to assemble a simulation-vector input file. When you start to simulate, you give up control of the input vectors until the simulation engine finishes. Then, you review the output vectors in a graphical waveform editor. The method offers no real-time interaction during the simulation. Ironically, the products you may be simulating, such as multimedia, fuzzy-logic, and electronic game circuits, are often interactive and would benefit from interactive testing.
You can often narrow down a problem much more quickly if you can observe circuit operation and modify inputs in realtime. Prototypes allow this direct interaction because they process information in real time.
One final shortcoming of simulation is that processing software vectors in software takes time. Fast software simulators running on expensive workstations can simulate just a fraction of the vectors a prototype can process. Even prototypes that run at a percentage of the end product's speed still offer significant gains.
Even if you allow for the time necessary to build and debug the prototype, the approach offers advantages; you can recover this time by using the prototypes to deliver your product earlier. These shortcuts can reduce time-to-production by several weeks. Equally important, you can ship initial production runs without creating manufacturing test vectors. You can generate manufacturing test vectors in parallel with fabricating a gate array while your company ships products containing programmable devices.
Several vendors offer both hardware and software that helps you prototype your designs. You should choose software tools that simplify migrating your design into the prototyping environment. Features that are high on the list include accepting a variety of inputs, such as VHDL, Verilog, or third-party schematics. You will also gain an advantage using software that can partition a large design among many programmable devices. This partitioning is critical because prototyping an entire system can demand more than 300,000 gates.
Advances in programmable logic and increasing system complexity have reinvigorated prototyping. The advantages of programmable logic include a drastic reduction in risk for new designs, increased flexibility during testing, and faster testing for a variety of designs. Prototypes using programmable logic also offer the advantage of filling in the vast time gap that the development of custom silicon creates in finishing a new product's design. All these factors combine to provide an approach that allows you to get your designs to market much faster-and more reliably-than if you were using software simulation alone.