Daniel, I hope you don't mind me copying to the list. I think others may be interested.
On 7/26/06, Daniel Rozsnyó wrote:
Timothy, is your PCI controller designed in respect to any application which can be in FPGA or is it rather optimized for a graphics card? (e.g. in types of transfers, interrupt handling, don't know what exactly matters). Maybe it's better to do it properly once, even if the bridge is in FPGA.
Well, I think we're going to rearchitect it a bit. But what I want is something modular. A target, a master, a module that binds them together, config space, bridge to main FPGA, etc. Someone using this in their own design would be able to pick and choose how much of our stuff they include. The design is optimized for DMA and for high clock rate. As an example of the tradeoffs, we use slow decode for target transactions, so there are two idle cycles between address and first data phase. This isn't a problem since we intend the design to rely primarily on DMA. I don't think one would want to alter it for audio or networking applications. I think the same optimizations apply. One issue, somewhat related, that comes back to mind is with regard to interrupt handling. Specifically, we'd like the engine to never have any idle time. My intuitive solution is to have an interrupt that the drawing engine uses to indicate that it's ALMOST done (rather than competely idle). The problem is that that interrupt would come during a DMA transfer that we don't want to interfere with, but you can't service the interrupt without doing some PIO, let alone indicate that there's more DMA data to be gotten. There is something called MSI that might be a solution, but I don't want to go there. The only thing I can think of as any sort of solution would be to interrupt when there's no more DMA to do but have a really big command queue in the engine. So the interrupt says, "I still have lots of commands to process, but there are no more to be read from host memory." I don't like this solution totally, since some commands will be processed faster than they can be loaded, making the engine queue rather useless. Image loads are an extreme example of this. With those, I can't see a way around idle time on the bus. One goofy way to deal with this is to require real-time software timers. The DMA engine could be made to check/write host addresses that hold DMA pointers. Whenever a certain size block of DMA words have been read, the DMA engine updates the head pointer in host memory. At the same time, it also reads the tail pointer from host memory. As long as we can atomically update that word when writing to it from software (and we can ensure that the tail pointer is written AFTER the packet data -- memory barriers), we can just POLL the pointers in software. At an interval that is about half the time it takes to completely DMA the entire ring buffer, a kernel timer wakes up and checks the pointers. If there's room, it wakes up whatever user process(es) are filling the DMA buffers. Only if the DMA goes completely idle (head==tail) do we need an actual interrupt from the engine. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
