Last month, Xilinx Product Marketing Manager Darren Zacher presented a Webinar on the extremely popular $99 Arty Dev Kit, which is based on a Xilinx Artix-7 A35T FPGA, and it’s now online. If you’re wondering if this might be the right way for you to get some design experience with the latest FPGA development tools and silicon, spend an hour with Zacher and Arty. The kit is available from Avnet and Digilent.
For more information about the Arty Dev Kit, see: “ARTY—the $99 Artix-7 FPGA Dev Board/Eval Kit with Arduino I/O and $3K worth of Vivado software. Wait, What????”
There’s considerable 5G experimentation taking place as the radio standards have not yet gelled and researchers are looking to optimize every aspect. SDRs (software-defined radios) are excellent experimental tools for such research—NI’s (National Instruments’) SDR products especially so because, as the Wireless Communication Research Laboratory at Istanbul Technical University discovered:
“NI SDR products helped us achieve our project goals faster and with fewer complexities due to reusability, existing examples, and the mature community. We had access to documentation around the examples, ready-to-run conceptual examples, and courseware and lab materials around the grounding wireless communication topics through the NI ecosystem. We took advantage of the graphical nature of LabVIEW to combine existing blocks of algorithms more easily compared to text-based options.”
Researchers at the Wireless Communication Research Laboratory were experimenting with UFMC (universal filtered multicarrier) modulation, a leading modulation candidate technique for 5G communications. Although current communication standards frequently use OFDM (orthogonal frequency-division multiplexing), it is not considered to be a suitable modulation technique for 5G systems due to its tight synchronization requirements, inefficient spectral properties (such as high spectral side-lobe levels), and cyclic prefix (CP) overhead. UFMC has relatively relaxed synchronization requirements.
The research team at the Wireless Communication Research Laboratory implemented UFMC modulation using two USRP-2921 SDRs, a PXI-6683H timing module, and a PXIe-5644R VST (Vector signal Transceiver) module from National Instruments (NI)–and all programmed with NI’s LabVIEW systems engineering software. Using this equipment, they achieved better spectral results over the OFDM usage and, by exploiting UFMC’s sub-band filtering approach, they’ve proposed enhanced versions of UFMC. Details are available in the NI case study titled “Using NI Software Defined Radio Solutions as a Testbed of 5G Waveform Research.” This project was a finalist in the 2017 NI Engineering Impact Awards, RF and Mobile Communications category, held last month in Austin as part of NI Week.
5G UFMC Modulation Testbed based on Equipment from National Instruments
Note: NI’s USRP-2921 SDR is based on a Xilinx Spartan-6 FPGA; the NI PXI-6683 timing module is based on a Xilinx Virtex-5 FPGA; and the PXIe-5644R VST is based on a Xilinx Virtex-6 FPGA.
My very good friend Jack Ganssle, the firmware expert and consultant, publishes a free semi-monthly newsletter called the Embedded Muse for engineers working on embedded systems and the latest issue, #330, contains this testimonial for Saleae and its FPGA-based logic analyzers:
“Another reader has nice things to say about Saleae. Dan Smith writes:
“I've owned Saleae logic analyzers since 2011, starting with their original (and at that time, only) logic analyzer, aptly named "Logic", which was an 8-channel unit and very good host-side software to go with it. Never had a problem with the unit or the software.
“Fast forward to a Saturday morning in 2017, where I was debugging a strange bus timing problem under a tight project deadline. I'd woken up early because I couldn't "turn my mind off" from the night before. I was using a newer, more expensive model with features I needed (analog capture, must higher bandwidth, etc.) For some reason, the unit wouldn't enumerate when I plugged it in that morning. I contacted support on a Saturday morning; to my surprise, I had a response later that day from Mark, one of the founders and also the primary architect and developer of the host-side software. After discussing the problem and my situation, they sent me a replacement unit right away, even before the old unit was returned and inspected. I'd also received excellent support a few weeks earlier getting the older Logic unit working with a strange combination of MacBook Pro, outdated version of OSX and an uncooperative USB port.
“My point is simply that even though the Saleae products -- hardware and software -- are excellent, it's their customer service that has earned my loyalty. Too often, great service and support go unmentioned; in my case, it's what saved me. And yes, I debugged the problem that weekend and met the deadline!”
Saleae engineers its compact, USB-powered logic analyzers using FPGAs like the Xilinx Spartan-6 LX16 FPGA used in its Logic Pro 8 logic analyzer/scope. (See “Jack Ganssle reviews the Saleae Logic Pro 8 logic analyzer/scope, based on a Spartan-6 FPGA” and “Compact, 8-channel, 500Msamples/sec logic analyzer relies on Spartan-6 FPGA to provide most functions.”) Although the Spartan-6 FPGA is a low-cost device, its logic and I/O programmability are a great match for the logic analyzer’s I/O and data-capture needs.
Saleae Logic Pro 8 logic analyzer/scope
“Cancer” is one of the scariest words in the English language and 1.6 million people in the US alone will be diagnosed with some form of cancer just this year. About 320,000 of those diagnosed cases will be eligible for proton therapy but there are currently only 24 proton treatment centers in the US. The math says that about 5% of the eligible patients will receive proton therapy and the rest will be treated another way. That’s not a great solution and this graph illustrates why:
Protons can deliver more energy to the tumor and less energy to surrounding healthy tissue.
One reason that there are few proton-treatment centers in the US is because you need a synchrotron or cyclotron to create a sufficiently strong beam of high-energy protons. ProNova is developing a lower-cost, smaller, lighter, and more energy efficient proton-therapy system called the ProNova SC360 will make proton therapy more available to cancer patients. It’s doing that by developing a cyclotron using superconducting magnets, a multiplexed delivery system that can deliver the resulting proton beam to as many as five treatment rooms, and a treatment gantry that can securely hold and position the patient while precisely delivering a 4mm-to-8mm proton beam to the tumor with 1mm positioning accuracy.
ProNova SC360 Proton Therapy System
It takes a lot of real-time control to do all of this, so ProNova developed the DDS (Dose Delivery System) for the SC360 using three National Instruments (NI) sbRIO-9626 embedded controllers, which incorporate a Xilinx Spartan-6 LX45 FPGA for real-time control. The three controllers implement four specific tasks:
A treatment plan contains a set of locations, or spots, in 3D space (horizontal-X, vertical-Y, depth-Z) that each receive a prescribed radiological dose. The system delivers the high-energy protons to the tumor by scanning the variable-intensity beam back and forth through the tumor volume, as shown below:
In addition, these subsystems are responsible for safely removing the beam from the treatment room during spot transitions and enforcing safety interlocks. Hard-wired control signals pass between the Spartan-6 FPGAs on each of the sbRIO controllers to signal spot completion, spot advancement, and treatment faults. Each of these three sbRIO applications is programmed using NI’s LabVIEW systems engineering software.
Here’s a block diagram of the ProNova DDS beam-control and -positioning system:
Here’s an example of the kinds of signals generated by this control system:
Proton-beam spot durations are on the order of 5msec and spot transitions take less than 800μsec.
ProNova received FDA approval for the SC360 earlier this year and plans to start treating the first patients later this year at the Provision Center for Proton Therapy in Knoxville, Tennessee.
Here’s a 4-minute video explaining the system in detail. It starts sort of over the top, but quickly settles down to the facts:
This life-changing project won a 2017 NI Engineering Impact Award in the Industrial Machinery and Control category last month at NI Week and the 2017 Humanitarian Award. It is documented in this NI case study.
Medium- and heavy-duty fleet vehicles account for a mere 4% of the vehicles in use today but they consume 40% of the fuel used in urban environments, so they are cost-effective targets for innovations that can significantly improve fuel economy. Lightning Systems (formerly Lightning Hybrids) has developed a patented hydraulic hybrid power-train system called ERS (Energy Recovery System) that can be retrofitted to new or existing fleet vehicles including delivery trucks and shuttle buses. This hybrid system can reduce fleet fuel consumption by 20% and decrease NOx emissions (the key component of smog) by as much as 50%! In addition to being a terrific story about energy conservation and pollution control, the development of the ERS system tells a great story about using National Instruments’ (NI’s) comprehensive line of LabVIEW-compatible CompactRIO (cRIO) and Single-Board RIO (sbRIO) controllers to develop embedded controllers destined for production.
Like an electric hybrid vehicle power train, an ERS-enhanced power train recovers energy during vehicle braking and adds that energy back into the power train during acceleration. However, Lightning Systems’ ERS stores the energy using hydraulics instead of electricity.
Here are the components of the ERS retrofit system, shown installed in series with a power train’s drive shaft:
Major components in the Lightning Systems ERS Hybrid Retrofit System
The power-transfer module (PTM) in the above image drives the hydraulic pump/motor during vehicle braking, pumping hydraulic fluid into the high- and low-pressure accumulator tanks, which act like mechanical batteries that store energy in tanks pressurized by nitrogen-filled bladders. When the vehicle accelerates, the pump/motor operates as a motor driven by the pressurized hydraulic fluid’s energy stored in the accumulators. The hydraulic motor puts energy back into the vehicle’s drive train through the PTM. A valve manifold controls the filling and emptying of the accumulator tanks during vehicle operation and all of the ERS control sequencing is handled by a National Instruments (NI) RIO controller programmed using NI’s LabVIEW system development software. All of NI’s Compact and Single-Board RIO controllers incorporate a Xilinx FPGA or a Xilinx Zynq SoC to provide real-time control of closed-loop systems.
Lightning Systems has developed four generations of ERS controllers based on NI’s CompactRIO and Single-Board RIO controllers. The company based its first ERS prototype controller on an 8-slot NI CRIO-9024 controller and deployed the design in pilot systems. A 2nd-generation ERS prototype controller used a 4-slot NI cRIO-9075 controller, which incorporates a Xilinx Spartan-6 LX25 FPGA. The 3rd-generation ERS controller used an NI sbRIO-9626 paired with a custom daughterboard. The sbRIO-9626 incorporates a larger Xilinx Spartan-6 LX45 FPGA and Lightning Systems fielded approximately 100 of these 3rd-generation ERS controllers.
Three generations of Lightning Systems’ ERS controller (from left to right: v2, v3, and v4) based on
National Instruments' Compact RIO and Single-Board RIO controllers
For its 4th-generation ERS controller, the company is using NI’s sbRIO-9651 single-board RIO SOM (system on module), which is based on a Xilinx Zynq Z-7020 SoC. The SOM is also paired with a custom daughterboard. Using NI’s Zynq-based SOM reduces the controller cost by 60% while boosting the on-board processing power and adding in a lot more programmable logic. The SOM’s additional processing power allowed Lightning Systems to implement new features and algorithms that have increased fuel economy.
Lightning Systems v4 ERS Controller uses a National Instruments sbRIO-9651 SOM based on a
Xilinx Zynq Z-7020 SoC
Lightning Systems is able to easily migrate its LabVIEW code throughout these four ERS controller generations because all of NI’s CompactRIO and Single-Board RIO controllers are software-compatible. In addition, this controller design allows easy field upgrades to the software, which reduces vehicle downtime.
Lightning Systems has developed a modular framework so that the company can quickly retrofit the ERS to most medium- and heavy-duty vehicles with minimal new design work or vehicle modification. The PTM/manifold combination mounts between the vehicle’s frame rails. The accumulators can reside remotely, wherever space is available, and connect to the valve manifold through high-pressure hydraulic lines. The system is designed for easy installation and the company can typically convert a vehicle’s power train into a hybrid system in less than a day. Lightning Systems has already received orders for ERS hybrid systems from customers in Alaska, Colorado, Illinois, and Massachusetts, as well as around the world in India and the United Kingdom.
Typical Lightning Systems ERS Installation
This project recently won a 2017 NI Engineering Impact Award in the Transportation and Heavy Equipment category and is documented in this NI case study.
Blood pumps for extracorporeal life support (ECLS) are used in medical therapies to support failing human organ systems. Conventional blood pumps use mechanically driven impellers supported on bearings and these impellers are prone to stress and heat concentration on the shaft-bearing contact areas, which increases hemolysis (rupture or destruction of red blood cells) and thrombosis (blood clots). Both are bad news in the bloodstream. In addition, ECLS applications require that any components that touch the blood be disposable, to prevent infection.
The Precision Motion Control Lab at MIT and Ension, Inc. are developing a new type of blood pump with a low-cost, disposable, bearingless impeller to reduce costs in ECLS applications. Magnetic levitation through reluctance coupling replaces the impeller’s mechanical bearings and hysteresis coupling drives the impeller using magnetically induced torque, which eliminates the mechanical drive shaft. Both magnetic forces are supplied by a 12-coil electromagnet in this new design.
To further reduce the cost of the replaceable rotor/impeller assembly, the design team substituted a steel ring made of type D2 tool steel for the normal permanent magnet in the rotor. The “D2 ring” is inductively magnetized by the coupled magnetic fields from the stator electromagnets. Reluctance coupling pulls the outer edges of the ring, causing it to levitate, while a rotating magnetic field generated by the twelve stator coils imparts rotational torque on the D2 ring, causing the impeller to spin.
Controlling the stator coils to produce the correct magnetic fields for levitation and motion requires closed-loop control of all twelve electromagnets in the stator. The design team chose the National Instruments (NI) MyRIO Student Embedded Controller because it’s easily programmed in NI’s LabVIEW systems engineering software package and because the MyRIO’s integrated Xilinx Zynq Z-7010 SoC incorporates the high-speed programmable logic needed to provide real-time, deterministic, closed-loop stator control.
Here’s a photo of a prototype bearingless motor for this design, showing the 12-magnet stator and the D2 ring rotor on the left and a National Instruments MyRIO controller on the right (and yes, that’s the Xilinx Zynq SoC peeking through the plastic window in the MyRIO controller):
Closed-loop feedback comes from four eddy-current sensors, which are sense coils driven by Texas Instruments LDC1101 16-bit LDCs (inductance-to-digital converters). The four LDC boards appear in the upper left part of the above photo. The four eddy-current sensors are organized in two pairs that differentially measure real-time rotor position. Each sensor connects to the MyRIO controller and the Zynq SoC using individual 5-wire SPI interfaces, as shown below:
The MyRIO controller drives the blood pump's 12-phase stator through twelve analog channels—built from an NI cRIO-9076 4-slot CompactRIO controller (with an integrated Xilinx Virtex-5 LX45 FPGA), three NI-9263 voltage output modules, and one NI 9205 voltage input module—and twelve custom linear transconductance power amplifiers. The flexibility this setup provides permits the design team to experiment with and refine different motor-control algorithms.
Closed-loop, drive-with-feedback control algorithms are implemented in the Zynq SoC’s programmable logic because software-based microcontroller or microprocessor control loops would not have been fast enough or sufficiently deterministic. Although this controller design is capable of implementing a 46KHz control loop, the actual loop rate is 10KHz because that’s fast enough for this electromechanical system. The Zynq SoC’s 32-bit ARM Cortex-A9 processors in the MyRIO controller implement the system’s user interface and data logging.
This project won a 2017 NI Engineering Impact Award in the Advanced Research category and is documented in this NI case study.
Last week in Austin at NI Week, MIT Professor Dr. Dave Trumper and Senior Software and Electrical Engineer Jared Kirschner from Continuum demonstrated a “Human Physiome on a Chip,” a collection of human organ tissues linked by nutrient flows and controlled by a National Instruments (NI) MyRIO controller, which is based on a Xilinx Zynq Z-7010 SoC. The Human Physiome chip, developed by an MIT team headed by Dr. Linda Griffith along with Continuum, contains wells for as many as ten different human cells from organs including liver, brain, gut, heart, kidney, pancreas, and bone marrow. The purpose of this “organ systems under test” device is to study the way human organ systems may respond to various drug therapies in vitro. The work is funded by DARPA.
7-Organ Version of MIT’s Human Physiome Chip
The nutrient system for the Human Physiome chip consists of as many as a dozen micropumps. Each micropump consists of three small pneumatic valves operated in a sequence that moves the fluid nutrient through the chip. Continuum developed a micropump controller using NI’s MyRIO student controller, one of many Zynq-based products in the NI RIO line of controllers. This controller has 36 control channels (12 pumps times three valves per pump) and pressure sensing. Software to operate the controller is based on NI’s LabVIEW system development software. Continuum needed to develop a system that could control twelve micropumps with a 1KHz update rate and chose the Zynq-based MyRIO controller as the appropriate design solution for this application.
Continuum built its Micropump controller around the Zynq-based NI MyRIO Platform
Here’s a 7-minute NI Week video describing this extremely unusual control application:
Note: For more information about the MyRIO controller, see “How Xilinx All Programmable technology has fundamentally changed business at National Instruments.”
Blue Origin New Shepard Rocket Launch – photo courtesy of Blue Origin
Jason Smith, an Instrumentation and Controls Engineer at commercial space pioneer Blue Origins, spoke during a keynote at last week’s NI Week in Austin, TX. According to Smith, Blue Origin’s corporate mission is to “see millions of people living and working in space.” To that end, the company is developing two rocket systems. The first to be tested is the New Shepard, a fully reusable, vertical-takeoff, vertical-landing space vehicle designed for suborbital missions. (Alan Shepard was the first American to rocket into space aboard the Freedom 7 Mercury space capsule atop a Redstone rocket in a suborbital mission.) The New Shepard rocket uses one of the company’s 3rd-generation BE-3 engines, which burns liquid hydrogen using liquid oxygen as the oxidizer. Smith said that Blue Origin has already successfully launched and landed its New Shepard rockets five times and the first crewed flight is scheduled for next year.
The company is also developing the more powerful New Glenn rocket for low-Earth-orbit missions based on seven of its 4th-generation BE-4 engines, which burns liquefied natural gas and again using a liquid oxygen oxidizer. (John Glenn became the first American to reach Earth orbit in 1962 in the Friendship 7 Mercury capsule atop an Atlas rocket.) Blue Origin expects the BE-4 engine to be ready for testing sometime this year and United Launch Alliance (ULA)–maker of the Atlas V and Delta IV launch systems–has chosen the BE-4 engine to power its next generation Vulcan launch vehicle. The New Glenn rocket is designed to be reused as many as 100 times.
Blue Origin’s BE-4 Rocket Engine
Smith is responsible for developing test techniques and test cells to ensure that everything Blue Origin builds—from parachute to guidance fins to reusable rocket engines—works in rigorous launch-and-land missions. To ensure that all rocket components work as designed, Blue Origin builds dedicated test stands with thousands of monitoring and control channels based on National Instruments’ (NI’s) equipment and LabVIEW and TestStand software. Although earlier test systems at Blue Origin were based on NI’s PXI modular instrumentation and CompactDAQ data acquisition systems, Smith is standardizing the design of his newest test systems using NI’s cRIO-9068 8-slot CompactRIO extended-temperature controller because these systems provide the needed autonomy and robustness required by the demanding test-cell environments. NI’s cRIO-9068 incorporates a Xilinx Zynq Z-7020 SoC, which provides that autonomy and robust control.
NI cRIO-9068 CompactRIO Extended-Temperature Controller based on a Xilinx Zynq Z-7020 SoC
Here’s a 7-minute video of Jason Smith’s keynote at NI Week that includes some great shots of the New Shepard rocket taking off and landing. (I advise you to turn up the volume for this one and watch the amazing thrust vectoring as the rocket sticks its landing.)
This may shock you, but Xilinx continues to be in the CPLD business. I was reminded of that point this week when I got an email blast about the Xilinx CoolRunner-II CPLD family—first introduced about 15 years ago—which is still being made, sold, and supported. In fact, said the email blast, Xilinx has committed to 7+ years of supply for these devices. They also have a slick, updated product brief:
Despite their age, Xilinx’s inexpensive, reprogrammable CoolRunner-II CPLDs are still pretty useful devices. They carry their own configuration in an on-chip EEPROM. Because CoolRunner-II CPLDs sip power—quiescent current can be a mere handful of μA for an XC2C32A device and there are some unique power-saving features in all of the devices including DataGATE and CoolCLOCK with DualEDGE flip-flops—they are often used for power sequencing and supervisory tasks. With maximum system toggle frequencies in the low hundreds of MHz, they’re capable of implementing fairly fast state machines as well. Yes, they’re used for glue logic too. They’re handy things to have in your design toolbox.
Need a very small programmable logic device for use on a tight pcb? The CoolRunner-II XC2C32A CPLD with 32 macrocells and 21 I/O pins is available in a 5x5mm QFG32 package and the CoolRunner-II XC2C64A CPLD with 64 macrocells and 37 I/O pins is available in a 7x7mm QFG48 package. Got an 8x8mm spot on your board? An XC2C256 CPLD can drop more than 100 I/O pins into that space.
You can still create designs for Coolrunner-II CPLDs using the Xilinx ISE Design Suite and, if you’ve not used these devices before, you can get a Digilent CoolRunner-II CPLD Starter Board for $39.99. The Starter Board incorporates a CoolRunner-II XC2C256 CPLD.
$39.99 Digilent CoolRunner-II CPLD Starter Board
Never at a loss for words, Adam Taylor has just published some additional thoughts on designing with Xilinx All Programmable devices over at the EEWeb.com site. His post, titled “Make Something Awesome with the $99 FPGA-Based Arty Development Board,” serves as a reminder or an invitation to attend the free May 31 Xilinx Webinar titled “Make Something Awesome with the $99 Arty Embedded Kit.”
Here’s what Adam has to say about FPGA design today:
“Both the maker and hobby communities are increasingly using FPGAs within their designs. This is thanks to the provision of boards at the right price point for the market, coupled with the availability of easy-to-use development tools that include simulation and High-Level Synthesis (HLS) capabilities.
“Let's be honest; compared to the reputation FPGAs have had historically, developing FPGA-based designs in this day-and-age is much simpler. This is largely thanks to a wide range of IP modules that are supplied with the development tools from board vendors and places like OpenCores.”
Adam’s article discusses two low-cost Digilent boards:
Digilent Arty Z7 Development Board
Adam concludes his article with this: “Overall, if you are looking to take your first steps into the world of FPGAs, then the Arty (Artix-based) or the Arty Z7 (Zynq 7000-based) should be high on your list of development boards to consider.”
A paper titled “Evaluating Rapid Application Development with Python for Heterogeneous Processor-based FPGAs” that discusses the advantages and efficiencies of Python-based development using the PYNQ development environment—based on the Python programming language and Jupyter Notebooks—and the Digilent PYNQ-Z1 board, which is based on the Xilinx Zynq SoC, recently won the Best Short Paper award at the 25th IEEE International Symposium on Field-Programmable Custom Computing Machines (FCCM 2017) held in Napa, CA. The paper’s authors—Senior Computer Scientist Andrew G. Schmidt, Computer Scientist Gabriel Weisz, and Research Director Matthew French from the USC Viterbi School of Engineering’s Information Sciences Institute—evaluated the impact of, the performance implications, and the bottlenecks associated with using PYNQ for application development on Xilinx Zynq devices. The authors then compared their Python-based results against existing C-based and hand-coded implementations.
The authors do a really nice job of describing what PYNQ is:
“The PYNQ application development framework is an open source effort designed to allow application developers to achieve a “fast start” in FPGA application development through use of the Python language and standard “overlay” bitstreams that are used to interact with the chip’s I/O devices. The PYNQ environment comes with a standard overlay that supports HDMI and Audio inputs and outputs, as well as two 12-pin PMOD connectors and an Arduino-compatible connector that can interact with Arduino shields. The default overlay instantiates several MicroBlaze processor cores to drive the various I/O interfaces. Existing overlays also provide image filtering functionality and a soft-logic GPU for experimenting with SIMT [single instruction, multiple threads] -style programming. PYNQ also offers an API and extends common Python libraries and packages to include support for Bitstream programming, directly access the programmable fabric through Memory-Mapped I/O (MMIO) and Direct Memory Access (DMA) transactions without requiring the creation of device drivers and kernel modules.”
They also do a nice job of explaining what PYNQ is not:
“PYNQ does not currently provide or perform any high-level synthesis or porting of Python applications directly into the FPGA fabric. As a result, a developer still must use create a design using the FPGA fabric. While PYNQ does provide an Overlay framework to support interfacing with the board’s IO, any custom logic must be created and integrated by the developer. A developer can still use high-level synthesis tools or the aforementioned Python-to-HDL projects to accomplish this task, but ultimately the developer must create a bitstream based on the design they wish to integrate with the Python [code].”
Consequently, the authors did not simply rely on the existing PYNQ APIs and overlays. They also developed application-specific kernels for their research based on the Redsharc project (see “Redsharc: A Programming Model and On-Chip Network for Multi-Core Systems on a Programmable Chip”) and they describe these extensions in the FCCM 2017 paper as well.
So what’s the bottom line? The authors conclude:
“The combining of both Python software and FPGA’s performance potential is a significant step in reaching a broader community of developers, akin to Raspberry Pi and Ardiuno. This work studied the performance of common image processing pipelines in C/C++, Python, and custom hardware accelerators to better understand the performance and capabilities of a Python + FPGA development environment. The results are highly promising, with the ability to match and exceed performances from C implementations, up to 30x speedup. Moreover, the results show that while Python has highly efficient libraries available, such as OpenCV, FPGAs can still offer performance gains to software developers.”
In other words, there’s a vast and unexplored territory—a new, more efficient development space—opened to a much broader system-development audience by the introduction of the PYNQ development environment.
For more information about the PYNQ-Z1 board and PYNQ development environment, see:
Epiq Solutions has announced the Matchstiq S12 SDR transceiver, an expansion to the Matchstiq transceiver family, which also includes the Matchstiq S10 and S11. All three Matchstiq family members pair a Freecale i.MX6 quad-core CPU, used for housekeeping and interfacing (Ethernet, HDMI, and USB), with a Xilinx Spartan-6 LX45T FPGA installed on the company’s Sidekiq MiniPCIe card, which performs the RF signal processing for SDR. These two devices, located on separate boards, communicate over a single PCIe lane and form a reusable SDR platform for the Matchstiq transceiver family. The Matchstiq S12 employs a Dropkiq frequency-extension board to take the bottom of its tuning frequency range below 1MHz. All three Matchstiq transceiver tuners top out at 6GHz and have 50MHz of channel bandwidth. The Matchstiq S10 and S11 SDR tuners go down to 70MHz.
Here are the block diagrams of all three Matchstiq transceivers, which illustrate the platform nature of the basic Matchstiq design:
Epic Solutions Matchstiq SDR Transceiver Block Diagrams
And here’s a family photo:
Epic Solutions Matchstiq SDR Transceiver Family
The huge number of low-cost Arduino peripheral shields from dozens of vendors makes the Arduino form factor extremely attractive. Now you can take advantage of that shield library using the Zynq SoC with the inexpensive, €89 Trenz ArduZynq, which puts a single-core Xilinx Zynq Z-7007S SoC along with 512Mbytes of DDR3L SDRAM, 16Mbytes of SPI Flash memory, and a MicroSD card socket into an Arduino form factor.
Here’s a photo of the Trenz ArduZynq board:
€89 Trenz ArduZynq puts a single-core Xilinx Zynq Z-7007S SoC into the Arduino form factor
Here’s a pinout diagram of the ArduZynq:
Trenz ArduZynq Pinout
Hardware and software design for this board is supported by the Xilinx Vivado Design Suite HL WebPACK Edition, downloadable at no cost.
Note: For more information about the single-core Zynq SoC family, see “One-ARM Zynq family joins the Zynq parade. Now you can choose from 31 devices with one, two, four, or six ARM microprocessors.”
Xilinx today announced that its Spartan-7 FPGA family is now available for order entry and shipping to standard lead times. Spartan-7 devices family are designed for cost-sensitive system designs. They are low-cost, low-power FPGAs. Spartan-7 devices are available in packages as small as 8x8mm (with 100 user I/O pins!) for designs where real estate for circuitry is limited—small video cameras for example—while still offering huge I/O capabilities.
Here’s a table showing the key features of Spartan-7 device family members:
Spartan-7 family members deliver 50% better embedded performance than previous generations when using Xilinx 32-bit MicroBlaze soft processor IP. These devices also incorporate layered security features including AES-256 bitstream decryption, SHA-256 bitstream authentication, and on-chip eFUSE key storage.
For more information about the Xilinx Spartan-7 FPGA family, see:
Iain Mosely, founder of Converter Technology, has a new project that’s particularly interesting to me: developing a class-D audio amp using the Xilinx Zynq SoC (in the form of an Avnet MicroZed SOM) and GaN (gallium-nitride) power transistors. Mosely has been working with Zynq SoCs to develop dc/dc power converters and a class-D audio amp is certainly a close cousin.
Based on this LinkedIn blog post, Mosely appears to have designed a motherboard that accepts the Avnet MicroZed SOM and includes a stereo pair of GaN transistors. Here’s a photo of the board:
If you’re not familiar with class-D amplifiers, they’re a riff on PWM used for audio applications. (Here’s a nice 8-minute tutorial video with a clear explanation of class-D amplification.) Class-D amplifiers were first proposed in 1958 (although the Internet appears to be mute on who first proposed the design, at least for the ten minutes I spent searching for the answer—surprise update, see below!). I remember learning about class-D amps in the late 1960s, when digital technology was still too immature to make the idea practical for consumer audio. The class-D amp’s advantage over linear audio amps is that class-D operation runs the output transistors like digital switches: on or off. That means little of the amp’s input power is wasted as heat and the output transistors won’t need big heat sinks or fans. The latter are anathema to the overall audio experience.
Another key factor in class-D amplifier design is that audio distortion comes from temporal errors and nonlinearities in the PWM (among other things).
In other words, clock jitter equals distortion for class-D amps.
That means that if you rely on a microprocessor’s software timing loop to perform the PWM conversion, you’re automatically and immediately in trouble. Not so if you implement the PWM in hardware, which is exactly what the Zynq SoC offers—in the form of high-speed programmable logic.
It appears that Mosely is just starting out with this project, so it will be interesting to see what he discovers as he brings his power-conversion expertise to bear on the problem.
Update on the inventor of the Class D amplifier. More determined searching produced this 2012 obituary for Hans Camenzind from the Santa Clara Magazine, published by Santa Clara University:
“Hans Camenzind MBA ’71, the Swiss emigre analog guru who invented one of the most successful circuits in electronics history and introduced the concept of phase-locked loop to IC design, passed away in his sleep at the age of 78.
“Camenzind came to the United States in 1960 and worked for several years at some of the storied names of the newly developing semiconductor industry: Transitron, Tyco Semiconductor, and Signetics.
“In 1971 he joined the ranks of entrepreneurs by founding InterDesign, a company specializing in semi-custom integrated circuit design. It was there, working under a contract with Signetics, that he invented the 555 timer. Signetics commercialized the device in 1972, and it went on to become one of the most successful in the industry's history. The device, used in oscillator, pulse-generation and other applications, is still widely used today. Versions of the device have been or are still made by dozens of major semiconductor vendors, including Texas Instruments, Intersil, Maxim, Avago, Exar, Fairchild, NXP and STMicroelectronics.
“Camenzind also introduced the idea of phase-locked loop to design and invented the first class D amplifier.
“Camenzind was a prolific author with interests as diverse as electronics textbooks and the history of the industry ("Much Ado About Almost Nothing") to a book on God and religion ("Circumstantial Evidence"). He wrote under the pen name John Penter. He received an MSEE from Northeastern University and an MBA from the University of Santa Clara, and, during his career secured 20 patents.”
By Adam Taylor
We recently examined how we could use Pmods in our system. There are a lot of Pmods available from many vendors but drivers are not necessarily available for all of them. If there is no driver available, we can use the Pmod bridge in the Zynq SoC’s PL (programmable logic), which enables us to correctly map Pmod ports on our selected development board and to create our own Zynq PS (processing system) driver. If we were to explore one of the provided drivers, we would find these also use the Pmod bridge, coupled with an AXI IIC or SPI component.
Pmod AD2 PL Driver Components
In this example, I am going to be using Digilent’s DA4 octal DAC Pmod. I’ll integrate it with Digilent’s dual ADC AD2 Pmod, which we previously used in the driver example. We will develop our own driver with the Pmod bridge, generate an analog signal using the DA4 Pmod, and then receive the signal using the AD2 Pmod.
Pmod DA4 test set up
The Pmod bridge allows us to define the input types for both the top and bottom row of the Pmod connector. We can select from either GPIO, UART, IIC, or SPI interfaces. We make this selection for each of the Pmod rows in line with the Pmod we wish to drive. Selecting the desired type makes the pinout of the Pmod connector align with the standard for the interface type.
For the DA4, we need to use a SPI interface on the top row only. With this selected, we need to provide the actual SPI communication channel. As we are using the Zynq SoC, we have two options. The first would be to use an AXI SPI IP block within the PL and connected to the bridge. The second approach—and the one I am going to use—is to connect the bridge to the Zynq PS’ SPI using EMIO. This choice provides us with the ability to wire the pins from the PS SPI ports to the bridge inputs directly.
To do this we need to read the standard to ensure we can map from the SPI pins to the input pins on the bridge in the correct order (e.g. which PS SPI signal is connected to IN_0?). As these pins on the bridge represent different interface types, they are named generically. The diagram below shows how I did it for the DA4. Once we have mapped the pins for this example, we can build the project, export it to SDK, and then write the software to drive our DA4.
We can use the SPI drivers created by the BSP within SDK to drive the DA4. To interact with the DA4, the first thing we need to do is initialize the SPI controller. Once we have set the SPI Options for clock phase and master operation, we can then define a buffer and use the polled-transfer mode to transfer the required information to the DA4. A more complex driver would use an interrupt-driven approach as opposed to a polled one.
I have uploaded the file I created to drive the DA4 onto the git hub repository. To test it I drove a simple ramp output and used the scope feature in the Digilent Analog Discovery module to monitor the DAC output. I received the following signal:
With this completed and the DA4 known to be working as expected, I connected the DA4 and the AD2 together so that the Zynq SoC could receive the signal:
When doing this, we need to be careful to ensure the signal output by the DA4 is within the AD2 Pmod’s operating range.
Having completed this and shown that the DA4 is working on the hardware, we now understand how we can create drivers if there is no driver available.
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.
Cutting-edge industrial and medical camera maker NET (New Electronic Technology) had a table at this week’s Embedded Vision Summit where the company displayed two generations of GigE cameras: the GigEPRO and CORSIGHT. Both of these camera families include multiple cameras that accommodate a wide range of monochrome and color image sensors. There are sixteen different C- and CS-mount cameras in the GigEPRO family with sensors ranging from WVGA (752x480 pixels) to WQUXGA (3664x2748 pixels) and a mix of global and rolling shutters. The CORSIGHT family includes eleven cameras with sensors ranging from WVGA (752x480 pixels) to QSXGA (2592x1944 pixels), or one of two line-scan sensors (2048 or 4096 pixels), with a mix of global and rolling shutters. In addition to its Gigabit Ethernet interface, the CORSIGHT cameras have WiFi, Bluetooth, USB 2.0, and optional GSM interfaces. Both the GigEPRO and CORSIGHT cameras are user-programmable and have on-board, real-time image processing, which can be augmented with customer-specific image-processing algorithms.
GigEPRO Camera from NET
CORSIGHT Camera from NET
You program both cameras with NET’s GUI-based SynView Software Development Kit, which generates code for controlling the NET cameras and for processing the acquired images. When you create a program, SynView automatically determines if the required functionality is available in camera hardware. If not, SynView will do the necessary operations in software (although this increases the host CPU’s load). NET’s GigEPRO and CORSIGHT cameras are capable of performing significant on-board image processing right out of the box including Bayer decoding for color cameras, LUT (Lookup Table) conversion, white balance, gamma, brightness, contrast, color correction, and saturation.
Which leads to the question: What’s performing all of these real-time, image-processing functions in NET’s GigEPRO and CORSIGHT cameras?
Xilinx FPGAs, of course. (This should not be a surprise. After all, you’re reading a post in the Xilinx Xcell Daily blog.)
The GigEPRO cameras are based on Spartan-6 FPGAs—an LX45, LX75, or LX100 depending on the family member. At the Embedded Vision Summit, Dr. Thomas Däubler, NET’s Managing Director and CTO, explained to me that “the FPGAs are what give the GigEPRO cameras their PRO features.” In fact, there is user space reserved in the larger FPGAs for customer-specific algorithms to be performed in real time inside of the camera itself. What sort of algorithms? Däubler gave me two examples: laser triangulation and Q-code recognition. In fact, he said, some of NET’s customers perform all of the image processing and analysis in the camera and never send the image to the host—just the results of the analysis. Of course, this distributed-processing approach greatly reduces the host CPU’s processing load and therefore allows one host computer to handle many more cameras.
Here’s a photo from the Summit showing a NEW GigEPRO camera inspecting a can on a spinning platform while reading the label on the can:
NET GigEPRO Camera Inspects Object on Spinning Table and Reads Label
There’s a second important reason for using the FPGA in NET’s GigEPRO cameras: the FPGAs create a hardware platform that allowed NET to develop the sixteen GigEPRO family members that handle many different image sensors with varied hardware interfaces and timing requirements. NET relied on the Spartan-6 FPGAs’ I/O programmability to help with this aspect of the camera family’s design.
So when it came time for NET to develop a new intelligent camera family—the recently introduced CORSIGHT smart vision system—with even more features, did NET’s design engineers continue to use FPGAs for real-time image processing?
Of course they did. For the newer camera, and for the same reasons, they chose the Xilinx Artix-7 FPGA family.
And here’s the CORSIGHT camera in action:
NET CORSIGHT Camera Inspects Object on Spinning Table
Note: For more information about the GigEPRO and CORSIGHT camera families, and the SynView software, please contact NET directly.
Looking for a low-cost way to get into the most advanced FPGA tools and device families? The $99 ARTY Eval Kit available from Avnet and Digilent is an excellent choice. The ARTY board features a Xilinx Artix-7 A35T FPGA with 256Mbytes of DDR3 SDRAM, Ethernet, four Digilent Pmod ports, and a set of Arduino Shield headers. The Artix-7 A35T FPGA is big enough to implement the 32-bit MicroBlaze soft RISC processor core .
Perhaps best of all, the kit includes a voucher for a downloadable copy of the Xilinx Vivado HL Design Edition, device-locked to the Artix-7 A35T FPGA. The full-featured Vivado HL Design Edition includes a lot of great tools including the IP Integrator (IPI), which lets you quickly build FPGA-based designs using graphical representations of IP blocks with intelligent, automated stitching.
This edition of Vivado also includes Vivado HLS, so you can experiment with logic synthesis based on design descriptions written in C, C++, or SystemC. The $99 ARTY FPGA Dev Board is really a great way to get started with the industry’s most advanced design tools for FPGA-based design.
If you want a closer look at the ARTY Dev Kit, there’s a free, 1-hour Webinar on May 31 you might want to attend. Register here.
For more information about the ARTY eval Kit, see “ARTY—the $99 Artix-7 FPGA Dev Board/Eval Kit with Arduino I/O and $3K worth of Vivado software. Wait, What????”
Last week, Xcell Daily noted the ZX Spectrum Next project on Kickstarter. (See “Jurassic Computer, Part 2: Recreating the Sinclair ZX Spectrum PC using a Spartan-6 FPGA—on Kickstarter.”) This project replicates an enhanced version of the Sinclair ZX Spectrum microcomputer (the "Speccy"), circa 1982, using a Xilinx Spartan-6 LX9 FPGA to recreate all of the microcomputer’s logic (including the Z80 microprocessor and the video controller), plus the I/O. The project now has pledges worth $521,776, which exceeds the goal by close to $200K and enables the first stretch goal—a bigger FPGA!
The ZX Spectrum Next Microcomputer on Kickstarter
The design will now use a Spartan-6 LX16 FPGA with 60% more programmable logic inside, so that the design team can cram even more features into the design. There are still three weeks in this Kickstarter campaign and four more stretch goals, so if you want one of these, now is probably a good time to pledge.
The ZX Spectrum microcomputer developed by Sinclair Research first appeared in 1982. That’s precisely 35 years ago. According to Wikipedia, Sinclair sold more than five million ZX Spectrum computers over the decade that the “Speccy”’ was offered for sale. (“Speccy” appears to be the pet name that the ZX Spectrum’s many fans gave to this small machine, which spawned a huge ecosystem of software and hardware add-on vendors.) The Speccy was one of the UK’s first mainstream PCs and was based on a 3.5MHz Zilog Z80 microprocessor with either 16 or 48Kbytes of RAM. A 16Kbyte ROM consumed the rest of the Speccy’s 64K address space. Fast forward 35 years to 2017. There’s a new Kickstarter project to recreate the Speccy called the “ZX Spectrum Next.”
Here’s a board photo of a ZX Spectrum motherboard, issue 3B, circa 1983, courtesy of Wikipedia:
Sinclair 48K ZX Spectrum motherboard, Issue 3B. 1983, Manufactured 1984.
Photo Credit: Bill Bertram
The 40-pin NEC D780C chip on the right is an NEC copy of the Zilog Z80 processor and the NEC D23128C chip to the right of the processor is a 128Kbit masked ROM. The 40-pin Ferranti ULA (uncommitted logic array) on the left side of the board implements the ZX Spectrum’s video, the keyboard interface, and the analog I/O for audiotape mass storage I/O and sound. Sinclair designed many custom ULAs into its products during the 1980s—years before FPGAs became mainstream devices.
With 26 days left in the funding campaign, the ZX Spectrum Next project already has $402,936 in pledges which is 125% of goal. So this project is going to be funded (but there are stretch goals yet to be achieved!). The $127 pledge price for the board or $224 for the full machine look like a steal for this piece of recreated computing history.
There’s a nice video explaining the project on the Kickstarter page, replicated here:
Here’s what under the hood of the machine:
And here’s a closeup of the ZX Spectrum’s motherboard to make the point for this blog post:
That’s right, the Spectrum ZX Next project team is using a Xilinx Spartan-6 LX9 FPGA to recreate essentially all of the above logic including the 8-bit Z80 microprocessor, three GI AY-3-8912 audio chips, the video (RGB, VGA, and HDMI), and all of the ZX Spectrum’s original and the new “Next” I/O ports. The Spartan-6 FPGA isn’t glue; it’s the entire system, except for the SRAM.
Finally, here’s an additional video demonstrating the ZX Spectrum Next PC’s capabilities and performance:
If you’re a Speccy fan, how can you resist?
By Adam Taylor
In some applications, we wish to maintain the phase relationship between sampled signals. The Zynq SoC’s XADC contains two ADCs, which we can operate simulateneously in lock step to maintain the phase relationship between two sampled signals. To do this, we use the sixteen auxillary inputs with Channels 0-7 assigned to ADC A and channeld 8-15 assigned to ADC B. In simultaneous mode, we can therefore perform conversions on channels 0 to 7 and at the same time, perform conversions on channels 8 to 15.
In simultaneous mode, we can also continue to sample the on-chip parameters, however they are not sampled simultaneously. We are unable to perform automatic calibration in simultaneous mode but we can use another mode to perform calibration when needed. This should be sufficent because calibration is generally performed only on power up of the device for most applications.
To use the simulatenous mode, we first need a hardware design on Vivado that breaks out the AuX0 and AuX8 channels. On the Zedboard and MicroZed I/O Carrier Cards, these signals are broken out to the AMS connector. This allows me to connect signal sources to the AMS header to stimulate the I/O pin with a signal. For this example, I an using a Digilent Analog Discovery module as signal source.
The hardware design within the Zynq for this example appears below:
Writing the software in SDK for simultaneous mode is very similar to the other modes of operation we have used in the past. The only major difference is that we need to make sure we have configured the simultaneous channels in the sequencer. Once this is done and we have configured the input format we want—bipolar or unipolar, averaging, etc.—we can start the sequencer using the XSM_SEQ_MODE_SIMUL mode definition.
When I ran this on the MicroZed set up as shown above and stored 64 samples from both the AUX0 and AUX8 input using input signals that were offset by 180 degrees, I was able to recover the following waveform, which shows the phase relations ship is maintained:
If we want, we can also use simultaneous-conversion mode with an external analog multiplexer. All we need to do is configure the design to use the external mux as we did previously. Perhaps the difference this time is that we need to use two external analog multiplexers because we need to be able to select the two channels to convert simultaneously. Also, we need only use three address bits to cover the 0-7 address range, as opposed four address bits that we needed for addressing all sixteen analog inputs when we previously used sequencer mode. We use the lower three address bits of the four available address bits.
At this point, the only XADC mode that we have not looked at is independent mode. This mode is like the XADC’s default (safe) mode, however in independent mode ADC A monitors the internal on chip parameters while ADC B samples the external inputs. Independent mode is intended to implement a monitoring mode. As such, the alarms are active so you can use this mode for implementing security and anti-tamper features in your design.
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.
I’ve written about the Zynq-based Red Pitaya several times in Xcell Daily. (See below.) Red Pitaya is a single-board, open instrumentation platform based on the Xilinx Zynq SoC, which combines a dual-core ARM Cortex-A9 MPCore processor with a heavy-duty set of peripherals and a chunk of Xilinx 7 series programmable logic. Red Pitaya packages its programmable instrumentation board with probes, power supply, and an enclosure and calls it the STEMlab. I’ve just discovered the STEMlab page on the Digi-Key site with inventory levels, so if you want to get into programmable instrumentation in a hurry, this is a good place to start.
The page lists three STEMlab starter kits:
Red Pitaya 27901 STEMlab kit with scope and logic probes
For more articles about the Zynq-based Red Pitaya, see:
Today, intoPIX announced that it’s lightweight TICO video-compression IP cores for Xilinx FPGAs can now support frame resolutions and rates to 8K60p as well as the previously supported HD and 4K resolutions. Currently, the compression cores support 10-bit, 4:2:2 workflows but intoPIX also disclosed in a published table (see below) that a future release of the IP core will support 4:4:4 color sampling. The TICO compression standard simplifies the management of live and broadcast video streams over existing video network infrastructures based on SDI and Ethernet by reducing the bandwidth requirements of high-definition and ultra-high-definition video at compression ratios as large as 5:1 (visually lossless at ratios to 4:1). TICO compression supports live video streams through its low latency—less than 1msec end-to-end.
Conveniently, intoPIX has published a comprehensive chart showing its various TICO compression IP cores and the Xilinx FPGAs that can support them. Here’s the intoPIX chart:
Note that the most cost-effective Xilinx FPGAs including the Spartan-6 and Artix-7 families support TICO compression at HD and even some UHD/4K video formats while the Kintex-7, Virtex-7, and UltraScale device families support all video formats through 8K.
Please contact intoPIX for more information about these IP cores.
I got a heads up on a new, low-end dev board called the “MiniZed” coming soon from Avnet and found out there’s a pre-announcement Web page for the board. Avnet’s MiniZed is based on one of the new Zynq Z-7000S family members with one ARM Cortex-A9 processor. It will include both WiFi and Bluetooth RF transceivers and, according to the MiniZed Web page, will cost less than $100!
Here’s the link to the MiniZed Web page and here’s a slightly fuzzy MiniZed board photo:
Avnet MiniZed (coming soon, for less than $100)
If I’m not mistaken, that’s an Arduino header footprint and two Digilent Pmod headers on the board, which means that a lot of pretty cool shields and Pmods are already available for this board (minus the software drivers, at least for the Arduino shields).
I know you’ll want more information about the MiniZed board but I simply don’t have it. So please contact Avnet for more information or register for the info on the MiniZed Web page.
The Vivado Design Suite HLx Editions 2017.1 release is now available for download. The Vivado HL Design Edition and HL System Edition now support partial reconfiguration. Partial reconfiguration is available for the Vivado WebPACK Edition at a reduced price.
Xilinx partial reconfiguration technology allows you to swap FPGA-based functions in and out of your design on the fly, eliminating the need to fully reconfigure the FPGA and re-establish links. Partial reconfigurability gives you the ability to update feature sets in deployed systems, fix bugs, and migrate to new standards while critical functions remain active. This capability dramatically expands the flexible use of Xilinx All Programmable designs in a truly wide variety of applications.
For example, a detailed article published on the WeChat Web site by Siglent about the company’s new, entry-level SDS1000X-E DSO family—based on a Xilinx Zynq Z-7020 SoC—suggests that the new DSO family’s system design employs the Zynq SoC’s partial-reconfiguration capability to further reduce the parts count and the board footprint: “The PL section has 220 DSP slices and 4.9 Mb Block RAM; coupled with high throughput between the PS and PL data interfaces, we have the flexibility to configure different hardware resources for different digital signal processing.” (See “Siglent 200MHz, 1Gsample/sec SDS1000X-E Entry-Level DSO family with 14M sample points is based on Zynq SoC.”)
Siglent’s new, entry-level SDS1000X-E DSO family is based on a Xilinx Zynq Z-7020 SoC
In addition, the Vivado 2017.1 release includes support for the Xilinx Spartan-7 7S50 FPGA (Vivado WebPACK support will be in a later release). The Spartan-7 FPGAs are the lowest-cost devices in the 28nm Xilinx 7 series and they’re optimized for low, low cost per I/O while delivering terrific performance/watt. Compared to Xilinx Spartan-6 FPGAs, Spartan-7 FPGAs run at half the power consumption (for comparable designs) and with 30% more operating frequency. The Spartan-7 S50 FPGA is a mid-sized family member with 52,160 logic cells, 2.7Mbits of BRAM, 120 DSP slices, and 250 single-ended I/O pins. It’s a very capable FPGA. (For more information about the Spartan-7 FPGA family, see “Today, there are six new FPGAs in the Spartan-7 device family. Want to meet them?” and “Hot (and Cold) Stuff: New Spartan-7 1Q Commercial-Grade FPGAs go from -40 to +125°C!”)
Spartan-7 FPGA Family Table
The MEGA65 is an open-source microcomputer modeled on the incredibly successful Commodore 64/65 circa 1982-1990. Ye olde Commodore 64 (C64)—introduced in 1982—was based on an 8-bit MOS Technology 6510 microprocessor, which was derived from the very popular 6502 processor that powered the Apple II, Atari 400/800, and many other 8-bit machines in the 1980s. The 6510 processor added an 8-bit parallel I/O port to the 6502, which no doubt dropped the microcomputer’s BOM cost a buck or two. According to Wikipedia, “The 6510 was only widely used in the Commodore 64 home computer and its variants.” Also according to Wikipedia, “For a substantial period (1983–1986), the C64 had between 30% and 40% share of the US market and two million units sold per year, outselling the IBM PC compatibles, Apple Inc. computers, and the Atari 8-bit family of computers.”
Now that is indeed a worthy computer to serve as a “Jurassic Park” candidate and therefore, the non-profit MEGA (Museum of Electronic Games & Art), “dedicated to the preservation of our digital heritage,” is supervising the physical recreation of the Commodore 64 microcomputer (mega65.org). It’s called the MEGA65 and it’s software-compatible with the original Commodore 64, only faster. (The 6510 processor emulation in the MEGA65 runs at 48MHz compared to the original MOS Technology 6510’s ~1MHz clock rate.) MEGA65 hardware designs and software are open-source (LGPL).
How do you go about recreating the hardware of a machine that’s been gone for 25 years? Fortunately, it’s a lot easier than extracting DNA from the stomach contents of ancient mosquitos trapped in amber. Considering that this blog is appearing in Xcell Daily on the Xilinx Web site, the answer’s pretty obvious: you use an FPGA. And that’s exactly what’s happening.
A few days ago, the MEGA65 team celebrated initial bringup of the MEGA65 pcb. You can read about the bringup efforts here and here is a photo of the pcb:
The first MEGA65 PCB
The MEGA65 pcb is designed to fit into the existing Commodore 65 plastic case. (The Commodore 65 was prototyped but not put into production.)
Sort of gives a new meaning to “single-chip microcomputer,” does it not. That big chip in the middle of the board is an Xilinx Artix-7 A200T. It implements the Commodore 64’s entire motherboard in one programmable logic device. Yes, that includes the RAM. The Artix-7 A200T FPGA has 13.14Mbits of on-chip block RAM. That’s more than 1.5Mbytes of RAM, or 25x more RAM than the original Commodore 64 motherboard, which used eight 4164 64Kbit, 150nsec DRAMs for RAM storage. The video’s a bit improved too, from 160x200 pixels, with a maximum of four colors per 4x8 character block, or 320x200 pixels, with a maximum of two colors per 8x8 character block, to a more modern 1920x1200 pixels with 12-bit color (23-bit color is planned). Funny what 35 years of semiconductor evolution can produce.
What’s the project’s progress status? Here’s a snapshot from the MEGA65 site:
MEGA65 Project Status
And here’s a video of the MEGA65 in action:
Remember, what you see and hear is running on a Xilinx Artix-7 A200T, configured to emulate an entire Commodore 64 microcomputer. Most of the code in this video was written in the Jurassic period of microcomputer development. If you’re of a certain age, these old programs should bring a chuckle or perhaps just a smile to your lips.
Note: You’ll find a MEGA65 project log by Antti Lukats here.
What do you do if you want to build a low-cost state-of-the-art, experimental SDR (software-defined radio) that’s compatible with GNURadio—the open-source development toolkit and ecosystem of choice for serious SDR research? You might want to do what Lukas Lao Beyer did. Start with the incredibly flexible, full-duplex Analog Devices AD9364 1x1 Agile RF Transceiver IC and then give it all the processing power it might need with an Artix-7 A50T FPGA. Connect these two devices on a meticulously laid out circuit board taking all RF-design rules into account and then write the appropriate drivers to fit into the GNURadio ecosystem.
Sounds like a lot of work, doesn’t it? It’s taken Lukas two years and four major design revisions to get to this point.
Well, you can circumvent all that work and get to the SDR research by signing up for a copy of Lukas’ FreeSRP board on the Crowd Supply crowd-funding site. The cost for one FreeSRP board and the required USB 3.0 cable is $420.
Lukas Lao Beyer’s FreeSRP SDR board based on a Xilinx Artix-7 A50T FPGA
With 32 days left in the Crowd Supply funding campaign period, the project has raised pledges of a little more than $12,000. That’s about 16% of the way towards the goal.
There are a lot of well-known SDR boards available, so conveniently, the FreeSRP Crowd Supply page provides a comparison chart:
If you really want to build your own, the documentation page is here. But if you want to start working with SDR, sign up and take delivery of a FreeSRP board this summer.
I don’t get to do too much hands-on work while writing Xcell Daily but today was an exception. Today, I took delivery of the new Digilent Discovery Portable Logic Analyzer and Digital Pattern Generator. This diminutive USB instrument measures about 3.25 inches on a side and costs a mere $199.99. For that, you get a 24-channel USB logic analyzer capable of 200Msamples/sec with simple single-ended leads and 800Msamples/sec on fewer channels with Digilent’s High Speed Adapter. (See “$199.99 Digital Discovery from Digilent implements 800Msample/sec logic analyzer, pattern generator. Powered by Spartan-6” for more information.)
Digilent Digital Discovery Logic Analyzer Kit
For comparison, my first logic analyzer was an engineering prototype of the HP 1615A, HP’s first timing/state analyzer. I borrowed this prototype instrument from HP’s Colorado Springs Division back in late 1977 to help debug a nagging problem with the I/O backplane of the HP 9845A Desktop Computer. The HP 1615A offered a “blazing” timing capture rate of 20Msamples/sec for 24 channels. Most important for me, it had a 5nsec “glitch capture” feature, which allowed me to see the I/O glitches taking place on the I/O backplane at the maxed-out DMA transfer rate of 400Ktransfers/sec. The HP 1615A logic analyzer cost $6800 back in the day and it sold like hotcakes. (For an affectionate history of HP’s entry into the logic analyzer business, see “Logic State Analyzer Birthing Pains” by Chuck House on the HP Memory Project Web site, hpmemoryproject.org.)
The HP 1615A Logic Analyzer circa 1978 (Photo courtesy Hewlett-Packard Company)
Well, it’s exactly 40 years later and see what time, Digilent, and Xilinx FPGA technology have wrought. Digilent’s $199.99 Digital Discovery provides the same number of logic-analysis channels as the $6800 HP 1615A but runs 10x to 40x faster and has a 2Gbit acquisition buffer. (The HP 1615A had a 6Kbit acquisition buffer, but that was 40 years ago.) In addition, the Digilent Digital Discovery can not only display digital signals, it can decode and trigger on commonly used serial-bus protocols including SPI, I²C, UART, I2S, and CAN. Of course, none of those even existed 40 years ago except for the UART NRZ protocol.
So, is the Digilent Digital Discovery easy to use? The user interface for this instrument is Digilent’s GUI-based Waveforms 2015 application, which you download from the Web and install. I downloaded the Waveforms 2015 installer and immediately ran into a problem. My Xilinx-provided laptop lacked Microsoft’s Visual C++ 2013 and Visual C++ Redistributable Package. Waveforms 2015 generously offered to install the missing Microsoft package for me. I clicked “yes,” and Waveforms then tried to install the Microsoft C runtime package—and failed. Without too much trouble, I found the software on the Microsoft Web site, downloaded it, and installed it manually. Then I restarted the Waveforms 2015 installation and completed that successfully.
When I ran Waveforms 2015, it went looking for the Digilent Digital Discovery module, which I intentionally had not yet plugged into my laptop’s USB port. After getting the expected complaint from Waveforms 2015, I plugged the Digital Discovery into a USB port and everything started working just fine.
I’d known for a couple of weeks that Digilent was sending this instrument to me, so I had decided beforehand how I wanted to generate my initial test waveforms. It seemed to me that the fastest and simplest test-signal generator I could use that would be interesting was a low-cost Sparkfun RedBoard Arduino clone and an Adafruit Motor Control Shield v2, which Radio Shack had just put on sale as part of its “inventory reduction” program. (Fortunately, the Digital discovery is 5V-tolerant (I checked), because the RedBoard is a 5V board.)
When running the supplied “MotorParty” Arduino Sketch, the Sparkfun RedBoard continuously writes I2C commands to an H-bridge driver IC on the Adafruit Motor Control Shield to spin up a dc motor. It then then spins the motor down, reverses direction, rinses, and repeats. The MotorParty Sketch also generates a variable, TTL-level PWM signal to drive a hobby servo. I used the Digital Discovery to capture both waveforms.
By the way, I did all of this without taking a peek at the manual.
First, I hooked up the Digital Discovery to the Adafruit Motor Control Shield’s I2C pins (driven by the Sparkfun RedBoard) and set up the Logic Analyzer for I2C. It’s pretty easy. You just select I2C and the I2C clock and data lines show up on the first two channels of the logic analyzer. After initially messing up these two connections (hey, I’ve got a 50% chance of getting it right, plus I did get ground connected correctly), I was rewarded with this waveform display with the I2C traffic automatically decoded:
Digilent Digital Discovery I2C Waveform Display
OK, let’s see how well I do when I only need to connect one signal: the PWM signal driving the servo. Hobby servos use a very simple 1-wire PWM interface where the width of the logic pulse positions the servo. This protocol was created back in the pre-microprocessor days when we used RC oscillators to drive servos.
Here’s a 30-second video showing you how easy it is to look at continuously changing digital waveforms using the Digilent Digital Discovery (once you set the trigger correctly).
Again, setting up the Digital Discovery to capture this waveform is pretty simple, pretty intuitive.
As a reminder, these logic-analysis features are all implemented inside of one Xilinx Spartan-6 LX25 FPGA coupled to one DDR3 SDRAM serving as a really large capture buffer. I’ve yet to experiment with the other Digital discovery features including the digital pattern generator and digital I/O, but this is an amazingly powerful “bit of kit” with a nice GUI-based interface for $199.99.
Digilent’s Digital Discovery is based on a Xilinx Spartan-6 FPGA
Note: For more information about the Digital Discovery, contact Digilent directly.
Hours after I posted yesterday’s blog about Siglent’s new sub-$400, Zynq-powered SDS1000-E family of 2-channel, 200MHz, 1Gsamples/sec DSOs (see “Siglent 200MHz, 1Gsample/sec SDS1000X-E Entry-Level DSO family with 14M sample points is based on Zynq SoC”), EEVblog’s Dave Jones posted a detailed, 25-minute teardown video of the very same scope, which clearly illustrates just how Siglent reached this incredibly low price point.
One way Siglent achieved this design milestone was to use one single board to implement all of the scope’s analog and digital circuitry. However, 8- or 10-layer pcbs are expensive, so Siglent needed to minimize that single board’s size and one way to do that is to really chop the component count on the board. To do that without cutting functions, you need to use the most highly integrated devices you can find, which is probably why Siglent’s design engineers selected the Xilinx Zynq Z-7020 SoC as the keystone for this DSO’s digital section. As discussed yesterday, the use of the Zynq Z-7020 SoC allowed Siglent’s design team to introduce advanced features from the company’s high-end DSOs and put them into these entry-level DSOs with essentially no increase in BOM cost.
Here’s a screen capture from Dave’s new teardown video showing you what the new Siglent DSO’s main board looks like. That’s Dave’s finger poised over the Xilinx Zynq SoC (under the heat sink), which is flanked to the left and right by the two Samsung K4B1G1646I 1Gbit (64Mx16) DDR3 SDRAM chips used for waveform capture and the display buffer—among other things.
As discussed yesterday, the Zynq SoC’s two on-chip ARM Cortex-A9 processors can easily handle the scope’s GUI and housekeeping chores. Its on-chip programmable logic implements the capture buffer, the complex digital triggering, and the high-speed computation needed for advanced waveform math and the 1M-point FFT. Finally, the Zynq SoC’s programmable I/O and SerDes transceiver pins make it easy to interface to the scope’s high-speed ADC and the DDR3 memory needed for the deep, 14M-point capture buffer and the display memory for the DSO’s beautiful color LCD with 256 intensity levels. (All this is discussed in yesterday’s Xcell Daily blog post about these new DSOs.)
Here’s a photo of that Siglent screen from one of Dave’s previous videos, where he uses a prototype of this Siglent DSO to troubleshoot and fix a malfunctioning HP 54616B DSO that had been dropped:
Note: Since sending this prototype to Dave, Siglent has apparently decided to bump the bandwidth of these DSOs to 200MHz. Just another reminder of how competitive this entry-level DSO market has become, and how the Zynq SoC's competitive advantages can be leveraged in a system-level design.
Here’s Dave’s teardown video:
Siglent’s new SDS1000X-E family of entry-level DSOs (digital sampling oscilloscopes) feature 200MHz of bandwidth with a 1G sample/sec sample rate in the fastest family members, 14M sample points in all family models, 256 intensity levels, and a high-speed display update rate of 400,000 frames/sec. The new DSOs also include many advanced features not often found on entry-level DSOs including intelligent triggering, serial bus decoding and triggering, historical mode and sequence mode, a rich set of measurement and mathematical operations, and a 1M-point FFT. The SDS1000X-E DSO family is based on a Xilinx Zynq Z-7020 SoC, which has made it cost-effective for Siglent to migrate its high-end SPO (Super Fluorescent Oscilloscope) technology to this new entry-level DSO family.
Siglent’s new, entry-level SDS1000X-E DSO family is based on a Xilinx Zynq Z-7020 SoC
According to this WeChat article published in January by Siglent (Ding Yang Technology in China), the Zynq SoC “is very suitable for data acquisition, storage and digital signal processing in digital oscilloscopes.” In addition, the high-speed, high-density, on-chip interconnections between the Zynq SoC’s PS (processor system) and PL (programmable logic) “effectively solve” the traditional digital storage oscilloscope CPU and FPGA data-transmission bottlenecks, which reduces the DSO’s dead time between triggers and increases the waveform capture and display rates. According to the article, the system design employs four AXI ports operating between the Zynq PS and PL to achieve 8Gbytes/sec data transfers—“far greater than the local bus transmission rate” achievable using chip-to-chip I/O, with far lower power consumption.
The Zynq SoC’s combination of ARM Cortex-A9 software-driven processing and on-chip programmable logic also reduces hardware footprint and facilitates integration of high-performance processing systems into Siglent’s compact, entry-level oscilloscopes. The article also suggests that the DSO system design employs the Zynq SoC’s partial-reconfiguration capability to further reduce the parts count and the board footprint: “The PL section has 220 DSP slices and 4.9 Mb Block RAM; coupled with high throughput between the PS and PL data interfaces, we have the flexibility to configure different hardware resources for different digital signal processing.”
Further, the SDS1000X-E DSO family’s high-speed ADC uses high-speed differential-pair signaling to connect directly to the Zynq SoC’s high-speed SerDes transceivers, which guarantee’s “stable and reliable access” to the ADCs’ 1Gbyte/sec data stream while the Zynq SoC’s on-chip DDR3 controller operating at 1066Mtransfers/sec allows “the use of single-chip DDR3 to meet the real-time storage of the ADC output data requirements.”
Siglent has also used the Zynq SoC’s PL to implement the DSOs’ high-sensitivity, low-jitter, zero-temperature-drift digital triggering system, which includes many kinds of intelligent trigger functions such as slope, pulse width, video, timeout, rungs, and patterns that can help DSO users more accurately isolate waveforms of interest. Advanced bus-protocol triggers and bus events (such as the onset of I2C bus traffic or UART-specific data can also serve as trigger conditions, thanks to the high-speed triggering ability designed into the Zynq SoC’s PL. These intelligent triggers greatly facilitate debugging and add considerable value to the new Siglent entry-level DSOs.
Here’s a translated block diagram of the SDS1000X-E DSO family’s system design:
The new SDS1000X-E DSO family illustrates the result of selecting a Zynq SoC as the foundation for a system design. The large number of on-chip resources permit you to think outside of the box when it comes to adding features. Once you’ve selected a Zynq SoC, you no longer need to think about cramming code into the device to add features. With the Zynq SoC’s hardware, software, and I/O programmability, you can instead start thinking up new features that significantly improve the product’s competitive position in your market.
This is precisely what Siglent’s engineers were able to do. Once the Zynq SoC was included in the design, the designers of this entry-level DSO family were able to think about which high-performance features they wished to migrate to their new design.