Displaying articles for: 03-19-2017 - 03-25-2017
The multi-GHz processing capabilities of Xilinx FPGAs never fails to amaze me and the following video from National Instruments (NI) demonstrating the real-time signal-generation and analysis capabilities of the NI PXIe-5840 VST (Vector Signal Transceiver) are merely one more proof point. The NI VST is designed for use in a wide range of RF test systems including 5G and IoT RF applications, ultra-wideband radar prototyping, and RFIC testing. In the demo below, this 2nd-generation NI VST is generating an RF signal spanning 1.2GHz to 2.2GHz (1GHz of analog bandwidth) containing five equally spaced LTE channels. The analyzer portion of the VST is simultaneously and in real time demodulating and decoding the signal constellations in two of the five LTE channels.
The resulting analysis screen generated by NI’s LabVIEW software tells the story:
The reason that the NI PXIe-5840 VST can perform all of these feats in real time is because there’s a Xilinx Virtex-7 690T FPGA inside pulling the levers, making this happen. (NI’s 1st-generation VSTs employed Xilinx Virtex-6 FPGAs.)
Here's the 2-minute video of the NI VST demo:
Please contact National Instruments directly for more information on its VST family.
For additional blogs about NI’s line of VSTs, see:
If you’re going to strap two 12Gsamples/sec, 16-bit DACs and two 6.4Gsamples/sec, 12-bit ADCs into your VPX/AMC module, you’d better include massive real-time DSP horsepower to tame them. That’s exactly what VadaTech has done with its VPX599 and AMC599 modules by placing a Xilinx Kintex UltraScale KU115 FPGA (along with 16 or 20Gbytes of high-speed DDR4 SDRAM) on the modules’ digital carrier board mated to an FMC analog converter board.
VadaTech AMC599 ADC/DAC Module
VadaTech VPX599 ADC/DAC Module
Here’s a block diagram of the AMC599 module (the VPX599 block diagram is quite similar):
VadaTech AMC599 ADC/DAC Module Block Diagram
At these conversion rates, raw data streams to and from the host CPU are quite impractical so you must, repeat must, have on-board processing and local storage—and what other processing genie besides a Xilinx UltraScale FPGA would you trust to handle and process those sorts of extreme streams?
Please contact VadaTech directly for more information on the VPX599 and AMC599 modules.
The just-announced VICO-4 TICO SDI Converter from Village Island employs visually lossless 4:1 TICO compression to funnel a 4K60p video (on four 3G-SDI video streams or one 12G-SDI stream) into onto a single 3G-SDI output stream, which reduces infrastructure costs for transport, cabling, routing, and compression in broadcast networks.
VICO-4 4:1 SDI Converter from Village Island
Here’s a block diagram of what’s going on inside of Village Island’s VICO-4 TICO SDI Converter:
And here’s a diagram showing you what broadcasters can do with this sort of box:
The reason this is even possible in a real-time broadcast environment is because the lightweight intoPIX TICO compression algorithm has very low latency (just very a few video lines) when implemented in hardware as IP. (Software-based, frame-by-frame video compression is therefore totally out of the question in an application such as this introduces too much delay.)
Looking at the VICO-4’s main (and only) circuit board shows one main chip implementing the 4:1 compression and signal multiplexing. And that chip is… a Xilinx Kintex UltraScale KU035 FPGA. It has plenty of on-chip programmable logic for the TICO compression IP and it has sixteen 16.3Gbps transceiver ports—more than plenty to handle the 3G- and 12G-SGI I/O required by this application.
Note: Paltek in Japan is distributing Village Island’s VICO-4 board in Japan as an OEM component. The board needs 12Vdc at ~25VA.
For more information about TICO compression IP, see:
A configurable, COG (center-of-gravity), laser-line extraction algorithm allows VRmagic’s LineCam3D to resolve complex surface contours with 1/64 sub-pixel accuracy. (The actual measurement precision, which can be as small as a micrometer, depends on the optics attached to the camera.) The camera must process the captured video internally because, at its maximum 1KHz scan rate, there would be far more raw contour data than can be pumped over the camera’s GigE Vision interface. The algorithm therefore runs in real time on the camera’s internal Xilinx series 7 FPGA, which is paired with a TI DaVinci SoC to handle other processing chores and 2Gbytes of DDR3 SDRAM. The camera’s imager is a 2048x1088-pixel CMOSIS CMV2000 CMOS image sensor with a pipelined global shutter. The VRmagic LineCam3D also has a 2D imaging mode that permits the extraction of additional object information such as surface printing that would not appear on the contour scans (as demonstrated in the photo below).
Here’s a composite photo of the camera’s line-scan contour output (upper left), the original object being scanned (lower left), and the image of the object constructed from the contour scans (right):
In laser-triangulation measurement setups, the camera’s lens plane is not parallel to the scanned object’s image plane, which means that only a relatively small part of the laser-scanned image would normally be in focus due to limited depth of focus. To compensate for this, the LineCam3D integrates a 10° tilt-shift adapter into its rugged IP65/67 aluminum housing, to expand the maximum in-focus object height. Anyone familiar with photographic tilt-shift lenses—mainly used for architectural photography in the non-industrial world—immediately recognizes this as the Scheimpflug principle, which increases depth of focus by tilting the lens relative to both the imager plane and the subject plane. It’s fascinating that this industrial camera incorporates this ability into the camera body so that any C-mount lens can be used as a tilt-shift lens.
For more information about the LineCam3D camera, please contact VRmagic directly.
There’s a new line in the table for Spartan-7 FPGAs in the FPGA selection guide on page 2 showing an expanded-temperature range option of -40 to +125°C for all six family members. These are “Expanded Temp” -1Q devices. So if you have the need for extreme hi-temp (or low-temp) operation, you might want to check into these devices. Ask your friendly neighborhood Xilinx or Avnet sales rep.
For more information about the Spartan-7 FPGA product family, see:
National Instruments’ (NI’s) VirtualBench All-in-One Instrument, based on the Xilinx Zynq Z-7020 SoC, combines a mixed-signal oscilloscope with protocol analysis, an arbitrary waveform generator, a digital multimeter, a programmable DC power supply, and digital I/O. The PC- or tablet-based user-interface software allows you to make all of those instruments play together as a troubleshooting symphony. That point is made very apparent in this new 3-minute video demonstrating the speed at which you can troubleshoot circuits using all of the VirtualBench’s capabilities in concert:
For more Xcell Daily blog posts about the NI VirtualBench All-in-One instrument, see:
For more information about the VirtualBench, please contact NI directly.
I’ve known this was coming for more than a week, but last night I got double what I expected. Digilent’s Web site has been teasing the new Arty Z7 Zynq SoC dev board for makers and hobbyists for a week—but with no listed price. Last night, prices appeared. That’s right, there are two versions of the board available:
Digilent Arty Z7 dev board for makers and hobbyists
Other than that, the board specs appear identical.
The first thing you’ll note from the photo is that there’s a Zynq SoC in the middle of the board. You’ll also see the board’s USB, Ethernet, Pmod, and HDMI ports. On the left, you can see double rows of tenth-inch headers in an Arduino/chipKIT shield configuration. There are a lot of ways to connect to this board, which should make it a student’s or experimenter’s dream board considering what you can do with a Zynq SoC. (In case you don’t know, there’s a dual-core ARM Cortex-A9 MPCore processor on the chip along with a hearty serving of FPGA fabric.)
Oh yeah. The Xilinx Vivado HL Design Suite WebPACK tools? Those are available at no cost. (So is Digilent’s attractive cardboard packaging, according to Arty Z7 Web page.)
Although the Arty Z7 board has now appeared on Digilent’s Web site, the product’s Web page says the expected release date is March 27. That’s five whole days away!
As they say, operators are standing by.
Please contact Digilent directly for more Arty Z7 details.
The organizers of last week’s Embedded World show in Nuremberg gave out embedded AWARDS in three categories last week during the show and MathWorks’ HDL Coder won in the tools category. (See the announcement here.) If you don’t know about this unique development tool, now is a good time to become acquainted with it. HDL Coder accepts model-based designs created using MathWorks’ MATLAB and Simulink and can generate VHDL or Verilog for all-hardware designs or hardware and software code for designs based on a mix of custom hardware and embedded software running on a processor. That means that HDL Coder works well with Xilinx FPGAs and Zynq SoCs.
Here’s a diagram of what HDL Coder does:
You might also want to watch this detailed MathWorks video titled “Accelerate Design Space Exploration Using HDL Coder Optimizations.” (Email registration required.)
For more information about using MathWorks HDL Coder to target your designs for Xilinx devices, see:
Sundance PXIe700 module based on a Xilinx Kintex-7 FPGA
Here’s a block diagram of the Sundance PXIe700 module:
Sundance PXIe700 module based on a Xilinx Kintex-7 FPGA, Block Diagram
Sundance provides this board with the SCom IP Core, which communicates to the host through the PCIe interface and provides the user logic instantiated in the Kintex-7 FPGA with a multichannel streaming interface to the host CPU and sample applications. Other IP cores, a Windows driver, DLL, and user-interface software are also available. The PXIe700 data sheet also mentions a VideoGuru toolset that can turn this hardware into a video test center for NTSC, VGA, DVI, SMPTE, GigE-Vision, and other video standards. (Contact Sundance DSP for more details.)
The Sundance product page also shows the PXIe700 board with a couple of Sundance FMC modules attached as example applications:
Sundance PXIe700 with attached FMC-DAQ2p5 multi-Gsample/sec ADC and DAC card
Sundance PXIe700 with attached FMC-ADC500-5 5-channel, 500Msamples/sec, 16-bit ADC card
You want to learn how to design with and use RF, right? Students from all levels and backgrounds looking to improve their RF knowledge will want to take a look at the new ADALM-PLUTO SDR USB Learning Module from Analog Devices. The $149 USB module has an RF range of 325MHz to 3.8GHz with separate transmit and receive channels and 20MHz of instantaneous bandwidth. It pairs two devices that seem made for each other: an Analog Devices AD9363 Agile RF Transceiver and a Xilinx Zynq Z-7010 SoC.
Analog Devices’ $149 ADALM-PLUTO SDR USB Learning Module
Here’s an extremely simplified block diagram of the module:
Analog Devices’ ADALM-PLUTO SDR USB Learning Module Block Diagram
However, the learning module’s hardware is of little use without training material and Analog Devices has already created dozens of online tutorials and teaching materials for this device including ADS-B aircraft position, receiving NOAA and Meteor-M2 weather satellite imagery, GSM analysis, listening to TETRA signals, and pager decoding.
By Adam Taylor
So far, we have addressed how to communicate, control, and read conversions from the Sysmon block in the Zynq UltraScale+ MPSoC’s PS (processing system). However, we have not addressed the Sysmon in the Zynq UltraScale+ MPSoC’s PL (programmable logic), which provides us the ability to monitor external signals.
As I mentioned in my first blog looking at the Zynq UltraScale+ MPSoC’s AMS capabilities, the first thing we need to do to use the PL Sysmon is check that it is available. We do this by reading the AMS block’s combined status register, which resides at address 0xFFA50044, named PL_SYSMON_CONTROL_STATUS. Only the LSB is used within this register. If that bit is set high, then the PL Sysmon is available. Otherwise, we should not try to address it.
We can access this register using a simple call to read the address as below:
pl_status = Xil_In32(0xFFA50044); // pl_status is a u32
Once we have confirmed availability, we can use the same approach that we did in the previous blog to configure the PS Sysmon. The only difference is that this time we will be configuring and using PL Sysmon, not the PS Sysmon. The exception this time it that as opposed to using the XSYSMON_PS block identifier, which says we wish to us the PS Sysmon, this time we need to use the XSYSMON_PL block identifier to use the PL Sysmon. This block identifier establishes the base address of the Sysmon we wish to use.
We can select the Sysmon channel wish to monitor using the sequencer masks available within xsysmonpsu_hw.h. Most of these sequencer channels are named as per their channel (e.g. VP_VN) as they are dedicated to one or the other Sysmon. The supply channels are not so named. As such, we need to understand when addressing either the PL or PS Sysmon what voltage parameter we are monitoring. The table below shows to monitored parameter for the both the PS and the PL channels.
What is very helpful is the ability of the PL Sysmon to monitor the PS core voltages. This is especially of interest for mission-critical applications. We will talk more about this in future blogs.
Putting this all together in a simple application that we run on the Zynq UltraScale+ MPSoC’s ARM cortex-A53 cores (the ARM Cortex-R5 cores can do the same), we can see the following results when reading both the PL and PS Sysmons:
Mapping the supplies above against the Zynq UltraScale+ MPSoC’s data sheet and IOCC user guide, voltages for the IO banks show both Sysmons are reading the correct values.
At this point, we have addressed either one or the other of the Sysmon blocks available using the block identifier. However, we can also read back several other critical voltages via the AMS block. This AMS Block is the third block identifier available which is XSYSMON_AMS.
We use this third block identifier to address the AMS block, within which we can read back the values of several other system critical voltages. These voltages include the five Zynq UltraScale+ MPSoC PS PLL voltages; the DDR PLL voltage; the battery voltage; and the VCC INT, BRAM, and AUX voltages.
We can address these voltages within the AMS block using the correct channel number and the “get ADC data” function as shown below:
XSysMonPsu_GetAdcData(InstancePtr, XSM_CH_VCC_PSLL0, XSYSMON_AMS);
When we are working with these channel numbers, it can get confusing as to what block identifier we should be using. It is worthwhile remembering that channels 0-6, 8-10 and 13-37 are addressed by the PL or PS Sysmon block identifiers while channels 38-53 to are addressed only by the AMS identifier.
If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.