I want to implement FPGA module which can communicate using PCIe. I am using Stratix IV GX which has PCIe Hard IP in it. How I can use this Hard IP module to communicate.

To develop my module I should understand interface details of hard IP (mainly input and outputs), which I am not finding online. Can someone help me with the same?

  • 1
    \$\begingroup\$ Have you read this doc? \$\endgroup\$ – Qiu Apr 13 '15 at 4:19
  • 1
    \$\begingroup\$ Writing your own PCIe core is very complex! Most examples use the simple but not allowed PIO mode to transfer data (it's only allowed for legacy devices not new ones). The embedded HardIPs implement only a link layer and a subset of the transaction layer, so in most cases you need to implement a PCIe master, credit based flow control, reordering, priority management, ... AND then there is the driver side ... BUT: there are free PCIe cores in the web: RIFFA, XilliBus, ... Currently, I think XilliBus is the nicest: it registers 2 device nodes in linux's dev-fs which can be used like fifos. \$\endgroup\$ – Paebbels Apr 13 '15 at 19:59

There is two main way to use a PCI bus between a FPGA and a processor. Note that I say PCI in the answer because there is nothing in what I tell special about PCIe; it encloses PCI.

The first one is using PCI BARs (Base Address Register). These are address spaces declared by the PCIe device (for example, a device could declare having a BAR0 of 4KB) that are mapped to virtual memory by the operating system. Read/writing to these address on the processor results on bus transfer request on the PCI device, basically providing the FPGA an address port with data and direction.

The second way is using the device as a DMA (Direct Memory Access) bus master. In this mode, the device can initiate memory transfer to/from the system memory (the one the processor uses). This is very efficient as the processor isn't hang up by the transfer, i.e. it can do something else while the device read/write to processor memory.

Note that the PCIe device can also trigger interrupts on the processor, for example to tell it a DMA transfer is required/done.

A typical processor-FPGA PCIe system will define a set of registers in the PCI BARs, and use these to tell the FPGA where the DMA buffer addresses are so it can transfer data without the need for processor intervention. As you can guess, you don't want the device to write to any processor memory address...

To put it in layman terms, BARs are easy to use and slow, DMAs are fast and cumbersome to setup. Note that you will most likely need a driver to deal with your PCI device on the processor, and program logic to response to BARs transfer and initiate DMAs.

I would recommend you to look at reference designs from altera before delving into PCIe; and that you get a reference book on PCIe standard. You may also need to learn more about writing drivers for whatever system your processor uses. BARs are easy and may not even requires a driver, but if you need PCIe, you want to use DMA.

  • \$\begingroup\$ Thanks for your answer. I think I should start with BARs compromising speed and and knowledge in this field. Can you suggest me some documents or reference designs. I tried reading altera_pci_user_manual, but it is too complecated for me. \$\endgroup\$ – tollin jose Apr 14 '15 at 5:20
  • 1
    \$\begingroup\$ As I recall, the Xilinx PCIe IP core come with an example design that connects a BAR to a BlockRAM and another to GPIOs. Also, any good FPGA development board with a PCIe interface will have a reference design readily available. There is also the xapp1052 from Xilinx (note that PCIe is general enough that any reference design is not totally irrelevant, even if you use a different board/technology, espicially driver-wise). I don't know enough of Altera to suggest anything from them. \$\endgroup\$ – Jonathan Drolet Apr 14 '15 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.