Now to get back on sidetrack

I decided that I had learned enough from my prototype board and that it was time to start working on the real board. A single board that would have everything on it, no need for a seperate FPGA board. This time I will compile everything before ordering the boards. I decided to start with the SPU, I can also test this with my Papilio. My initial goal was to basically put a midi file in shared memory and point the SPU at it. I started to write a midi file reader in VHDL, the state machine got complicated in short order. Looking at it, it started to look like a processor. Then I thought, why not implement it as a soft processor. And this is the point where I get sidetracked. I designed a 16-bit register based RISC CPU, implemented it in software, wrote an assembler, implemented it in VHDL, and started creating a C compiler. The soft processor worked well enough to output hello world over a UART and even output a sine wave through a memory mapped delta sigma DAC.

Though there were a few lose ends to tie up. I had a 32-bit 16.16 fixed point unit in the design with add/subtract/multiply/divide. The divide translates to a 48-bit integer divide and I saw VHDL has a divide operator. I didn’t expect it to work, surely it won’t make timing, doing the divide in a single cycle, but I also didn’t expect it to fail quite as badly as it did. It wouldn’t even compile. The Xilinx tools told me I was trying to use 125% of my available resources. Woops. Luckily removing the fixed point instructions dropped my resource utilization down to 60%. I still need to remove those instructions completely or re-implement them using multiple cycles. I also noticed a few instructions I hadn’t tested yet had bugs in them. Then there was the C compiler. I had a pre-processor, parser, syntax analyzer, and I had started on the semantic analyzer, but I still had to finish it and implement the code generator and optimizer. Of course I’d also want a debugger and perhapse this is getting out of hand. Looking at my FPGA resource utilization, after adding JTAG debugging, the video unit, and the SRAM controller, I may well run out of resources before I get everything implemented.

Time to shelve this, maybe pick it up later with a new project with the soft processor taking up the entire FPGA. I decided instead to greatly simplify the audio unit and go back to implementing it in VHDL. Now instead of trying to read a midi file it would just handle the audio channels, generating sine waves and mixing them, with the CPU doing the sequencing. This simpler design was implemented and tested without too much fanfare and once again I’m on track. I added in the video unit modified from my earlier VGA/DVI tests and the SRAM controller and everything compiles.

Lessons learned: dividing is hard.