Displaying articles for: 04-02-2017 - 04-08-2017
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.
Xcell Daily has covered the Xilinx version of QEMU for the Zynq UltraScale+ MPSoC, Zynq-7000 SoC, and for any design that uses the Xilinx MicroBlaze 32-bit soft-core RISC processor but now there’s a short video that gives you a good introduction to the tool in just over 10 minutes.
If you haven’t heard about QEMU, it’s a fast, software-based processor emulator and virtual emulation platform developed by the open-source community. Xilinx adopted QEMU several years ago for internal product development and, as a consequence, has developed and extended QEMU to cover the ARM Cortex-A53, -A9, and -R5 processor cores used in the Zynq UltraScale+ MPSoCs and Zynq-7000 SoCs and for the Xilinx MicroBlaze processor core as well. At the same time, Xilinx has fed these enhancements back to the open-source community. (More info here.)
You reap the benefit of this development in the rapid introduction of new Zynq devices and in your ability to download the Xilinx version of QEMU and use it for developing your own designs. The availability of QEMU for the processors used in Zynq devices and the MicroBlaze processor allows you to develop code for your design long before the application-specific hardware IP is ready. That means you can short-cut big chunks of your development cycle when the software team might otherwise be idled, waiting for a development platform. With QEMU, the development platform is as simple as a laptop PC.
That said, here’s the short video:
For additional Xcell Daily coverage of QEMU, see:
If you have a mere 14 minutes to spare, you can watch this new video that will show you how to set up the Zynq UltraScale+ MPSoC’s hardened, embedded PCIe block as a Root Port using the Vivado Design Suite. The target system is the ZCU102 eval kit (currently on sale for half price) and the video shows you how to use the PetaLinux tools to connect to a PCIe-connected NVMe SSD.
This is a fast, painless way to see a complete set of Xilinx development tools being used to create a fully operational system based on the Zynq UltraScale+ MPSoC in less than a quarter of an hour.
Hardent, A Xilinx Approved Training Provider, is conducting a free 1-hour Webinar that will discuss best practices for Constraints Management using the the Vivado Design Suite on April 18. Topic covered will include:
Samtec recorded a demo of its FireFly FQSFP twinax cable assembly carrying four 28Gbps lanes from a Xilinx Virtex UltraScale+ VU9P FPGA on a VCU118 eval board to a QSFP optical cage at the recent OFC 2017 conference in Los Angeles. (The Virtex UltraScale+ VU9P FPGA has 120 GTY transceivers capable of 32.75Gbps operation and the VCU118 eval kit includes the Samtec FireFly daughtercard with cable assembly.) Samtec’s FQSFP assembly plugs mid-board into a FireFly connector on the VCU118 board. The 28Gbps signals then “fly over” the board through to the QSFP cage and loop back over the same path, where they are received back into the FPGA. The demonstration shows 28Gbps performance on all four links with zero bit errors.
As explained in the video, the advantage to using the Samtec FireFly flyover system is that it takes the high-speed 28Gbps signals out of the pcb-design equation, making the pcb easier to design and less expensive to manufacture. Significant savings in pcb manufacturing cost can result for large board designs, which no longer need to deal with signal-integrity issues and controlled-impedance traces for such high-speed routes.
Samtec has now posted the 2-minute video from OFC 2017 on YouTube and here it is:
Note: Martin Rowe recently published a related technical article about the Samtec FireFly system titled "High-speed signals jump over PCB traces" on the EDN.com Web site.
By Adam Taylor
So far on this journey, most of the boards we have looked at have been fitted with either the Zynq Z-7010 or Z-7020 SoCs. The new Aldec TySOM 2 board comes which with either a Zynq Z-7045 or Z-7100 device fitted, making it the most powerful Zynq-based board we have looked at to date. Especially with the Z-7100 SoC fitted as is the example Aldec has provided to me.
The TySOM 2 board is intended for development prototyping. As such, it provides you with a range of I/O pins, broken out on two FMC connectors that connect to 288 of the Zynq Z-7100 SoC’s 362 I/O pins and all 16 GTX lanes. It also provides some simple user peripherals including switches and LEDS along with an HDMI port connected to the Zynq SoC’s PL (programmable logic). Meanwhile, the Zynq PS (processing system) provides four USB 2.0 ports, Ethernet, and a USB/UART for connectivity and 1Gbyte of DDR memory. In short, the Aldec TySOM 2 board has everything we need to create a very power single board computer.
Here’s a block diagram of the TySOM 2 board:
Aldec TySOM 2 board block diagram
Of course, there’s a range of FPGA Mezzanine Cards (FMC) available from Aldec and other vendors to enable prototyping over a wide range of applications including vision, IIOT and ADAS. Aldec supplied my board with the ADAS daughter board, which enables the connection of up to five cameras using FPD-Link III connections. As FMC is an ANSI standard, there are a wide range of 3rd-party FMCs available, which further widen the prototyping options to support applications such as Software Defined Radio.
As I mentioned before, the Zynq Z-7100 SoC is the most powerful Zynq device we have examined to date. So what does the Z-7100 bring to the party that we have not seen before (not including the PL’s increased logic resources)? The most obvious addition is the provision of the 16 GTX transceivers that support data rates to 12.5Gbps. You can also use these high-speed serial links to implement Gen1 (2.5 Gbps) and Gen2 (5.0 Gbps) PCIe interfaces. Multi-lane solutions are also possible. The Z-7100 can support as many as 8 lanes if we so desire.
We also gain access to high performance I/O pins for the first-time, which introduce digitally controlled, on-chip termination for better signal integrity. Zynq Z-7020 devices and below only provide High Range (HR) I/O, which handle a wider range of I/O voltages (1.2V to 3.3V) although with reduced performance. When it comes to logic resources, the Zynq Z-7100 SoC is very impressive. It gives us 444K logic cells, 2020 DSP slices, 26.5Mbits of block RAM, and 554,800 flip flops.
We will look more in detail at how we can use this development board over the next few weeks. However, Aldec shipped this board pre-installed with a face-detection application, which connects to a single camera using the ADAS FMC and an HDMI display. When I connected it all up and ran the application, the example sprung to life and detected my face as I moved about in front of the supplied camera:
My 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.
Here’s a 90-second video showing a 56Gbps Xilinx test chip with a 56Gbps PAM4 SerDes transceiver operating with plenty of SI margin and better than 10-12 error rate over a backplane originally designed for 28Gbps operation.
Note: This working demo employs a Xilinx test chip. The 56Gbps PAM4 SerDes is not yet incorporated into a product. Not yet.
For more information about this test chip, see “3 Eyes are Better than One for 56Gbps PAM4 Communications: Xilinx silicon goes 56Gbps for future Ethernet.”
With a big part of the embedded world just catching up to 32-bit RISC processors, you may have looked at the multiple 64-bit ARM Cortex-A53 processors in the Xilinx Zynq UltraScale+ MPSoC and wondered, “Why?” It’s a fair question and one that reminds me of the debates I had with my good friend Jack Ganssle at long-past Embedded Systems Conferences. I consider Jack to be one of the world’s foremost embedded-system design experts so he has a very informed opinion about these things. (If you do not subscribe to Jack’s free Embedded Muse newsletter, you should immediately click on that link and then come back.)
Jack and I discussed the use of 8-bit versus 32-bit processors in embedded systems many years ago. I argued that you could already see designers employing all sorts of memory block-switching schemes to circumvent the 8-bit processors’ 64Kbyte address-space limitations. Why do that? Why take on the significant burden of the added software complexity to juggle these switched-memory blocks when Moore’s Law had already made 32-bit processors with their immense address spaces eminently affordable?
Well, even 32-bit processors no longer have “immense’ memory spaces relative to the embedded tasks we must now tackle and address-space considerations are a big part of why you want to think about using 64-bit processors for embedded designs. But that’s not the sole or even the main consideration for using 64-bit processors in embedded designs.
Rather than argue the points here, my intent is to alert you to a free, 1-hour Webinar being taught by Doulos titled “Shift Gear with a 64-bit ARM-Powered MPSoC.” Yes, the title could be more descriptive, so here are the ARM Cortex-A53 programmer’s model enhancements that this Webinar will cover:
The Webinar will be conducted twice on April 21 to accommodate multiple time zones worldwide. Click here for more info.
Mentor has just announced the DRS360 platform for developing autonomous driving systems based on the Xilinx Zynq UltraScale+ MPSoC. The automotive-grade DRS360 platform is already designed and tested for deployment in ISO 26262 ASIL D-compliant systems.
This platform offers comprehensive sensor-fusion capabilities for multiple cameras, radar, LIDAR, and other sensors while offering “dramatic improvements in latency reduction, sensing accuracy and overall system efficiency required for SAE Level 5 autonomous vehicles.” In particular, the DRS360 platform’s use of the Zynq UltraScale+ MPSoC permits the use of “raw data sensors,” thus avoiding the power, cost, and size penalties of microcontrollers and the added latency of local processing at the sensor nodes.
Eliminating pre-processing microcontrollers from all system sensor nodes brings many advantages to the autonomous-driving system design including improved real-time performance, significant reductions in system cost and complexity, and access to all of the captured sensor data for a maximum-resolution, unfiltered model of the vehicle’s environment and driving conditions.
Rather than try to scale lower levels of ADAS up, Mentor’s DRS360 platform is optimized for Level 5 autonomous driving, and it’s engineered to easily scale down to Levels 4, 3 and even 2. This approach makes it far easier to develop systems at the appropriate level for the system you’re developing because the DRS360 platform is already designed to handle the most complex tasks from the beginning.
If you’re working with any sort of video, there’s a new 4-minute demo video you need to see. This video shows two new Zynq UltraScale+ EV MPSoC devices working in tandem to decode and display 4K60p streaming video in both H.264 and H.265 video formats in real time. Zynq UltraScale+ EV MPSoC devices incorporate hardened, low-latency H.264 and H.265 video codecs (encode and decode). The demo employs two Xilinx ZCU106 boards in the following configuration:
The first ZCU106 extracts the 4K60p video stream from a USB stick at 60Mbps, decodes the video, and displays it on a local monitor using a DisplayPort interface. At the same time, the on-board Zynq UltraScale+ EV device re-encodes the video using the on-chip H.265 encoder, which reduces the video bit rate to 10Mbps thanks to the improved encoding efficiency of the H.265 standard. The board then transmits the resulting 10Mbps video stream over a wired Ethernet connection to a second ZCU106 board, which decodes the video and displays it on a second monitor. The entire process occurs with such low latency that it’s hard to see any delay between the two displayed video streams.
Here’s the video demo:
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.
By Adam Taylor
We have looked at the XADC several times within this series. One thing we have not examined is how to use the external analog multiplexer capability. This is an oversight on my part as it can be very useful when we are architecting our system. With the XADC we can interface with up to 17 analog inputs: one dedicated Vp/Vn pair of inputs and sixteen auxiliary differential input pairs which share pins with the logic IO. This means that we can sample up to 17 different analog signals along with the device’s on-chip supply voltages and temperatures. This does of course does require the use of as many as 34 I/O pins, which can be challenging on some pin-constrained devices or designs.
The use of an external multiplexor provides us with the ability to sample up to 16 analog inputs. We need only 4 I/O lines for the multiplexer address as the Vp/Vn pair are dedicated and are outside of the multiplexer address. Note that we are not limited to using only the Vp/Vn pair for analog inputs. You can use any of the auxiliary inputs as well.
To demonstrate how we do this, the first thing with need is a Vivado design with the XADC set up to allow an external mux. We can do this on the ADC setup tab of the XADC wizard. We can also select which analog inputs are being used with the external mux. If we already have a design with the XADC enabled, we can use the AXI interface to configure it.
With the wider Vivado design, I am going to include some ILAs (Integrated Logic Analyzers) so that we can see what is happening internally and I am going to connect the mux pins from the FPGA to the ZedBoard AMS header GPIO pins and into a logic analyzer so that we can see they are changing as would be the case when driving an external mux.
Implementing this within the software is very similar to how we previously did this for the XADC. The first step is to configure the XADC as we would if we were using the internal mux capability. However, when we want to use the external mux we need to consider the information within UG480 and particularly the diagram below:
To use an external mux, we therefore need to do the following in addition to our normal approach:
Once these have been configured, we set the XADC sampling by setting the sequencer mode to continuous pass. This will then sequence the external mux pins around the inputs desired as shown below in the ILA capture when all 16 aux inputs are sampled.
The eagle-eyed will have noticed there are 16 external inputs which requires 4 pins but the external mux address provides 5 pins. To connect these to an external multiplexer we need to connect only the lower four bits of the address.
Just as we do when the internal mux is used, the sampled data from the conversion will be in the appropriate register and not in the Vp/Vn aux conversion register (e.g. aux 0 will be in aux 0, aux 1 in aux 1 and so on).
An external analog mux therefore allows us to monitor nearly the same number of analog signals with a much-reduced pin count. There is also another trick we can do with the XADC, which we will look, soon.
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.