We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!


Earlier this week at Photonics West in San Francisco, Tattile introduced the high-speed, 12Mpixel S12MP Smart Camera based on a Xilinx Zynq Z-7030 SoC. (See “Tattile’s 12Mpixel S12MP industrial GigE Smart Camera captures 300 frames/sec with Zynq SoC processing help.”) However, the S12MP camera is not the company’s first smart camera to be based on Xilinx Zynq SoCs. In fact, the company previously introduced four other color/monochrome/multispectral, C-mount smart cameras based on various Zynq SoC family members:


  • The 640x480-pixel, 120 frames/sec S50 Compact Smart Camera series based on a CMOSIS CMV300 image sensor and a single-core Xilinx Zynq Z-7000S SoC.



Tattile S50 Smart Camera.jpg 


Tattile S50 Compact Smart Camera based on a single-core Xilinx Zynq Z-7000S SoC




  • The VGA-to-4Mpixel, 35-250 frames/sec Next-Generation S100 Smart Camera series based on one of three CMOSIS image sensors and a dual-core Xilinx Zynq Z-7000 SoC.




Tattile S100 Smart Camera.jpg 


Tattile S100 Compact Smart Camera based on a dual-core Xilinx Zynq Z-7000 SoC




  • The 4.2Mpixel, 180 frames/sec High-Performance S200 Smart Camera series based on a CMOSIS CMV4000 image sensor and a dual-core Xilinx Zynq Z-7000 SoC.


  • The Hyperspectral S200 Hyp Smart Camera series based on one of three hyperspectral image sensors and a dual-core Xilinx Zynq Z-7000 SoC.



Tattile S200 Smart Camera.jpg



Tattile S200 and S200 Hyp Smart Cameras based on a dual-core Xilinx Zynq Z-7000 SoC



All of these cameras use the Zynq SoC’s on-chip programmable logic to perform a variety of real-time vision processing. For example, the S50 and S100 Smart Cameras use the on-chip programmable logic for image acquisition and image preprocessing. The S200 Hyp camera uses the programmable logic to also perform reflectance calculations and multispectral image/cube reconstruction. In addition, Tattile is able to make the real-time processing capabilities of the programmable logic available in these cameras to its customers through software including a graphical development tool.


The compatible Xilinx Zynq Z-7000 and Z-7000S SoCs give Tattile’s development teams a choice of several devices with a variety of cost/performance/capability ratios while allowing Tattile to develop a unified camera platform on which to base a growing family of programmable smart cameras. The Zynq SoCs’ programmable I/O permits any type of image sensor to be used, including the multispectral line, tiled, and mosaic sensors used in the S200 Hyp series. The same basic controller design can be reused multiple times and the design is future-proof—ready to handle any new sensor type that might be introduced at a later date.


That’s exactly that happened with the newly introduced S12MP Smart Camera.



Please contact Tattile directly for more information about these Smart Cameras.



Xilinx launched the UltraFast Design Methodology more than three years ago. It’s designed to get you from project start to a successful, working design using the Xilinx Vivado Design Suite in the least amount of time using hand-picked best practices from industry experts. There’s a 364-page methodology manual titled “UltraFast Design Methodology Guide for the Vivado Design Suite” (UG949) that describes the methodology in detail and you can download and read it for free. (And you should.)


Don’t have time right now to read the 364-page version? Maybe you just want to get the ideas to see if it’s worth your time to read the full manual. (Hint: It is.)


OK, so if you’re that pressed for time there’s a 2-page Quick Reference Guide (UG1231) that you can read to see what the ideas are all about. You can download that guide here, also for free.



UltraFast Design Methodology Quick Reference Guide.jpg



Note: If you’re looking for something in between take a look at “UltraFast: Hand-picked best practices from industry experts, distilled into a potent Design Methodology.”


A Very Short Conversation with Ximea about Subminiature Video Cameras and Very Small FPGAs

by Xilinx Employee ‎02-02-2017 01:00 PM - edited ‎02-02-2017 09:54 PM (48,123 Views)


Yesterday at Photonics West, my colleague Aaron Behman and I stopped by the Ximea booth and had a very brief conversation with Max Larin, Ximea’s CEO. Ximea makes a very broad line of industrial and scientific cameras and a lot of them are based on several generations of Xilinx FPGAs. During our conversation, Max removed a small pcb from a plastic bag and showed it to us. “This is the world’s smallest industrial camera,” he said while palming a 13x13mm board. It was one of Ximea’s MU9 subminiature USB cameras based on a 5Mpixel ON Semiconductor (formerly Aptina) MT9P031 image sensor. Ximea’s MU9 subminiature camera is available as a color or monochrome device.


Here’s are front and back photos of the camera pcb:



Ximea MU9 Subminiature Camera.jpg


Ximea 5Mpixel MU9 subminiature USB camera



As you can see, the size of the board is fairly well determined by the 10x10mm image sensor, its bypass capacitors, and a few other electronic components mounted on the front of the board. Nearly all of the active electronics and the camera’s I/O connector are mounted on the rear. A Cypress CY7C68013 EZ-USB Microcontroller operates the camera’s USB interface and the device controlling the sensor is a Xilinx Spartan-3 XC3S50 FPGA in an 8x8mm package. FPGAs with their logic and I/O programmability are great for interfacing to image sensors and for processing the video images generated by these sensors.


Our conversation with Max Larin at Photonics West got me to thinking. I wondered, “What would I use to design this board today?” My first thought was to replace both the Spartan-3 FPGA and the USB microcontroller with a single- or dual-core Xilinx Zynq SoC, which can easily handle all of the camera’s functions including the USB interface, reducing the parts count by one “big” chip. But the Zynq SoC family’s smallest package size is 13x13mm—the same size as the camera pcb—and that’s physically just a bit too large.


The XC3S50 FPGA used in this Ximea subminiature camera is the smallest device in the Spartan-3 family. It has 1728 logic cells and 72Kbits of BRAM. That’s a lot of programmable capability in an 8x8mm package even though the Spartan-3 FPGA family first appeared way back in 2003. (See “New Spartan-3 FPGAs Are Cost-Optimized for Design and Production.”)


There are two newer Spartan FPGA families to consider when creating a design today, Spartan-6 and Spartan-7, and both device families include multiple devices in 8x8mm packages. So I decided see how much I might pack into a more modern FPGA with the same pcb real-estate footprint.


The simple numbers from the data sheets tell part of the story. A Spartan-3 XC3S50 provides you with 1728 logic cells, 72Kbits of BRAM, and 89 I/O pins. The Spartan-6 XCSLX4, XC6SLX9, and XCSLX16 provide you with 3840 to 14,579 logic cells, 216 to 576Kbits of BRAM, and 106 I/O pins. The Spartan-7 XC7S6 and XC7S15 provide 6000 to 12,800 logic cells, 180 to 360Kbits of BRAM, and 100 I/O pins. So both the Spartan-6 and Spartan-7 FPGA families provide nice upward-migration paths for new designs.


However, the simple data-sheet numbers don’t tell the whole story. For that, I needed to talk to Jayson Bethurem, the Xilinx Cost Optimized Portfolio Product Line Manager, and get more of the story. Jayson pointed out a few more things.


First and foremost, the Spartan-7 FPGA family offers a 2.5x performance/watt improvement over the Spartan-6 family. That’s a significant advantage right there. The Spartan-7 FPGAs are significantly faster than the Spartan-6 FPGAs as well. Spartan-6 devices in the -1L speed grade have a 250MHz Fmax versus 464MHz for Spartan-7 -1 or -1L parts. The fastest Spartan-6 devices in the -3 speed grade have an Fmax of 400MHz (still not as fast as the slowest Spartan-7 speed grade) and the fastest Spartan-7 FPGAs, the -2 parts, have an Fmax of 628MHz. So if you feel the need for speed, the Spartan-7 FPGAs are the way to go.


I’d be remiss not to mention tools. As Jayson reminded me, the Spartan-7 family gives you entrée into the world of Vivado Design Suite tools. That means you get access to the Vivado IP catalog and Vivado’s IP Integrator (IPI) with its automated integration features. These are two major benefits.


Finally, some rather sophisticated improvements to the Spartan-7 FPGA family’s internal routing architecture means that the improved placement and routing tools in the Vivado Design Suite can pack more of your logic into Spartan-7 devices and get more performance from that logic due to reduced routing congestion. So directly comparing logic cell numbers between the Spartan-6 and Spartan-7 FPGA families from the data sheets is not as exact a science as you might assume.


The nice thing is: you have plenty of options.



For previous Xcell Daily blog posts about Ximea industrial and scientific cameras, see:






Tattile’s rugged, new S12MP Ultra High Resolution Smart Camera for industrial and machine-vision applications pairs a 12Mpixel CMOSIS CMV12000 image sensor with a Xilinx Zynq Z-7030 SoC to create a compact, high-performance, programmable imaging system capable of capturing 300 12Mpixel, full-resolution frames/sec at 10 bits/pixel (and 140 frames/sec at 12 bits/pixel). The camera can capture partial-resolution video at even higher frame rates under programmatic control of the Zynq SoC. An on-board GigE Vision server streams the captured video to an Ethernet-connected host and an integrated SD card slot permits as much as 32Gbytes of local video storage. The camera takes F-mount lenses, measures only 80x80x60 (without the lens mount), and consumes just 12W from a 12Vdc supply.



Tattile S12MP Ultra High Resolution Smart Camerat.jpg 



The S12MP Ultra High Resolution Smart Camera is the latest in a growing line of Smart Cameras from Tattile. The company has focused on adding intelligence to its latest cameras to help customers reduce overall system costs in a variety of vision applications. To that end, Tattile has exposed the programmable logic inside of the S12MP camera to permit its customers to develop and run custom real-time vision algorithms in the camera itself using the Xilinx Vivado Design Suite. According to Tattile, pushing vision processing to the edge in this manner increases vision-system performance and lowers cost.


For more information about the S12MP Ultra High Resolution Smart Camera, please contact Tattile directly.



Adam Taylor’s MicroZed Chronicles, Part 168: The UltraZed Edition, Part 1

by Xilinx Employee ‎01-31-2017 02:48 PM - edited ‎01-31-2017 02:59 PM (88,466 Views)


By Adam Taylor


Note: Adam Taylor just cannot stop working with or writing about Xilinx devices (nor would we want him to). So here’s the first instalment of his new sub-series about the Zynq UltraScale+ MPSoC.)


Over the last three years, we have used this blog to look at and will continue to look at how we can use the Zynq-7000 SoC in our designs. However, the next generation Zynq, the Zynq UltraScale+ MPSoC, is now available and it would be remiss if we did not also cover how to use this new device and the Avnet UltraZed board in our designs and applications as well. So, welcome to the UltraZed edition of the MicroZed Chronicles.





Avnet UltraZed board on Carrier Card



Before we delve into the Avnet UltraZed board, which we are going to be using to explore this device, I want to spend some time explaining the internals of the Zynq UltraScale+ MPSoC device itself. Of course, this is just an overview and we will be looking more in depth at all aspects of the device as this series continues.


The Zynq UltraScale+ MPSoC is a heterogeneous processing platform which, like the Zynq-7000 SoC, combines a Processing System (PS) with Programmable Logic (PL). However, both PS and PL in the Zynq UltraScale+ MPSoC are significantly more capable.


Within the Zynq UltraScale+ MPSoC’s PS, we find the following main processing elements (I say main as there are others which will be introduced as well):


  • Quad-core or dual-core 64-bit ARM Cortex A53 processors within the Application Processing Unit (APU)
  • Dual 32-bit ARM Cortex R5 processors within the Real-Time Processing Unit (RPU)
  • Mali-400 Graphics Processing Unit (GPU) – Within the Zynq UltraScale+ EG and EV devices


These processing elements connect via a central interconnect to the MIO peripherals and other functions and interfaces within the PS. The MIO contains the same SPI, UART, I2C, CAN, etc. that are familiar to developers using the Zynq-7000 SoC. For configuration and storage, we can use SD/eMMC, Quad SPI or NAND Flash, also provided by the MIO, while high-speed system communication is provided via multiple GigE and USB 3 interfaces.







Zynq UltraScale+ MPSoC Block Diagram



The APU connects to the central interconnect via the System Memory Manager Unit (SMMU) and the Cache Coherent Interconnect (CCI) while the RPU connects to it via the low-power domain switch and the SMMU.


Which brings us nicely to the MPSoC power domains. There are four in total; three within the PS; and one in the PL:


  1. Battery Power Domain (BPD) – Lowest power mode, allows the maintenance of information when the power is removed, for instance in the BBRAM and RTC.
  2. Low Power Domain (LPD) – Mid power mode of the PS, powering a subset of the PS including the RPU.
  3. Full Power Domain (FPD) – Highest power mode of the PS with all the components of the PS powered up. In this mode we can still have the PL powered down if desired.
  4. PL Power Domain (PLPD) – Final Power mode which powers the PL.


We should remember that in these modes, the power dissipation will depend upon which of the components within the domain are currently being used and their operating frequency. These power domains are operated under the control of the Platform Management Unit (PMU). The PMU is a triple-redundant processor. It controls the power-up, reset and system monitoring for the Zynq UltraScale+ MPSoC. The PMU is a very interesting resource as it is also capable of running user-developed programs to provide more detailed system monitoring for safety and security applications.


When it comes to executing our application(s), we can use DDR3/4 SDRAMs or their low-power versions under the control of the integrated DDR controller. Data paths to this controller are directly from the RPU or the APU via its Cache Coherent Interconnect, while the PL, DMA controller, and Display Port Interfaces can be switched between as required.

So far, we have only examined the PS. The PL of the Zynq UltraScale+ MPSoC consists of next-generation programmable-logic fabric from either the Kintex UltraScale+ or Virtex UltraScale+ FPGA families, which include UltraRAM, Block RAM, and DSP48E2 slices. Depending upon which of the Zynq UltraScale+ MPSoC devices you select, you will find increased connectivity solutions like PCIe, Interlaken, GTH and GTY transceivers within the PL. In the EG device family, you will also find an H.265 / H.264 Video Codec.  


Like the Zynq-7000 SoC, the PS is the device master and configures the PL after power-up and initialization. The main method communication between the PL and the PS is also very similar and uses AXI Interfaces in both directions. Either the PL or the PS can be the AXI master. Depending upon the interface selected, these can be Cache- or I/O-Coherent or non-coherent; with data widths of 32, 64 or 128 bits.


Additional interfaces between the PS and the PL include:


  • PS Clocks – Four frequency-programmable clocks from the PS to the PL
  • Interrupts – PL-to-PS and PS-to-PL interrupts
  • EMIO Interfaces – Extended MIO made available from selected MIO components to the PL
  • Stream Interfaces – Dedicated stream interfaces for the GigE and Display Port components
  • PMU PL Interface – Dedicated signals for controlling and monitoring the PL via the PMU
  • Events – Bidirectional event signalling between PS and PL including wait for event and wait for interrupt, FPD and LPD events
  • DMA signals – Dedicated signals required for DMA transfers between PS and PL


Having briefly introduced the Zynq UltraScale+ MPSoC architecture, next week we will look at the UltraZed board and begin to build our first example.


You can find an overview of the different Zynq UltraScale+ MPSoC families here.


The in depth Zynq UltraScale+ MPSoC technical reference manual is available here.



SP Devices ADQ7_170125_02.jpg 


SP Devices’ ADQ7 digitizer boasts one or two 14-bit acquisition channels with an aggregate acquisition rate of 10Gsamples/sec (5G samples/sec in 2-channel mode) with either ac or dc coupling and is available in multiple bus formats including MTCA.4, USB3, PCIe, PXIe, and 10 Gbit Ethernet with a maximum, sustained data-transfer rate of 5Gbytes/sec (over PCIe).


Given those specs, you should see an immediate problem: there’s not enough bus bandwidth to get the full, continuous digitized data stream out of the module so you immediately know you’re going to need local storage and on-board processing and data reduction.


And what controls that on-board storage and performs that on-board processing (and does practically everything else as well)?




A Xilinx Kintex UltraScale FPGA, of course.




Here’s a block diagram of the dc-coupled ADQ7DC:






SP Devices ADQ7 Digitizer Block Diagram.jpg



On the left, you see the two pairs of high-speed ADCs that yield the 10Gsamples/sec acquisition speed. Note that all four of those ADCs directly feed the Kintex UltraScale FPGA, which performs several signal-processing steps including calibration; gain and offset adjustments; triggering; and any user-defined, real-time signal processing. You can define those processing blocks using SP Devices’ Dev Kit or you can order one of the several optional signal-processing modules that SP Devices has already developed for the ADQ7 including:


  • Advanced time-domain firmware (–FWATD)
  • Pulse data (–FWPD)
  • Software defined radio (–FWSDR)


As you can see from the block diagram, the Kintex UltraScale FPGA also manages the ADQ7 module’s overall timing control and manages the data flow through FIFO queues, into and out of the on-board 4Gbyte DRAM, and over the various interfaces offered in this module family—although the native interface appears to be PCIe. (Note: All Kintex UltraScale FPGA family members have at least one integrated PCIe Gen1/2/3 controller, independent of the on-chip programmable logic.)


This digitizer illustrates the use of one Xilinx All Programmable device to implement most of the functions in a complex system. The Kintex UltraScale FPGA in this design implements everything but the ADCs, the clock, the memory, and some of the interface hardware. Everything else is nicely bundled in the one UltraScale device with enough capability left over to allow for the addition of user-defined processing. This sort of flexibility offers real value for system designers.


For more information about the ADQ7 digitizer family, contact SP Devices directly.






Aquantia has packed its Ethernet PHY—capable of operating at 10Gbps over 100m of Cat 6a cable (or 5Gbps down to 100Mbps over 100m of Cat 5e cable)—with a Xilinx Kintex-7 FPGA, creating a universal Gigabit Ethernet component with extremely broad capabilities. Here’s a block diagram of the new AQLX107 device:



Aquantia AQLX107 PHY Block Diagram.jpg 



This Aquantia device gives you a space-saving, one-socket solution for a variety of Ethernet designs including controllers, protocol converters, and anything-to-Ethernet bridges.


Please contact Aquantia for more information about this unique Ethernet chip.




By Adam Taylor


Last week we explained how the servos we will be using worked and completed the hardware build in Vivado to control the servos with the TTC (triple timer/counter) in the Zynq SoC. All that remains now is to write software to configure the TTCs to generate the servo-control waveforms.


Within the hardware definition we included all the TTC components, breaking out all the wave outputs to EMIO pins in the Zynq SoC’s PL (programmable logic). So, when we look within the xparameters.h file, we find all of the device ID’s:





Definitions for TTC0 and TTC1 in the xparameters.h file



The software architecture we are going to follow will be a simple interrupt-based system. We need an interrupt-based system to ensure that we can drive the connected servos independently. If we don’t use an interrupt-based system and instead base our design on delays—like usleep provided by unistd.h—then the system won’t be adequately responsive. We must drive the servos independently if we want to anything remotely useful with them (e.g. steering and speed control).


We will structure the program as follows:



  1. Initialize the number of TTC’s we wish to use in our design. For this example we will use two.
  2. Set up both TTCs to generate a 50Hz waveform. We can control the generated waveform’s duty cycle using the match register.
  3. Configure the Generic Interrupt Controller (GIC) and enable both the match and interval interrupts for each TTC used.
  4. Write the interrupt service routine to be called for each TTC when an interrupt occurs. Each ISR will:
    1. Read the TTC Interrupt status register.
    2. If the interrupt source is an interval interrupt, then update the match register value to the desired position value to update the servo position.
    3. Clear the Interrupt Status.



For this simple example, each ISR will move the servo between its extreme positions and neutral. To do this, we need to change the waveform duty cycle for that servo during the ISR. The wave out signal for a TTC changes polarity when it matches the value contained within the match register, assuming the wave out is not disabled in the timer options. We can use the options to define the initial polarity as well, providing granular control over the wave out behavior. For us to move the servo between extreme positions and neutral, we need pulse widths between 0.5msec and 2.5msec with 1.5msec being the servo’s neutral position.


From last week we know this equates to either 2.5%, 7.5% or 12.5% of the 20msec waveform. We use the XTtcPs_CalcIntervalFromFreq()function, which takes the desired frequency and TTC clock frequency declared in the xparameters.h to determine what the interval and pre-scale of the TTC.


With this calculated we then apply these to the TTC and set it running once we have enabled the interrupts. To generate the correct pulse widths for the servo positions, we need to know the interval count and then we use that to set the pulse width accordingly. We can determine what the interval is one of two ways. In our application, we can use the XTtcPs_GetInterval() function or we can directly access the timer set up structure.


With the code written we can see that the interrupts for both servos in this example are handled independently of each other, allowing each servo to move to a different position as commanded.


Connecting a Digilent Analog Discovery to the two servo outputs, you can see the different pulse widths both repeating at 20msec (50Hz). The top trace shows the 1.5msec neutral-position value while the bottom waveform shows the extreme 2.5msec position.








When I connected this code to the servos, I recorded the following simple video showing the servos working as expected.





Having done this, we now understand not only how to drive simple servos but also, and just as importantly, how we can use the TTC to generate a PWM (Pulse-Width Modulated) output. Within embedded design, the ability to generate PWM waveforms can be very useful and has a number of different applications including analog signal generation.



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.




  • First Year E Book here
  • First Year Hardback here.




MicroZed Chronicles hardcopy.jpg 



  • Second Year E Book here
  • Second Year Hardback here




MicroZed Chronicles Second Year.jpg 




All of Adam Taylor’s MicroZed Chronicles are cataloged here.





The Linley Cloud Hardware Conference (formerly our Data Center Conference) is coming to the Hyatt Regency Hotel in Santa Clara, CA on February 8. This full-day, single-track event focuses on the processors, accelerators, Ethernet controllers, new memory technologies, and interconnects used for cloud computing and networking. The conference includes a special afternoon panel titled “Accelerating the Cloud” that will be moderated by The Linley Group’s Principal Analyst Jag Bolaria with the following panelists:


  • Kushagra Vaid, GM, Microsoft
  • Manish Muthal, VP, Xilinx
  • Scott Aylor, VP & GM, AMD
  • Chris Nicol, CTO, Wave Computing


Until Feb 2, you can snag a free ticket to the conference (and a free breakfast) by clicking here if you’re a cloud-service provider, network-service provider, network-equipment vendor, server OEM, system designer, software developer, member of the press, or work in the financial community. (That’s a pretty wide net.) After that date, it’s going to cost you $195 to attend if you’re in that net or $795 if you’re not.


Time to start swimming.



About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.