We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!


After five years and a dozen prototypes, the Haddington Dynamics development team behind Dexter—a $3K, trainable, 5-axis robotic arm kit for personal manufacturing—launched the project on Kickstarter just yesterday and are already 41.6% of the way to meeting the overall $100K project funding goal with 28 days left in the funding period. Dexter is designed to be a personal robot arm with the ability to make a wide variety of goods. Think of Dexter as your personal robotic factory with additive (2.5D/3D printing) and subtractive (drilling and milling) capabilities.


Dexter incorporates a 6-channel motor controller but the arm itself uses five stepper motors for positioning. Adding a gripper or other end-effector to the end of the arm adds a 6th degree of freedom.



Dexter Robotic Arm.jpg


Dexter Robotic Arm 3D CAD Drawing




You need some hefty, high-performance computation to precisely coordinate five axes of motion and the current Dexter prototype employs programmable logic in the form of a Xilinx Zynq Z-7000 SoC on an Avnet MicroZed dev board for this task. (The Kickstarter page even shows an IP block diagram from the Vivado Design Suite.)


The Dexter team calls the Zynq SoC an FPGA supercomputer:


“By using a(n) FPGA supercomputer to solve the precision control problem, we were able to optimize the physical and electrical architecture of the robot to minimize the mass and therefore the power requirements. All 5 of the stepper motors are placed at strategic locations to lower the center of mass and to statically balance the arm. This way almost all of the torque of the motors is used to move the payload not the robot.”


The prototype design achieves 50-micron repeatability!


Here’s a video of the prototype Dexter robotic arm in development, including a shot of the robotic arm threading a needle:





There are several more videos on the Dexter Kickstarter page.





Adam Taylor’s MicroZed Chronicles, Part 172: UltraZed Part 3—Saying hello world and First-Stage Boot

by Xilinx Employee ‎02-16-2017 10:55 AM - edited ‎02-16-2017 11:14 AM (43,516 Views)


By Adam Taylor


We have now built a basic Zynq UltraScale+ MPSoC hardware design for the UltraZed board in Vivado that got us up and running. We’ve also started to develop software for the cores within the Zynq UltraScale+ MPSoC’s PS (processor system). The logical next step is to generate a simple “hello world” program, which is exactly what we are going to do for one of the cores in the Zynq UltraScale+ MPSoC’s APU (Application Processing Unit).


As with the Zynq Z-7000 SoC, we need three elements to create a simple bare-metal program for the Zynq UltraScale+ MPSoC:


  • Hardware Platform Definition – This defines the underlying hardware platform configuration, address spaces, and IP modules within the design.
  • Board Support Package – This uses the hardware platform to create a hardware abstraction layer (HAL) that provides the necessary drivers for the IP within the system. We need those drivers to use these hardware resources in an application.
  • Application – This is the application we will be writing. In this case it will be a simple “hello world” program.



To create a new hardware platform definition, select:



File-> New -> Other -> Xilinx – Hardware Platform Specification



Provide a project name and select the hardware definition file, which was exported from Vivado. You can find the exported file within the SDK directory if you exported it local to the project.





Creating the Hardware platform



Once the hardware platform has been created within SDK, you will see the hardware definition file opens within the file viewer. Browsing through this file, you will see the address ranges of the Zynq UltraScale+ MPSoC’s ARM Cotex-A53 and Cortex-R5 processors and PMU (Performance Monitor Unit) cores within the design. A list of all IP within the processors’ address space appears at the very bottom of the file.





 Hardware Platform Specification in SDK file browser



We then use the information provided within the hardware platform to create a BSP for our application. We create a new application by selecting:



File -> New -> Board Support Package



Within the create BSP dialog, we can select the processor this BSP will support, the compiler to be used, and the selected OS, In this case, we’ll use bare metal or FreeRTOS.


For this first example, we will be running the “hello world” program from the APU on processor core 0. We must be sure to target the same core as we create the BSP and application if everything is to function correctly.





 Board Support Package Generation



With the BSP created, the next step is to create the application using this BSP. We can create the application in a similar manner to the BSP and hardware platform:



File -> New -> Application Project



This command opens a dialog that allows us to name the project, select the BSP, specify the processor core, and select operating system. On the first tab of the dialog, configure these settings for APU core 0, bare metal, and the BSP just created. On the second tab of the dialog box, select the pre-existing “hello world” application.  





Configuring the application





Selecting the Hello World Application



At this point, we have the application ready to run on the UltraZed dev board. We can run the application using either the debugger within SDK or we can boot the device from a non-volatile memory such as an SD card.


To boot from an SD Card, we need to first create a first-stage boot loader (FSBL). To do this, we follow the same process as we do when creating a new application. The FSBL will be based on the current hardware platform but it will have its own BSP with several specific libraries enabled.



Select File -> New -> Application Project



Enter a project name and select the core and OS to support the current build as previously done for the “hello world” application. Click the “Create New” radio button for the BSP and then on the next page, select the Zynq MP FSBL template.






Configuring the FSBL application






 Selecting the FSBL template



With the FSBL created, we now need to build all our applications to create the required ELF files for the FSBL and the application. If SDK is set to build automatically, these files will have been created following the creation of the FSBL. If not, then select:



Project -> Build All



Once this process completes, the final step is to create a boot file. The Zynq UltraScale+ MPSoC boots from a file named boot.bin, created by SDK. This file contains the FSBL, FPGA programming file, and the applications. We can create this file by hand and indeed later in this series we will be doing so to examine the more advanced options. However, for the time being we can create a boot.bin by right-clicking on the “hello world” application and selecting the “Create Boot Image” option.





 Creating the boot image from the file, from the hello world application




This will populate the “create boot image” dialog correctly with the FSBL, FPGA bit file, and our application—provided the elf files are available.





Boot Image Creation Dialog correctly populated



Once the boot file is created, copy the boot.bin onto a microSD card and insert it into the SD card holder on the UltraZed IOCC (I/O Carrier Card). The final step, before we apply power, is to set SW2 on the UltraZed card to boot from the SD Card. The setting for this is 1 = ON, 2 = OFF, 3 = ON, and 4 = OFF. Now switch on the power on, connect to a terminal window, and you will see the program start and execute.


When I booted this on my UltraZed and IOCC combination, the following appeared in my terminal window:





Hello World Running



Next week we will look a little more at the architecture of the Zynq UltraScale+ MPSoC’s PS.




Code is available on Github as always.


If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.




  • First Year E Book here
  • First Year Hardback here.




MicroZed Chronicles hardcopy.jpg




  • Second Year E Book here
  • Second Year Hardback here



MicroZed Chronicles Second Year.jpg 




Innovative Integration’s XA-160M PCIe XMC module suits applications that require high-speed data acquisition and real-time signal processing. The module provides two 16-bit TI ADC16DV160 160Msamples/sec ADCs for high-speed analog input signals and an Analog Devices AD9122 16-bit dual DAC capable of operating at 1200Msamples/sec for driving high-speed analog outputs. The ADCs and DACs are coupled to a Xilinx Artix-7 XC7A200T FPGA (that’s the largest member of the Artix-7 device family with 215,360 logic cells and 740 DSP48 slices). The FPGA also manages 1Gbyte of on-board DDR3 SDRAM and implements PCIe Gen2 x4 and Aurora interfaces for the XMC module’s P15 and P16 connectors respectively. You can use the uncommitted programmable logic on the Artic-7 FPGA for high-speed, real-time signal processing.




Innovative Integration XA-160M XMC Module.jpg


Innovative Integration’s XA-160M PCIe XMC Module




Here’s a block diagram that makes everything clear:



Innovative Integration XA-160M XMC Module Block Diagram.jpg



Innovative Integration’s XA-160M PCIe XMC Module Block Diagram




Innovative Integrations suggest that you might want to consider using the XA-160M PCIe XMC Module for:



  • Stimulus/response measurements
  • High-speed servo controls
  • Arbitrary Waveform Generation
  • Optical Servo
  • Medical Scanning



You can customize the logic implemented in the Artix-7 FPGA using VHDL and MathWorks’ MATLAB using the company’s FrameWork Logic toolset. The MATLAB BSP supports real-time, hardware-in-the- loop development using the graphical Simulink environment along with the Xilinx System Generator for DSP, which is part of the Xilinx Vivado Design Suite.


Please contact Innovative Integrations directly for more information about the XA-160M PCIe XMC Module.



The steep attenuation of 28Gbps signals on pcbs cause problems for every system designer trying to deal with high-speed serial interfaces. Samtec’s new brochure titled “Samtec Products Supporting Xilinx Virtex UltraScale+ FPGA VCU118 Development Kit” sums up the problem in just one graphic:



High-Speed Signal Attenuation.jpg 



The best you can hope for with a pcb (the dark blue line) is about half a db of attenuation per trace inch for a pcb manufactured using PTFE laminates, which were originally developed for microwave and RF applications. Up there at the top of the graph, showing far less attenuation, you see Samtec’s solution: its Twinax FireFly interconnect system, which is designed to carry these high-speed data signals within a system. (For essentially no loss, there’s a compatible optical FireFly module, shown for comparison at the very top of the graph.)


This next table, also taken from the Samtec brochure, sharpens the picture even more:




FireFly Performance Table.jpg 



As the table shows, if you are dealing with 28Gbps transceiver signals (and soon perhaps 56Gbps) and you need to go more than a very few inches, then you’ll want to consider the Samtec FireFly Micro Flyover system.


An easy way to experiment with the Samtec FireFly Micro Twinax interconnect system is to use the company’s FMC+ Active Loopback card, which is included with the Xilinx VCU118 Virtex UltraScale+ FPGA Dev Kit. Here’s a photo of that card plugged into the FMC port of the VCU118 Dev Kit:




Xilinx VCU118 Dev Kit for UltraScale Plus with Samtec FireFly Micro Flyover FMC Card.jpg


Xilinx VCU118 Virtex UltraScale+ FPGA Development Kit with Samtec FireFly Micro Flyover FMC Card




Note that one end of the FireFly Twinax cable is connected to this FMC card and the other end plugs into a FireFly connector already present on the Xilinx VCU118 Dev Kit’s FPGA board.


Samtec has a new 12-page FireFly Application Design Guide that provides more details.



For previous Xcell Daily blog posts about the Samtec FireFly interconnect system, see:




The Xilinx Zynq Z-7000 SoC makes a great high-performance embedded-Linux platform and if you’re interested in getting started down that path, there’s a free 1-hour Webinar for you on February 28. Senior Member of Technical Staff Simon Goda of Doulos will be presenting the Webinar.


Note: This Webinar will be presented twice to be more convenient for time zones around the world.


Register here.


Curtis-Wright Defense Solutions’ customer had a problem. The customer needed to develop a large radar system based on a “large number” of DSP modules interconnected with a high-speed switch. The question was, would the switch provide enough bandwidth to support the project requirements? The estimated development cost to answer this question was between $200K and $400K. The estimated time required to answer this question was four to eight weeks.


An expensive question, not to mention the potential project delay while this question was answered.


Curtiss-Wright has developed a “light-integration” capability to answer such questions for its customers, which it documented in an article titled “Meeting Performance Benchmarks Using Light System Integration for Radar Applications” and further described in a new article appearing on the Military Embedded Systems Web site titled “Reducing costs and risk while speeding development of signal processing system development.”


Getting the answer to this question involved prototyping the target radar system using six Curtiss-Wright CHAMP-AV9 DSP Processor modules interconnected through a Curtiss-Wright VPX6-1958 SBC with a dual-port 40GbE Switch along with some of the company’s CHAMP-WB (Wide-Band) OpenVPX Virtex-7 FPGA modules (with two FMC sites per module) connected to the processor modules via PCIe Gen3, and FMC I/O cards plugged onto the FMC sites on the FPGA modules. The FMC I/O cards provide sensor data directly to the FPGA modules at speed for initial high-speed processing.





Curtiss-Wright CHAMP-WB Virtex-7 FPGA Module.jpg 


CHAMP-WB (Wide-Band) OpenVPX Virtex-7 FPGA module



The light-integration team worked with the customer to develop a set of system requirements and then assembled a system, configured it, and developed the necessary firmware to run the following tests:


  1. Measure the bandwidth for communication among all processing nodes through the 40GbE switch on the SBC.
  2. Demonstrate PCIe DMA at the desired transfer rate between the Virtex-7 FPGA module and one of the processor modules.
  3. Demonstrate 1GbE connectivity throughout the system.
  4. Demonstrate SATA inter-connectivity between this system and a 3rd-party drive.



This proof of connectivity developed by the Curtiss-Wright light-integration team validated that the overall system design could accommodate the expected system data throughput and gave the customer sufficient confidence to proceed with algorithm development based on the hardware used for these tests. The hardware used in the system-level connectivity demonstration was able to provide sufficient processing for the algorithms used in the radar-system design. Algorithm development is the real added value for radar-system integrators and prime contractors.



Red Pitaya has been offering its namesake, Zynq-SoC-based, open instrumentation platform as a packaged STEMlab with analog and digital probes, power supply and enclosure. The STEMlab prices range from €249.00 to €499.00 depending on options. To support this hardware, Red Pitaya is distributing apps and the latest turns the STEMlab into a combo 40MHz digital oscilloscope and 50MHz signal generator.


Here are the scope specs:



Red Pitaya STEMlab Scope Specs.jpg



Red Pitaya STEMlab DSO Specs




And here are the signal generator specs:




Red Pitaya STEMlab Signal Generator Specs.jpg



Red Pitaya STEMlab Signal Generator Specs




For more articles about the Zynq-based Red Pitaya, see:




The Koheron SDK and Linux distribution, based on Ubuntu 16.04, allows you to prototype working instruments for the Red Pitaya Open Instrumentation Platform, which is based on a Xilinx Zynq All Programmable SoC. The Koheron SDK outputs a configuration bitstream for the Zynq SoC along with the requisite Linux drivers, ready to run under the Koheron Linux Distribution. You build the FPGA part of the Zynq SoC design by writing the code in Verilog using the Xilinx Vivado Design Suite and assembling modules using TCL.


The Koheron Web site already includes several instrumentation examples based on the Red Pitaya including an ADC/DAC exerciser, a pulse generator, an oscilloscope, and a spectrum analyzer. The Koheron blog page documents several of these designs along with many experiments designed to be conducted using the Red Pitaya board. If you’re into Python as a development environment, there’s a Koheron Python library as well.


There’s also a quick-start page on the Koheron site if you’re in a hurry.




Red Pitaya Open Instrumentation Platform small.jpg 

 The Red Pitaya Open Instrumentation Platform




For more articles about the Zynq-based Red Pitaya, see:





Last year, I wrote about a new graphical system-level design tool called Visual System Integrator that lets you “graphically describe complete, heterogeneous, high-performance, systems based on ‘Platforms’ built from processors and Xilinx All Programmable devices.” (See “Visual System Integrator enables rapid system development and integration using processors and Xilinx FPGAs.”) I always thought that definition was a bit too abstract and now there’s a short 2.5-minute video that makes the abstract a bit more concrete:





There’s an even shorter companion video that demonstrates the tool being used to create a 10GbE inline packet processing system using a Xilinx Virtex-7 FPGA as a hardware accelerator for an x86 microprocessor:






In total, you need only five minutes to get a good overview of this relatively new development tool.




By Adam Taylor


Having introduced the concept of AMP and the OpenAMP frame work in a previous blog (See Adam Taylor’s MicroZed Chronicles, Part 169: OpenAMP and Asymmetric Processing, Part 1), the easiest way to get OpenAMP up and running is to use one of the examples provided. Once we have the example up and running, we can then add our own application. Getting the example up and running before we develop our own application allows us to pipe-clean the development process.


To create the example, we are going to use PetaLinux SDK to correctly configure the PetaLinux image. We will be running PetaLinux on the Zynq SoC. As such, this blog will also serve as a good tutorial for building and using PetaLinux.


The first thing we need to do is download the PetaLinux SDK and install it on our Linux machine, if you do not have one of these, that’s not a problem. You can use a virtual machine, which is exactly what I am doing. Installing PetaLinx is very simple. You can download the installer from here and the installation guide and all of the supporting documentation is available here.


Once we have installed PetaLinux to get this example going, we are going to follow the UG1186 example and run the “echo world” example. To do this, we need to create a new PetaLinux project and then update it to support Open AMP.


When we create a new PetaLinux project, we need to provide the project a BSP (Board Support Package) reference. We can of course create our own BSP, however as I am going to be using the ZedBoard to demonstrate OpenAMP, I downloaded the ZedBoard BSP provided with the PetaLinux Installation files.


To create the new project, open a terminal window and enter the following:



petalinux-create --type project --name <desired name> -- source <path to BSP>



This command creates the project that we can then customize and build. After you create the project, change your directory to the project directory in the terminal window.


The examples we are going to be using are provided within the PetaLinux project. If you open a File Explorer window, you will find these examples under <project>/components/apps/. We plan to create new code, so this is where will be adding new applications as well.


To run these applications, we need to first make some changes to PetaLinux. The first change is to configure the kernel base address. The bare-metal application and the Linux application need to use different base addresses. The bare-metal application has a fixed base address of 0, so we need to offset the Linux base address. To do this within the terminal window in the project directory type the following command:






This command opens a dialog window that allows us to configure the Linux base address. Using the arrow keys, navigate to Subsytem AUTO Hardware Settings ---> Memory Settings and set the kernel base address to 0x10000000 as shown below. Remember to save the configuration and then navigate from the root menu to U-boot Configuration and set the netboot offset to 0x11000000. Again save the configuration before exiting and returning to the root menu.




Setting the Kernel Base Address






Setting the NetBoot Offset



The next step is to configure the kernel to ensure that it contains the remote processor and can load modules and user firmware. To do this, enter the following command in the terminal window:




petalinux-config -c kernel




This will again open a configuration dialog within which we need to set the following:





Make sure Enable Loadable Module Support is set  







Under Device Drivers --->Generic Drivers ---> set Userspace firmware loading support





Under Device Drivers --->Remoteproc drivers ensure support for the Zynq remoteproc is set



We also need to correctly configure the kernel memory space between user and kernel. Navigate to kernel features ---> Memory split (<current setting> user/kernel split) ---> and set it to 2G/2G:





Setting the User /Kernel Split



The final stage of configuring the kernel is to support high memory support:





Setting the high memory support under Kernel Features



This completes the changes we need to make to the kernel. Save the changes and exit the dialog.


The next thing we need to configure the Root File System to include the example applications. To do this, enter the following to bring up the rootfs dialog:



petalinux-config -c rootfs



Under Apps, ensure that echo_test, mat_mul_demo, and proxy_app are enabled:






Enabling the Apps



We also need to enable the OpenAMP drivers modules. These are under the Modules:




Enabling the OpenAMP drivers



With these changes made, save the changes and exit the dialog. We are nearly now almost ready to create our new PetaLinux build. But first we need to update the device tree to support OpenAMP. To do this, use File Explorer to navigate to:






Within this directory, you will find a number of files including system_top.dts and openamp-overlay.dtsi. Open the system_top.dts file and tell it to include the openamp-overlay.dtsi file by adding the line:



/include/ “openamp-overlay.dtsi”






System_top.dts configured for OpenAMP




Now we are finally ready to build PetaLinux. In the terminal window within the project directory, type:








This will create the following folders within your project directory using the built image files <project>/images/linux.


Within this file you will see a range of files. However, the key files moving forward are:



  • bit – the bit file for the PL
  • elf – the first stage boot loader
  • ub – A combined file which contains the kernel, device tree and rootfs



For this example I want to boot from the SD card so I need to create a boot.bin file. Looking in the directory you will notice one has not been provided. However, all the files we need to create one have been included.


To create a boot.bin file, enter the following using the terminal:



petalinux-package --boot --fsbl images/linux/zynq_fsbl.elf --fpga images/linux/download.bit --uboot



This command creates the boot.bin file that we will put onto our SD card along with the image.ub. Once we have these files on an SD card, connect it to the ZedBoard and boot the board.


Using a serial terminal connected to the ZedBoard, we can now run our example and see that it is running ok. Once the example boots, you need to log in. The username and password are both “root.”


Enter the following command in the terminal to run the example:


modprobe zynq_remoteproc firmware=image_echo_test







Results of running the first command




After the channel is created, you may need to press return to bring up the command prompt again. Now enter the following command:


modprobe rpmsg_user_dev_driver




Result of running the second command



Now it is time to run the application itself. Enter the following:








Start of the Echo Test application



Select option 1 and the test will run to completion. You can exit the application by selecting 2:





Successful test of the example application




At this point, we have successfully demonstrated that OpenAMP is running on the Zynq SoC. (We will look at the Zynq UltraScale+ MPSoC in due course.)


Now we are ready to start developing our own applications using OpenAMP.




Code is available on Github as always.


If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.




  • First Year E Book here
  • First Year Hardback here.



MicroZed Chronicles hardcopy.jpg 




  • Second Year E Book here
  • Second Year Hardback here



 MicroZed Chronicles Second Year.jpg



About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.