Motherboard Forums

Thread Tools Display Modes

Re: feeding a FIFO from PCI

Posts: n/a
      04-14-2008, 02:58 AM
In article <(E-Mail Removed)>,
(E-Mail Removed) says...
> On Sun, 13 Apr 2008 16:25:55 -0700, "Joel Koltner"
> <(E-Mail Removed)> wrote:
> >John,
> >
> >"John Larkin" <(E-Mail Removed)> wrote in message
> >news:(E-Mail Removed).. .
> >> 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.

Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: PCI FIFO Design Embedded 0 03-31-2009 06:28 PM
Re: feeding a FIFO from PCI rickman Embedded 4 04-21-2008 01:22 PM
Re: feeding a FIFO from PCI Nial Stewart Embedded 4 04-14-2008 07:37 PM
ADC unit with 2 input channels, 12 bit, 10MHz conversion rate, 4Ksamples FIFO, USB (or PCI on PC104+ form) interface, Linux, QNX driver Embedded 0 09-03-2004 11:48 AM
High speed ADC board (12-16Bits, 10MHz,1-2In,4-16K FIFO,USB-PCI PC104+, Linux support) Embedded 1 07-10-2004 12:41 AM

All times are GMT. The time now is 04:33 AM.

Welcome to Motherboard Point