Getting started with the FPGA demo bundle for Altera

4 Modifications

4.1 Integration with custom logic

The Xillybus demo bundle is constructed for easy integration with application logic. The place for connecting data is the xillydemo.v or xillydemo.vhd file (depending on the preferred language). All other HDL files in the bundle can be ignored for the purpose of using the Xillybus IP core for transporting data between the host (Linux or Windows) and the FPGA.

Additional HDL files with custom logic designs may be added to the project that was prepared as described in paragraph 3.3, and then rebuilt by clicking “Compile Design”. There is no need to repeat the other steps of the initial deployment, so the development cycle for logic is fairly quick and simple.

When attaching the Xillybus IP core to custom application logic, it is warmly recommended to interact with the Xillybus IP core only through FIFOs, and not attempt to mimic their behavior with logic, at least not in the first stage.

An exception for this is when connecting memories or register arrays to Xillybus, in which case the example that is shown in the xillydemo module should be followed.

In the xillydemo module, FIFOs are used to perform a data loopback. In other words, the data that arrives from the host is sent back to it. Both of the FIFO’s sides are connected to the Xillybus IP core, so the core is both the source of the data and the consumer of the data.

In a real-life usage scenario, only one of the FIFO’s sides is connected to the Xillybus IP core. The FIFO’s other side is connected to application logic, which supplies or consumes data.

The FIFOs that are used in the xillydemo module work with only one common clock for both sides (scfifo), as both sides are driven by Xillybus’ main clock. In a real-life application, it may be desirable to replace them with FIFOs that have separate clocks for reading and writing. This allows driving the data sources and data consumers with a clock other than bus_clk. By doing this, the FIFOs serve not just as mediators, but also for proper clock domain crossing.

Note that the Xillybus IP core expects a plain FIFO interface, (as opposed to “show-ahead”) for streams from the FPGA to the host.

The following documents are related to integrating custom logic:

• The API for logic design: Xillybus FPGA designer’s guide

• Getting started with Xillybus on a Linux host

• Getting started with Xillybus on a Windows host

• Xillybus host application programming guide for Linux

• Xillybus host application programming guide for Windows

• The guide to defining a custom Xillybus IP core

4.2 Making changes in Altera’s PCIe IP / Megafunction

Unless absolutely necessary, changes in the configuration of the Altera IP compiler for PCI Express Megafunction should not be made.

In particular, there is a high senstivity to the allocation of receive buffers. The Xillybus IP core relies upon the sizes of those buffers according to the numbers that are given by the IP Compiler / MegaWizard in the demo bundle. If the PCIe core allocates less buffer space than expected by the Xillybus IP core, sporadic data errors may occur in the communication from the host to FPGA. This can also cause a complete stall of the communication in this direction. Such problem would be the result of packets arriving to the FPGA that cause an overflow of these buffers.

If any change is needed in the IP / Megafunction, please seek assistance through the email address published at Xillybus’ web site.

4.3 Inclusion in a custom project

If desired, it’s possible to include the Xillybus IP core in an existing Quartus project, or create a new project from scratch. This section relates to Xillybus for PCIe, however a similar procedure applies for XillyUSB.

If the project doesn’t exist already, start a new project, and set it up as based upon your preferred HDL language and intended FPGA.

To include the Xillybus IP core in the project:

• Copy the pcie_c4_1x.v file (or alike) from the pcie_core/ subdirectory to a directory related to the project.

• For Cyclone V, Arria V, Stratix V, and series-10 FPGAs, also copy pcie_core/pcie_reconfig.qsys (or pcie_core/pcie_ip.ip) into the same directory.

• Follow the procedure that is outlined in 3.3.2 if the chosen FPGA requires that, in order to build Altera’s PCIe block.

• These files should be added (possibly a copy of them) for Cyclone IV:

  • pcie_c4_1x.v

  • pcie_c4_1x_core.v

  • pcie_c4_1x_serdes.v

  • pcie_c4_1x_examples/chaining_dma/pcie_c4_1x_rs_hip.v

  • ip_compiler_for_pci_express-library/altpcie_hip_pipen1b.v

  • ip_compiler_for_pci_express-library/altpcie_reconfig_3cgx.v

  • ip_compiler_for_pci_express-library/altpcie_rs_serdes.v

  For Stratix IV and Arria II, these files should be added:

  • pcie_s4_4x.v

  • pcie_s4_4x_core.v

  • pcie_s4_4x_serdes.v

  • pcie_s4_4x_examples/chaining_dma/pcie_s4_4x_rs_hip.v

  • ip_compiler_for_pci_express-library/altpcie_hip_pipen1b.v

  • ip_compiler_for_pci_express-library/altpcie_reconfig_4sgx.v

  • ip_compiler_for_pci_express-library/altpcie_rs_serdes.v

  For series-V FPGAs, there is no need to copy similar files, as they are generated and included by Qsys.

• Copy the two HDL files, xillybus.v and xillydemo.v(hd), in one of the two src/ subdirectories (depending on your language preference) and add them to the project.

• Adopt the constraints in the SDC file in either of the src/ directories (they may need slight modifications to match names of top level signals in the project).

• Copy xillybus_core.qxp or xillybus_core.vqm from the core/ directory and add this file to the project as well.

• If the xillydemo module isn’t the top level module of the projects, connect its ports to the top level.

• To attach the Xillybus IP core to custom application logic, edit the xillydemo module, replacing the existing application logic with the desired one.

4.4 Using other boards

4.4.1 General

When working with a board which doesn’t appear in the list of demo bundles, some slight modifications in the bundle are necessary.

4.4.2 Device family

The demo bundle includes a QXP or VQM file, which is a synthesized file for a certain device family. It can be used with any device within this family.

4.4.3 Pin placements

Most purchased boards have their own example of an FPGA design, which shows how the PCIe interface is used on that board. It’s often easiest to locate the relevant pin assignments in the intended board’s QSF file, and modify the pins’ names to those that are used in Xillybus’ QSF file. Having done this, it’s possible to replace the relevant rows in the QSF file that is used in Xillybus’ project.

There are also four user_led wires, which have no functional significance. But if there are vacant LEDs on the board, it’s recommended to connect them, as they supply some indications on the communication status. The user_led signal assumes active low logic (a logic ’0’ means LED is on).

4.4.4 PCIe only: Clocking

The xillydemo module requires some or all of these three clocks as inputs. The clocks that are needed are those that are inputs to the xillydemo module.

• pcie_refclk – Connected directly to the reference clock that is supplied by the host’s motherboard. This clock should have a frequency of 100 MHz. This clock may not be active when the host is powered off, and in other situations when this is allowed by the PCIe specification. A clock cleaning circuit may be present between the motherboard’s clock and the one that is connected to the FPGA, as required by the FPGA.

  If a different clock frequency is supplied to this input port (e.g. 125 MHz supplied by a clock cleaner), it’s necessary to change the Xcvr_ref_clk parameter in the IP Compiler for PCI Express settings accordingly. This is done when invoking the relevant IP Compiler / MegaWizard plug-in manager, as shown in paragraph 3.3.

• clk_50 – Drives the gigabit transceiver’s reconfig_clk, and must always be active. Therefore it must not depend on the motherboard’s reference clock. The allowed frequency range of this clock depends on the FPGA family (e.g. 37.5 MHz to 50 MHz on Cyclone IV). The specifications for this clock can be found by searching for “reconfig_clk” in the device handbook for the relevant FPGA.

• clk_125 – Drives the always-active clock that is required by the transceiver. The frequency of this clock must be 125 MHz, and must not depend on the motherboard’s reference clock.

In the demo bundle for Cyclone IV GX Transceiver Starter Board, the clk_50 and clk_125 inputs are driven directly by I/O pins that are connected to clock sources of 50 MHz and 125 MHz respectively on the board. In the absence of suitable clocks directly from the board, a PLL can be used to generate both, as described in section 7 of the IP Compiler for PCI Express User Guide, which is published by Altera.

When using a PLL, xillybus.v must be edited, connecting the reconfig_clk_locked signal to the PLL’s lock indicator. This has already been done on the demo bundle for Stratix IV, because the DE4 board doesn’t supply an always-active clock with a 125 MHz frequency.

An example of using a PLL is available among the files in the pcie_core subdirectory, after the PCI Compiler for PCI Express files are generated. This can be found as pcie_c4_1x_example_chaining_pipen1b.v in the pcie_c4_1x_examples/chaining_dma directory (or similar files when working with a family other than Cyclone IV).

4.4.5 Working with XillyUSB

XillyUSB can be used on other boards that have an SFP+ interface. In this case it’s just a matter of setting the design’s constraints to use the MGT that is wired to the SFP+ connector.

The board should also supply a 125 MHz reference clock with low jitter for the MGT. Despite the requirement in the USB specification, Spread Spectrum Clocking (SSC) should not be enabled (if such option exists): The MGT doesn’t lock properly on the received signal if an SSC reference clock is used.

For custom boards, it’s recommended to refer to the sfp2usb module’s schematics, as the pins of the SFP+ connector are connected directly to the FPGA’s MGT. It is optional to swap the SSRX wires, as done on the sfp2usb module. This is recommended only if it simplifies the PCB design.

Swapping the SSTX wires is also possible, if desired. This requires editing the *_frontend.v file so that the polarity of the transmitted bits is reversed, and hence compensates for the wire pair swap. Note that there’s a good chance that the USB connection will operate properly even without this edit, since the USB specification requires the link partners to work properly even with a polarity swap. It’s however recommended to not rely on this.