Blinkies, Buttons, Bah!!!

Posted by: Dave Vandenbout 6 years, 2 months ago

(1 comment)

I get some comments like this: “All the other FPGA boards have loads of blinking LEDs. And they have bunches of buttons and switches! My XuLA board has nothing!”

Now when you learned how to ride a bike, you might have started out using training wheels. These were helpful – they let you get experience with the bike without getting hurt (unless your parents push you out in a busy street – but that's another story). But after a while, you couldn't wait to get rid of those training wheels. Wherever you went, they just screamed out: “I'm a bike-riding noob! Come give me a wedgie!” But the worst part was they got in the way; you couldn't get any speed up because those training wheels were dragging on the ground. Luckily, they weren't welded to the bike and you could take them off. Then you could use the bike for what it was for: getting you from here to there faster and easier than being on foot.

LEDs and buttons are similar to training wheels: good when getting started, but a hindrance after that. They're meant to operate at human interaction speeds, like 10 Hz or less. But FPGAs are meant for applications that run at hundreds of MHz; it's a waste to have them waiting around while you look at an LED and then push a button to tell them what to do! Plus, they're hard to use for anything but the simplest designs: do you really want to flip switches to input a three-digit hexadecimal number and then translate the pattern on a bunch of LEDs back into hex? (If you do, then I've got a PDP-8 in the basement with your name on it!)

But LEDs and buttons are different from training wheels in one important aspect: they aren't easy to take off when you're done with them. They're usually soldered to the board where they take up space (and make the board larger than it needs to be). They interfere electrically when you use the FPGA pins for other purposes (unless there are jumpers to disconnect them, taking up even more space). And they're never connected to the pin you want them on (although this is less of a problem with FPGAs since you can move your I/O signals from pin to pin as you please).

Still, there is no denying that you need some way to observe what your design is doing. Logic probes are one solution (sort of a portable LED), but limited in the amount of information they can present (just like an LED). Oscilloscopes are good for capturing signal behavior, especially at high frequencies, but most scopes have four inputs or less and they cost a fair bit of money (around $300 for a minimal scope). Logic analyzers provide a lot of inputs that can be sampled at hundreds of MHz, but they are truly a pain to hook up to your circuit (although they are much cheaper now: as little as $50). A companion to the logic analyzer is the digital pattern generator which can drive signals into your design and which suffers from the same connection difficulties as the analyzer.

If those are the drawbacks of existing solutions for testing an application circuit in the FPGA, what would the characteristics of an ideal solution look like? Here's my list:

  • Free.
  • Flexible.
  • Easy to use.
  • Takes up no space.
  • Uses no FPGA pins.
  • Lets you drive inputs into your circuit and also observe its response.
  • Drives inputs into your circuit and observes its response automatically.
  • Goes away when you no longer need it.

While this sounds like a fantasy product, you actually already have it! And you can find out all about it in Chapter 6 of "FPGAs!? Now What?". And remember that all the source files for this book - including the FPGA projects - are available at Github.

Currently unrated


Comments

  • There are currently no comments

New Comment

required
required (not published)
optional

Recent Posts

Archive

2016
2015
2014
2013
2012
2011

Categories

Authors

Feeds

RSS / Atom