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?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
  1. Me
    Ben Myers
    Jul 27, 2004
  2. DAS
  3. BBB

    feeding video into computer

    BBB, Jan 23, 2004, in forum: Nvidia
  4. Guest
    Aidan Grey
    Jul 10, 2004
  5. Guest
    Sep 3, 2004
  6. rickman

    Re: feeding a FIFO from PCI

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

    Re: feeding a FIFO from PCI

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

    , Mar 31, 2009, in forum: Embedded