WARP Project Forums - Wireless Open-Access Research Platform

Please note that the eval board you linked to does not use a standard FMC connector.  As you can see from page 14, 17 and 25 of the user guide, it uses CONN_PCB 60-pin RA connectors for P501 & P502 which is the digital interface to the FPGA board.  Unless you have an adapter, this will be difficult to use with WARP.

The WARP v3 FMC interface is detailed in the user guide.  This has the FMC pin to FPGA mapping that you will need in order to connect a custom FMC module to the FPGA.  To help with integration of other FMC modules, you should familiarize yourself with the FMC-RF-2X245 which uses the FMC connection to provide two additional radios.  Once, you understand the schematics, and the WARP FMC user guide, then you can see how everything is integrated in the top level reference designs by studying the system.ucf file for connections to the FPGA ports and the system.mhs file for connections to the various peripherals.  You can also study the custom pcores that we built for interfacing external devices, such as the AD bridge and the AD controller.

Yeah, sorry for the confusion, I am using the eval board with the FMC connector. I am trying to use the digital output of this ADC as the baseband RX signal into a WARP board. Which clock configuration would you recommend for this application?

First, I have not attempted to build the design you're working on, so I can't provide exact instructions for the best approach. This is definitely a case where you'll have to study the various options and decide which best fits your needs.

With that said, a few thoughts:
-The FMC module ties the SPI data/clock signals of the AD9467 and AD9517 together. The SPI data line is bidirectional (the SDIO net). The SPI chip selects are separate. The ML605 reference design uses the Xilinx axi_spi core (which assumes separate SDI and SDO serial lines) plus the ADI util_spi_3w core (to convert the separate SDI/SDO lines to a bidirectional SDIO). I don't know exactly how the axi_spi core works - we designed our own simpler SPI HDL (simple_spi_v1_00_a) that is used by the various SPI-enabled pcores (w3_ad_controller, radio_controller, etc). The axi_spi driver should have some examples of how to configure and use the core from code.

-I was wrong above- the current version of the FMC module drives the ADC "DOC" signal (data out clock) to CLK0_M2C, FMC pins H4/H5. The ADI schematics and PCB layout are consistent on this. The DOC signal should be used by the FPGA to capture the ADC data signals. I suspecct this is how the ADI ADC interface pcore works. FMC pins D4/D5 are reserved for multi-gigabit transceiver clocks, not used on the ADI module.

-The ADI ADC interface pcore (axi_adc_1c_v1_00_a) would be a good thing to understand. I think the ADC data interface is DDR LVDS. The ADI pcore should implement a known-good HDL interface for these fast nets. The rest of this core is pretty complicated- it reads samples from the ADC and outputs them as an AXI stream for transfer to DRAM using the axi_dma core. You probably don't want all this complexity if your goal is to feed samples directly into the 802.11 Rx PHY. I would suggest building a simple core like the w3_ad_bridge, to adapt the ADC native interface to a simple internal interface for use by other cores in the FPGA.

-Clocking the ADC remains a challenge. The ADC minimum clock frequency is 50MHz. The 802.11 Rx PHY requires complex samples (12-bit I, 12-bit Q) at 20MHz. The first decision is whether to run the ADC synchronous to the FPGA design. This would greatly simplify the pipeline from the ADC to PHY. To achieve this you will need to drive an external clock into the ADC module. One option would be to drive an 80MHz clock via a CM-MMCX module and use this directly as the ADC clock. Another option would be to drive a clock from the WARP v3 debug header and use this as a reference clock for the VCO+PLL in the AD9517. Assuming you get the ADC running at 80MHz, you will still need to decimate the sample stream to 20MSps before the Rx PHY. Simply discarding 3/4 of samples will create aliasing; this might be ok if your external analog signal is quiet outside 20MHz. A proper decimation filter (LPF + 4x downsample) would be required if not.

Have you completed the Getting Started Exercises?  There are tutorials in there about creating a pcore from System Generator and how to instantiate a custom pcore in an XPS project.  Those tutorials should give you some of the basics about how to proceed.

While you can create a pcore in System Generator, you can also create one by hand writing Verilog or VHDL.  In that case, take a look at some of the existing pcores in the EDK repository.  If you look at something like the AD bridge peripheral, you can see the minimum required to create a pcore by hand and the basic structure of it.  You can look at some of the other pcores to get examples of how to add software drivers and more complex configuration options.

Each pcore has an MPD file. The MPD file lists the ports the core presents to the next level of hierarchy. The MPD file also describes any metadata about the ports, such as grouping ports into a bus interface for connection to an AXI interconnect. The MPD file does not describe any connections from the pcore to the rest of the system.

The XPS project hardware design is specified in the system.mhs file. Think of XPS as a VHDL generator. It reads the MHS file and all associated MPD files, then generates hdl/system.vhd. All connections among pcores and between pcores an FPGA pins are defined in the MHS file.

Consider the fmc_bb_4da_bridge as an example. Its MPD file defines ports like user_DAC_A and DAC_AB_DB. These ports are not inherently internal or external- they just describe the interface of the underlying HDL (verilog/fmc_bb_4da_bridge.v, in this case).

When the fmc_bb_4da_bridge core is instantiated in the MHS file, these ports are tied to named nets. For example

BEGIN fmc_bb_4da_bridge
 PARAMETER INSTANCE = my_dac_bridge
 PARAMETER HW_VER = 1.00.b
 PORT user_DAC_A = sig_for_DAC_A
 PORT DAC_AB_DB = DAC_AB_DB_ext
 ...
END

In this example the input port "user_DAC_A" is tied to net "sig_for_DAC_A", and the output port "DAC_AB_DB" is tied to net "DAC_AB_DB_ext".

To complete these connections you must use the same net names elsewhere in the MHS file. For connections to FPGA pins, a top-level PORT declaration is used. For connections to other pcores, the same net name must be used in a PORT directive for that core's instantiation. For example:

#Top level ports
PORT DAC_AB_DB_ext = DAC_AB_DB_ext, DIR = O, VEC = [11:0]
...
BEGIN my_signal_generator_core
 PARAMETER INSTANCE = my_sig_gen
 PARAMETER HW_VER = 1.00.A
 PORT sig_A = sig_for_DAC_A
...
END

For external connections (top-level PORT's) you must specify the signal width and direction explicitly. For internal connections the signal width and direction are inferred from the PORT declarations for the connected pcores.

Ah, I forgot the last step of mapping top-level PORT's to actual FPGA pins. This mapping is in the data/system.ucf constrains file. Each signal is mapped to a pin with LOC constraints. Busses have one LOC signal/pin assignment for each bit in the bus.

The list of all FPGA pins for WARP v3 is in the Mango_WARP_v3_1p1_Pinout.ucf file. Scroll down to the FMC slot section for those pins. The naming scheme there uses the FMC spec name for each signal on the FMC header. There are three groups of general I/O: LA, HA, HB. The ADI schematics use the same names on pg 5. I believe that module only uses the LA signals.

It is important that every top-level signal in your design is assigned to a pin in the UCF file. Unconstrained signals will be mapped to arbitrary pins, leading to unpredictable behavior in hardware.

HPC is a superset of LPC. The HPC spec adds the HA and HB I/O banks to the LPC spec. The LA bank is the same for LPC and HPC modules/carriers. An LPC module can used on an LPC or HPC carrier. For an LPC module and HPC carrier (like the ML605 and WARP v3) the unused HA/HB pins are left safely unconnected.