Re: feeding a FIFO from PCI

In article <>,
says...
> On Sun, 13 Apr 2008 16:25:55 -0700, "Joel Koltner"
> <> wrote:
>
> >John,
> >
> >"John Larkin" <> wrote in message
> >news:.. .
> >> We could buy an FPGA pci soft core (or use one of the public ones) or
> >> even just use a PLX chip to handshake the PCI transactions for the
> >> fpga.
> >
> >FYI, I've used the old PLX9054 (before PCI Express took over the word), and it
> >was a *very* nice chip. The board was, essentially, a frame grabber with 4GB
> >of DRAM going through an FPGA containing its own "2D slicing" DMA engine (so
> >that a camera looking at multiple logical "windows" could have each window
> >appear as a contiguous stream of pixels) which fed the DMA engine in the
> >PLX9054. From the end-user's perspective then, what would happen would be:
> >
> >1) User would request a particular frame buffer, that would already have been
> >set up such that on the "local bus" (the address/data bus connecting the
> >PLX9054 and the FPGA) sequential addresses would grab the correct pixels. The
> >user would want that frame buffer transferred into a contiguous buffer in
> >their own user-mode memory space.
> >2) The device driver for the frame grabber would ask Windows for all the
> >*physical* addresses of that user's frame buffer, since of course in many
> >cases Window had run off and used a large number of discontinuous physical
> >memory (pages) to create the user's (virtual) contiguous buffer.
> >3) For the benefit of the PLX9054, the device driver builds a "scatter-gather"
> >list in the PC's memory, where each list entry just contains information such
> >as the number of bytes to transfer, the physical address to transfer to, the
> >local bus address to transfer from, and whether or not this is the last entry
> >in the list.
> >4) The device driver writes to the appropriate control registers in the
> >PLX9054... and it does the rest! Poof! (An interrupt was generated when it
> >finished.)
> >
> >In other words, the PLX9054 would start walking through the scatter-gather
> >list, automatically creating read requests on the local bus and write requests
> >on the PCI bus as needed, keeping its own internal FIFOs full (it had some
> >modest-sized ones... maybe 64 or 128 bytes? -- I've forgotten), and breaking
> >the write requests into multiple pieces as needed to keep the PCI bus protocol
> >happy. On quality motherboards, we got ~80Mbps, which was considered pretty
> >decent given the 33MHz/32 bit PCI bus architecture of the day.
> >
> >It was really pretty impressive. The only caveat was that it couldn't
> >transfer more than 16MB or thereabouts in one complete setup, so in software
> >we just broke apart any larger transfers into multiple 16MB transfers (since
> >transferring 16MB took about 200ms anyway, the additional overhead of some us
> >setting up the next transfer was negligible).
> >
> >I imagine the sequence of steps above is quite similar in Linux. Although
> >I've never written a Linux device driver, I've been told that they're actually
> >simpler in many ways that Windows device drivers are. If you end up using
> >Windows, it's absolutely worthwhile to drop the ~$3k or so to send the guy
> >who's going to write the device driver to the week-long classes by, e.g., OSR
> >to learn how to do so.
> >
> >My main point here is that going with a chip such as those from PLX gives you
> >one heck of a lot of power that would otherwise take a LOT of time and effort
> >to implement yourself. Although for a high-volume project it probably makes
> >sense to go with a soft PCI Core for the FPGA, for low volumes I'm a big
> >believer in using someone else's "all in one" IC.
> >
> >---Joel
> >
>
> Yup, I'm leaning towards using a PLX chip as the PCI interface. I
> didn't know they were that smart!

They'll save you a TON of work. PCI isn't easy, though PLX makes it
(relatively) easy. I also highly recommend the MindShare books as
reference.

> I suspect we can persuade Linux and our application to make the shot
> program (the opcodes we poke into the fpga FIFO) physically contiguous
> in real memory.

--
Keith