Some FPGA applications take advantage of both of these properties. Many systems do Digital Signal Processing (DSP) operations in an FPGA to avoid needing a super fast CPU. The "subroutines" are really chains of hardware logic and instead of loops, you build parallel arrays of these hardware "subroutines."

The details depend on the actual chip you are using and I'll explain more about the Verilog language in upcoming weeks. But the point is, you can construct little dedicated pieces of hardware that will be very fast compared to a software solution. And each piece of hardware "runs" at the same time.

In fact, that's another issue with FPGAs and hardware design in general. Because the delays are so small and everything operates simultaneously, it is easy to produce glitches. Suppose I have two inputs that change at some time and will eventually control an output. The first input takes 10nS to get to the output control gate, but the second input takes 15nS (presumably, there is more logic involved, although longer interconnects can also cause this on a smaller scale). That means the output control gate will glitch when it sees one input change but the other one is still in the previous state for an extra 5nS.

You could attempt to equalize all the paths through the circuit, but that's a prescription for madness. Instead, the most common method of dealing with this problem is to do synchronous logic. A special circuit element called a flip flop (colloquially called a flop) is like a one-bit memory (and, yes, that's a gross oversimplification). A master system clock causes the flops to remember their input. The clock is such that it is slower than the longest delay in the circuit.

In the made up example above, the clock pulse might come every 20nS. So when the inputs change, the flop that drives the output would not look until 20nS later. (If the inputs are not synchronized with the clock, that's a problem, but ignore that for now.) This is simpler to manage and the tools available will generally help you work out things like clock speeds. Have you ever wondered why your CPU needs a clock? This is why. Designing an asynchronous (clockless) CPU is possible, but would be incredibly difficult. (If you are really curious, check this out, though it's hardly a crystal radio).

In the upcoming blogs, I'll talk about the basic logic gates, the types of devices you are likely to encounter, Verilog in general, and how to actually try out designs. Don't worry — one of the big secrets to this whole business is that you can do just about everything in simulation with free software. Simulation is really important for a close cousin to the FPGA, the ASIC (Application-Specific Integrated Circuit). These have significant tooling costs and can't be easily changed, so when you pay big bucks to have a batch of ASICs made, you want to make sure they will work. We can use similar tools to experiment without buying any hardware.

My ultimate goal: Next time you have a development board with an FPGA or CPLD (a Complex Programmable Logic Device; sort of a junior FPGA) on it, I want you to realize that you can program it. It isn't any harder than programming a CPU. You may or may not want to dive into my crazy hobby of developing things like CPUs. But programmable logic is becoming more and more important to embedded development. You just need the crystal radio to get your feet wet.