Saturday, June 16. 2007
The processor works
About two weeks ago, I built the first hardware revision of the intersect processor. I was quite exited to start writing some programs using its acceleration features - only to find out that it encountered serious errors every couple of thousand operations. What happened is that it 'choked' from time to time and kept operations inside the intersection pipeline without ever finishing them.
A picture of the FPGA routing
This was awful since it wasn't reproducible at all on computer simulations. And how do you debug a microchip? It's like finding a needle in a haystack using a 50-foot pole and binoculars.
Today, I finally managed to pinpoint the error inside the caching subsystem, which comes as a great relief!
A picture of the FPGA routing
This was awful since it wasn't reproducible at all on computer simulations. And how do you debug a microchip? It's like finding a needle in a haystack using a 50-foot pole and binoculars.
Today, I finally managed to pinpoint the error inside the caching subsystem, which comes as a great relief!
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Can you explain the cause of the error, or is it not understandable by the general geek public?
The cause is the built-in cache: Before a kd-Tree-Node or Triangle can be used by the intersection processor, it first has to be loaded from DDR memory into the 1024-line direct mapped cache (48 KB). This takes several cycles and the intersection processor uses a special mechanism so that it doesn't wait for the data but instead continues with the next thread at once (The cache can be simultaneously acessed by multiple readers/writers). Later, it checks again whether the data has been loaded. The problem occurred when the 3D scene was larger than the cache and a cache line had to be replaced. In this case, the cache generated invalid signals for several cycles which put the intersection hardware into an invalid state.
