Don't have a Xilinx account yet?

  • Choose to receive important news and product information
  • Gain access to special content
  • Personalize your web experience on

Create Account



Forgot your password?
XClose Panel
Xilinx Home

Keysight has been developing network analyzers for more than 50 years and the company’s newest, the M937XA PXI Vector Network Analyzer (VNA), recently won a DesignCon 2015 Best in Design & Test Award in the RF/Microwave Test category. Unlike the big network analyzer boxes from half a century ago, the Keysight PXI VNA is the size of a “piece of toast.” Yet it’s a full two-port vector network analyzer that offers the same test capabilities of the company’s larger analyzers. It just happens to fit in one PXI slot.


The primary use for VNAs is for high-volume testing of RF components—filters, power amps, RF modules—bound for all sorts of communications gear. Here, high volume means tens of millions of components per month. The strong need for high-speed testing and small test-floor footprint in this market drove the Keysight PXI VNA’s product definition. It’s 17x faster, significantly smaller, and much lighter than the company’s venerable 8753ES Network Analyzer, which weighed in at 21kg or 46 pounds.


Actually, the Keysight PXI VNA is not one unit; it’s six. The six members of the Keysight PXI VNA family cover six frequency ranges from 300kHz-4GHz to 300kHz-26.5GHz. This product range allows customers to purchase only the capability needed immediately.



Keysight PXI VNA.jpg 


The six members of the Keysight PXI Vector Network Analyzer family



Test customers working on commercial communications systems may only need a top-end frequency of 4GHz. Aerospace and defense test applications tend to need analyzers with higher top-end capabilities. Other applications fall somewhere in between. The Keysight M937XA PXI VNAs are designed to allow field upgrades. The top-end frequency can be boosted after purchase by replacing an instrument’s RF board if needs arise. (As an added bonus, the front-panel connectors are easily replaced if damaged on the test floor, which virtually eliminates costly down time.)



RF component manufacturers are trending towards the use of multi-site testers with the ability to test 8 or 16 units simultaneously. The PXIe module form factor is ideal for shrinking the size of the test equipment to fit in small test-floor footprints and PCIe modularity is well suited to the needs of customers for developing flexible, multi-site test systems. Each of the Keysight PXI VNAs is a 2-port analyzer. Plugging 16 of these PXI VNAs into the PXIe hybrid slots of a Keysight M9018A PXI chassis produces a 32-port analyzer capable of testing multiple units simultaneously. Similarly, some devices may need significantly more than two ports for a complete test. Plugging multiple PXI VNAs into a PXI chassis allows the test engineer to create a large, multiport analyzer as shown below:




Keysight PXI VNA multiport configuration.jpg



Eight Keysight PXI Vector Network Analyzers in a multiport test configuration




Keysight uses two Xilinx Spartan-6 FPGAs in each PXI VNA. The product design is based on a 2-board set: an RF board and a carrier board. The RF board contains the analog RF components as you’d expect. A Spartan-6 FPGA on the RF board controls the board’s operation, acquires data from the RF front end, performs the required DSP signal processing, and sends the processed data to the carrier board. The FPGA on the carrier board buffers the data and implements the PXIe communications protocol, based on a PLDA EZDMA PCIe and DMA controller IP block. The two FPGAs on the RF and carrier boards communicate over a unidirectional, 40Mbps SPI interface—which carries the captured and processed data—and a bidirectional, 20Mbps SPI interface for instrument command and control.





Xilinx 16nm UltraScale+ Devices Yield 2-5X Performance/Watt Advantage

by Xilinx Employee ‎03-04-2015 11:02 AM - edited ‎03-04-2015 11:03 AM (124 Views)

(Excerpted from the latest issue of Xcell Journal)UltraScale+ System Performance Improvement.jpg



Xilinx has just unveiled its 16nm UltraScale+ lineup. The device portfolio will enable customers to build systems with a 2X to 5X performance-per-watt advantage over comparable systems designed with Xilinx’s 28nm devices. These performance/watt advantages rest on three main pillars: device implementation in TSMC’s 16FF+ (16nm FinFET Plus) process, Xilinx’s on-chip UltraRAM memory and an innovative system-level interconnect-optimization technology called SmartConnect. In addition, Xilinx has also unwrapped its second-generation Zynq All Programmable SoC. The Zynq UltraScale+ Multiprocessing SoC (MPSoC) features on a single device a quad-core 64-bit ARM Cortex-A53 application processor, a 32-bit ARM Cortex-R5 real-time processer and an ARM Mali-400MP graphics processor, along with 16nm FPGA logic (with UltraRAM), a host of peripherals, security and reliability features, and an innovative power control technology. The new Zynq UltraScale+ MPSoC gives users what they need to create systems with a 5X performance/watt advantage over systems designed with the 28nm Zynq SoC.


Mark Moran, director of new product introduction and solution marketing, said that Xilinx decided to begin its UltraScale rollout with 20nm in 2013. “We implemented a lot of architectural changes in 20nm that we knew we could build on for 16nm to add an extra level of performance and value for markets that need it.” Many of the Virtex UltraScale+ devices will be pin-compatible with the 20nm Virtex UltraScale devices, making it easy to trade up for designs that require the extra performance/watt benefits. From a tools perspective, the 20nm UltraScale and 16nm UltraScale+ devices look almost identical.


Many UltraScale+ designs will gain an additional performance/watt improvement vs. 28nm from a new, large on-chip memory called UltraRAM. Xilinx is adding the UltraRAM to most of the UltraScale+ devices.


There is a growing chasm between the on-chip memory you have, such as LUT RAM or distributed RAM and Block RAM, and the memory you have off-chip, such as DDR or off-chip SRAM. If you put memory off the chip, it adds to power consumption, complicates I/O and adds to BOM cost. UltraRAM adds another level of memory hierarchy on-chip, along with the ability to easily implement large blocks of memory into the design.


The Zynq UltraScale+ MPSoC also features a number of on-chip memory enhancements. The largest devices in the product family will include UltraRAM in addition to Block RAM in the programmable logic. The Zynq UltraScale+ MPSoC also features a wider, 72-bit DDR interface core with ECC (64 bits plus 8 bits for ECC). The interface boasts speeds of up to 2,400 Mbps for DDR4, with support for larger-memory-depth DRAM capacity of 32 Gbytes.

A dedicated security unit on the Zynq UltraScale+ MPSoC enables military-class security such as secure boot, key and vault management, and anti-tamper capabilities—all standard requirements for machine-to-machine communication and connected control applications. An extremely flexible dedicated power-management unit (PMU) enables users to control power domains and islands (coarse and fine-grained) to power only those processing units the system is using.


Thanks to all of these processing features added to the 16nm performance/watt features discussed above, designs built with the Zynq UltraScale+ MPSoC will enjoy on average a 5X performance/watt advantage over designs implemented with the 28nm Zynq SoC.


Early customer engagements are in process for all of the UltraScale+ families. Xilinx has scheduled first tapeouts and early-access release of the design tools for the second calendar quarter of 2015. The company expects to begin shipping UltraScale+ devices to customers in the fourth calendar quarter of 2015.




Note: This blog is an excerpt. To read the full article by Mike Santarini on the UltraScale+ announcement, click here.



Latest issue of Xcell Journal now available

by Xilinx Employee on ‎03-04-2015 09:20 AM (163 Views)

The eagerly anticipated latest issue of the Xilinx Xcell Journal is now online and available. In addition to the cover story on the introduction of the three new Xilinx 16nm UltraScale+ All Programmable device families, this issue includes in-depth articles about:


  • The Solar Orbiter
  • 60G Millimeter-Wave Backhaul
  • Data Center Security
  • The Zynq SoC (two articles)
  • PetaLinux
  • Algorithm Refactoring


Along with announcements from Xilinx and its Alliance Program members.


Click here for more info.


My regular Google search on the term “Zynq” turned up this gem of a blog post: “Zynq AMP: Linux on CPU0 and bare metal on CPU1.” Blog author Henry Choi appears to have a lot of experience with multi-processor systems and he’s now blogging about his work with the Zynq-based ZedBoard. Choi writes, “I set a goal to investigate ways to integrate all computing that I've ever done in an expensive (I've never worked on something that sold for less than $100K--actually more like $500K) hardware into an SoC.”


“When I studied xapp 1079 (Simple AMP: Bare-Metal System Running on Both Cortex-A9 Processors), I had trouble thoroughly understanding its companion reference app xapp 1078 (Simple AMP Running Linux and Bare-Metal System on Both Zynq SoC Processors), in which the app on CPU1 is kicked off from Linux running on CPU0. But my half-year long detour through the various Linux subsystems just paid off serendipitously, because I found a Linux kernel module that may obviate the need for xapp 1078 altogether…”


What follows is a lot of hard-won, valuable development advice. If you’re developing AMP systems based on the Xilinx Zynq SoC, this blog is worth a read.

Here’s a slick Zynq-based SOM (system on module) introduced last week at Embedded World in Nuremberg: the DAVE Embedded Systems BORA Xpress. On top, you see what you might expect: a Zynq All Programmable SoC (either a Z-7015 or a Z-7030), 512Mbytes or 1Gbyte of DDR3-533 SDRAM, as much as 16Mbytes of bootable NOR Flash, and as much as 512Mbytes of NAND Flash. On the bottom, you’ll find a lot of inter-system connectivity in the form of three 140-pin connectors. Here’s a composite photo of the top and bottom of the 85x50mm BORA Xpress SOM:



DAVE Embedded Systems BORA Xpress Zynq SOM.jpg



And here’s a block diagram of the BORA Xpress SOM that details all of its I/O capabilities. (The three dark rectangles on the periphery are the 140-pin I/O connectors):



DAVE Embedded Systems BORA Xpress Zynq SOM Block Diagram.jpg



DAVE Embedded Systems says that the BORA Xpress SOM is designed for harsh mechanical and thermal environments. The SOM is available in commercial (0°C to 70°C) and industrial (-40°C to 85°C) temp ranges.

Back on November 18th, ZTE announced that the company successfully completed pre-commercial field testing of the world's first pre5G 3D/Massive MIMO (Multiple-Input Multiple-Output) base stations in partnership with China Mobile. Tests showed the 64-port/128-antenna base station provides excellent coverage enhancement in complicated multi-path urban environments, indoor areas, and open rural spaces as well—further demonstrating the technology’s superiority of the over existing intelligent antennas. Dr. Xiang Jiying, CTO of ZTE’s Wireless Division, said “As the number of antennas is ten times more, 3D/Massive MIMO had appeared to be a distant pipe-dream. However, the test indicates that we are taking a big step forward to realize the new technology using 4G handsets. This is a result of a number of innovations, and is in line with the pre5G concept previously proposed by ZTE. We will continue to deliver Pre5G features to offer 5G-like experience before 5G standardization.”


Today, Xilinx announced that ZTE's pre5G 3D/massive MIMO base station is based on the company’s Kintex-7 All Programmable FPGAs, used in conjunction with ZTE's high-performance vector processor SoCs. "Together, our pre5G multi-user/multi-stream spatial multiplexing technology and Xilinx-7 series FPGAs are enabling our base station to set new records in single-carrier transmission capacity and spectral efficiency," said Dr. Xiang.




Free one hour video tutorial on CloudRANs (CRANs) and Fronthauling. Watch now!

by Xilinx Employee ‎03-03-2015 08:08 AM - edited ‎03-03-2015 08:13 AM (149 Views)

If you’re involved with the design of cellular systems you’ve at least heard of CloudRANs (CRANs) and Fronthauling, the technologies you need to make better, more cost-effective use of widely distributed processing power. Raghu Rao, Xilinx Principal Architect of Wireless Communications, put together a tutorial on the topic, which he presented live. Now he’s put the tutorial on video and you can watch it for free. No registration needed. The video appears below:





How many SerDes ports do the 11 members of the Zynq UltraScale+ MPSoC family have?

by Xilinx Employee ‎03-02-2015 03:37 PM - edited ‎03-02-2015 03:49 PM (442 Views)

Increasing use of high-speed serial interconnect in high-performance systems means that you’ll find a lot of multi-Gbps serial ports in the 11 members of the Zynq UltraScale+ MPSoC family. How many? I went to look in the Zynq UltraScale+ MPSoC Product Selection Guide and didn’t immediately find the numbers. It turns out, they’re in the packaging specs (because the number depends on the package).


That’s logical enough, but thinking like a system designer I wanted to pivot the data to let me see how many SerDes ports and of what type each Zynq UltraScale+ MPSoC family member has. So I created this handy table with the 11 Zynq UltraScale+ MPSoC members listed in the first column. The second column tells you how many 6Gbps GTR ports there are associated with the Zynq UltraScale+ MPSoC’s PS (processor system). That number’s always four. The next two columns tell you how many 16.3Gbps GTH ports and how many 32.75Gbps GTY ports you’ll find in each family member’s PL (programmable logic) area. Where there’s a range shown, the number depends on package size.



 Number of SerDes Ports on Zynq UltraScale+ MPSoCs.jpg


Xilinx Zynq UltraScale+ MPSoC SerDes Ports



I hope this chart simplifies your selection process.

Get the 3-minute explanation of the new 16nm Xilinx Zynq UltraScale+ MPSoC from Embedded World

by Xilinx Employee ‎03-02-2015 11:03 AM - edited ‎03-02-2015 11:04 AM (472 Views)

Last week, Xilinx announced three new UltraScale+ device families based on TSMC’s 16FF+ FinFET process technology. One of those consists of the 11 members in the Xilinx Zynq UltraScale+ MPSoC family. All eleven devices in this family incorporate a 1.3GHz quad-core ARM Cortex-A53 MPCore 64-bit application processor, a 600MHz dual-core ARM Cortex-R5 32-bit real-time processor, a Mali-400MP GPU, SDRAM control, a boatload of standard peripheral devices, and big chunks of UltraScale+ programmable logic including multiple Mbits or tens of Mbits of on-chip SRAM and hundreds or thousands of DSP48 slices.


It can take a while to assimilate these features in the Zynq UltraScale+ MPSoC Product Selection Guide, so here’s a 3-minute video from ARM shot at last week’s Embedded World in Nuremberg, Germany that explains the highlights of the family and the applications that might best use such devices.




By Adam Taylor


The previous blog post in this series introduced the basic Vivado timing constraints that define the operating frequency or frequencies of your design’s clock(s). The next step towards establishing good timing constraints consists of defining the relationships between clock paths. We do this so that vivado can determine if it needs to analyze these paths or if the timing relationships between clock paths can be discounted because there is no valid timing relationship between them. By default, Vivado analyzes all inter-signal timing relationships. However, not all clocks within a design will have a timing relationship that Vivado can accurately analyze. For example, the phase relationship between asynchronous clocks cannot be accurately determined—by definition—because they’re asynchronous.

We manage timing relationships between clock paths within Vivado using the constraints file and by declaring clock groups. Vivado performs no timing analysis among clocks contained within a declared clock group.



MegaBEE Logo.jpgThe “M”s in MIMO stand for “multiple” but a MIMO antenna array with 256x256 antennas is “massive” in anyone’s book. Prototyping large 5G MIMO systems is going to be a challenge—one that the Zynq-based MegaBEE prototyping platform from BEEcube intends to simplify. The Xilinx Zynq SoC's dual-core ARM Cortex-A9 MPCore processor runs a Linux cluster architecture unique in the 5G prototyping space. The MegaBEE has built-in capabilities for 8x8 MIMO applications with easy scalability to 16x16, 32x32, 64x64, 128x128, or 256x256 MIMO antenna configurations using the MegaBEE platform’s integrated RF chains, filters, and power amps. The platform also incorporates 4000 DSP48 slices and multiple 10GE ports provided by Xilinx Virtex-7 FPGAs with on-board DDR3 SDRAM for storing real-time 5G test vectors.


“The MegaBEE platform delivers all the required elements for 5G massive MIMO prototyping in one box,” says BEEcube founder and CEO Chen Chang. The MegaBEE platform's clocking structure allows antenna modules to be dispersed over a three mile radius while maintaining phase coherence, enabling the system to be used for developing prototype systems using distributed MIMO as well as massive MIMO.

Acromag’s XMC-7K family of XMC modules based on Xilinx Kintex-7 FPGAs deliver configurable and reconfigurable, high-performance processing capability for aerospace, defense, and other COTs systems. Build options include the choice of a Xilinx Kintex-7 XC7K325T or XC7K410T FPGA device with 326,080 logic cells and 840 DSP48E1 slices or 406,720 logic cells and 1540 DSP48E1 slices respectively. The boards also incorporate 8Gbytes of DDR3 SDRAM in a 64-bit-wide configuration and 64Mbytes of 16-bit parallel flash memory for MicroBlaze soft processor program/data storage or other non-volatile storage needs.





Help for Zynq system developers: A whole page of new training videos

by Xilinx Employee ‎02-25-2015 02:36 PM - edited ‎02-25-2015 02:37 PM (723 Views)

The Xilinx Zynq SoC fuses a dual-core ARM Cortex-A9 MPCore processing system with a nice chunk of Xilinx programmable logic. That’s another way of saying that the Zynq SoC is a complex device. Some designers have asked for more help in using the Zynq SoC.


We hear you.


Now, there’s a new Web page loaded with hours of Zynq tutorials and training videos to help you start your design faster and finish it faster. Topics cover both hardware and software.


Where is it? Click here.



System interconnect is a big deal. That deal grows bigger as the system grows more complex—with complex blocks of logic tied together with increasingly complex interconnect. As FPGAs have grown larger—large enough to consume the entirety of a system—so has interconnect complexity. In simple systems, direct point-to-point connections make obvious sense. In larger systems, buses (which look like giant multiplexing systems when they’re on-chip) make more sense. When systems become even more complex, you may need a crossbar interconnect. Finally, really complex systems may need on-chip networks to provide system interconnect with the required bandwidth and latency. How do you pick one over the other? Can’t we just automate this?


You can use a Xilinx Zynq-7000 SoC to implement a complete wireless backhaul network node, as demonstrated in the reference design found in the new 31-page Xilinx White Paper WP457 “Integrated Single System-on-a-Chip Mobile Backhaul for Small-Cell Deployments.”


One Zynq-7000 device can:


  • Run the application software on the Zynq SoC’s dual-core ARM Cortex-A9 MPCore processor.
  • Implement the backhaul functionality—including timing and synchronization, packet switching, and the wireless modem—using the Zynq SoC’s Programmable Logic (PL).
  • Implement the required interfaces, including 1 GbE and 10 GbE MAC/PCS interfaces, and interfaces to ADCs and DACs using JESD204B or LVDS using the Zynq SoC’s SerDes and programmable I/O ports.


Here’s a block diagram of the design:



Zynq Backhaul Modem Reference Design.jpg



And here’s a diagram from the White Paper showing you how the wireless backhaul tasks are distributed to the on-chip ARM Cortex-A9 processor cores and the programmable logic:



Zynq Backhaul Modem Task Distribution.jpg


The White Paper covers many details including the design of an E-band Modem reference design. Download it here.

Kevin Morris, President at TechFocus Media, regularly discusses FPGA-related topics at One could easily say he’s one of the industry’s most authoritative voices when it comes to programmable logic as well as EDA. Here are seven significant quotes from Kevin Morris’ article “Xilinx Throws Down,” which dissects this week’s 16nm UltraScale+ All Programmable device announcements from Xilinx:


“This is one of the broadest, most complex announcements we have ever heard from Xilinx.”


“…the families Xilinx is announcing will have more than a typical one-node improvement in performance, power, and density - based on the new process alone. That’s a big deal.”


“The company has done some significant innovation in the areas of architecture, packaging, tools, and IP that give us considerably more boost than Moore’s Law alone.”


“…Vivado has had a few years to mature and get into fighting trim, and it played a major role in the development of the architecture for the latest devices. As a result, the UltraScale and UltraScale+ families are significantly better than their predecessors in terms of overall routability and utilization. If you’re accustomed to sizing your FPGA based on a 60-70% utilization, you’ll be pleasantly surprised with the 90%+ results many teams are finding with these newly re-architected devices.”


“Considering the size and complexity of the target applications for these devices, UltraRAM will likely come in extremely handy in many designs, and it is likely to improve the system performance, reduce latency, reduce power consumption, and significantly reduce BOM cost and board complexity when compared with external memory.”


“Clearly, this perfect storm of process scaling, 3D transistor improvement, architectural improvement, packaging technology advances, and design tool progress will give us the largest single leap forward in FPGA technology and capability we’ve ever seen.”


“Zynq got such a massive upgrade, it almost needs a new name.”





This week at Embedded World in Nuremberg, Xylon is showing its latest version of a Zynq-based Automotive Driver assistance Kit, the logiADAK Version 3.0, which can combine live video streams from four video cameras to produce a smooth, 360-degree, real-time surround view with 3D and birds-eye viewing modes. The system stitches video streams from four cameras to create the surround view and the system can accommodate a fifth camera dedicated to pedestrian detection or in-cabin face detection and tracking.


The surround view can be used for a variety of automotive applications including lane-departure and blind-spot detection. These applications require intensive real-time video processing, parallel execution of multiple complex algorithms, and flexible interfacing with sensors and the vehicle’s communication backbones. The Xilinx Zynq SoC provides the needed processing, programmable hardware, and I/O capabilities.


Stitching a seamless 360-degree, surround view from four independent video streams requires system calibration and the logiADAK Version 3.0 kit includes a logiOWL Vehicle Self Calibration application that accomplishes multi-camera calibration in as little as 10 seconds using four calibration targets set on the pavement near the vehicle’s four corners:



logiADAK Surround View Calibration Diagram.jpg



The resulting bird’s-eye, surround-view image looks like this:




 logiADAK Birds Eye View.jpg



The latest version of the Vivado Design Suite, version 2014.4.1, incorporates updates for the now-in-production Xilinx Kintex UltraScale XCKU040 All Programmable device. If you’re using that device in your latest designs, you’ll want to download the update, here.



The Xilinx Zynq UltraScale+ MPSoC family: No such thing as too much processing power

by Xilinx Employee ‎02-24-2015 10:49 AM - edited ‎02-24-2015 11:11 AM (1,990 Views)

For many embedded systems, there’s no such thing as too much processing power. The new 11-member Xilinx Zynq UltraScale+ MPSoC device family introduced earlier this week brings the needed processing power to the table with “the right engines for the right tasks.” Here’s a block diagram showing all of the components available in the Xilinx Zynq UltraScale+ MPSoC family:



Xilinx Zynq UltraScale+ MPSoC Block Diagram.jpg 



Dual-ported BRAMs (aka block RAMs) first appeared in the original Xilinx Virtex FPGAs way, way back in 1998. (Yes, that’s so last millennium.) That’s “Virtex” without a numeric suffix—as in the very first Virtex parts. These original Virtex BRAMs (called Block SelectRAMs back then) had a capacity of 4096 bits. That might not seem very big today but it was a heck of a lot bigger than the pre-existing 16-bit LUT RAMs (originally dubbed Select-RAMs) introduced in the even older Xilinx XC4000 series. BRAM capacity jumped to 18Kbits with the introduction of the Xilinx Virtex II FPGA family two years later. And that’s where BRAM capacity stayed until this week with the introduction of UltraRAM in the new Xilinx UltraScale+ All Programmable device families. UltraRAMs in the new Xilinx 16nm UltraScale+ All Programmable device families have a capacity of 288Kbits, each. (That’s a 16x capacity increase per RAM block, in case you were wondering.)



Xilinx UltraScale+ UltraRAM.jpg



Xilinx introduced 24 new devices in three UltraScale+ 16nm device families today and they’re chock full of new ingredients. Xcell Daily will be shining the light on many of these new ingredients over the next several days but if you wanted an overview at the 1m (3-foot) level, here’s a shot of the back of the UltraScale+ chocolate bar distributed today at Xilinx HQ in San Jose.



Xilinx UltraScale+ Chocolate Bar Back Side.jpg


The ingredients are listed:


  • UltraRAM
  • 3D-on-3D
  • SmartConnect
  • Heterogeneous multi-processing SoC technologies including 64-bit quad core ARM Cortex-A53 processor, dual-core ARM Cortex-R5 real-time processor
  • ARM MALI 400MP dedicated GPU (graphics processor)
  • 265 Video Codec
  • Support for DisplayPort, MIPI, and HDMI
  • Dedicated PMU (power management unit)
  • Xilinx All Programmable Flavor





For more information about today’s UltraScale+ announcement, see:


UltraScale architecture + TSMC’s 16FF+ process = 16nm UltraScale+ All Programmable Devices (24 new devices)


Charlie and the FinFET Factory: UltraScale+, the chocolate edition






By Adam Taylor



Having introduced the basics of constraints within Vivado in my most recent blog posts, this post will focus upon timing constraints.


At the most basic level within an FPGA, we use a clock to provide a regular timing reference upon which to transmit and receive data. If we were to analyze this by hand we would need to consider the clock period, set up (Tsu) and hold (Thd) times, and the clock-to-output (TclkQ) time to ensure that our design violates none of these times:







We can check for timing violations by hand for a single register. However, as we implement complex designs within FPGAs containing millions of flip flops and complex, non-ideal clock trees, accounting for skew and jitter must be automated by the EDA tool—in this case the Vivado Design Suite; there are just too many things to check by hand.


The world got a surprise today when Xilinx introduced 24 new devices in three new 16nm UltraScale+ All Programmable device families (Virtex UltraScale+, Kintex UltraScale+, and Zynq UltraScale+ MPSoCs) based on TSMC’s 16FF+ process technology. Xilinx employees got a sweet surprise when they arrived at work today and found ginormous UltraScale+ chocolate bars left on their desks during the weekend.



Xilinx UltraScale+ Chocolate Bar.jpg



Sweet! I guess this makes 25 new devices.


Today, Xilinx simultaneously rolled out three families of 16nm UltraScale+ All Programmable devices based on TSMC’s new 16FF+ FinFET process technology. The three new 16nm UltraScale+ families with 24 new devices are:



Each family targets different sets of system-design goals.


Adam Taylor’s MicroZed Chronicles Part 69: Zynq SoC Constraints Overview

by Xilinx Employee ‎02-17-2015 03:02 PM - edited ‎02-17-2015 03:05 PM (1,035 Views)


By Adam Taylor


So far we have looked considerably at the PL (programmable logic) and PS (processor system) side of the Zynq SoC device family. One area we have mentioned but not focused upon is constraints. Constraints allow you to relay additional information about your specific design and its implementation to the synthesis and implementation tools. Perhaps the simplest constraint examples are the setting the operating clock frequency and the pin allocation. Another type of constraint allows you to precisely set the location of a logic block in a Xilinx All Programmable device like the Zynq SoC.






AXI DMA Leaf Cells coloured pink from the previous example.




Constraints can be split into two categories: those used during synthesis and implementation—timing constraints, for instance—and those used exclusively for implementation—pin placement, for example.


The constraints we will use within Vivado are based upon the industry-standard SDC or Synopsis Design Constraints format with additional Xilinx-specific constraints to specify implementation details. Because this is a Xilinx specific constraint’s file, the file prefix is XDC and not SDC.


When we declare our constraints we must do so in the following order:


  • Timing constraints—the timing relationships required for correct operation
  • Timing Exceptions—having first defined the timing relationships, we then define any exceptions to those constraints, if these exceptions exist (e.g. for multi cycle paths). Note that we cannot define an exception unless we first describe what the norm is.
  • Implementation constraints—constraints used in the design’s placement and routing. These constraints help to achieve the desired results (e.g. pin out and location constraints).

As we can (and in most cases will) have multiple constraints files within a design, best practice splits the constraints into two files—one with timing constraints and another with implementation constraints.


For both constraint files, the default setting is apply the constraints to both synthesis and implementation. However it is possible to set the file to be read in before synthesis and used for both synthesis and implementation or just for implementation. You designate which you want by selecting the source file properties and checking the desired box or boxes, as shown below.






The Xilinx Vivado design flow is built around the use of IP. IP modules from the IP library often come with relevant constraints files as well. With several different user and auto-generated constraint files, it stands to reason that we need to understand constraint file prioritization how to change the file priorities.


By default, user-generated constraints files are applied before constraints in generated IP files. However, it is possible to change the order in which these constraints are read. This is similar to the setting of the Used In Synthesis or Implementation option. We can select the processing order on the properties tab of the constraints source. Priorities can be:


  • First: These constraints are to be read in first before others
  • Default: These are to be read in during the normal sequence
  • Last: These are to be read in last after all other







We will look more at how we create and verify constraints over the next few blogs in this series. In the next blog, we will look a little more at the first constraint group: timing constraints, what they mean, and how we can create them using Vivado.


You can access the article archive of the MicroZed chronicles here




Please see the previous entries in this MicroZed Chronicles series by Adam Taylor:


Adam Taylor’s MicroZed Chronicles Part 68: AXI DMA Part 3, the Software


Adam Taylor’s MicroZed Chronicles Part 67: AXI DMA II


Adam Taylor’s MicroZed Chronicles Part 66: AXI DMA


Adam Taylor’s MicroZed Chronicles Part 65: Profiling Zynq Applications II


Adam Taylor’s MicroZed Chronicles Part 64: Profiling Zynq Applications


Adam Taylor’s MicroZed Chronicles Part 63: Debugging Zynq Applications


Adam Taylor’s MicroZed Chronicles Part 62: Answers to a question on the Zynq XADC


Adam Taylor’s MicroZed Chronicles Part 61: PicoBlaze Part Six


Adam Taylor’s MicroZed Chronicles Part 60: The Zynq and the PicoBlaze Part 5—controlling a CCD


Adam Taylor’s MicroZed Chronicles Part 59: The Zynq and the PicoBlaze Part 4


Adam Taylor’s MicroZed Chronicles Part 58: The Zynq and the PicoBlaze Part 3


Adam Taylor’s MicroZed Chronicles Part 57: The Zynq and the PicoBlaze Part Two


Adam Taylor’s MicroZed Chronicles Part 56: The Zynq and the PicoBlaze


Adam Taylor’s MicroZed Chronicles Part 55: Linux on the Zynq SoC


Adam Taylor’s MicroZed Chronicles Part 54: Peta Linux SDK for the Zynq SoC


Adam Taylor’s MicroZed Chronicles Part 53: Linux and SMP


Adam Taylor’s MicroZed Chronicles Part 52: One year and 151,000 views later. Big, Big Bonus PDF!


Adam Taylor’s MicroZed Chronicles Part 51: Interrupts and AMP


Adam Taylor’s MicroZed Chronicles Part 50: AMP and the Zynq SoC’s OCM (On-Chip Memory)


Adam Taylor’s MicroZed Chronicles Part 49: Using the Zynq SoC’s On-Chip Memory for AMP Communications


Adam Taylor’s MicroZed Chronicles Part 48: Bare-Metal AMP (Asymmetric Multiprocessing)


Adam Taylor’s MicroZed Chronicles Part 47: AMP—Asymmetric Multiprocessing on the Zynq SoC


Adam Taylor’s MicroZed Chronicles Part 46: Using both of the Zynq SoC’s ARM Cortex-A9 Cores


Adam Taylor’s MicroZed Chronicles Part 44: MicroZed Operating Systems—FreeRTOS


Adam Taylor’s MicroZed Chronicles Part 43: XADC Alarms and Interrupts 


Adam Taylor’s MicroZed Chronicles MicroZed Part 42: MicroZed Operating Systems Part 4


Adam Taylor’s MicroZed Chronicles MicroZed Part 41: MicroZed Operating Systems Part 3


Adam Taylor’s MicroZed Chronicles MicroZed Part 40: MicroZed Operating Systems Part Two


Adam Taylor’s MicroZed Chronicles MicroZed Part 39: MicroZed Operating Systems Part One


Adam Taylor’s MicroZed Chronicles MicroZed Part 38 – Answering a question on Interrupts


Adam Taylor’s MicroZed Chronicles Part 37: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 8


Adam Taylor’s MicroZed Chronicles Part 36: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 7


Adam Taylor’s MicroZed Chronicles Part 35: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 6


Adam Taylor’s MicroZed Chronicles Part 34: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 5


Adam Taylor’s MicroZed Chronicles Part 33: Driving Adafruit RGB NeoPixel LED arrays with the Zynq SoC


Adam Taylor’s MicroZed Chronicles Part 32: Driving Adafruit RGB NeoPixel LED arrays


Adam Taylor’s MicroZed Chronicles Part 31: Systems of Modules, Driving RGB NeoPixel LED arrays


 Adam Taylor’s MicroZed Chronicles Part 30: The MicroZed I/O Carrier Card


Zynq DMA Part Two – Adam Taylor’s MicroZed Chronicles Part 29


The Zynq PS/PL, Part Eight: Zynq DMA – Adam Taylor’s MicroZed Chronicles Part 28  


The Zynq PS/PL, Part Seven: Adam Taylor’s MicroZed Chronicles Part 27


The Zynq PS/PL, Part Six: Adam Taylor’s MicroZed Chronicles Part 26


The Zynq PS/PL, Part Five: Adam Taylor’s MicroZed Chronicles Part 25


The Zynq PS/PL, Part Four: Adam Taylor’s MicroZed Chronicles Part 24


The Zynq PS/PL, Part Three: Adam Taylor’s MicroZed Chronicles Part 23


The Zynq PS/PL, Part Two: Adam Taylor’s MicroZed Chronicles Part 22


The Zynq PS/PL, Part One: Adam Taylor’s MicroZed Chronicles Part 21


Introduction to the Zynq Triple Timer Counter Part Four: Adam Taylor’s MicroZed Chronicles Part 20


Introduction to the Zynq Triple Timer Counter Part Three: Adam Taylor’s MicroZed Chronicles Part 19


Introduction to the Zynq Triple Timer Counter Part Two: Adam Taylor’s MicroZed Chronicles Part 18


Introduction to the Zynq Triple Timer Counter Part One: Adam Taylor’s MicroZed Chronicles Part 17


The Zynq SoC’s Private Watchdog: Adam Taylor’s MicroZed Chronicles Part 16


Implementing the Zynq SoC’s Private Timer: Adam Taylor’s MicroZed Chronicles Part 15


MicroZed Timers, Clocks and Watchdogs: Adam Taylor’s MicroZed Chronicles Part 14


More About MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 13


MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 12


Using the MicroZed Button for Input: Adam Taylor’s MicroZed Chronicles Part 11


Driving the Zynq SoC's GPIO: Adam Taylor’s MicroZed Chronicles Part 10


Meet the Zynq MIO: Adam Taylor’s MicroZed Chronicles Part 9


MicroZed XADC Software: Adam Taylor’s MicroZed Chronicles Part 8


Getting the XADC Running on the MicroZed: Adam Taylor’s MicroZed Chronicles Part 7


A Boot Loader for MicroZed. Adam Taylor’s MicroZed Chronicles, Part 6 


Figuring out the MicroZed Boot Loader – Adam Taylor’s MicroZed Chronicles, Part 5


Running your programs on the MicroZed – Adam Taylor’s MicroZed Chronicles, Part 4


Zynq and MicroZed say “Hello World”-- Adam Taylor’s MicroZed Chronicles, Part 3


Adam Taylor’s MicroZed Chronicles: Setting the SW Scene


Bringing up the Avnet MicroZed with Vivado






5 Years to 5G: Enabling Rapid 5G System Development

by Xilinx Employee on ‎02-13-2015 02:18 PM (758 Views)

David Squires of BEEcube and David Hawke of Xilinx have just published an article on the EETimes Web site titled “5 Years to 5G: Enabling Rapid 5G System Development.” The article lays out some of the challenges of the 5G RAN and ways in which ideas can be implemented in hardware -- both for prototyping, which needs to happen over the next three years, and ultimately for production deployment, which is slated to commence in 2020. If things go as planned, 5G will provide 1000x more capacity and will support 100+ billion connections with data rates to 10Gbps and less than 1msec latency. Those are goals we’d all like to see realized.


Developing 5G networks that meet these goals will require a combination of existing systems such as LTE-Advanced and WiFi, combined with revolutionary technologies designed to support new uses such as the Internet of Things (IoT), augmented reality, immersive gaming, and UHD (ultra-high-definition) streaming video. 5G will see some of the spectrum below 6GHz being re-purposed for use with newer technologies and existing cellular bands will be augmented with new spectrum allocations above 6GHz.


If you’d like a detailed look at the future of 5G communications, take a read. As one EETimes reader commented, “This is really comprehensive!”




OMG: Kids home from school next week! What to do??? STEM Academy, Feb 17-19—Silicon Valley

by Xilinx Employee ‎02-12-2015 10:12 PM - edited ‎02-12-2015 10:28 PM (1,093 Views)

Next week here in Silicon Valley is Winter break, Presidents’ Week, or Ski Week. Take your pick. If you have a science/math/engineering/nerdy middle schooler—you know, the one who likes to take things apart; the one who asks a lot of questions you can’t answer—have I got a deal for you. It’s called STEM Academy, a joint project between 

Silicon Valley Career Technical Education (SVCTE) and Xilinx. For three half-days next week, Feb 17-19, teachers from SVCTE and technical professionals from Xilinx (including me) will show a small class of kids what it’s like to have a STEM job in the heart of Silicon Valley. They’ll learn to make stuff, program Arduinos, hog out aluminum with CNC machines, solve problems, and have tons of fun. Yes, it’s going to be way cool.


Here’s the thing though. The class is nearly full so you don’t have any more time to waste. You need to register now.


Ah, but I hear you saying, my kid doesn’t want to be learning anything next week. They’re off from school. They want to chill. No problem. I can solve that for you in six minutes. Have your kid sit with you and watch the Nigel Stanford video below. It’s a STEAM video like nothing you’ve (or I’ve) ever seen. (Thanks for the hint, Make Magazine.) The video is a perfect marriage of science, math, engineering, and good ole rock and roll. Watch the video, collect all the “How did they do that?” questions, and then sign up here. Remember, when it’s full, it’s full. See you next week.






A phasor is a complex number that represents a sinusoidal wave’s amplitude, frequency, and phase. Electrical power-generation and –distribution companies use phasor measurements to help them gauge the health and efficiency of their systems as they enter the new world of many smaller renewable power generation plants (wind and solar) and new load challenges (conversion from incandescent lamps to compact fluorescents and LEDS and electric-car chargers, to name but two examples). National Instruments (NI) has just introduced a Phasor Measurement Unit (PMU) based on the company’s CompactRIO embedded-control and data-acquisition system. In turn, the NI CompactRIO is based on a Xilinx Zynq SoC.



NI PMU.jpg


NI Phasor Measurement Unit



The PMU is part of NI’s Grid Automation System, which is designed to be installed throughout a power grid. Readings from this distributed grid instrumentation then informs and guides control-room decisions. National Grid UK has already adopted NI’s Grid Automation System.


For more information about the Zynq-based NI CompactRIO data-acquisition and control system, see “National Instruments Shrinks Product, Improves Performance, and Grows Available Market Using the Xilinx Zynq All Programmable SoC.”




Low-cost, High-speed Eye Tracking Detects Concussions and Traumatic Brain Injuries—Powered by Zynq

by Xilinx Employee ‎02-12-2015 11:02 AM - edited ‎02-12-2015 01:26 PM (2,519 Views)

Concussions and traumatic brain injury (TBI) are much in the news of late. Pro sports players get them in games. Amateur athletes get them on the field. Warfighters get them in combat. (The U.S. Army reported nearly 20,000 TBI incidents yearly between 2008 and 2012.) Barrow Neurological Institute in Phoenix developed eye tracking as a non-invasive way to detect and track the progress of such injuries. Now a startup company called Saccadous is developing that IP into a usable product based on high-speed cameras. At first, researchers used high-speed cameras that cost $45,000 to $90,000, which wasn’t practical for a product that would see widespread use. However, Scottsdale-based Saccadous found a suitable, low-cost eye-tracking product at EyeTech Digital Systems just down the road in nearby Mesa, AZ. EyeTech’s high-speed, eye-tracking camera is based on a Xilinx Zynq SoC.



EyeTech OEM Board.jpg



EyeTech developed an eye-tracking module that clips to the bottom of a tablet for Saccadous that drops the cost of a high-speed, eye-tracking camera to around $1000—which significantly brightens the prospects for making a low-cost diagnostic tool that you can put into the hands of doctors, coaches, and military medics.


Besides the two teams on the field—the New England Patriots and the Seattle Seahawks—plus 70,288 fans in the stands and 114.4 million television viewers, Super Bowl XLIX was observed by five I-MOVIX X10 UHD (4K) ultra-slo-mo cameras tied to Evertz DreamCatcher replay systems. The I-MOVIX system augments Vision Research’s Phantom Flex4K high-speed digital video cameras to produce a camera system that delivers instant replays with 4K resolution at 1000 frames/sec, continuous 4Kp60 video at 120 frames/sec, or continuous HD video at 600 frames/sec. Fletcher Sports, a Chicago-based sports production house, supplied the cameras for the game.



I-MOVIX 4K X10 UHD Camera at Super Bowl XLIX.jpg



The I-MOVIX X10 UHD system is based on Xilinx Virtex-6 FPGAs (the company’s first products appeared in 2008). Introduction of the 4K X10 UHD system at last year’s NAB 2014 continued the company's super-slow-motion product line.


For more information about the I-MOVIX super-slow-motion system, see “FPGA-based i-movix X10 UHD Ultra Slow-Motion System accepts 1000fps in 4K, 2000fps in HD.”


About the Author
  • 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.