
Wow - Jules has been asleep for a couple of hours now, and I thought I'd write about how I spent my time this sunday night.
Both Erin & I needed to catch up on a little work. My targets were:* OE (OpenEmbedded) environment for the BeagleBoard
* OE environment for OpenMoko/FreeRunner
* Qemu for the OpenMoko/FreeRunner
* Qemu for my thesis
I'm really only interested in talking about the last point right now though, since that's the only one that's news to me.
My thesis has been very bleeding edge and very 'theoretical' directly from the start - the goal is to design and build a PCI co-processor for accelerated application of geometric algebra. The last attempt ran into a memory bandwidth bottleneck due to the use of shared system SDRAM over the PCI bus (even with DMA the problem cannot be solved). Unfortunately, the last attempt used an externally developed PCI card, and so they couldn't expand on the hardware itself. My solution to the problem was to throw more hardware at it - by designing a card with a sufficient amount of on-board SDRAM and SRAM, I hypothesize that PCI-imposed memory bandwidth limitations can be eliminated.
The board would contain an FPGA with a sufficient number of logic cells / blocks for one or many instances of the GA processor. There would be a high density of SDRAM to facilitate extra storage requirements for image processing, as well as sufficient amounts of SRAM to facilitate the needs of each processor and to act as a first-stage cache to the slower SDRAM.
My current vision of the board is something like the following:
(Insert diagram here - fpga, sdram, sram, optional DSP @ xxx MHz )
It's somewhat similar to the DSP Card by Darrell Harmon, and I plan on using free tools to do the schematic & circuit as well.
Now, there are several problems with PCI:
- I only have a vague understanding of the protocol, data format, and timings of the PCI bus
- I don't want to spend literally thousands of dollars on a prototype board, or even hundreds on literature describing the PCI bus
- I don't want to waste time and money designing, ordering, reflowing, and testing PCI boards from scratch, including PCB layouts, etc. I want to do 1 PCB layout and have it work!!! (a very optimistic goal)
- Even if I design a PCI board from scratch and it was electrically flawless, it's worthless if the interface software isn't on the other side (i.e. driver, low-level libraries, application)
Having used Qemu for a long time, I already knew that many people have written excellent code which performs kernel-level emulation of PCI hardware. So I started writing some C which described the basic functionality of a PCI card, borrowing from other existing modules (rtl8139.c, ne2k.c). After a lot of time spent, I finally got Qemu to initialize my module, which I appropriately called the 'OmniCard'.
However, even if I got the PCI protocol down, I would still be stuck writing C code to 'pretend' to do what each component in the FPGA would do (I'm not really interested in designing a VHDL interpreter). Furthermore, since emulation on a single-pipeline chip is not parallelization, a software simulation wouldn't really cut it for actually accelerating the operations of geometric algebra. Thus, the original goals would not be accomplished, and creating a piece of hardware is absolutely necessary.
Then I read some art-ic-les about using SystemC with Qemu. SystemC is probably the closest thing that I'll be able to get to that's highly integrable for emulation and also very close to the hardware level. Therefore, making a hardware design out of SystemC code is entirely possible. There are already translators that convert SystemC to HDL. The way that SystemC works with Qemu in the above articles is through a built-in PCI bridge. It will take some investigation, but I think that SystemC could be my key to maximizing my design efficiency with full debugability.
Stay tuned for updates.

0 comments:
Post a Comment