Zynq-7000 AP SoC Spectrum Analyzer part 6 - AMS - XADC Signal Acquisition and DMA to L2 Cache & Compete Design Tech Tip

Zynq-7000 AP SoC Spectrum Analyzer part 6 - AMS - XADC Signal Acquisition and DMA to L2 Cache & Compete Design Tech Tip

Document History

Description of Revisions
23 Sept 2013
Faster Technology
Initial posting with figures

24 October 2013
Faster Technology
Update with revised files and figures
1 march 2014
Faster Technology
Update to 2013.4 Release
More Revisions


In Tech Tip "Zynq Adding Hardware FFT Tech Tip" the FFT application developed in "Zynq Building an FFT Application Tech Tip" was enhanced by the addition of a hardware FFT implemented in the PL fabric of the Zynq-7000 AP SoC. This enabled us to compare execution times for the ARM processor, NEON SIMD engine and a pure hardware block, all computing the same FFT. The FFT application operates from data in an input table. Previously that data table was loaded with software generated data. In this Tech Tip, hardware will be added to the application to capture data from the on-chip Analog to Digital converter; the XADC block connected to an AMS 101 or other appropriate analog input board.

This Tech Tip will illustrate the use of multiple DMA blocks and how the AXI interconnect can be used to funnel multiple processes into the ACP port of the PS. DMA operations are used for both moving the converted analog data into the PS and for filling and draining the hardware FFT block when that block is in use. This complication of the information flow is readily handled by the interconnect blocks in the PL design in coordination with the ACP port on the PS. In addition, this Tech Tip will demonstrate use of the IP Integrator (IPI) capability in Vivado 2013.4 for creation of the overall hardware system being utilized and coupling that to SDK for the software development and debug.


Implementation Details
Design Type
PS and PL
SW Type
1 CPU - standard ZC702 frequency
PS Features
ARM Processor, ACP port interface, DRAM, OCM,
PL Cores
Hardware FFT, DMA, AXI Interconnect, XADC
ZC702, external signal generator
Xilinx Tools Version
Vivado / SDK 2013.4
Other Details
ZC702 setup for console terminal and Ethernet required; AMS101 card

Files Provided
Hardware source file set for Vivado 2013.4; required to build XADC hardware interface in PL
Software source files for application software to interface to XADC hardware in PL
Optional starting point workspace for software build process
Optional u-boot.elf file for building a new BOOT.bin with XADC hardware in PL

Block Diagram

This Tech Tip relies on information used in the AMS Targeted Reference Design and builds upon some of the software supplied with that design. An implementation block diagram within Vivado will show the overall structure in a later section of this Tech Tip. The XADC block is initialized for the selected sample rate and the channel corresponding to the AMS 101 card installed on the ZC702. A DMA engine and AXI Stream to Memory map block is interfaced to the XADC to move the sample data. An AXI Interconnect block provides the interface to the ACP port on the PS, providing arbitration and multiplexing between the XADC data and the data flowing to and from the hardware FFT block. Inside the PS, data from the XADC transfer is stored in the FFT input buffer until a buffer full has been accumulated. At that point, the FFT is invoked, either in software or the hardware FFT block, to process the sampled data.

Step by Step Instructions

Vivado 2013.4 will be used to create the hardware FFT and XADC interface used in this Tech Tip. The hardware design elements for this Tech Tip are derived from the sources supplied with the ZC702 base Targeted Reference Design (TRD) for Vivado 2013.2. This enables us to use the IP Integrator capability in Vivado 2013.4 to build the hardware required for the FFT block and the XADC control and data movement hardware. Additional IP blocks are supplied to supplement the base TRD with functions required for the XADC capability. This set of sources is combined in the xadc.zip file associated with this Tech Tip.

If you have not yet downloaded XADC.zip, do so now. It is best to save this at the root of a hard drive to avoid problems with long path names. In our instance we downloaded and unzipped XADC.zip to G:\XADC - the default if XADC.zip is saved to the root of the drive.

This Tech Tip will proceed in two main sections; using Vivado to build the hardware, and using SDK to build the software. The result will be a revised boot file for the ZC702 that contains updated hardware for the base TRD with the hardware FFT and XADC control hardware along with a set of application files that build on the capabilities of the "Zynq Adding a Hardware FFT Tech Tip".

Building the hardware

Supplied with this Tech Tip is a tcl script file that will simplify the process of building the FFT and XADC support hardware in Vivado. This file is:


The script file is in the /scripts sub directory where XADC was unzipped. In our case this is G:\XADC\scripts or


where $ZYNQ_XADC_HOME is whatever starting directory of the un-zipped xadc.zip. In our case $ZYNQ_XADC_HOME is G:/XADC. It is useful to note what your specific $ZYNQ_XADC_HOME path is as it will be used later within Vivado.

We then run Vivado to build the hardware system.

On Windows, select Start > All Programs > Xilinx Design Tools > Vivado 2013.4 > Vivado 2013.4

Vivado will start and show the welcome screen

Before starting the process of building the hardware, verify that you have installed valid hardware licenses for the IP cores used in the ZC702 Base TRD design. These include the Chroma-Resampler, Video Timing Controller, etc. (See the Base TRD user guide for more information.) If a hardware implementation license is not in place when bitstream generation starts, the whole project will need to be deleted and started from the beginning.

In the tcl console input line, run the following commands


source . /scripts/project.tcl

The project.tcl should build the complete base TRD hardware system with the PS and various video processing hardware blocks used by the TRD software. In addition, it will add the FFT hardware block from the Tech TIp "Zynq Adding Hardware FFT Tech TIp" and the XADC block with additional hardware DMA support.

If you encounter any licensing issues or other implementation errors in running the project.tcl script, these must be resolved before running continuing. Otherwise the hardware will not build properly.

With this tcl script complete, the hardware FFT and XADC have been added to the system and connected to the PS as shown below

In the block diagram pane, we can zoom into the XADC hardware to see what it contains. Move the cursor to hover over the upper left corner of the XADC block. When it changes to double chevrons, click to expand the hierarchy of the XADC IP core.

Using the zoom controls, either the magnifying glass with the + or selecting and dragging a zoom window in the diagram pane, zoom in to better see the contents of the XADC block. You can also maximize the diagram pane (click the maximize icon in the upper right corner) if desired.

The XADC block is a standard IP core that is configured through the Core Generator. In this instance it is configured to be controlled from the SPI interface that is exposed in the PS. This will enable us to use software to select the various possible inputs, set the sample rate, etc. When the software is built later in this Tech Tip, setup code from a reference design for the XADC block will be reused. This is facilitated by the use of the same physical and logical connections from the PS to the XADC core.

The axi_dma block previously seen in the hardware FFT implementation is used to move the data from the XADC into the FFT core. The AXI interconnect block is also used to move the data to the ACP port of the PS. The AXI interconnect handles any multiplexing and arbitration between the two AXI streams of data; from XADC and from the FFT processing block. In addition it handles the translation from streaming data, used by the FFT block to memory mapped data required to interface to memory in the PS through the ACP port.

With successful completion of the project.tcl script, all of the configuration is complete and the design is ready for use.

To complete the hardware design, synthesis and implementation must be run. This can be done by initiating each step individually or if "Generate Bitstream" is selected, the Synthesis and Implementation steps will be run automatically.

In the flow Navigator panel, click Generate Bitstream (in the Program and Debug group at the bottom of the panel)

Synthesis, implementation and bitstream generation may take over two hours for this design. There will be some warnings, but these are not critical to the proper operation of the hardware. Most notably, there are a number of optional ports on some of the IP blocks that are not required and are therefore not mapped into the processor address space. If the following message appears, click OK to accept it and allow the synthesis to continue.

When Vivado completes processing the design, verify that there are no errors; warnings are expected with most relating to optimizations that are being done and have no impact on operation of the hardware. The "Bitstream Generation Completed" message will appear when the processing of the design has been completed. It is best to accept the default of "Open Implemented Design" as this will enable the system to save the generated bitstream with the other files to be exported for use in SDK.

Click OK to continue

The next step is to export this hardware design in a form that SDK can use to build the files needed to properly configure the ZC702 to run the hardware FFT.

The block diagram must be in view for the Export to SDK commands to be visible. To display the block diagram, click on the Open Block Design item in the IP Integrator section of the Flow Navigator.

Then click system_top.bd

With the block diagram in view, from the File menu select

File > Export > Export Hardware for SDK

NOTE: If the block diagram is not displayed, the export option will not be visible. Another method to display the block diagram is to select Window > Diagram to display the block diagram.

In the dialogue box that appears, leave the defaults selected and click OK.

Vivado creates several hardware description files and the bitstream in a directory branch off of the "project" area as shown below. The files in this branch will be used in the next step so remember where they are.

At this point, we are done with Vivado and it can be closed. Save the project for future reference if prompted.

Building the Software

With the hardware for the FFT and XADC in the PL fabric complete and included in the base TRD hardware, we need to build the software to control the XADC and move data through the interconnect to the ACP port. Data received at the ACP port from the XADC operation will be placed in the FFT input table in the PS memory. When data receipt is complete, the DMA signals the PS of this action. Simple polling supported in Linux with the "while" construct will be used to poll for this operation complete notification.

The various software source files required are in the compressed file "xadc_test.zip" that is associated with this Tech Tip. Download this zip file from the Xilinx wiki at


and save it to a convenient location on your hard drive. In our case, we put it in our Zynq fft project directory under HW_XADC

These source files and the files exported from Vivado will be used to build two things required for the XADC hardware system;
- a new BOOT.bin file, part of the boot process, that contains the bitstream and other hardware related information to construct the hardware system
- the executable application files; an extension of the prior application that adds the XADC data acquisition as the source of data for the FFT input table.

Building a new BOOT.bin

At the conclusion of the Tech Tip "Zynq Adding a Hardware FFT Tech Tip" the workspace contains the library of signal processing functions built in the Tech Tip "Zynq Ne10 Library Tech Tip"and tested in the Tech Tip "Zynq Ne10 Testing Tech Tip". It also has the tested application code for the FFT application including the hardware FFT. This Tech Tip is built upon that existing workspace. If you have that workspace in place,skip forward in these instruction to where the workspace is in place (Old Workspace in Place).

If the workspace is not available, or if there is an question if it was completed properly (or you simply want to skip those earlier steps), the referenced file HWfft_workspace.zip can be used to create a known working starting point for the software portion of this Tech Tip.

Download the zip file from the HWfft_workspace.zip link.

Create an empty directory where you will be implementing this Tech Tip. To be consistent with the balance of these step by step instructions, the directory could be:


However, these steps to import a known workspace will work with any new folder of the user's choosing.

Many users have unusual problems with SDK when using different directory structures or names. If you encounter any odd behaviors with SDK, it is advised to use the suggested directory structure and names.

Start SDK

Start -> All Programs -> Xilinx Design Tools -> Vivado 2013.4 -> SDK -> Xilinx SDK 2013.4

In the Workspace Launcher, browse to and select the previously created empty folder. In our case this is G:\ZC702fft\zc702-zvik-base-trd-rdf0286\sw

Click OK to continue

If you are presented with a Welcome tab, close it by clicking on the x on the tab.

SDK will start with a blank Project Explorer pane

Select File -> Import

The Import dialogue box will appear. Expand the General line and select Existing Projects into Workspace

Click Next

Click the Select archive file button. Then click Browse to navigate to the saved workspace file that you want to import and click Open. In our case this is HWfft_workspace.zip.

Click Finish

SDK will build the workspace automatically. If it does not, simply select Project -> Build All

Because SDK is now running and the workspace is in place, you can skip the following instructions on starting SDK and go directly to after SDK is running and the workspace is in place (Starting Projects Ready).

Old Workspace in Place

The first step in building our new BOOT.bin is to bring the new hardware information from Vivado into SDK. We start with the workspace that resulted from the completion of the "Zynq Building an FFT Tech Tip".

Start SDK

On Windows, select Start > All Programs > Xilinx Design Tools > ISE Design Suite 14.5 > EDK > Xilinx Software Development Kit

When the Workspace Launcher appears, be sure that it is pointed to the workspace used for the "Zynq Building an FFT Application Tech Tip".

Click OK

Starting Projects Ready

SDK should have the files and projects in place as we last saw them. If it has changed, use the known workspace from the steps above or repeat the various steps to be sure this is a tested working set of files and projects before proceeding.

The new hardware will impact the hw_platform and the synq_fsbl_bsp, both of which are used to build the zynq_fsbl, a key file in building a new BOOT.bin.

Select hw_platform in the Project Explorer pane, right click on it and select "Change Hardware Platform Specification". When the pop up box appears, read the cautions and click Yes.

Click Browse and follow the path from the $ZYNC_XADC_HOME used earlier to project/zynq_base_trd_2013.4.sdk/SDK/SDK_Export/hw

SDK will show system_top.xml as an available file.

Select system_top.xml

Click Open and then OK in the "Change Hardware Platform Specification" dialog

SDK may issue a warning about the bitstream or bmm file being different

Click Yes to allow SDK to copy the new files into the project.

The file will be read and SDK will build new hardware information from the imported xml file. If the build process does not start automatically, this indicates that the option is not set up for automatic builds. To change this, from the top menu bar select Project. If Build Automatically is not checked, then the builds will need to be done manually. For the balance of this Tech Tip, we assume that Build Automatically is NOT checked. If it is currently checked, click on it to uncheck that option.

If the Build Automatically option was not checked, that is acceptable at this point. Other steps will also build the required projects.

Expand hw_platform to verify that the import performed correctly. The files should be similar to the following. Right click on one of the files such as ps7_init.h, select Properties and verify that the time and date are correct for when they were just now imported.

Right click on zynq_fsbl_bsp in the Project Explorer pane and select Build Project.

This will re-build the hardware platform using the new hardware definition and files just imported. This is critical as it is the basis of the new zynq_fsbl built in the nest step.

The main file that is critical at this point is the zynq_fsbl (first stage boot loader). If the Build Automatically option was not checked, force SDK to build it at this point.

We want to be sure that the Release settings are used to build the new zynq_fsbl.

Righ click on the znyq_fsbl project in the Project Explorer pane. Select Build Configurations -> Set Active and then select Release.

Select zynq_fsbl in the Project Explorer pane then click "Clean Project".

When this completes, right click on zynq_fsbl again and then click "Build Project".

This build creates the zynq_fsbl.elf file. Verify that this file has been created and is new by expanding the zynq_fsbl project, then expanding the Binaries sub-directory. Right click on zynq_fsbl.elf and select properties. The information should reflect the fact that this file was just recently modified.

Click Cancel to return to SDK.

With the new zynq_fsbl in place, we can create the new boot file required to invoke the hardware interface to the XADC block of the ZC702.

Because we are starting with a workspace that was used to create a new boot image in the previous Tech Tip, some information that is retained is not beneficial to the boot image creation process for this Tech Tip. To simplify the process, we can delete the history and start fresh.

In the Project Explorer pane, expand the zynq_fsbl project, then expand the bootimage folder. Right click on the zynq_fsbl.bif file and select Delete. When the Delete Resources warning appears, click OK.

We can now create a new fresh boot image.

In the Project Explorer pane, select zynq_fsbl

A special utility that creates the new boot image can be started in at least two ways- from the top menu bar, select Xilinx Tools > Create Zynq Boot Image- with zynq_fsbl selected in Project Explorer, right click on zynq_fsbl and select "Create Boot Image" from the pop up menu

With either method, the following dialogue will appear

Because we had zynq_fsbl selected, SDK will automatically populate the fsbl.elf entry. While it is possible to use this utility with external zynq_fsbl files, we will not go into that at this point.

The output folder by default will be a sub-folder under the zynq_fsbl project. This is fine for this Tech Tip but the ouput (and the BIF file) could be written to any location on your computer if desired.

Three files are required for creation of a new boot image file:- a first stage boot loader file - zynq_fsbl.elf as already indicated above- a valid bitstream file for the target device - this was produced earlier by Vivado- a valid u-boot.elf file that will start Linux for our application to run (other u-boot.elf files are possible for stand-alone operation)

In addition, these three files MUST in the order stated above for proper boot operation!

In this example, because we had zynq_fsbl selected when the Create boot image command was invoked, SDK has automatically populated the Boot image partitions list box with the bitstream file as the first entry and the bootloader file zynq_fsbl.elf as the second file.

These two files are in the incorrect order. If the Boot image partitions list has the bitstream file l(system.bit in this case) first, it must be moved. If the Up and Down buttons to the right of the Boot image partitions list box are disabled, select the system.bit entry and click the Delete button.

We then need to add the correct bitstream file and the u-boot.bin file to complete the set.

Click the Add button and the Add partition dialogue will appear.

With the Partition type set to datafile, click Browse and navigate to the location where the bitstream from the hardware creation process was stored. In our case this is G:\XADC\project\zynq_base_trd_2013.4.sdk\SDK\SDK_Export\hw

Click on the bit file - system_top_wrapper.bit - and click Open

When the Add partition dialogue appears, click OK.

This will add the bitstream file as the second item on the list

We need to specify the u-boot.elf file as the last item for our new boot image.

We will use the u-boot.elf file supplied with the base TRD as that will properly initiate the Linux loading and setup of the balance of the system that our application code expects, This is in the boot image directory in base TRD un-zipped file structure.

If you do not have the base TRD files, a copy of the u-boot.elf file is associated with this Tech Tip. Download it and unzip it to the base directory you are using and navigate to that file in the next step.

Click Add and the Add partition diaolgue box will appear

Be sure that the Partition type dropdown list is set to datafile.

Then select Browse and navigate to the base TRD and then to the boot_image sub-directory

Select u-boot.elf and click Open

The Add partition dialogue will appear

Click OK to add the u-boot.elf file to the list

We now have the three required files in the proper order.

Click the Create Image button at the bottom of the dialogue box.

SDK will create the new boot file and store it in the bootimage directory under the zynq_fsbl project. If you get a message to override an existing file, click OK

To work properly with the ZC702, this boot file MUST be named BOOT.bin

To rename the output.bin file, right click on it in the Project Explorer pane, change the name to BOOT.bin and click OK.

With the new boot file in place, we then build the application software that adds support for the XADC hardware system.

Building the application

Recall that earlier we downloaded a zip of a set of files into a HW_XADC directory on our computer. We now use those to build the application.

Because we started with the workspace where we built the software for the "Zynq Building an FFT Application Tech Tip", we already have a fft-zynq project defined. We will now add a separate project that supports the XADC capability needed for this Tech Tip. The project has a top level set of files and two sub directories that will be imported as a complete project.

Start the File Import dialog in one of at least two ways; a) Right click on blank space in the Project Explorer window. From the pop up menu, select Import or b)From the top menu bar select File > Import

In the Import select dialogue box, expand the General category and select "Existing Projects into Workspace".

Click Next

Click the button next to Select archive file, then click Browse

Navigate to where you saved the application source files; in our case ZC702fft/HW_XADC

Select xadc_test.zip and click Open

The possible projects will be listed. If it is not already selected, click the box next to the fft_backend project in the list. The other projects are already in the workspace and are not available to select.

Be certain that the option to "Copy projects into workspace" is checked.

Click Finish to import the files

The new project will appear in the Project Explorer pane

Before building this imported project, we need to be sure the Paths and Symbols are set correctly.

Right click on the xadc_test project in the Project Explorer pane. From the pop up menu, select C/C++ Build Settings

Expand the C/C++ General category and then select Paths and Symbols.

Some paths may already be set from the process of creating this project. If the Include Directories pane has an item that begins with /standalone_bsp_2013 ... this will need to be changed. Select that item and click the Delete button on the tight side of the window. The Paths and Symbols should have the following already set. If the path is already set, skip the next step that adds this path.

If it DOES NOT include the /zynq_fsbl_bsp/ps7_cortexa9_0/include pathe, we need to add that path to reference the new hardware parameters to enable our new application software to build properly.

Click the drop down arrow for the Configurations line and select All Configurations

Click the Add button on the right side of the dialogue box

In the Add directory path dialogue box, click both of the options then click the Workspace button and expand the zynq_fsbl_bsp folder and then expand the ps7_cortexa9_0 and select the include sub directory

Click OK

Click OK again to add this path.

Click Apply

When the warning message appears regarding indexing, click Yes.

Click OK to finish adding the paths

We also need to verify that a standard library will be used in the linking process.

Right click on the xadc_test project in the Project Explorer pane. From the pop up menu, select C/C++ Build Settings

Expand the C/C++ Build category and then select Settings.

In the right pane, under ARM Linux gcc linker, click Libraries

The list of libraries should appear as below. Be sure that Release is selected in the Configuration: line

If the library m is not listed in the Libraries(-l) list box. we need to add it. To do this

Click the green plus icon at the top of the Libraries list box.

type m in the entry box and click OK

The standard library m will appear in the list as shown above.

We can now build the application software.

To be sure we are using the Release build options (for best performance), Right Click on the xadc_test project in the Project Explorer pane, then select Build Configurations -> Set Active -> Release

Right click on xadc_test and select Clean Project from the pop up menu. When that completes, right click on xadc_test and select Build Project from the pop up menu. SDK will then build the new application software.

Testing the XADC hardware system

With the new BOOT.bin and xadc_test.elf application files completed, we can test them and verify that the XADC system is capturing data properly.

The BOOT.bin file replaces one already on the SD card used to boot the ZC702. With the power to the ZC702 OFF, remove the SD card and insert it in a SD card reader or media slot on your computer. The files on the card should be at least this set

If the files are different in any way, it is wise to delete the files on the SD card and copy a new set to it before proceeding. A new set of base TRD files can be found in the un-zipped TRD in the sd_image directory as shown above. Standard Windows copy / paste can be used to copy the files to the SD card.

Once the SD card files have been checked, delete the BOOT.bin file on the SD card (or rename it to something completely different).

Locate the BOOT.bin file we just created - in SDK, expand the zynq_fsbl project then expand bootimage to reveal the recently renamed BOOT.bin. Right click on it and select copy. Or it can be found using Windows Explorer at (in our case)


Copy BOOT.bin and then paste it to the SD card.

Mount the AMS 101 card on the ZC702 as described in the user guide for the card. We will be using an external input on one of the two channels so set the jumpers as follows:- J3 - connect pins 2 and 3 to select External Input- J5 - connect pins 2 and 3 to select External Input

To exercise the fft_backend application and the corresponding XADC hardware system, we need an input source for the AMS 101 card. The input to the AMS card MUST be in the range of 0.0 to 1.0 Volts. this can be accomplished with a signal generator where the offset is at 0.5 volts and the input signal is limited to 1.0 Volts peak to peak. Before connecting to the AMS card, use an oscilloscope to verify that the input is within the range of 0.0 to 1.0 Volts.

Remove the SD card from your computer, insert it into the ZC702 and power on the ZC702.

With the input signal levels verified, connect the signal source to the AMS card on J2 as shown below. For simplicity of viewing the sampled data, a square wave offers a readily recognizable sample pattern.

Once the ZC702 has booted and the Sobel Filter demonstration is running, exit from the demo to return to Linux. We can then use Remote System Explorer to run the application. As an alternate, we could copy the xadc_test.elf application file to the SD card when we changed BOOT.bin and run it from the command line on the ZC702.

The same SDK Remote System Explorer steps as used in the previous Tech Tips can be used. They are summarized here for simplicity.

Right click on xadc_test and select Run As from the pop up menu, then select Remote ARM Linux Application. Because we have used SDK and RSE in the prior Tech Tips, all of the entries will be filled. To verify operation of the XADC hardware system, we run xadc_test.elf in a debug mode. This enables us to run it once and display the data. Verify the setup of the run configuration and then select the Arguments tab.

Enter the following in the Arguments pane:

-g 64

This will force fft_backend to execute once and display the first 64 samples of input data.

If the -g option is not specified, the XADC will be set up for continuous sampling and will not stop to display the results as expected. If this is done, it may be necessary turn off the ZC702 and start the RSE process again.

Click Apply

Click the Main tab and verify that the setup is proper.

Start the signal source and select a frequency (for this test we used ~6.5 KHz.) and an amplitude less than the maximum and select a square wave. The square wave is readily recognizable in the output data table.

Click Apply and then Click Run

RSE will launch the xadc_test application on the ZC702. The results will be displayed in the console pane. If xadc_test does not halt after one pass, try clicking the large red X at the top of the console window to cause it to halt.

Scroll back to the top of the console pane to see the beginning of the data from the XADC hardware system. Note that we see periods of reasonably consistent large positive numbers interspersed with periods of large negative numbers. Some simple math using the sample numbers will show that we have roughly equal periods of positive and negative data. This is sufficient to indicate that the XADC and associated hardware is functioning as expected. If a different waveform is supplied, similar capture of the data and analysis can be used to verify rate of rise / fall and overall period of the signal.

For an alternate method to gather some sampled data, we can switch to a RSE perspective and run the application directly from SDK using Linux commands.

Depending on how the options are set for your SDK installation, you may have a Remote System Explorer icon in the upper right corner of the SDK window. Click on that to get a RSE perspective. Otherwise, from the main menu bar select Window > Open Perspective > Other.

In the selection box, click Remote System Explorer and click OK

In the left pane, right click on Ssh Terminals and select Launch Terminal

A terminal for the ZC702 will be opened

From this terminal pane (maximize it to see the largest output stream) enter the following commands:

cd /tmp

./xadc_test.elf -g 512

This will run the fft_backend application a single time and print the first 512 samples of input data. From this pane it is possible to copy the sample data and paste it into a spreadsheet for further analysis and display.


Using the same DMA techniques as in previous Tech Tips enables us to capture sample data from the XADC block and operate on it from Linux in the PS. While the output in this Tech Tip is simply a dump of the sampled data, it is clear that this data can be the input of other processes. Most notably, we can use this input data with the FFT application in the Tech Tip "Zynq Building an FFT Application Tech Tip" and "Zynq Adding Hardware FFT Tech Tip".

The Zynq-7000 AP SoC offers a powerful combination of general purpose processing in the PS and hardware processing in the PL. This coupled with the Analog to Digital conversion capability enables a wide variety of highly integrated applications.

The use of standard building blocks with IP Integrator in Vivado enables rapid addition of hardware to the existing Zynq-7000 AP SoC platform. By using the same physical and logical connectivity as other reference designs, we can rapidly build a new system with proper control and data management between the PS and PL within the device.

© Copyright 2019 - 2022 Xilinx Inc. Privacy Policy