PCI FPGA Dev Board Suggestions

Kunal

I think if such a card does not exist today it probably won't. PCIE is killing of PCI66 very rapidly although we do hear of other people, usually Sun machine users, wanting PCI66 and we have considered doing a PCI66 version of our Broaddown4 product. I would be interested to hear from anyone else that thinks there is a market for this interface, even niche smallish quantities, as we could deliver such a product within a few weeks if a strong requirement exists.

Your next problem is getting a Virtex level product cheaply. Spartan level products don't often support PCI66. Our base level version of Broaddown4 does come just with your price target but at the moment is the wrong interface with the PCIE.

Is this an academic application? If so some vendors like ourselves have University discount schemes.

The PLX style approach isn't used by many FPGA development board manufacturers as usually they are trying to demo PCI inside a FPGA. We are doing an alternative to this in some planned products and you can see the first implementation in our Trarfessock1 board that has a FPGA for the PCI(Cardbus) interfaces and an independent one for the main logic development. This allows a lot of flexability in how the card is used.

John Adair Enterpo> I should also mention that we'd like to keep the cost under $2000, and

Hi,

These chaps might have someting suitable:

Cheers,

Andy

This is a good point.

This is for university research, and we're basically looking for the easiest and cheapest way to get about 600-800 Mbits of data onto a PC without resorting to National Instruments cards (including their FPGA product).

We're certainly not closed to the idea of using PCIe, although it would require purchasing new computers.

It seems that most FPGA PCI boards are tailored to embedded applications; since our application is a relatively simple one (where the complexity is in transferring the data from FPGA to PC), this seems a bit overkill.

Nevertheless, we're still explor> Kunal

A design consisting of multiple Spartan FPGAs is far cheaper than one big Virtex. Still, 100MB/s is not something that is easely transferred through the old style PCI33 or PCI66 bus. You'll find other devices also demand bandwidth and you'll want bus-mastering as well.

An easier way to design such a beast is moving to PCI Express PCs and use a PLX PCI express to PCI33 bridge chip. Now you have a dedicated PCI33 bus you can use without having to concern yourself with other devices which reside on the same bus. Perhaps you can even get by using a less strictly timed PCI implementation since you also have full control over all signal integrity issues.

The driver is another problem. If you can find a device which does almost what you want, you can try to mimic it and use drivers that come with Windows. Back when I had to do my first PCI design, I simply emulated a 16550 style UART to exchange data at a low rate. Windows knew how to talk to it so I could move on without having to wait for the software people to come up with a driver.

Kunal

One thing to watch with PCI is that you rarely get a bandwidth near the theoretical. Your figure is about 1/3 and is just about feasable. You still need to be careful in that if any card on your PCI segment is restricted to 33MHz then the whole segment runs at 33MHz. Also we have seen a wide range in PC PCI frequencies so you don't always what you expect and sometimes less performance results. You also may find other devices on the motherboard may be sitting on the segment and taking lots of bandwidth e.g. network card.

The PCI66/32 is unusual. Most 66MHz systems use the wider 64bit data and you may find more cards with this data width.

John Adair Enterpo> > PCIE is killing of PCI66 very rapidly

I just got another idea on the mimic thing: If you let your fpga design mimic a network card (an NE2000 or Realtek as long as the drivers can deal with bus mastering), you can put your data into UDP packets (maybe one port per stream??). All you need to do in your application software is listen to the proper network socket. No need to write a driver. With some care, your software and hardware will run on any platform instantly.