The countdown counter/timer circuit was pretty trivial to code up in VHDL.  My dev board had an old FPGA on it, but it didn’t matter.  The original version of my little design probably used less than 10% of the chip anyway.  I’d enhanced it several times, of course.  The original one loaded a big number into the register and then counted down.  When the countdown reached zero, an audio-frequency square wave was generated at an output pin.  A little amplifier circuit took the digital signal and ran it straight to a small speaker producing the desired effect – a buzzy tone that was clearly audible. 

Version two had a bit more capability.  I keyed a button on the development board to first stop the buzzing tone, then load a new (much smaller) value into the countdown register and start the countdown again.  Now, there were two controls – the master reset that configured the FPGA and started the big countdown and the new control that stopped the buzz and re-started the delay timer with a smaller value.  I also figured out that I could run the counter at audio frequencies and simply use the clock signal as the tone generator when the count reached zero.  Slowing down the clock also allowed the use of a smaller countdown register to reach my target delay – about eight hours.

When you have programmable hardware, feature creep with the device already deployed in the field is not only an engineering risk, it’s a moral imperative.  When I was watching a demo of an MP3 player built on an FPGA demo board, I knew my design had to be updated.  Now, the countdown timer would reach zero, and the MP3 demo design would be triggered to start playing music through the speaker.  No more waking up to the dreaded square wave buzz…  One more tweak to allow my MP3 of choice to be read from the removable SD card on the demo board, and my FPGA-based alarm clock was complete.  Now, I could hit the button when I went to sleep, and, eight hours later, my favorite MP3 track would burst forth from the speaker.  If I wasn’t ready to rise, I hit button number two and got a 15 minute snooze.

Up and out of bed – I get to the office and my coffee is getting cool.  No problem, I have an FPGA-based solution for that, too – a development board with a large FPGA clocking a bunch of registers back and forth at the maximum frequency.  This is the oldest FPGA technology I could find so that power consumption is maxed out.  Balancing my favorite mug on the dev board, my brew is quickly back up to temperature. 

Here at FPGA Journal, we use FPGAs for just about everything – from waking us up in the morning to rejuvenating our java.  Whatever you’re trying to engineer – hardware programmability will make it better, faster, cheaper, more flexible, and more efficient.  It will get your design to market faster with fewer errors, a longer useful life, a smaller form-factor, better design security, and maximum quantities of engineering Karma. 

When I was writing this article, I was thinking about what we learned from Abraham Maslow – that our basic needs form a hierarchy from essentials like breathing, drinking, eating and FPGAs up to more complex and esoteric aspects of our humanity like morality, creativity, and self-esteem. 

Wait, sorry, that’s wrong. 

What I was really thinking that we learned from Maslow was: “When the only tool you have is a hammer, everything looks like a nail.”  Perhaps we in the FPGA industry (see, it’s a whole “industry” now, not just a category of device…) suffer somewhat acutely from the so-called “Golden Hammer” syndrome.  In their efforts to continually remind us that FPGAs are the best possible solution for all problems, FPGA companies may have cried “Wolf” – or more accurately “Silver Bullet” so often that we no longer even hear the words.

There is no question that programmability – and specifically hardware programmability –brings numerous advantages to the electronic design party.  Of course, if NRE were free and ASIC design cycles were weeks instead of months, we’d probably get optimal results if we just did an ASIC for every design we tackle.  In today’s reality, however, FPGAs can come surprisingly close to that ideal – and leave us with the advantage of in-system programmability as a bonus.  The core functions that we’d want in optimized hardware (for purposes of speed, area efficiency, and power consumption) are generally already present on most FPGAs in optimized form.  Because the FPGA is often on a more advanced technology node than we’d choose for our ASIC, those functions may be even better than what we’d get from the ASIC version.  Things like on-chip memory, fast multipliers, sophisticated I/O technology, and even high-end processors give up nothing to ASIC in their FPGA implementations.  The rest of our system can coast on the luxurious flexibility of the programmable fabric.

Verification benefits dramatically from choosing an FPGA platform, as well.  If we were doing an ASIC with all those embedded hard-core modules, we’d have to verify our own implementation of each of those also.  In the case of the FPGA, the verification work has already been finished before the device is delivered to us.  The only thing we need to verify is our own IP and the way we connect the blocks together.

The perceived deficits of programmable logic compared with other system-on-chip integration solutions are cost, speed, size, and power.  With so much integrated hard IP and today’s much smaller geometries, however, the gap has closed considerably, and the practical gap may have disappeared entirely for many applications.  We made fun of FPGAs for years for hyped-up “system gate” counts that gave the misleading idea that FPGAs had densities similar to leading-edge ASICs.  Today, however, FPGAs are getting so big that yesterday’s hype is coming true for many practical cases.  We also have spent years laughing at Fmax specifications on FPGA data sheets that couldn’t be achieved with any reasonable real-world application.  Today, however, FPGAs can operate fast enough on most real designs where Fmax is not the critical issue.  Similarly, while FPGAs used to be an order of magnitude more expensive than competing integration solutions, today there are FPGAs with unit costs that rival many ASICs one-on-one, not to mention the astronomical NRE and risk associated with ASIC implementations.

In short, the marketing mistake of the magi may be about to come full circle.  FPGAs just might be the perfect solution for every problem.  The irony is, we’ve spent so many years doubting and disbelieving the people trying to convince us of that when it wasn’t true, that we may have failed to notice when that charade quietly morphed into reality.