Displaying articles for: 02-26-2017 - 03-04-2017
RFEL has supplied the UK’s Defence Science and Technology Laboratory (DSTL), an executive agency sponsored by the UK’s Ministry of Defence, with two of its Zynq-based HALO Rapid Prototype Development Systems (RPDS). DSTL will evaluate video processing algorithms using IP from RFEL and 3rd parties in real-time, interactive video trials for military users. The HAL RPDS dramatically speeds assessment of complex video-processing solutions and provides real-time prototypes while conventional software-based simulations do not provide real-time performance).
HALO Rapid Prototype Development Systems (RPDS)
HALO is a small, lightweight, real-time video-processing subsystem based on the Xilinx Zynq Z-7020 or Z-7030 SoCs. It’s also relatively low-cost. HALO is designed for fast integration of high-performance vision capabilities for extremely demanding video applications—and military video applications are some of the most demanding because things whiz by pretty quickly and mistakes are very costly. The Zynq SoC’s software and hardware programmability give the HALO RPDS the flexibility to adapt to a wide variety of video-processing applications while providing real-time response.
Here’s a block diagram of the HALO RPDS:
HALO Rapid Prototype Development Systems (RPDS) Block Diagram
As you can see from the light blue boxes at the top of this block diagram, there are already a variety of real-time, video-processing algorithms. RFEL itself offers many such cores for:
All of these video-processing functions operate in real-time because they are hardware implementations instantiated in the Zynq SoC’s PL (programmable logic). In addition, the Zynq SoC’s extensive collection of I/O peripherals and programmable I/O mean that the HALO RPDS can interface with a broad range of image and video sources and displays.(That's why we say that Zynq SoCs are All Programmable.)
DSTL procured two HALO RPDS systems to support very different video processing investigations, for diverse potential applications. One system is being used to evaluate RFEL's suite of High Definition (HD) video-stabilization IP products to create bespoke solutions. The second system is being used to evaluate 3rd-party algorithms and their performance. The flexibility and high performance of the Zynq-based HALO RPDS system means that it is now possible for DSTL to rapidly experiment with many different hardware-based algorithms. Of course, any successful candidate solutions are inherently supported on the HALO platform, so the small, lightweight HALO system provides both a prototyping platform and an implementation platform.
For previous coverage of an earlier version of RFEL’s HALO system, see “Linux + Zynq + Hardware Image Processing = Fused Driver Vision Enhancement (fDVE) for Tank Drivers.”
Today, Keysight Technologies announced its low-cost InfiniiVision 1000 X-Series oscilloscopes with 50MHz and 100MHz models that start at $449. (Apparently, this is Scope Month and Keysight is giving away 125 DSOs in March—click here for more info.) Even at that low price, these 2-channel 1000 X-Series DSOs are based on Keysight’s high-performance MegaZoom IV custom ASIC technology, which enables a high 50,000 waveforms/sec update rate.
Keysight 1000 X-Series DSO
These new scopes are intended for students and new users. In fact, the two 50MHz models have “EDU” as a model number prefix. Here’s a table listing the salient features of the four models in the 1000 X-Series family:
All four models also operate as a serial protocol analyzer, digital voltmeter, and frequency counter. The EDUX1002G and DSOX1102G models include a frequency response analyzer and function generator.
So why are you reading about this very nice, new Keysight instrument in the Xilinx Xcell Daily blog? Well, Keysight supplied one of these new DSOs to my good friend Dave Jones at eevblog.com and of course, he did a teardown; and of course, he found a Xilinx FPGA inside. That's why.
Here’s Dave Jones’ 30-minute teardown video of the new Keysight 1000 X-series DSO:
This DSO features a 2-board construction. The main board is mostly analog and a small daughter board contains the high-speed ADC, the Keysight MegaZoom IV ASIC, an STMicroelectronics SPEAR600 application processor, and a low-end Xilinx Spartan-3E XC3S500E FPGA. That’s a lot of processing power in a very inexpensive DSO family that starts at $450.
Here’s Dave’s closeup shot of that digital daughtercard showing the Xilinx FPGA positioned between the SPEAR600 processor and the Keysight MegaZoom IV ASIC (under the finned heat sink):
Now the Spartan-3E FPGA is not a particularly new device; it was announced more than a decade ago. The Spartan-3E FPGA family was designed from the start to be cost-effective, which is no doubt why Keysight used it in this DSO design. Its appearance in a just-introduced product is a testament to Xilinx’s ongoing commitment to device availability over the long term.
Please contact Keysight directly for more information about the InfiniiVision 1000 X-Series DSOs.
What could be better than a PCIe SBC (single-board computer) that combines a Xilinx Zynq SoC with an FMC connector? How about the world’s smallest FMC carrier card that also happens to be based on any one of three Xilinx Zynq SoCs (your choice of a single-core Zynq Z7012S SoC or a dual-core Z7015 or Z-7030)? That’s the description of the Berten DSP GigaExpress SBC.
The Berten DSP GigaExpress SBC, the world’s smallest FMC carrier card
The GigaExpress SBC incorporates 1Gbyte of DDR3L-1066 SDRAM for the Zynq SoC’s single- or dual-core ARM Cortex-A9 PS (Processing System) and there’s 512Mbytes of dedicated DDR3L SDRAM clocked at 333MHz for exclusive use by the Zynq PL (Programmable Logic). The PS software and PL configuration are stored in a 512Mbit QSPI Flash memory. A 1000BASE-T Ethernet interface is available on a rugged Cat5e RJ45 connector. The block diagram of the GigaExpress SBC appears below. From this diagram and the above photo, you can see that the Zynq SoC along with the various memory devices is all the digital silicon you need to implement a complete, high-performance system.
Berten DSP GigaExpress SBC Block Diagram
Please contact Berten DSP directly for more information about the GigaExpress SBC.
Today, Aldec announced its latest FPGA-based HES prototyping board—the HES-US-440—with a whopping 26M ASIC gate capacity. This board is based on the Xilinx Virtex UltraScale VU440 FPGA and it also incorporates a Xilinx Zynq Z-7100 SoC that acts as the board’s peripheral controller and host interface. The announcement includes a new release of Aldec’s HES-DVM Hardware/Software Validation Platform that enables simulation acceleration and emulation use modes for the HES-US-440 board in addition to the physical prototyping capabilities. You can also use this prototyping board directly to implement HPC (high-performance computing) applications.
Aldec HES-US-440 Prototyping Board, based on a Xilinx Virtex UltraScale VU440 FPGA
The Aldec HES-US-440 board packs a wide selection of external interfaces to ease your prototyping work including four FMC HPC connections, PCIe, USB 3.0 and USB 2.0 OTG, UART/USB bridge, QSFP+, 1Gbps Ethernet, HDMI, SATA; has on-board NAND and SPI Flash memories; and incorporates two microSD slots.
Here’s a block diagram of the HES-US-440 prototyping board:
Aldec HES-US-440 Prototyping Board Block Diagram
For more information about the Aldec HES-US-440 prototyping board and Aldec’s HES-DVM Hardware/Software Validation Platform, please contact Aldec directly.
Last September at the GNU Radio Conference (GRCon16) in Boulder, CO, Ettus Research announced its RFNoC & Vivado HLS Challenge with a $10,000 grand prize for developing “innovative and useful open-source RF Network on Chip (RFNoC) blocks that highlight the productivity and development advantage of Xilinx Vivado High-Level Synthesis (HLS) for FPGA programming using C, C++, or System C. The new RFNoC blocks generated during the challenge will add to the rapidly growing library of available open-source blocks for programming FPGAs in SDR development and production.”
Based on formal proposals, the company has now accepted seven teams for the challenge:
The final challenge competition will take place in May or June 2017 (venue to be announced) and the teams are required to submit technical papers for publication in the GRCon17 technical proceedings outlining their design’s contribution, implementation, results, and lessons learned. (GRCon17 takes place on September 11-15, 2017 in San Diego, CA.)
For more information about the challenge, see “Matt Ettus of Ettus Research wants you to win $10K. All you have to do is meet his RFNoC & Vivado HLS challenge for SDR.”
Here are four online training classes in March that cover various technical design aspects of Xilinx UltraScale and UltraScale+ FPGAs and the Zynq UltraScale+ MPSoC:
03/09/2017 Zynq UltraScale+ MPSoC for the Software Developer
03/15/2017 Serial Transceivers in UltraScale Series FPGAs/MPSoCs – Part I – Transceiver Design Methodology
03/22/2017 Serial Transceivers in UltraScale Series FPGAs/MPSoCs – Part II – Debugging Techniques and PCB Design
03/23/2017 Zynq UltraScale+ MPSoC for the System Architect
These four classes will be taught by three Xilinx Authorized Training Providers: Faster Technology, Xprosys, and Hardent. Click here for registration details.
Berten DSP’s GigaX API for the Xilinx Zynq SoC creates a high-speed, 200Mbps full-duplex communications channel between a GbE port and the Zynq SoC’s PS (programmable logic) through an attached SDRAM buffer and an AXI DMA controller IP block. Here’s a diagram to clear up what’s happening:
The software API implements IP filtering and manages TCP/UDP headers, which help you implement a variety of hardware-accelerated Ethernet systems including Ethernet bridges, programmable network nodes, and network offload appliances. Here’s a performance curve illustrating the kind of throughput you can expect:
Please contact Berten DSP directly for more information about the GigaX API.
Today, Cadence announced the Protium S1 FPGA-Based Prototyping Platform, which delivers as many as 200M ASIC gates worth of prototyping capacity per chassis for hardware/software integration, software development, system validation, and hardware regression using one to eight Xilinx Virtex UltraScale VU440 FPGAs as a foundation. That’s double the previous version of the Protium FPGA-based Prototyping Platform which had a maximum gate capacity of 100M ASIC gates. The Protium S1 combines these Virtex UltraScale FPGA boards with a complete implementation and debug software suite, permitting ultra-fast design bring-up. The new Protium S1 platform is compatible with Cadence’s Palladium platforms and SpeedBridge adapters, paving the way for a smooth transition of SoC designs from an existing emulation environment into a high-performance FPGA-based prototype.
Here’s a 4-minute Protium S1 introductory video from Cadence:
Xcell Daily has covered the Samtec FireFly mid-board interconnect system several times but now there’s a new 3.5-minute video demo of a PCIe-specific version of the FireFly optical module. In the video demo, FireFly optical PCIe modules convey PCIe signals between a host PC and a video card over 100m of optical fiber in real time. The video passed over this link works smoothly. That’s quite a feat for a small module like the FireFly and it creates new possibilities for designing distributed systems.
The PCIe-specific version of the Samtec FireFly module handles PCIe sidebands and other PCIe-specific protocols. These modules match up well with the PCIe controllers found in Xilinx UltraScale and UltraScale+ devices and many 7 series FPGAs and Zynq SoCs. As Kevin Burt of Samtec’s Optical Group explains, the mid-board design of the FireFly system allows you to locate the modules adjacent to the driving chips (FPGAs in this case), which improves signal integrity of the pcb design.
Here’s the Samtec video:
For additional coverage of the Samtec FireFly system, see:
By Adam Taylor
Having looked at how we can quickly and easily get the Zynq UltraScale+ MPSoC up and running, I now want to look at the architecture of the system in a little more detail. I am going to start with examining the processor’s global address map. I am not going to look in detail into the contents of the address map. Initially, I want to explore how it is organized so that we understand it. I want to explain how the 32-bit ARM Cortex-R5 processors in the Zynq UlraScale+ MPSoC’s RPU (Real-time Processing Unit) and the 64-bit ARM Cortex-A53 processors in the APU (Application Processing Unit) share their address spaces.
The ARM Cortex-A53 processors use a 40-bit address bus, which can address up to 1Tbyte of memory. Compare this to the 32-bit address bus of the ARM Cortex-R5 processors, which can only address a 4Gbyte address space. The Zynq UltraScale+ MPSoC architects therefore had to consider how these address spaces would work together. The solution they came up with is pretty straightforward.
The memory map of the The Zynq UltraScale+ MPSoC is organised to so that the PMU (Platform Management Unit), MIO peripherals, DDR controller, the PL (programmable logic), etc. all fall within the first 4Gbyte of addressable space so that the APU and the RPU can both address these resources. The APU has further access to the DDR and PCIe controllers and the PL up to the remaining 1Tbyte address limit. The lower 4Gbytes of address space supports 32-bit addressing for some peripherals. One example of this is the PCIe controller, which supports 32-bit addressing via a 256Mbyte address range in the lower 4Gbytes and up to 256Gbytes (using 64-bit addressing) in the full address map.
MPSoC Global Address Map
It goes without saying that the only the APU can access the address space above 4 GB. However, the more observant amongst us will have noticed that there is also what appears to be a 36-bit addressable mode as well. Using a 36-bit address, provides for faster address translation, because the table walker uses only three stages instead of four for a 40-bit address. Therefore, 36 bit addressing should be used if possible to optimize system performance.
Address translation is the role of the System Memory Management Unit (SMMU), which has been designed to transform addresses from a virtual address space to a physical address space when using a virtualized environment. The SMMU can provide the following translations if desired:
Virtual Address (VA) - > Intermediate Physical Address (IPA) -> Physical Address (PA)
Within the SMMU, these are defined as being stage one VA to IPA or stage two IPA to PA and depending upon use case we can perform only a stage one, stage two or a stage one and two translation. To understand more about the SMMU—which is a complex subject—I would recommend reading chapters 3 and 10 of the Zynq UltraScale+ MPSoC TRM (UG1085) and the ARM SMMU architecture specification.
SMMU translation schemes
Now that we understand a little more about the Zynq UltraScale+ MPSoC’s global memory map, we will look at exactly what is contained within this memory map and how we can configure and use this map with both the APU and the RPU cores over the next few blogs.
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.