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!


Earlier this year, Shahriar Shahramian, who regularly posts in-depth electronics videos on his YouTube channel “The Signal Path,” reviewed and then tore down a Rohde & Schwarz Spectrum Rider FPH. This hand-held, battery-powered, portable spectrum analyzer has been on the market for a couple of years now and covers 5kHz to 2, 3, or 4GHz, depending on options. (Shahriar Shahramian is department head for millimeter-Wave ASIC Research at Nokia Bell Labs.)




Rohde and Schwarz 4GHz Spectrum Rider FPH.jpg 



Rohde & Schwarz Spectrum Rider FPH portable spectrum analyzer




Shahriar’s extensive user review and teardown video of the Spectrum Rider FPH lasts an hour, so here are some salient points in the video.



1:10 – Model comparison of R&S portable spectrum analyzers


5:44 – Instrument hardware overview and GUI characteristics


22:24 – Using the FPH Spectrum Rider to analyze unknown wireless signals including a multi-tone, QPSK modulated signal, AM/FM demodulation analysis and frequency hopping


46:46 – FPH teardown and analysis


55:33 – Overview of the Instrument View remote connection software


57:42 – Concluding remarks




Most important for Xcell Daily, at 48 minutes into the video Shahriar finally cracks the instrument apart and finds a Zynq SoC handling essentially all of the instrument’s RF digital signal processing; I/O control; its clean, responsive, elegant, and well-thought-out user interface based on hard buttons and a pinch-sensitive touch screen; and its Instrument View remote front-panel interface that operates over the USB port or Ethernet.


The Zynq SoC is a perfect fit for such an application. The Zynq Processing System (PS) handles the user interface and general supervision. The Zynq Programmable Logic (PL) section with its high-speed programmable logic and DSP slices handles the instrument’s high-speed control and signal processing.


Here’s a photo clipped from the video. Shahriar is pointing to the Zynq SoC in this photo:




Rohde and Schwarz 4GHz Spectrum Rider FPH Zynq Detail.jpg


A Zynq SoC manages the overall operation and digital signal processing for the Rohde & Schwarz Spectrum Rider FPH




You should note that this portable, hand-held instrument has an 8-hour battery life despite the rather sophisticated RF and digital electronics. I strongly suspect the high level of integration made possible by the Zynq SoC has something to do with this.


Because of its All Programmable flexibility, the Zynq SoC makes a terrific foundation for entire product families. You can see this here because Rohde and Schwarz has also used the Zynq SoC as the digital heart of its Scope Rider, a multi-function, hand-held, 2/4-channel, 500MHz DSO (as reported by the Powered by Xilinx Web page.) The family resemblance with the Spectrum Rider FPH is quite strong:





Rohde and Schwarz Scope Rider.jpg


Rohde & Schwarz Scope Rider



I’ll go out on a limb and guess that there’s a lot of shared code (not to mention case tooling) between the company’s Scope Rider and Spectrum Rider FPH. The Zynq SoC’s PS and PL along with its broadly programmable I/O pins combine to create a very flexible design platform for a product family or multiple product families. That kind of leverage allows you to create an assembly line for new-product development with competition-beating time to market.




Here’s The Signal Path’s YouTube video review of the Rohde & Schwarz 4.0GHz Spectrum Rider FPH:






For more information about the Spectrum Rider FPH and the Scope Rider, please contact Rohde & Schwarz directly.




There’s a new tutorial on Digilent’s Web site that tells you how to use its Digital Discovery high-speed logic analyzer and pattern generator to get a detailed look at the boot sequence of a Zynq Z-7000 SoC by monitoring the SPI interface between the Zynq SoC and its SPI-attached QSPI boot ROM. You only need seven connections. The tutorial uses a custom interpreter script for the Digital Discovery analyzer to decode the SPI traffic. The script is installed in the analyzer’s PC-based control software called Waveforms and the tutorial page gives you the script.


The entire boot transfer sequence takes 700msec and the entire boot-sequence acquisition consumes a lot of memory: 268,435,456 samples in this case. The Digital Discovery doesn’t store that many samples—it doesn’t need to do so because it sends the acquired data to the attached PC over the connecting USB cable.




Digilent Digital Discovery captures Zynq Boot Sequence over SPI.jpg 



Digilent’s Digital Discovery logic analyzer captures the entire boot sequence for a Zynq Z-7000 SoC over SPI




There’s nothing particularly unusual about a logic analyzer capturing a processor’s boot sequence. However in this case, Digilent’s Digital Discovery is based on a Xilinx Spartan-6 LX25 FPGA (see “$199.99 Digital Discovery from Digilent implements 800Msample/sec logic analyzer, pattern generator. Powered by Spartan-6”) and it’s monitoring the boot sequence of a Xilinx Zynq SoC. Good tools all around.



Wireless, handheld, 30MHz, $379 IkaScope DSO based on Spartan-3 FPGA gets a distributor: Saelig

by Xilinx Employee ‎10-19-2017 10:02 AM - edited ‎10-19-2017 10:03 AM (750 Views)


Last month, I wrote about the wireless, 30MHz, handheld IkaScope WS200 DSO created by IkaLogic. It’s based on a Spartan-3 FPGA, which handles almost all of the instrument’s internal functions and is fast enough to support the WS200 DSO’s 200MHz sample rate. (See “Wireless, €299, 30MHz, 200Msamples/sec DSO fits entirely inside of a probe thanks to the integration power of a Spartan FPGA.”) Late last month, the Saelig Company announced that it was carrying the IkaScope WS200. It lists for $379. (Click here for the Saelig Web page.)






The 30MHz, 200Msamples/sec WS200 IkaScope DSO from IkaLogic




The IkaScope WS200 DSO’s internal 450mAh battery lasts about one week with daily regular use before you need to recharge it. That’s because the instrument uses smart power management to turn itself on when it detects pressure on the probe tip, signaling that you’re taking a measurement, and turn itself off when it observes that no measurements have been taken for a period of time. The IkaScope's Automatic History feature saves a captured signal waveform when it detects a pressure release on the DSO’s probe tip.


The IkaScope WS200 DSO has no display. Instead, it uses WiFi to communicate with a Windows/Mac/Linux/Android/iOS app running on a PC or tablet. That means you can use finger gestures to control the display if the PC or tablet has a touch screen, another innovation built into this instrument.




RedZone Robotics’ Solo—a camera-equipped, autonomous sewer-inspection robot—gives operators a detailed, illuminated view of the inside of a sewer pipe by crawling the length of the pipe and recording video of the conditions it finds inside. A crew can deploy a Solo robot in less than 15 minutes and then move to another site to launch yet another Solo robot, thus conducting several inspections simultaneously and cutting the cost per inspection. The treaded robot traverses the pipeline autonomously and then returns to the launch point for retrieval. If the robot encounters an obstruction or blockage, it attempts to negotiate the problem three times before aborting the inspection and returning to its entry point. The robot fits into pipes as small as eight inches in diameter and even operates in pipes that contain some residual waste water.




RedZone Robotics Solo Sewer Inspection Robot.jpg


RedZone Robotics Autonomous Sewer-Pipe Inspection Robot




Justin Starr, RedZone’s VP of Technology, says that the Solo inspection robot uses its on-board Spartan FPGA for image processing and for AI. Image-processing algorithms compensate for lens aberrations and also perform a level of sensor fusion for the robot’s multiple sensors. “Crucial” AI routines in the Spartan FPGA help the robot keep track of where it is in the pipeline and tell the robot what to do when it encounters an obstruction.


Starr also says that RedZone is already evaluating Xilinx Zynq devices to extend the robot’s capabilities. “It’s not enough for the Solo to just grab information about what it sees, but let’s actually look at those images. Let’s have the solo go through that inspection data in real time and generate a preliminary report of what it saw. It used to be the stuff of science fiction but now it’s becoming reality.”


Want to see the Solo in action? Here’s a 3-minute video:










WP460, “Reducing System BOM Cost with Xilinx's Cost-Optimized Portfolio,” was recently updated. This White Paper contains a wealth of helpful information if you’re trying to cut manufacturing costs in your system. Updates to the White Paper include new information about new Spartan-7 FPGA family and Zynq Z-7000S SoCs with single-core Arm Cortex-A9 processors that run at clock rates as fast as 766MHz. Both of these Xilinx device families help drive BOM costs down while still delivering plenty of system performance—just what you’d expect from Xilinx All Programmable devices.


The White Paper also contains additional information about new MicroBlaze soft microprocessor presets, which you can read about in the new MicroBlaze Quick Start Guide. You can drop a 32-bit RISC MicroBlaze soft processor into any current Xilinx device very efficiently. The microcontroller preset version of the MicroBlaze processor consumes fewer than 2000 logic cells, yet runs at a much higher clock rate than most low-cost microcontrollers. There’s plenty of performance there when you need it.





Once again, the two LIGO and the Advanced Virgo gravity-wave observatories have jointly recorded a cataclysmic event, but this time it’s two neutron stars colliding instead of a pair of black holes—and this time, the event was visible! A paper published yesterday in Physical Review Letters by the LIGO Scientific Collaboration and the Virgo Collaboration titled “GW170817: Observation of Gravitational Waves from a Binary Neutron Star Inspiral” starts out by saying “On August 17, 2017, the LIGO-Virgo detector network observed a gravitational-wave signal from the inspiral of two low-mass compact objects consistent with a binary neutron star (BNS) merger.” Although this new ripple in spacetime was recorded on August 17, it occurred about 130 million years ago. Two seconds after the gravity waves were detected, NASA’s Fermi satellite and ESA’s INTEGRAL satellite both detected a gamma-ray burst from the same direction. Astrophysicists have theorized that neutron-star collisions would produce gamma-ray bursts and the Integral and Fermi observations tend to support that theory.


Using triangulation data from these observations, the LIGO team quickly alerted astronomers around the world and told them where to look. Optical, ground-based observatories were able to image the event visibly and for days after. The Hubble Space Telescope was brought to bear on the event and it captured this image:




Neutron Binary Star Merger captured by Hubble Space Telescope.jpg


Neutron Binary Star Merger Captured by the Hubble Space Telescope

Photo credit: NASA and ESA




This event doesn’t just confirm the gravity-wave observatories’ ability to capture heretofore undetected astronomical phenomena; it has also produced new data that tends to confirm some theoretical models of the universe including the manufacture of heavier elements including silver, gold, platinum, and uranium from the collision. Here’s Dan Kasen, a theoretical physicist at UC Berkeley, to explain this in a riveting 3-minute video:






And why discuss this huge leap in astrophysics in an Xcell Daily blog post? Because Xilinx Spartan FPGAs are incorporated into the design of the gravity-wave observatories and therefore play a role in the discoveries. For more information about this, see:












By Adam Taylor


One ongoing area we have been examining is image processing. We’ve look at the algorithms and how to capture images from different sources. A few weeks ago, we looked at the different methods we could use to receive HDMI data and followed up with an example using an external CODEC (P1 & P2). In this blog we are going to look at using internal IP cores to receive HDMI images in conjunction with the Analog Devices AD8195 HDMI buffer, which equalizes the line. Equalization is critical when using long HDMI cables.





Nexys board, FMC HDMI and the Digilent PYNQ-Z1




To do this I will be using the Digilent FMC HDMI card, which provisions one of its channels with an AD8195. The AD8195I on the FMC HDMI card needs a 3v3 supply, which is not available on the ZedBoard unless I break out my soldering iron. Instead, I broke out my Digilent Nexys Video trainer board, which comes fitted with an Artix-7 FPGA and an FMC connector. This board has built-in support for HDMI RX and TX but the HDMI RX path on this board supports only 1m of HDMI cable while the AD8195 on the FMC HDMI card supports cable runs of up to 20m—far more useful in many distributed applications. So we’ll add the FMC HDMI card.


First, I instantiated a MicroBlaze soft microprocessor system in the Nexys Video card’s Artix-7 FPGA to control the simple image-processing chain needed for this example. Of course, you can implement the same approach to the logic design that I outline here using a Xilinx Zynq SoC or Zynq UltraScale+ MPSoC. The Zynq PS simply replaces the MicroBlaze.


 The hardware design we need to build this system is:


  • MicroBlaze controller with local memory, AXI UART, MicroBlaze Interrupt controller, and DDR Memory Interface Generator.
  • DVI2RGB IP core to receive the HDMI signals and convert them to a parallel video format.
  • Video Timing Controller, configured for detection.
  • ILA connected between the VTC and the DVI2RBG cores, used for verification.
  • Clock Wizard used to generate a 200MHz clock, which supplies the DDR MIG and DVI2RGB cores. All other cores are clocked by the MIG UI clock output.
  • Two 3-bit GPIO modules. The first module will set the VADJ to 3v3 on the HDMI FMC. The second module enables the ADV8195 and provides the hot-plug detection.







The final step in this hardware build is to map the interface pins from the AD8195 to the FPGA’s I/O pins through the FMC connector. We’ll use the TMDS_33 SelectIO standard for the HDMI clock and data lanes.


Once the hardware is built, we need to write some simple software to perform the following:



  • Disable the VADJ regulator using pin 2 on the first GPIO port.
  • Set the desired output voltage on VADJ using pins 0 & 1 on the first GPIO port.
  • Enable the VADJ regulator using pin 2 on the first GPIO port.
  • Enable the AD8195 using pin 0 on the second GPIO port.
  • Enable pre- equalization using pin 1 on the second GPIO port.
  • Assert the Hot-Plug Detection signal using pin 2 on the second GPIO port.
  • Read the registers within the VTC to report the modes and status of the video received.



To test this system, I used a Digilent PYNQ-Z1 board to generate different video modes. The first step in verifying that this interface is working is to use the ILA to check that the pixel clock is received and that its DLL is locked, along with generating horizontal and vertical sync signals and the correct pixel values.


Provided the sync signals and pixel clock are present, the VTC will be able to detect and classify the video mode. The application software will then report the detected mode via the terminal window.





ILA Connected to the DVI to RGB core monitoring its output







Software running on the Nexys Video detecting SVGA mode (600 pixels by 800 lines)




With the correct video mode being detected by the VTC, we can now configure a VDMA write channel to move the image from the logic into a DDR frame buffer.



You can find the project on GitHub



If you are working with video applications you should also read these:



PL to PS using VDMA

What to do if you have VDMA issues  

Creating a MicroBlaze System Video

Writing MicroBlaze Software  




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 




Previously, I wrote about MicroCore Labs’ cycle-exact MCL65 soft-core version of the venerable 6502 microprocessor, which found its way into many significant microprocessor-based designs in the 1970s, 1980s, and beyond. When I wrote about the core, instantiated in less than 1% of a Xilinx Spartan-7 S50 FPGA, it was operating a Commodore VIC-20 personal computer. (See “Cycle-exact 6502 processor clone fits in 0.77% of a Spartan-7 (and Spartan-3) FPGA, powers VIC-20 PC.”) Now, there’s further evidence of the core’s cycle-exactness: it’s running an Atari 2600 VCS (Video Computer System) and an Apple II personal computer. Both of these machines were introduced in 1977 and both are significant in the context of the MCL65 processor core because both of them rely entirely on instruction-level timing loops for critical functions.


The Atari 2600 VCS intimately ties its video to the NTSC timing of analog TV because it only had 128 bytes (not mega-, not kilo-, just plain old bytes) of RAM. That’s too small for a frame buffer so the processor had to generate a new screen 30 times a second and stay in sync with the TV’s horizontal line drawing and vertical refresh rate. (See Wired.com’s fascinating “Racing the Beam: How Atari 2600's Crazy Hardware Changed Game Design.”)


Here’s a photo of MicroCore Labs’ MCL65 processor core running on a $109 Digilent Arty S7 Spartan-7 FPGA dev board and operating an Atari 2600 VCS:




MicroCore Labs MCL6502 processor running an Atari 2600 VCS.jpg


MicroCore Labs’ MCL65 processor core running an Atari 2600 VCS, using a Spartan-7 FPGA




Then there’s the Apple II personal computer. The legendary Steve Wozniak designed the Disk II floppy disk drive for the Apple II. After studying existing floppy-controller designs based on discrete TTL chips (North Star Computers) and the WD1771 floppy controller, he decided that he could do better with less hardware. His controller design was simpler in terms of hardware, relying on precise, instruction-level processor timing to encode data to be written to the disk and to decode the signals coming off the disk. According to Wikipedia, Wozniak call the Disk II project “my most incredible experience at Apple and the finest job I did", and credited it and VisiCalc with the Apple II's success.


Here’s a photo of MicroCore Labs’ MCL65 processor core on a $109 Digilent Arty S7 Spartan-7 FPGA dev board operating an Apple II personal computer and booting Apple DOS 3.3 from a Disk II drive:




MicroCore Labs MCL6502 processor running an Apple II PC.jpg


MicroCore Labs’ MCL65 processor core booting Apple Dos 3.3 from a Disk II drive for an Apple II computer, using a Spartan-7 FPGA




So far, this is all somewhat interesting on an intellectual level but what’s in it for you? How about downloadable source code for MicroCore Labs’ instruction-cycle and bus-cycle accurate MCL65 processor core? Click here.







Avnet’s MiniZed SpeedWay Design Workshops are designed to help you jump-start your embedded design capabilities using Xilinx Zynq Z-7000S All Programmable SoCs, which meld a processing system based on a single-core, 32-bit, 766MHz Arm Cortex-A9 processor with plenty of Xilinx FPGA fabric. Zynq SoCs are just the thing when you need to design high-performance embedded systems or need to use a processor along with some high-speed programmable logic. Even better, these Avnet workshops focus on using the Avnet MiniZed—a compact, $89 dev board packed with huge capabilities including built-in WiFi and Bluetooth wireless connectivity. (For more information about the Avnet MiniZed dev board, see “Avnet’s $89 MiniZed dev board based on Zynq Z-7000S SoC includes WiFi, Bluetooth, Arduino—and SDSoC! Ships in July.”)


These workshops start in November and run through March of next year and there are four full-day workshops in the series:


  • Developing Zynq Software
  • Developing Zynq Hardware
  • Integrating Sensors on MiniZed with PetaLinux
  • A Practical Guide to Getting Started with Xilinx SDSoC


You can mix and match the workshops to meet your educational requirements. Here’s how Avnet presents the workshop sequence:



Avnet MiniZed Workshops.jpg 




These workshops are taking place in cities all over North America including Austin, Dallas, Chicago, Montreal, Seattle, and San Jose, CA. All cities will host the first two workshops. Montreal and San Jose will host all four workshops.


A schedule for workshops in other countries has yet to be announced. The Web page says “Coming soon” so please contact Avnet directly for more information.


Finally, here’s a 1-minute YouTube video with more information about the workshops





For more information on and to register for the Avnet MiniZed SpeedWay Design Workshops, click here.



Shahriar Shahramian, department head for millimeter-Wave ASIC Research at Nokia Bell Labs, has a YouTube channel that he calls “The Signal Path” where he delivers high-quality introductory videos about many areas in electronics and deeply knowledgeable teardowns of equipment—often high-frequency equipment. (He’s been making these videos for nearly seven years.) His teardown videos often uncover Xilinx All Programmable devices inside the equipment he studies, and this blog is about just such an instrument: the $2595 Siglent SSA3032X 9kHz - 3.2GHz Spectrum Analyzer and Tracking Generator (SA and TG).



Siglent SSA3032X Spectrum Analyzer.jpg



Siglent SSA3032X 9kHz - 3.2GHz Spectrum Analyzer and Tracking Generator




A recently published teardown video by Shahramian shows you how the Siglent SSA3032X SA and TG is designed and how it works. In this 1-hour video, you get a detailed look inside of the Siglent SSA3032X SA and TG, Shahramian’s analysis of how the instrument is designed, extended demonstrations of its performance while conducting myriad RF tests, and a very good look at the components used in the instrument’s design.


While examining the instrument’s digital board, Shahramian points out a Xilinx Spartan-6 LX45 FPGA (at 8:40 in the video). Based on its physical location, he concludes that the FPGA is used for real-time control of the SA’s analog sections and ADC, graphics and control of its large 1024x600-pixel LCD, and monitoring of the instrument’s front-panel controls. The FPGA acts as the Spectrum Analyzer’s real-time control master, working in tandem with the on-board TI Sitara microprocessor, which is based on an ARM Cortex-A8 microprocessor.




Siglent SSA3032X Spectrum Analyzer Digital Board.jpg



The digital board for the Siglent SSA3032X 9kHz - 3.2GHz Spectrum Analyzer and Tracking Generator uses a Xilinx Spartan-6 FPGA for real-time instrument control and management




If you have the time, the video is well worth watching:





By the way, if you like Shahramian’s videos, one way you can help him is to let vendors like Siglent know you watched this video to learn about the company’s SSA3032X.




Photonfocus has just introduced two cameras that specialize in seeing in the SWIR (short-wave IR, 930nm to 1700nm) spectral range to its huge and growing line of industrial cameras. The company’s MV3-D640I-M01-144 cameras are based on the Sofradir SNAKE low-noise InGaAs image sensor with 640x512-pixel resolution with a 12-bit, grayscale output. CameraLink or GigE interfaces are available. SNR is said to be as much as 1200:1 and the camera can operate at 300 frames/sec at full resolution. A global shutter makes µsec-long exposures possible even at the camera’s highest frame rate and permits a constant frame rate independent of exposure time.




Photonfocus MV3-D640I-CL SWIR camera.jpg 


Photonfocus MV3-D640I-M01-144-CL camera based on Sofradir SNAKE low-noise SWIR image sensor




Like many of the company’s industrial cameras, the MV3-D640I-M01-144 cameras employ a Xilinx All Programmable device—an Artix-7 FPGA in this case—to interface to the image sensor and to give the camera some of its programmable, frame-rate features. For this camera, that means as many as 256 configurable regions of interest, which enables hyperspectral applications.



For information about other Photonfocus industrial cameras, see:















The Vivado 2017.3 HLx Editions are now available and the Vivado 2017.3 Release Notes (UG973) tells you why you’ll want to download this latest version now. I’ve scanned UG973, watched the companion 20-minute Quick Take video, and cherry-picked twenty of the many enhancements that jumped out at me to help make your decision easier:



  • Reduced compilation time with a new incremental compilation capability


  • Improved heuristics to automatically choose between high-reuse and low-reuse modes for incremental compilation


  • Verification IP (VIP) now included as part of pre-compiled IP libraries including support for AXI-Stream VIP


  • Enhanced ability to integrate RTL designs into IP Integrator using drag-and-drop operations. No need to run packager any more.


  • Checks put in place to ensure that IP is available when invoking write_bd_tcl command


  • write_project_tcl command now includes Block designs if they are part of the project


  • Hard 100GE Subsystem awareness for the VCU118 UltraScale+ Board with added assistance support


  • Hard Interlaken Subsystem awareness for the VCU118 UltraScale+ Board with assistance support


  • Support added for ZCU106 and VCU118 production reference boards


  • FMC Support added to ZCU102 and ZCU106 reference boards


  • Bus skew reports (report_bus_skew) from static timing analysis now available in the Vivado IDE


  • Enhanced ease of use for debug over PCIe using XVC


  • Partial Reconfiguration (PR) flow support for all UltraScale+ devices in production


  • Support for optional flags (FIFO Almost Full, FIFO Almost Empty, Read Data Valid) in XPM FIFO


  • Support for different read and write widths while using Byte Write Enable in XPM Memory


  • New Avalon to AXI bridge IP


  • New USXGMII Subsystem that switches 10M/100M/1G/2.5G/5G/10G on 10GBASE-R 10G GT line rate for NBASE-T standard


  • New TSN (Time-Sensitive Network) subsystem


  • Simplified interface for DDR configuration in the Processing Systems Configuration Wizard


  • Fractional Clock support for DisplayPort Audio and Video to reduce BOM costs





Seven days ago, the Virgo Consortium announced the fourth detection of gravity waves caused by the cataclysmic collision of two black holes. The newly operational Virgo observatory and the two existing LIGO (the Laser Interferometer Gravitational-Wave Observatory) installations all observed this event, caused by two black holes colliding two billion years ago. (See “Advanced Virgo detects gravity waves—only the fourth time this has happened—and FGPAs were involved (of course)”) Yesterday, the Nobel committee at the Royal Swedish Academy of Sciences announced that three American physics professors including Rainer Weiss from MIT and Kip Thorne and Barry Barish from the California Institute of Technology have received the 2017 Nobel Prize in Physics for architecting the LIGO observatory and for the first gravity wave observations, which have once again confirmed some of the spacetime implications of Einstein’s General Theory of Relativity.


(The Royal Swedish Academy of Sciences actually used the more colorful word “captured” instead of “observed.”)


Although Xilinx Spartan FPGAs are peripherally involved in these bleeding-edge, Nobel-winning scientific achievements, the day really belongs to Weiss, Thorne, Barish, and of course Einstein.




LIGO Graphic from Nobel.org.jpg 



“How to catch a gravitational wave” from The Royal Swedish Academy of Sciences article “Cosmic Chirps




For more information about the LIGO gravity-wave observatory, see “When Black Holes Collide: Gravitational Waves detected by Advanced LIGO with some timely help from Spartan FPGAs.”





Voice-controlled systems are suddenly a thing thanks to Amazon’s Alexa and Google Home. But how do you get reliable, far-field voice recognition and robust voice recognition in the presence of noise? That’s the question being answered by Aaware with its $199 Far-Field Development Platform. This system couples as many as 13 MEMS microphones (you can use fewer in a 1D linear or 2D array) with a Xilinx Zynq Z-7010 SoC to pre-filter incoming voice, delivering a clean voice data stream to local or cloud-based voice recognition hardware. The system has a built-in wake word (like “Alexa” or “OK, Google”) that triggers the unit’s filtering algorithms.


Here’s a video showing you the Aaware Far-Field Development Platform in action:







Aaware’s technology makes significant use of the Zynq Z-7010 SoC’s programmable-logic and DSP processing capabilities to implement and accelerate the company’s sound-capture technologies including:



  • Noise and echo cancellation
  • Source detection and localization



You’ll find more technology details for the Aaware Far-Field Development Platform here.



Please contact Aaware directly for more information.





Cycle-exact 6502 processor clone fits in 0.77% of a Spartan-7 (and Spartan-3) FPGA, powers VIC-20 PC

by Xilinx Employee ‎10-03-2017 02:38 PM - edited ‎10-04-2017 09:38 AM (4,139 Views)


In the 1970s, nearly every low-end microcomputer and video game from the Apple II to the Atari 2600 ran the opcodes of one immensely successful 8-bit microprocessor: MOS Technology’s 6502. Ted Fried at MicroCore Labs has created a cycle-accurate clone of the 6502 processor called the MCL65 and instantiated it in FPGAs. First up, Fried instantiated a version of the MCL65 in a $109 Digilent Arty S7 dev board containing a Spartan-7 S50 FPGA. The 6502 processor core consumes a mere 0.77% (that’s 0.0077) of the device so, presumably, if you really felt like it, you could stamp more than 100 of these processor cores into a low-cost FPGA, assuming you knew what you wanted to do with that many 8-bit processors.


Here’s a photo showing a most unlikely bridging of old and new technologies: a MicroCore MCL65 processor core instantiated in a Spartan-7 FPGA on an Arty S7 dev board plugged into the 40-pin MOS Technology processor DIP socket of a Commodore VIC-20 running Commodore Basic.



MicroCore Labs MCL6502 processor on an Arty S7 board running a Commodore VIC-20.jpg 


MicroCore MCL65 processor in a Spartan-7 FPGA on an Arty S7 dev board plugged into a Commodore VIC-20 running Commodore Basic




Commodore introduced the VIC-20 in 1980. That’s 37 years ago.


MicroCore Labs then instantiated the same core in a Spartan-3 S250E FPGA, using 490 LUTs and just 10% of the device.




MicroCore Labs MCL6502 processor on a Spartan3.jpg 



MicroCore MCL65 processor in a Spartan-3 FPGA plugged into a Commodore VIC-20

Old technology running even older technology






According to a recent LinkedIn post, Fried plans to release the core as open source. Contact him directly for more information.



For more stories and tall tales about the MOS Technology 6502 processor, see Tekla S Perry’s great article from IEEE Spectrum titled  “Atari Alumni Talk About the Tall Tales They Told to Launch an Industry,” which chronicles a meeting in 2016, sponsored by the IEEE Silicon Valley History Committee, that included Atari founders Nolan Bushnell, Al Acorn, and Owen Rubin with Chuck Peddle, who designed the 6502 at MOS Technology, chiming in from the audience.






I joined Xilinx five years ago and have looked for a good, introductory book on FPGA-based design ever since because people have repeatedly asked me for my recommendation. Until now, I could mention but not recommend Max Maxfield’s book published in 2004 titled “The Design Warrior’s Guide to FPGAs”—not because it was bad (it’s excellent) but because it’s more than a decade out of date. Patrick Lysaght, a Senior Director in the Xilinx CTO's office, alerted me to a brand new book that I can now recommend to anyone who wants to learn about using programmable logic to design digital systems.


It’s titled “Digital Systems Design with FPGA: Implementation Using Verilog and VHDL” and it was written by Prof. Dr. Cem Ünsalan in the Department of Electrical and Electronics Engineering at Yeditepe University in İstanbul and Dr. Bora Tar, now at the Power Management Research Lab at Ohio State University in Columbus, Ohio. Their book will take you from the basics of digital design and logic into FPGAs; FPGA architecture including programmable logic, block RAM, DSP slices, FPGA clock management, and programmable I/O; hardware description languages with an equal emphasis on Verilog and VHDL; the Xilinx Vivado Design Environment; and then on to IP cores including the Xilinx MicroBlaze and PicoBlaze soft processors. The book ends with 24 advanced embedded design projects. It’s quite obvious that the authors intend that this book be used as a textbook in a college-level digital design class (or two), but I think you could easily use this well-written book for self-directed study as well.




Digital System Design with FPGA Book cover.jpg



“Digital Systems Design with FPGA: Implementation Using Verilog and VHDL” uses the Xilinx Artix-7 FPGA as a model for describing the various aspects of a modern FPGA and goes on two describe two Digilent development boards based on the Artix-7 FPGA: the $149 Basys3 and the $99 Arty (now called the Arty A7 to differentiate it from the newer Arty S7, based on a Spartan-7 FPGA, and Zynq-based Arty Z7 dev boards). These boards are great for use in introductory design classes and they make powerful, low-cost development boards even for experienced designers.


At 400 pages, “Digital Systems Design with FPGA: Implementation Using Verilog and VHDL” is quite comprehensive and so new that the publisher has yet to put the table of contents online, so I decided to resolve that problem by publishing the contents here so that you can see for yourself how comprehensive the book is:



1 Introduction

1.1 Hardware Description Languages

1.2 FPGA Boards and Software Tools

1.3 Topics to Be Covered in the Book


2 Field-Programmable Gate Arrays

2.1 A Brief Introduction to Digital Electronics

2.1.1 Bit Values as Voltage Levels

2.1.2 Transistor as a Switch

2.1.3 Logic Gates from Switches

2.2 FPGA Building Blocks

2.2.1 Layout of the Xilinx Artix-7 XC7A35T FPGA

2.2.2 Input / Output Blocks

2.2.3 Configurable Logic Blocks

2.2.4 Interconnect Resources

2.2.5 Block RAM

2.2.6 DSP Slices

2.2.7 Clock Management

2.2.8 The XADC Block

2.2.9 High-Speed Serial I/O Transceivers

2.2.10 Peripheral Component Interconnect Express Interface

2.3 PPGA-Based Digital System Design Philosophy

2.3.1 How to Think While Using FPGAS

2.3.2 Advantages and Disadvantages of FPGAS

2.4 Usage Areas of FPGAs

2.5 Summary

2.6 Exercises


3 Basys3 and Arty FPGA Boards

3.1 The Basys3 Board

3.1.1 Powering the Board

3.1.2 Input / Output

3.1.3 Configuring the FPGA

3.1.4 Advanced Connectors

3.1.5 External Memory

3.1.6 Oscillator / Clock

3.2 The Arty Board

3.2.1 Powering the Board

3.2.2 Input/Output

3.2.3 Configuring the FPGA

3.2.4 Advanced Connectors

3.2.5 External Memory

3.2.6 Oscillator / Clock

3.3 Summary

3.4 Exercises


4 The Vivado Design Suite

4.1 Installation and the Welcome Screen

4.2 Creating a New Project

4.2.1 Adding a Verilog File

4.2.2 Adding a VHDL File

4.3 Synthesizing the Project

4.4 Simulating the Project

4.4.1 Adding a Verilog Testbench File

4.4.2 Adding a VHDL Testbench File

4.5 Implementing the Synthesized Project

4.6 Programming the FPGA

4.6.1 Adding the Basys3 Board Constraint File to the Project

4.6.2 Programming the FPGA on the Basys3 Board

4.6.3 Adding the Arty Board Constraint File to the Project

4.6.4 Programming the FPGA on the Arty Board

4.7 Vivado Design Suite IP Management

4.7.1 Existing IP Blocks in Vivado

4.7.2 Generating a Custom IP

4.8 Application on the Vivado Design Suite

4.9 Summary

4.10 Exercises


5 Introduction to Verilog and VHDL

5.1 Verilog Fundamentals

5.1.1 Module Representation

5.1.2 Timing and Delays in Modeling

5.1.3 Hierarchical Module Representation

5.2 Testbench Formation in Verilog

5.2.1 Structure of a Verilog Testbench File

5.2.2 Displaying Test Results

5.3 VHDL Fundamentals

5.3.1 Entity and Architecture Representations

5.3.2 Dataflow Modeling

5.3.3 Behavioral Modeling

5.3.4 Timing and Delays in Modeling

5.3.5 Hierarchical Structural Representation

5.4 Testbench Formation in VHDL

5.4.1 Structure of a VHDL Testbench File

5.4.2 Displaying Test Results

5.5 Adding an Existing IP to the Project

5.5.1 Adding an Existmg IP in Verilog

5.5 2 Adding an Existing IP in VHDL

5.6 Summary

5.7 Exercises


6 Data Types and Operators

6.1 Number Representations

6.1.1 Binary Numbers

6.1.2 Octal Numbers

6.1.3 Hexadecimal Numbers

6.2 Negative Numbers

6.2.1 Signed Bit Representation

6.2.2 One’s Complement Representation

6.2.3 Two’s Complement Representation

6.3 Fixed- and Floating-Point Representations

6.3.1 Fixed-Point Representation

6.3.2 Floating-Point Representation

6.4 ASCII Code

6.5 Arithmetic Operations on Binary Numbers

6.5.1 Addition

6.5.2 Subtraction

6.5.3 Multiplication

6.5.4 Division

6.6 Data Types in Verilog

6.6.1 Net and Variable Data Types

6.6.2 Data Values

6.6.3 Naming a Net or Variable

6.6.4 Defining Constants and Parameters

6.6.5 Defining Vectors

6.7 Operators in Verilog

6.7.1 Arithmetic Operators

6.7.2 Concatenation and Replication Operators

6.8 Data Types in VHDL

6.8.1 Signal and Variable Data Types

6.8.2 Data Values

6.8.3 Naming a Signal or Variable

6.8.4 Defining Constants

6.8.5 Defining Arrays

6.9 Operators in VHDL

6.9.1 Arithmetic Operators

6.9.2 Concatenation Operator

6.10 Application on Data Types and Operators

6.11 FPGA Building Blocks Used In Data Types and Operators

6.11.1 Implementation Details of Vector Operations

6.11.2 Implementation Details of Arithmetic Operations

6.12 Summary

6.13 Exercises


7 Combinational Circuits

7.1 Basic Definitions

7.1.1 Binary Variable

7.1.2 Logic Function

7.1.3 Truth Table

7.2 Logic Gates

7.2.1 The NOT Gate

7.2.2 The OR Gate

7.2.3 The AND Gate

7.2.4 The XOR Gate

7.3 Combinational Circuit Analysis

7.3.1 Logic Function Formation between Input and Output

7.3.2 Boolean Algebra

7.3.3 Gate-Level Minimization

7.4 Combinational Circuit Implementation

7.4.1 Truth Table-Based Implementation

7.4.2 Implementing One-Input Combinational Circuits

7.4.3 Implementing Two-Input Combinational Circuits

7.4.4 Implementing Three-Input Combinational Circuits

7.5 Combinational Circuit Design

7.5.1 Analyzing the Problem to Be Solved

7.5.2 Selecting a Solution Method

7.5.3 Implementing the Solution

7.6 Sample Designs

7.6.1 Home Alarm System

7.6.2 Digital Safe System

7.6.3 Car Park Occupied Slot Counting System

7.7 Applications on Combinational Circuits

7.7.1 Implementing the Home Alarm System

7.7.2 Implementing the Digital Safe System

7.7.3 Implementing the Car Park Occupied Slot Counting System

7.8 FPGA Building Blocks Used in Combinational Circuits

7.9 Summary

7.10 Exercises


8 Combinational Circuit Blocks

8.1 Adders

8.1.1 Half Adder

8.1.2 Full Adder

8.1.3 Adders in Verilog

8.1.4 Adders in VHDL

8.2 Comparators

8.2.1 Comparators in Verilog

8.2.2 Comparators in VHDL

8.3 Decoders

8.3.1 Decoders in Verilog

8.3.2 Decoders in VHDL

8.4 Encoders

8.4.1 Encoders in Verilog

8.4.2 Encoders in VHDL

8.5 Multiplexers

8.5.1 Multiplexers in Verilog

8.5.2 Multiplexers in VHDL

8.6 Parity Generators and Checkers

8.6.1 Parity Generators

8.6.2 Parity Checkers

8.6.3 Parity Generators and Checkers in Verilog

8.6.4 Parity Generators and Checkers in VHDL

8.7 Applications on Combinational Circuit Blocks

8.7.1 Improving the Calculator

8.7.2 Improving the Home Alarm System

8.7.3 Improving the Car Park Occupied Slot Counting System

8.8 FPGA Building Blocks Used in Combinational Circuit Blocks

8.9 Summary

8.10 Exercises


9 Data Storage Elements

9.1 Latches

9.1.1 SR Latch

9.1.2 D Latch

9.1.3 Latches in Verilog

9.1.4 Latches in VHDL

9.2 Flip—Flops

9.2.1 D Flip-Flop

9.2.2 JK Flip-Flop

9.2.3 T Flip-Flop

9.2.4 Flip-Flops in Verilog

9.2.5 Flip-Flops in VHDL

9.3 Register

9.4 Memory

9.5 Read-Only Memory

9.5.1 ROM in Verilog

9.5.2 ROM in VHDL

9.5.3 ROM Formation Using IP Blocks

9.6 Random Access Memory

9.7 Application on Data Storage Elements

9.8 FPGA Building Blocks Used in Data Storage Elements

9.9 Summary

9.10 Exercises


10 Sequential Circuits

10.1 Sequential Circuit Analysis

10.1.1 Definition of State

10.1.2 State and Output Equations

10.1.3 State Table

10.1.4 State Diagram

10.1.5 State Representation in Verilog

10.1.6 State. Representation in VHDL

10.2 Timing in Sequential Circuits

10.2.1 Synchronous Operation

10.2.2 Asynchronous Operation

10.3 Shift Register as a Sequential Circuit

10.3.1 Shift Registers in Verilog

10.3.2 Shift Registers in VHDL

10.3.3 Multiplication and Division Using Shift Registers

10.4 Counter as a Sequential Circuit

10.4.1 Synchronous Counter

10.4.2 Asynchronous Counter

10.4.3 Counters in Verilog

10.4.4 Counters in VHDL

10.4.5 Frequency Division Using Counters

10.5 Sequential Circuit Design

10.6 Applications on Sequential Circuits

10.6.1 Improving the Home Alarm System

10.6.2 Improving the Digital Safe System

10.6.3 Improving the Car Park Occupied Slot Counting System

10.6.4 Vending Machine

10.6.5 Digital Clock

10.7 FPGA Building Blocks Used in Sequential Circuits

10.8 Summary

10.9 Exercises


11 Embedding a Soft-Core Microcontroller

11.1 Building Blocks of a Generic Microcontroller

11.1.1 Central Processing Unit

11.1.2 Arithmetic Logic Unit

11.1.3 Memory

11.1.4 Oscillator / Clock

11.1.5 General Purpose Input/Output

11.1.6 Other Blocks

11.2 Xilinx PicoBlaze Microcontroller

11.2.1 Functional Blocks of PicoBlaze

11.2.2 PicoBlaze in Verilog

11.2.3 PicoBlaze in VHDL

11.2.4 PicoBlaze Application on the Basys3 Board

11.3 Xilinx MicroBlaze Microcontroller

11.3.1 MicroBlaze as an IP Block in Vivado

11.3.2 MicroBlaze MCS Application on the Basys3 Board

11.4 Soft-Core Microcontroller Applications

11.5 FPGA Building Blocks Used in Soft—Core Microcontrollers

11.6 Summary

11.7 Exercises


12 Digital Interfacing

12.1 Universal Asynchronous Receiver/ Transmitter

12.1.1 Working Principles of UART

12.1.2 UART in Verilog

12.1.3 UART in VHDL

12.1.4 UART Applications

12.2 Serial Peripheral Interface

12.2.1 Working Principles of SPI

12.2.2 SPI in Verilog

12.2.3 SPI in VHDL

12.2.4 SPI Application

12.3 Inter-Integrated Circuit

12.3.1 Working Principles of I2C

12.3.2 I2C in Verilog

12.3.3 I2C in VHDL

12.3.4 I2C Application

12.4 Video Graphics Array

12.4.1 Working Principles of VGA

12.4.2 VGA in Verilog

12.4.3 VGA in VHDL

12.4.4 VGA Application

12.5 Universal Serial Bus

12.5.1 USB-Receiving Module in Verilog

12.5.2 USB-Receiving Module in VHDL

12.5.3 USB Keyboard Application

12.6 Ethernet

12.7 FPGA Building Blocks Used in Digital Interfacing

12.8 Summary

12.9 Exercises


13 Advanced Applications

13.1 Integrated Logic Analyzer 1P Core Usage

13.2 The XADC Block Usage

13.3 Adding Two Floating-Point Numbers

13.4 Calculator

13.5 Home Alarm System

13.6 Digital Safe System

13.7 Car Park Occupied Slot Counting System

13.8 Vending Machine

13.9 Digital Clock

13.10 Moving Wave Via LEDs

13.11 Translator

13.12 Air Freshener Dispenser

13.13 0bstacle-Avoiding Tank

13.14 Intelligent Washing Machine

13.15 Non-Touch Paper Towel Dispenser

13.16 Traffic Lights

13.17 Car Parking Sensor System

13.18 Body Weight Scale

13.19 Intelligent Billboard

13.20 Elevator Cabin Control System

13.21 Digital Table Tennis Game

13.22 Customer Counter

13.23 Frequency Meter

13.24 Pedometer


14 What Is Next?

14.1 Vivado High-Level Synthesis Platform

14.2 Developing a Project in Vivado HLS to Generate IP

14.3 Using the Generated IP in Vivado

14.4 Summary

14.5 Exercises







Note: In an acknowledgement in the book, the authors thank Xilinx's Cathal McCabe, an AE working within the Xilinx University Program, for his guidance and assistance. They also thank thank Digilent for allowing them to use the Basys3 and Arty board images and sample projects in the book.

How to power your Zynq or Spartan-7 devices: New 6-minute video contains many proven examples

by Xilinx Employee ‎09-27-2017 10:49 AM - edited ‎09-28-2017 08:06 AM (3,175 Views)


Different system performance, size, efficiency, and cost goals call for using different Xilinx devices and different solutions to power those devices. Xilinx has partnered with many leading power-semiconductor vendors to provide you with a wide selection of proven power designs and a brand new video discusses six of these designs for systems based on Xilinx Zynq UltraScale+ MPSoCs, Zynq Z-7000 SoCs, and Spartan-7 FPGAs in a shockingly brief six minutes. The video’s examples were provided by:



  • Infineon, as used in the Avnet UltraZed EG kit based on a Xilinx Zynq UltraScale+ MPSoC
  • TI, as used to power a Zynq UltraScale+ MPSoC in remote radio head applications
  • Maxim, as used to power a Zynq UltraScale+ MPSoC, also for remote radio head applications
  • Monolithic Power Systems (MPS) for Zynq Z-7000 SoCs
  • Exar for Zynq Z-7000 SoCs
  • Dialog Semiconductor for Spartan-7 FPGAs



One size can’t fit all when it comes to power.


Here’s the video:







For more information on these power solutions plus more, click here.





The just-announced MV1-D2048x1088-3D06 industrial laser-triangulation video camera from Photonfocus is based on a high-sensitivity, 2048x1088-pixel CMOSIS CMV2000 V3 CMOS image sensor and takes advantage of a new, real-time Photonfocus LineFinder algorithm running in the camera’s on-board Xilinx Spartan-6 FPGA to compute the laser line position with sub-pixel accuracy. Using this information, the camera computes the height profile of an object with no help needed from a host PC. You can program specific regions of interest within the camera imaging frame and the size of the region of interest determines the 3D triangulation rate, which ranges from 42 frames/sec for a 2048x1088-pixel region of interest in 2D+3D imaging mode to 18619 frames/sec for a 2048x11-pixel region of interest in 3D imaging mode.



Photonfocus MV1-D2048x1088-3D06 industrial laser-triangulation video camera .jpg 



Photonfocus MV1-D2048x1088-3D06 industrial laser-triangulation video camera based on a Xilinx Spartan-6 FPGA





Like many of its existing industrial video cameras, Photonfocus’ MV1-D2048x1088-3D06 is based on a Spartan-6 LX75T FPGA, which serves as a platform for the company’s smart industrial video cameras. Use of the Spartan-6 FPGA permitted Photonfocus to create an extremely flexible real-time, vision-processing platform that serves as a foundation for several very different types of cameras based on very different imaging sensors with very different sensor interfaces including:










For a limited time, Digilent is offering a $100 discount (that’s half off) on its Digital Discovery, a USB 24-channel logic analyzer (800Msamples/sec max acquisition rate @ 8 bits) and 16-channel digital pattern generator. (See “$199.99 Digital Discovery from Digilent implements 800Msample/sec logic analyzer, pattern generator. Powered by Spartan-6” for more information on this interesting little instrument.) To get the discount, you need to order at least $500 worth of items in the FPGA category on Digilent’s Web site.



Digilent Digital Discovery Fall Promo.jpg 




Digilent offers a truly wide selection of development and trainer boards in this category. Officially listed are boards based on Xilinx Spartan-6, Spartan-7, Artix-7, Kintex-7, and Virtex-7 FPGAs. You’ll also find several boards based on the Xilinx Zynq Z-7000 SoC including the Zybo, Arty Z7, ZedBoard, and the Python-based PYNQ-Z1. If you’re into vintage design, you’ll even find some older Xilinx devices on boards in this list including the CoolRunner-II CPLD and the Spartan-3E FPGA.


Why the deal on a Digilent Digital Discovery board and how does this deal work? Details in this new Digilent post by Kaitlyn Franz titled “Debugging Done Right.”






Guitar pedal aficionados will love this winning entry in the Xilinx University Program’s Open Hardware 2017 competition, Student Category. It’s a senior-year project from Vladi Litmanovich and Adi Mikler from Tel Aviv University and it’s based on an Avnet ZedBoard Dev Kit. The on-board Zynq Z-7020 SoC accepts audio from an electric guitar, passes it through four effects processors, sums the resulting audio, and ships the audio to a guitar amplifier. The result is a multi-effect processor similar to the stacked pedal processors favored by musicians for the last 50 years to achieve just the right sound for each song.


The on-board Zynq SoC implements the multi-effects processor’s user interface, based on the ZedBoard’s switches and LEDs, and implements four real-time audio effects using the Zynq SoC’s programmable logic:


  • Distortion and Overdrive
  • Octavelo (an Octaver plus Tremolo)
  • Tremolo
  • Delay


Here’s a block diagram of the audio-processing chain:



Guitar Multi-Effects Processor Block Diagram.jpg




There’s a complete description of the project with implementation details on GitHub.



Because this is music, a video demo is much better for illustrating these audio effects:










I really enjoy watching EEVBlog’s Dave Jones tear down a piece of equipment and give his analysis of the good and bad of the design under scrutiny. The subject of Jones’ latest teardown is a Rigol DL3021 200W Programmable DC Electronic Load and I watched this video with no expectation that it would offer up an Xcell Daily blog topic. After all, who uses an FPGA in an electronic load? Rigol, that’s who. There’s a Xilinx Spartan-6 LX9 FPGA at the heart of the Rigol DL3021 Electronic Load.


The interest in electronic loads has spiked recently. They’re great for testing power supplies but they’re really seeing more bench and manufacturing floor use as battery-powered products and utility-grade solar panels proliferate. You can find inexpensive, bare-board, bare-bones 60W and 150W electronic loads for as little as $20 or $30 on eBay. These low-end loads are based on a power FET and a fan sink originally intended for cooling gamer PC processors. The next step up gets you a $300, 150W load that actually looks like a bench instrument. Then there are the high-end programmable loads with more precision and multiple load channels that cost thousands of dollars. Most of the low-end loads are based one or more power FETs controlled by an inexpensive microcontroller. That’s all the electronic control they need for the time, voltage, and current resolution they provide.


The Rigol DL3021 that’s the subject of Dave Jones’ latest teardown is a $499, 200W, 150V, 40A, single-channel electronic load. There’s also a 350W version called the Rigol DL3031 and there are more expensive “A” versions of the Rigol DL3021 and DL3031 electronic loads with better and faster specs, more features, and color screens. This is also something that Jones’ opines about in his teardown video.



Rigol DL3000 Series Electronic Load.jpg 



So why is there a Xilinx Spartan-6 FPGA deep inside the design of the Rigol DL3021? Only Rigol knows for sure but I think there are visible clues in the design of the instrument. For starters, the instrument is designed with three major electronics subsystems. The main board holds the power FET array that does the electronic load’s heavy lifting. The power FETs are mechanically and thermally attached to a large aluminum box heat sink with a large fan on one end to force cooling air through the box. In the 200W Rigol DL3021 that Dave examines, the power FET array is partially populated. The missing power FETs likely appear in the 350W Rigol DL3031 and DL3031A loads.


The controller on the main power FET board is a Xilinx Spartan-6 LX9 FPGA. That’s a “small” FPGA with “only” 9152 logic cells, 576Kbits of memory, and 16 DSPs. For a “small” device, the Spartan-6 LX9 packs ample processing power to handle the real-time monitoring and control of the load’s power FETs. That’s also true for the faster “A” variants of the Rigol DL3021 and DL3031 electronic loads.



Rigol DL3000 Series Electronic Load Spartan-6 FPGA Detail.jpg 




You’ll also find a processor board plugged into a PCIe slot in the Rigol DL3021 load’s main board. The processor board obviously handles the instrument’s front panel and graphical user interface and the I/O ports on the back of the instrument including LXI Ethernet, USB, and RS-232. The processor board uses a Freescale/NXP i.MX283 Multimedia Applications Processor with an ARM 926EJ-S processor running at 454 MHz with 16Kbytes of instruction cache and 32Kbytes of data cache. The i.MX283 Applications processor operates the I/O ports and manages the front panel (the electronic load’s third major electronic subsystem) over the PCIe bus that spans the main board.


Why not use the i.MX283 processor to control everything? For precision time measurement and control, you really should not use a cached processor because you can’t depend on getting instrument-grade timing consistency from cached software running on a processor. You will get absolutely dependable, consistent, deterministic timing from an FPGA and in a precision electronic load, that’s exactly what you want.


Here’s Jone’s 45-minute EEVblog teardown video of the Rigol DL3021 Electronic Load with all of Dave’s insights and his usual, colorful commentary:















Ever seen an entire DSO fit inside of a probe? How about a wireless version? That describes the new €299, rechargeable, 30MHz, 200Msamples/sec IkaScope WS200 Wireless DSO from IkaLogic. Here’s a photo of the IkaScope in action:






The IkaScope DSO communicates over WiFi with computer or tablet




Here are the IkaScope’s specs:



IkaScope Specs.jpg


(Spec sheet here.)




Here’s a 90-second video showing the IkaScope in action:





The IkaScope will ship this month and IkaLogic plans to support wireless connection of the IkaScope to a variety of platforms including Windows, Linux, Mac OSx, iOS, and Android. Platform support apps will roll out over the next three months.


IkaLogic’s Ibrahim Kamal says that the IkaScope’s design is based on a Xilinx Spartan-3 FPGA, which was “quite enough” for the DSO’s 200MHz sample rate. Kamal says that the selected device “just fits the design.”


Except for the analog front end and the WiFi radio communications, the FPGA handles “almost everything” including:


  • Analog control
  • Triggering
  • Signal buffering
  • WiFi packet generation



Kamal also says that the Spartan-3 FPGAs internal memory offered a good way to save board space and the programmable I/O features were of great help when interfacing the FPGA to the analog front end’s ADC. In addition, the Spartan-3 FPGA communicates with the WiFi chip using a high-speed SPI, obviously built from the FPGA’s programmable logic. The design was created using VHDL.



Please contact IkaLogic directly for more information about the IkaScope.




Brandon Treece from National Instruments (NI) has just published an article titled “CPU or FPGA for image processing: Which is best?” on Vision-Systems.com. NI offers a Vision Development Module for LabVIEW, the company’s graphical systems design environment, and can run vision algorithms on CPUs and FPGAs, so the perspective is a knowledgeable one. Abstracting the article, what you get from an FPGA-accelerated imaging pipeline is speed. If you’re performing four 6msec operations on each video frame, a CPU will need 24msec (four times 6msec) to complete the operations while an FPGA offers you parallelism that shortens processing time for each operation and permits overlap among the operations, as illustrated from this figure taken from the article:




NI Vision Acceleration.jpg 



In this example, the FPGA needs a total of 6msec to perform the four operations and another 2msec to transfer a video frame back and forth between processor and FPGA. The CPU needs a total of 24msec for all four operations. The FPGA needs 8msec, for a 3x speedup.


Treece then demonstrates that the acceleration is actually much greater in the real world. He uses the example of a video processing sequence needed for particle counting that includes these three major steps:



  • Convolution filtering to sharpen the image
  • Thresholding to produce a binary image
  • Morphology to remove holes in the binary particles



Here’s an image series that shows you what’s happening at each step:



NI Vision Acceleration Steps.jpg 



Using the NI Vision Development Module for LabVIEW, he then runs the algorithm run on an NI cRIO-9068 CompactRIO controller, which is based on a Xilinx Zynq Z-7020 SoC. Running the algorithm on the Zynq SoC’s ARM Cortex-A9 processor takes 166.7msec per frame. Running the same algorithm but accelerating the video processing using the Zynq SoC’s integral FPGA hardware takes 8msec. Add in another 0.5msec for DMA transfer of the pre- and post-processed video frame back and forth between the Zynq SoC’s CPU and FPGA and you get about a 20x speedup.


A key point here is that because the cRIO-9068 controller is based on the Zynq SoC, and because NI’s Vision Development Module for LabVIEW supports FPGA-based algorithm acceleration, this is an easy choice to make. The resources are there for your use. You merely need to click the “Go-Fast” button.



For more information about NI’s Vision Development Module for LabVIEW and cRIO-9068 controller, please contact NI directly.





Digilent sent me an Analog Discovery 2 early last month. (See “Just arrived: Digilent’s $279 Analog Discovery 2 multi-instrument based on a Spartan-6 FPGA and a ton of ADI chips.”) The Analog Discovery 2 lists a two-channel USB digital oscilloscope (1MΩ, ±25V, differential, 14-bit, 100MS/s, 30MHz+ bandwidth) and a two-channel arbitrary function generator (±5V, 14-bit, 100MS/s, 12MHz+ bandwidth) among its many integrated instruments (all made possible by the reprogrammable capabilities of a Xilinx Spartan-6 FPGA) and I wanted to break these particular instruments out so I could use them more easily with conventional BNC-terminated probes and cables. Now Digilent sells an Analog Discovery BNC Adapter Board with four BNC connectors for $19.99 so the most reasonable thing to do would be to order one.



Digilent BNC Adapter.jpg



Digilent’s $19.99 BNC Adapter Board for the Analog Discovery 2




I built my own instead. Why not? How hard could it be?


My first inclination was to get four BNC connectors and an extruded aluminum box and drill out the box for the connectors over at TechShop San Jose where I am qualified to use one of the Jet end mills. (Cue the “Tim ‘the Toolman’ Taylor” alpha male grunting.) I did get as far as stopping by the most excellent Excess Solutions surplus electronics store in San Jose where I picked up four panel-mount BNCs, but then an even better solution occurred to me. (More grunting.)


I got a 4-channel OdiySurveil Cat 5 Passive HD Transceiver balun box from Amazon for $12.59. These balun boxes are designed to take as many as four channels of HD video from coax cables and route them over long lengths (1500m !!!) of twisted-pair cabling. The balun box’s beefy steel enclosure is pre-punched for four BNCs and comes complete with four BNC connectors connected to an RJ45, Cat5 Ethernet connector and an 8-pin Phoenix Contact screw-terminal block through a pcb securely mounted inside of the box. It’s twelve bucks and change, nicely finished with no drilling or milling required, delivered to your door in two days by Amazon Prime.



Original Balun Box.jpg 



OdiySurveil Cat 5 Passive HD Transceiver




Here’s what it looks like inside:



Original Balun Box Interior.jpg 



OdiySurveil Cat 5 Passive HD Transceiver Unmodified Interior




Sure, there are some pesky balun transformers and a few other unneeded passive components on the board but I quickly popped those off the pcb with a screwdriver (more grunting), cleaned up the pads, and shorted out the appropriate connections on the board with eight short jumper wires. I still know which end of the soldering iron to hold, apparently.




Modified Balun Box Interior.jpg



OdiySurveil Cat 5 Passive HD Transceiver Modified Interior




Then, I needed to decide whether to use the box’s Phoenix Contact terminal block or the RJ45 connector to connect to the Analog Discovery 2’s double-row, 0.1-inch header strip. At first, I thought I’d use the terminal block but the more I considered that RJ45 connector, the better it looked. A quick trip over to IT here at Xilinx secured a Cat6 cable in a huge box of orphaned Ethernet cables.


I snipped one end off of the cable and then cut the outer insulation off of the cable end. There were the four unshielded, twisted-wire pairs that I needed for the connection to the Analog Discovery 2. I also ordered a reasonably large kit of crimpable “Dupont” pins with plastic headers from eBay for about $9 (including shipping).


Note: Somehow in the last 30 years, I missed the transition point where “Berg pins” became “Dupont pins.”



When everything arrived, I stripped the twisted pairs, crimped on the Dupont pins, and inserted the pins into a 2x5-pin plastic header.


A big piece of heat-shrink tubing cleaned up everything and there you go, one bulletproof breakout box. Finally, I made a printable label using Visio and attached it to the top of the box, which now looks like this:




Finished Breakout Box.jpg



Finished Analog Discovery 2 Breakout Box



Works great.



(Note: This isn't a great example of a wise make-versus-buy decision. If I weren't blogging this project, I'd probably just buy Digilent's adapter board.)




For more information about the Analog Discovery 2, please contact Digilent directly and see these previous Xcell Daily posts:






Ag Tech Precision Spray Autopilot uses Aerotenna’s new, Zynq-based Smart Drone Dev Platform

by Xilinx Employee ‎09-11-2017 11:45 AM - edited ‎09-11-2017 04:23 PM (4,133 Views)


Last week, Aerotenna announced its ready-to-fly Smart Drone Development Platform, based on its OcPoC with Xilinx Zynq Mini Flight Controller. Other components in the $3499 Drone Dev Platform include Aerotenna’s μLanding radar altimeter, three Aerotenna μSharp-Patch collision avoidance radar sensors, one Aerotenna CAN hub, a remote controller, and a pre-assembled quadcopter airframe:



Aerotenna Drone Dev Platform.jpg 




The OcPoC flight controller uses the Zynq SoC’s additional processing power and I/O flexibility—embodied in the on-chip programmable FPGA fabric and programmable I/O—to handle the immense sensor load presented to a drone in flight through sensor fusion and on-board, real-time processing. The Aerotenna OcPoC flight controller handles more than 100 sense inputs.


How well do all of these Aerotenna drone components work together? Well, one indication of how well integrated they are is another announcement last week—made jointly by Aerotenna and UAVenture of Switzerland—to roll out the Precision Spray Autopilot—a “simple plug-and-play solution, allowing quick and easy integration into your existing multirotor spraying drones.” This piece of advanced Ag Tech is designed to create smart drones for agricultural spraying applications.



Precision Spray Autopilot.jpg 


The Precision Spray Autopilot in Action




The Precision Spray Autopilot’s  features include:



  • Fly spray missions from a tablet or with a remote control
  • Radar-based, high-performance terrain following
  • Real-time adjustment of flight height and speed
  • In-flight spray-rate monitoring and control
  • Auto-refill and return to mission
  • Field-tested in simple and complex fields



What’s even cooler is this 1-minute demo video of the Precision Spray Autopilot in action:








If you’re teaching digital design (or learning it), then the Digilent Nexys4-DDR FPGA Trainer Board based on the Xilinx Artix-7 A100T FPGA is a very good teaching platform because it provides you with ample programmable logic to work with (15,850 logic cells, 13.14Mbits of on-chip SRAM, and 240 DSP48E1 slices) along with 128Mbytes of DDR2 SDRAM and a good mix of peripherals and it’s paired with the industry’s most advanced system design tool—Xilinx Vivado.


RS University and Digilent have partnered to provide academics with a free half-day workshop on teaching digital systems using FPGAs (and the Nexys4-DDR Trainer Board). The half-day workshop will take place at Coventry U. on October 25th 2017 in the Engineering and Computing Building. (More info here, registration here.)



Digilent Nexys4-DDR Trainer Board.jpg 



Avnet publishes article that serves as a Buyer’s Guide for its Zynq-based Dev Boards and SOMs

by Xilinx Employee ‎08-29-2017 02:04 PM - edited ‎08-30-2017 05:25 AM (7,140 Views)


Avnet just published an article titled “Zynq SoMs Decrease Customer Development Times and Costs” that provides a brief-but-good buyer’s guide for several of its Zynq-based dev boards and SOMs including the MicroZed (based on the Xilinx Zynq Z-7010 or Z-7020 SoCs), PicoZed (based on the Zynq Z-7010, 7015, 7020, or Z-7030 SoCs), and the Mini-Module Plus (based on the Xilinx Zynq Z-7045 or Z-7100 SoCs). These three boards give you pre-integrated access to nearly the entire broad line of Zynq Z-7000 dual-ARM-core SoCs.



Avnet PicoZed SOM.jpg 


Avnet PicoZed SOM



The article also lists several important points to consider when contemplating a make-or-buy decision for a Zynq-based board including:



  • “Designing the high-speed DDR3 interface for Zynq requires a deep understanding of transmission line theory. The PCB layout calls for matching trace lengths, controlling impedances and using proper termination. If designed improperly, several PCB spins and months of development times can be wasted.”



  • “Avnet jumpstarts Zynq-based software, firmware and HDL development by providing the necessary tools to get started. MicroZed, PicoZed and Avnet’s entire portfolio of Zynq-based SoM have board support packages (BSPs) available.”



Whichever way you choose to go, the Zynq SoC (and the more powerful Zynq UltraScale+ MPSoC), give you a unique blend of software-based processor horsepower and programmable-logic that delivers hardware-level performance when and where you need it in your design.




Carnegie Robotics currently uses a Spartan-6 FPGA in its GigE 3D imaging sensors to fuse video feeds from the two video cameras in the stereo pair; to generate 2.1 billion correspondence matches/sec from the left and right camera video streams; to then generate 15M points/sec of 3D point-cloud data from the correspondence matches; which in turn helps the company’s robots to make safe movement decisions and avoid obstacles while operating in unknown, unstructured environments. The company’s 3D sensors are used in unmanned vehicles and robots, which generally weigh between 100 and 1000 pounds, operate in a variety of such unstructured environments in applications as diverse as agriculture, building maintenance, mining, and battlefield mine sweeping. All of this is described by Carnegie Robotics’ CTO Chris Osterwood in a new 3-minute “Powered by Xilinx” video, which appears below.


The company is a spinout of Carnegie Mellon University’s National Robotics Engineering Center (NREC), one of the world’s premier research and development organizations for advanced field robotics, machine vision and autonomy. It offers a variety of 3D stereo cameras including:



  • The MultiSense S7, a rugged, high-resolution, high-data-rate, high-accuracy GigE 3D imaging sensor.
  • The MultiSense S21, a long-range, low-latency GigE imaging sensor based on the S7 stereo-imaging sensor but with wide (21cm) separation between the stereo camera pair for increased range
  • The MultiSense SL, a tri-modal GigE imaging sensor that fuses high-resolution, high-accuracy 3D stereo vision from the company’s MultiSense S7 stereo-imaging sensor with laser ranging (0.4 to 10m).




Carnegie Robotics MultiSense SL Tri-Modal 3D Imaging Sensor.jpg



Carnegie Robotics MultiSense SL Tri-Modal 3D Imaging Sensor





All of these Carnegie Robotics cameras consume less than 10W, thanks in part to the integrated Spartan-6 FPGA, which uses 1/10 of the power required by a CPU to generate 3D data from the 2.1 billion correspondence matches/sec. The Multisense SL served as the main perceptual “head” sensor for the six ATLAS robots that participated in the DARPA Robotics Challenge Trials in 2013. Five of these robots placed in the top eight finishers during the DARPA trials.


The video below also briefly discusses the company’s plans to migrate to a Zynq SoC, which will allow Carnegie Robotics’ sensors to perform more in-camera computation and will further reduce the overall robotic system’s size, weight, power consumption and image latency. That’s a lot of engineering dimensions all being driven in the right direction by the adoption of the more integrated Zynq SoC All Programmable technology.


Earlier this year, Carnegie Robotics and Swift Navigation announced that they were teaming up to develop a line of multi-sensor navigation products for autonomous vehicles, outdoor robotics, and machine control. Swift develops precision, centimeter-accurate GNSS (global navigation satellite system) products. The joint announcement included a photo of Swift Navigation’s Piksi Multi—a multi-band, multi-constellation RTK GNSS receiver clearly based on a Zynq Z-7020 SoC.





Swift Piksi Multi GNSS Receiver.jpg 



Swift Navigation Piksi Multi multi-band, multi-constellation RTK GNSS receiver, based on a Zynq SoC.




There are obvious sensor-fusion synergies between the product-design trajectory based on the Zynq SoC as described by Chris Osterwood in the “Powered by Xilinx” video below and Swift Navigation’s existing, Zynq-based Piksi  Multi GNSS receiver.


Here’s the Powered by Xilinx video:







Good news. Spartan-7 7S50FT196 ES devices with 52,160 logic cells and 120 DSP48E1 slices will be available starting this month. However, maybe you’re planning on using a smaller member of the Spartan-7 family like the 7S25, 7S15, or 7S6 and you’d like to start on the hardware design including the pcb now. Is there a way?


Yes, there is.


Start your development now with the Spartan-7 7S50FT196 ES FPGA in the 15x15mm FTGB196 package with 100 3.3V SelectIO HR I/O pins. That Spartan-7 FPGA in that package is footprint-compatible with the 7S25, 7S15, and 7S6 devices in the same package. It’s the smallest package that’s footprint-compatible across all four devices and it takes you down to the Spartan-7 7S6 FPGA’s 6000 logic cells and 10 DSP slices should one of the smaller devices meet your needs. You get a head start on your development program with no need for a future pcb turn due to the component change out. You also get an immediate hardware upgrade path should your future needs demand a larger FPGA.


As they say, “Operators are standing by.”



Spartan-7 Family Table with FTGB196 Pin Compatibility.jpg






MYIR Tech’s 91x63mm Z-turn Lite is a flexible SBC (single-board computer)/dev board that’s offered in a $69 version populated with a Xilinx Zynq Z-7007S SoC with one ARM Cortex-A9 processor core or in a $75 version populated with a dual-core Xilinx Zynq Z-7010 SoC. The two versions of the Zynq SoC are pin-compatible, making it much easier for MYIR to offer two versions of the board using the same pcb layout. Both versions of the Z-turn Lite dev board also include 512Mbytes of DDR3 SDRAM, eMMC Flash memory, QSPI Flash memory, and a TF (SD) card slot.




MYIR Tech Zynq-Based Z-turn Lite Top.jpg 


MYIR Tech Z-turn Lite SBC (single-board computer)/dev board (top)




The above photo of the top of the Z-turn Lite board initially threw me off, as it may you. It looks like the board has a few standard I/O ports (10/100/1000 Ethernet, USB OTG, UART, and JTAG), but no ports that break out the Zynq SoC PL’s (programmable logic’s) many programmable I/O pins for I/O-centric applications such as sensor fusion. That’s why you need to look at the bottom of the board as well because that’s where you’ll find the breakout/expansion connector for an additional 84 PL I/O pins:




MYIR Tech Zynq-Based Z-turn Lite Bottom.jpg 


MYIR Tech Z-turn Lite SBC (single-board computer)/dev board (bottom)




MYIR’s use of the single- and dual-core Zynq SoC with the same board layout gives you a lot of scalability with respect to PS (processing system) horsepower and some scalability with respect to PL capacity. (Feel free to use this trick yourself.) The PL in the Zynq Z-7007S SoC has 23K logic cells and 66 DSP48E1 slices. The PL in the Zynq Z-7010 SoC has 28K logic cells and 80 DSP48E1 slices.


For more information about the Z-turn Lite SBC/dev board, please contact MYIR directly.


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.