[Theora-dev] FPGA implementation

[Andrey Filippov]

> There's a simple tool filec in
> http://svn.xiph.org/experimental/derf/theora-exp/tools/ that can be used
> to compare the output of two dump_video runs and pinpoint the
> location(s) where they differ.
Thanks - I'll look into those tools

> The only more complex debugging tools
> I've been using are "sprinkle the code with printf()s" and diff, but I
> guess that's a little bit harder on an FPGA.

When I was debugging the JPEG encoder, after I made it "mostly work" the
most challenging was to catch a bug in the images (watching actual
hardware working) and reproduce it on minimal window (something not more
than 256x256, better 64x64 window). Then copy the input data (there is
program access to the frame buffer memory) and feed it to the simulator
that runs about 1,000,000 time slower than the actual chip. And in
simulator it is rather easy to analyse the problem, find the differences
and fix it.

It is really difficult (but not impossible) to get into the working FPGA.
One option is to use Xilinx proprietary tool that uses JTAG interface and
gets to any register bit in the chip. And I do have JTAG pins connected to
the CPU GPIO ports. But - it is a closed source tool so I can not modify
it to use the existent hardware connections instead of the special cable
that comes with the software.
Second option - write such software myself. But I'm too lazy for that :-)

And the third one (and I used it many times) is exactly what you suggested
- "sprinkle the code with printf()s". Just add some registers that latch
the data of interest triggered by some combination of signals and provide
means to read them out. This is useful to catch some rare events that can
be very difficult to simulate (because they will be 1000000*rare) or when
simulation does not match the hardware. that can happen with incomplete
simulation when there are some asynchronous interactions with external
devices, some tricky timing problems or - how I had it - "ground bounce"
that caused uncontrolled switching of some registers. Additional
difficulties in hunting such problems are related to the fact that
"silicon compilation" produces different results from the same source
depending on minor changes (or even on the value of the random seed
software uses in multiple attempts when instructed to match tight timing
constrains. So you just add that "printf()" and the problem goes away or
the bug just jumps to a new safe place :-)