FPGA Ray Tracer
Scott Bingham / Donald Zhang

Design Difficulties
Our biggest design challenge turned out to be signed arithmetic. We found that we had to explicitly manage the signs of operands in multiplications by making both operands positive, multiplying, and then fixing the resultant's sign if necessary. Also, we found that the arithmetic shift operator '>>>' didn't always work as expected. Compile times at the end of the project were approaching half an hour which made debugging very difficult. Meeting the clock cycle timing requirements while trying to pack as many calculations as possible into a given state was also tricky at times. Debugging on a per pixel basis was also impossible once a large number of spheres, shadows, and reflections were added so we had to rely on mostly the VGA output to see if our changes were correct. Also, occasionally toggling one of the input switches, the state machine would jump to a state that it was never designed to reach. To solve this, we simply made any unused state return to the initial state for the ray.

On the software side one of the biggest problems is timing and handshaking between the hardware and software. Problems include assigning the spheres data to the wrong sphere registers, or cutting off the first or the last sphere due to timing problem. These problems are all fixed when we handed over the control of the interface to the software. The software would tell the hardware when the data is valid and which sphere register it should be storing the data to.

Statistical Analysis of Ray Tracer
This section presents some of the performance stats of our ray tracer. A total of 17 scenes were drawn to show the speed of the ray tracers in term of rays per second and frames per second. These 17 scenes include four configurations for four different scenes which all have resolution 512x480, and a best case performance (a low resolution scene 320X240 with no features turned on). Also note that the following time does not include the time the hardware waits for the software to sends the sphere list.

Table 2

Figure 12

The number of rays per second varied between 440,000 to 540,000 depending on the specific scene. As expected the number of spheres and planes both have a big impact on the performance of the ray tracer. Certain relationship can be observed from the above graphs. The number of rays per second is more effected by the number of spheres and planes, and less by what features are turned on. On the other hand the frames per second is mostly effected by what features are turned on. For the same scene when both 8 times anti-aliasing and 3 levels of reflection are turned on, the frame rate can have as much as 30 times decrease from the standard case.

Hardware Usage
In the end we had to limit our design due to limited number of logic elements available to us on the DE2 board. The NIOS II CPU uses about 1400-1800 LEs, which leaves us with 33216 LEs for the ray tracer hardware. We had to shrink the size of the number of spheres that can be drawn down to 4 so our design can fit on the FPGA. Below is some stats from the compliation report of our final design.

Table 3