1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Re: feeding a FIFO from PCI

Discussion in 'Embedded' started by krw, Apr 14, 2008.

  1. krw

    krw Guest

    In article <>,
    > 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

    > 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.

    krw, Apr 14, 2008
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guest
    Aidan Grey
    Jul 10, 2004
  2. Guest
    Sep 3, 2004
  3. rickman

    Re: feeding a FIFO from PCI

    rickman, Apr 12, 2008, in forum: Embedded
    Apr 21, 2008
  4. Nial Stewart

    Re: feeding a FIFO from PCI

    Nial Stewart, Apr 14, 2008, in forum: Embedded
  5. Re: PCI FIFO Design

    , Mar 31, 2009, in forum: Embedded