feature article
Subscribe Now

Golden Hammer

Pursuit of the Programmable Panacea

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.

Leave a Reply

featured blogs
Jun 21, 2018
Doing business today isn’t quite like it was back in the 80’s. Sparkling teeth and x-ray vision shouldn’t be a side effect of a customer using your product. This, of course, is said in jest, but no longer do we sell only a product; but a product and physical...
Jun 21, 2018
Welcome back to our series on cloud verification solutions. This is part two of a three-part blog'€”you can read part one here . The high-performance computing (HPC) market continues to grow. Analysts say that the HPC market will reach almost $11 billion by 2020'€”that'€...
Jun 7, 2018
If integrating an embedded FPGA (eFPGA) into your ASIC or SoC design strikes you as odd, it shouldn'€™t. ICs have been absorbing almost every component on a circuit board for decades, starting with transistors, resistors, and capacitors '€” then progressing to gates, ALUs...
May 24, 2018
Amazon has apparently had an Echo hiccup of the sort that would give customers bad dreams. It sent a random conversation to a random contact. A couple had installed numerous Alexa-enabled devices in the home. At some point, they had a conversation '€“ as couples are wont to...
Apr 27, 2018
A sound constraint management design process helps to foster a correct-by-design approach, reduces time-to-market, and ultimately optimizes the design process'€”eliminating the undefined, error-prone methods of the past. Here are five questions to ask......