Burn and learn – stimulate don’t simulate

When I told him that I hadn't needed to simulate a design for almost three years, he gave me one of those blank looks reserved for those who have just grown a second head. Something clearly did not compute. The discussion was similar to many others I've had with fpga designers about raising design abstraction. Just as software developers rely heavily on debuggers and code emulators to track down errors and prove functionality, fpga designers have grown accustomed to using simulators in much the same way. It provides them with the control and visibility necessary for developing complex ip, and their design flows are subsequently centred on good simulation tools. The notion of doing design without simulation is completely foreign. Contrasting this is the approach used by board level designers. They are the people who stitch off the shelf components together on a pcb to create the next crazy gadget. By assuming that components meet the specs of their datasheets, board level designers treat components as black boxes and focus their development around component interactions rather than their internals. Systems are rarely simulated in their entirety. Instead, they are prototyped and run 'live' using test code and/or stimulation sources. To the board level designer, the notion of simulating an entire system at the gate level seems just as perplexing as not simulating a system seems to an fpga designer. So, as board level designers increasingly make use of fpgas and off the shelf ip to shrink designs and speed up development, what is the most appropriate development approach to take? Should they stimulate or simulate? FPGA simulation is most appropriate for developers of custom ip. But once that ip has been verified, downstream designers who make use of that ip will obtain little value repeating that work. Instead, they should adopt a similar strategy to board level designers who prototype their designs 'live'. Of course, for this to be possible, an appropriate execution platform needs to be available. For many traditional fpga designers 'burn and learn' remains an uncomfortable proposition. But as the abstraction level continues to rise towards system level design, it stands as the favoured means of development over simulation. It's ironic that board level designers armed with the next generation of design tools are actually better positioned to take advantage of fpgas in a way that traditional users can't compute.