FPGA’s can handle simple things well, and they handle simple things fast. Other things like PI (3.1415926535897932…) are harder to deal with. How then shall phase be dealt with within an FPGA, and in what units?

Fig 1: Radians
Radians measure angles counterclockwise from right or East, starting at zero and going to 2pi

The mathematicians will define phase in units of Radians, with values ranging between zero and 2PI, as shown in Fig 1. Further, the units are periodic, so anything outside of the range between zero and 2PI may be brought into the range by adding as many 2PI values as necessary.

Fig 2: Degrees
Degrees measure angles counterclockwise from right or East, starting at zero and going to 360

Others will define phase as a number between 0 and 360 degrees, as shown in Fig 2.

Both refer to the same thing–the measure of of the angle between pointing to the right and any other direction, measured in the counter clockwise direction. You can also use one of these measures to measure the amount of time, within a periodic waveform, from the beginning of the period to anywhere within the period.

While Radians may be the natural units of phase (angles), they are not the first choice of the FPGA designer. Why not?

  • FPGA’s need to have a known number of bits to represent something. If you allocate enough bits to handle 0 to 8 (containing 0 to 2PI, or 6.28..), you’ll have a difficult time dealing with 16PI.

  • Radians have roll over problems. While both PI and 3PI/2 are valid angles between 0 and 2PI, their sum is outside of the range between 0 and 2PI. Before you can use this out-of-range value, and before you can add any more phase increments to it, the number must be normalized by subtracting 2PI from it to get it back into the range of 0 to 2PI.

    This will cost you a clock, and slow any algorithm you are building down by a factor of two.

    It will also only work if your wander into the range between 2PI and 4PI, but not between 50PI and 52PI.

  • FPGA’s can’t really handle numbers between 0 and 1.

    This problem is so common and the solution so simple and so well known that aspiring FPGA DSP engineers might just multiply the values from 0 to PI by 2^N and consider that the solution without ever thinking twice.

While these might seem like viable solutions, a better approach to dealing with angles exists.

A Better Unit for Angles

Fig 3: FPGA Angles
FPGA angular units measure angles counterclockwise from right or East, starting at zero and going to 2^N

A simpler and better angular unit choice, shown in Fig 3, is simply to map the range from 0 to 2PI onto the integer interval from 0 to 2^N. This can then be represented with an N-bit number.

fpga_val = floor( theta * 2^N / (2PI) + 0.5)

What’s neat about this approach to angles within an FPGA is that rollover is handled naturally, with no other logic required.

Consider how one might add PI to 3PI/2. We’ll use N=8, and so we’ll be representing angles with to within a degree or two. Hence, our expression becomes 8’h80 plus 8’hc0. If you add these two values together, and throw out any rollover, you get the value 8’h40.

Notice from this example how we didn’t need to waste a clock to bring our results back within limits. Neither were we restricted to only integer Radians values, even though we did our calculation with integers.

Even better, FPGA’s are often optimized for integer arithmetic. Hence, angular adjustments made in this fashion become easy and simple.

Generating Sine or Cosine

Depending upon your needs, you can easily convert this angle to a sine and cosine value.

For example, you could use the top bit as your sine wave value, and get a square wave out with no more work. This was the approach used by the wishbone controlled FM transmitter hack in order to transmit an FM signal from an FPGA.

You could also use the top several bits as an index into a table, and so build a direct digital synthesizer. Your table doesn’t need to contain a full copy of a sine wave, it might even contain only a quarter wave and still be quite successful.

Even slicker is to use your angle as an input to a CORDIC algorithm. In that case, you can use this angle as an input to generate a sine wave or cosine wave. You can also use the CORDIC algorithm to multiply by sine and cosine (at the same time), or to calculate arc-tangents. If you like this idea, you ought to know that the CORDIC algorithm can be pipelined so as to operate at one input/output per clock–with no throughput loss, such as you would’ve had were you using either Radians or degrees as your angular units.

Gosh, the CORDIC algorithm is just so useful, we might need to write a post on it by itself.

Coming back to our topic, though, all of these approaches to generating sine waves work nicely … but only if you use the right angular units.