FPGA to PCI Bus Interface

I used a PLX chip a few years ago and had very little trouble with it. PCI was not so easy to learn, but otherwise it was no big issue. I would recommend that you use a PCI bus analyzer to help you debug your low level protocol. Or you might not need it if you are doing a simple memory mapped interface. We were doing DMA and needed all the help we could get since we didn't have much info on the disk controller bus master.

I've also worked on boards with PLX chips on them. One (family of boards) in particular had a PLX PCI 9030 to bridge between the PCI and a simple synchronous local bus that went to a number of FPGAs.

It didn't have amazing performance, but it was simple and worked.

Regards, Allan.

AndyAtHome wrote: : Hi All,

: I'm need to interface a Xilinx Virtex to a PCI Bus. The Xilinx PCI IP : core is too costly for the volumes I will be building, so I'm looking : at PCI controller chips.

: From experience can anybody recommend a vendor, such as Quicklogic, : AMCC, Tundra, etc.

Look at the Opencore PCI Core

If Target PCI core is enough for your product, we have a complet package coming with : - ezPCI PCI Core (target only) VHDL or pre-synthesized code - linux drivers - w2k, xp, nt ,win98 drivers

It is very easy to use and will allow you to skip the need of PCI interface chip ;-)

Our PCI package was used by 4 companies for specific products. Works well, but it is target only for now.

Please contact me to know the prices.

Laurent Gauch

Thanks - two votes for PLX, I'll check them out.

Andy.

Personally I prefer using a separate chip because it allows me to load that FPGA through the PCI bus making field upgrades easy. I am waiting with putting PCI inside of a FPGA until modular design and partial reconfiguration will allow me to achieve the same level of flexibility.

/Mikhail

You don't need partial reconfiguration to do a field upgrade. Connect a couple of pins on the FPGA to the programming pins on the serial PROM. Use them to rewrite the bit stream, then power cycle.

Not as convient for debugging.

It also has the problem of leaving your board in a broken state if you drop power in the middle of the update.

If it is just functionality you use, have a look here:

/Rob

Or something else goes wrong, plus the cost of the PROM is comparable to the cost of a PCI bridge...

/Mikhail

I've used PLX 9030 and 9656 in different designs, and they're actually pretty easy to use. The local bus is fairly straightforward. I don't think they have Verilog or VHDL models of their local bus. I did write my own, based on the data sheets, and it matched the real hardware (always a bonus).

I also did a design with the QuickLogic QL5064. The local bus (inside the FPGA) is also fairly straightforward and their simulation models are correct. It's also fast -- I set up a DMA test from one QL5064 (as a master) to another (as a slave) behind a bridge and I got damn near max PCI64/66 bandwidth. The main downside to the part (other than its expense -- $110 a pop) is that it's an OTP BGA, so you'll need to use a fairly expensive socket and be prepared to burn through a bunch of chips.

My current design is based on a roll-my-own PCI interface in an FPGA, for two reasons: 1) no room on the board for a PLX (or other) controller chip), and 2) my application requires a DMA engine that I don't think maps too well to Brand A or Brand X's IP.

I will also say that a PCI bus analyzer is mandatory.

Hi,

I've used PLX in the past. They are quite good for support and tools. Yes, you need some configuration tools to set up the registers, handshaking, etc.

Regards,

Luc

I wasn't trying to push for or against the PLX type approach. Just pointing out that there are ways to change the configuration when your design gets loaded from a PROM. Board space or layour or something else might make the PLX/bridge unattractive.

Another potential disadvantage of the PLX/Bridge is a few more clock cycles if you just want to do a simple read. (Writes can be pipelined.)

The design I worked on used a small CPLD along with the PLX chip and allowed the download to come from the main CPU with no PROM. This was used to download different configurations for different modes of operation (selftest vs. record vs. playback).

That's exactly what I am doing in most of my PCI designs, but Hal is right in the sense that this is not a universal solution in every case.

/Mikhail