All-Programmable SoC Solution

Anyone creating a complex, powerful digital design may want to turn to a single device that integrates high-speed processing and programmable logic.

In Circuit Cellar’s April issue, columnist Colin O’Flynn explores using the Xilinx Zynq  Z-7020 All Programmable SoC (system-on-a-chip) as part of the Avnet ZedBoard development board.

“I used a Xilinx Zynq SoC device, although Altera offers several flavors of a similar device (e.g., the Cyclone V SoC, the Arria V SoC, and the Arria 10 SoC), and Microsemi offers the SmartFusion2 SoC FPGA,” O’Flynn says in his article. “The Xilinx and Altera devices feature a dual-core ARM Cortex-A9 processor, whereas the Microsemi devices feature a less powerful Cortex-M3 processor. You may not need a dual-core A9 processor, so ‘less powerful’ may be an advantage.”

While O’Flynn’s article introduces the ZedBoard, he notes many of its specifics also apply to the MicroZed board, a less expensive option with a smaller SoC. Xilinx’s Zynq device has many interesting applications made highly accessible through the ZedBoard and MicroZed boards, he says.

O’Flynn’s discussion of the Zynq SoC device includes the following excerpt. (The April issue, which includes O’Flynn’s full article, is available for membership download or single-issue purchase.)

WHERE’S THE BEEF?
Originally, I had planned to describe a complete demo project in this article. I was going to demonstrate how to use a combination of a custom peripheral and some of the hard cores to stream data from a parallel ADC device into DDR memory. But there wasn’t enough room to introduce the tools and cover the demo, so I decided to introduce the Zynq device (using the ZedBoard).

A demo project is available at ProgrammableLogicInPractice.com. Several tutorials for the Zynq device are available at xilinx.com and zedboard.org, so there isn’t any point in duplicating work! I’ve linked to some specific tutorials from the April 2014 post on ProgrammableLogicInPractice.com. Photo 1 shows the hardware I used, which includes a ZedBoard with my custom OpenADC board connected through the I/O lines.

An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

Photo 1: An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

FPGA PROCESSOR DESIGN 101
Even if you’re experienced in FPGA design, you may not have used Xilinx tools for processor-specific design. These tools include the Xilinx Platform Studio (XPS) and the Xilinx Software Development Kit (SDK). Before the advent of hard-core processors (e.g., Zynq), there have long existed soft-core processors, including the popular Xilinx MicroBlaze soft processor. The MicroBlaze system is completely soft core, so you can use the XPS tool to define the peripherals you wish to include. For the Zynq device, several hard-core peripherals are always present and you can choose to add additional soft-core (i.e., use the FPGA fabric) peripherals.

In a future article I will discuss different soft-core processor options, including some open-source third-party ones that can be programmed from the Arduino environment. For now, I’ll examine only the Xilinx tools, which are applicable to the Zynq device, along with the MicroBlaze core.

The ARM cores in the Zynq device are well suited to run Linux, which gives you a large range of existing code and tools to use in your overall solution. If you don’t need those tools, you can always run on “bare metal” (e.g., without Linux), as the tools will generate a complete base project for you that compiles and tests the peripherals (e.g., printing “Hello World” out the USART). To give you a taste of this, I’ve posted a demo video of bringing up a simple “Hello World” project in both Linux and bare metal systems on ProgrammableLogicInPractice.com.

The FPGA part of the Zynq device is called the programmable logic (PL) portion. The ARM side is called the processing system (PS) portion. You will find a reference to the SoC’s PL or PS portion throughout most of the tutorials (along with this article), so it’s important to remember which is which!

For either system, you’ll be starting with the XPS software (see Photo 2). This software is used to design your hardware platform (i.e., the PL fabric), but it also gives you some customization of the PS hard-core peripherals.

This is the main screen of the Xilinx Platform Studio (XPS) when configuring a Zynq design. On the left you can see the list of available soft-core peripherals to add to the design. You can configure any of the hard-core peripherals by choosing to enable or disable them, along with selecting from various possible I/O connections. Additional screens (not shown) enable you to configure peripherals addressing information, configure I/O connections for the soft-core peripherals, and connect peripherals to various available extension buses.

Photo 2: This is the main screen of the Xilinx Platform Studio (XPS) when configuring a Zynq design. On the left you can see the list of available soft-core peripherals to add to the design. You can configure any of the hard-core peripherals by choosing to enable or disable them, along with selecting from various possible I/O connections. Additional screens (not shown) enable you to configure peripherals addressing information, configure I/O connections for the soft-core peripherals, and connect peripherals to various available extension buses.

MAKING THE CONNECTION
For example, clicking on the list of hard-core peripherals opens the options dialogue so you can enable or disable each peripheral along with routing the I/O connections. The ZedBoard’s Zynq device has 54 multipurpose I/O (MIO) lines that can be used by the peripherals, which are split into two banks. Each bank can use different I/O standards (e.g., 3.3 and 1.5 V).

Enabling all the peripherals would take a lot more than 54 I/O lines. Therefore, most of the I/O lines share multiple functions on the assumption that every peripheral doesn’t need to be connected. Many of the peripherals can be connected to several different I/O locations, so you (hopefully) don’t run into two peripherals needing the same I/O pin.

Almost all of the peripheral outputs can be routed to the PL fabric as well under the name EMIO, which is a dedicated 64-bit bus that connects to the PL fabric. If you simply wish to get more I/O pins, you can configure these extra pins from within XPS. But you can also use this EMIO bus to control existing cores in your FPGA fabric using peripherals on the Zynq device.

Assume you had an existing FPGA design where you had an FPGA core doing some processing connected to a microcontroller or computer via I2C, SPI, or serial. You could simply connect this core to the appropriate PS peripheral and port the existing code onto the Zynq processor by changing the low-level calls to use the Zynq peripherals. You may eventually wish to change this interface to the peripheral bus, the AMBA Advanced eXtensible Interface (AXI), for better performance. However, using standard peripherals to interface to a PL design can still be useful for many cores for which you have extensive existing code.

The MIO/EMIO pins can even be used in a bit-banging fashion, so if you need a special device or core control logic, it’s possible to quickly develop this in software. You can then move to a hardware peripheral for considerably better performance.

O’Flynn’s article goes on to discuss in greater detail the internal buses, peripherals, and taking a design from hardware to software. For more, refer to Circuit Cellar‘s  April issue and related application notes posted at O’Flynn’s companion site ProgrammableLogicInPractice.com.

Embedded Programming: Rummage Around In This Toolbox

Circuit Cellar’s April issue is nothing less than an embedded programming toolbox. Inside you’ll find tips, tools, and online resources to help you do everything from building a simple tracing system that can debug a small embedded system to designing with a complex system-on-a-chip (SoC) that combines programmable logic and high-speed processors.

Article contributor Thiadmer Riemersma describes the three parts of his tracing system: a set of macros to include in the source files of a device under test (DUT), a PC workstation viewer that displays retrieved trace data, and a USB dongle that interfaces the DUT with the workstation (p. 26).

Thaidmer Riemersma's trace dongle is connected to a laptop and device. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation.

Thaidmer Riemersma’s trace dongle is connected to a laptop and DUT. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation.

Riemersma’s special serial protocol overcomes common challenges of tracing small embedded devices, which typically have limited-performance microcontrollers and scarce interfaces. His system uses a single I/O and keeps it from bottlenecking by sending DUT-to-workstation trace transmissions as compact binary messages. “The trace viewer (or trace “listener”) can translate these message IDs back to the human-readable strings,” he says.

But let’s move on from discussing a single I/0 to a tool that offers hundreds of I/0s. They’re part of the all-programmable Xilinx Zynq SoC, an example of a device that blends a large FPGA fabric with a powerful processing core. Columnist Colin O’Flynn explores using the Zynq SoC as part of the Avnet ZedBoard development board (p. 46). “Xilinx’s Zynq device has many interesting applications,” O’Flynn concludes. “This is made highly accessible by the ZedBoard and MicroZed boards.”

An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

An Avnet ZedBoard is connected to the OpenADC. (Source: C. O’Flynn, Circuit Cellar 285)

Our embedded programming issue also includes George Novacek’s article on design-level software safety analysis, which helps avert hazards that can damage an embedded controller (p. 39). Bob Japenga discusses specialized file systems essential to Linux and a helpful networking protocol (p. 52).

One of the final steps is mounting the servomotor for rudder control. Thin cords connect the servomotor horn and the rudder. Two metal springs balance mechanical tolerances.

Jens Altenburg’s project

Other issue highlights include projects that are fun as well as instructive. For example, Jens Altenburg added an MCU, GPS, flight simulation, sensors, and more to a compass-controlled glider design he found in a 1930s paperback (p. 32). Columnist Jeff Bachiochi introduces the possibilities of programmable RGB LED strips (p. 66).

Configurable Regulator

LinearThe LTM4644 quad output step-down µModule (micromodule) regulator is configurable as a single (16-A), dual (12-A, 4-A, or 8-A, 8-A), triple (8-A, 4-A, 4-A), or quad (4-A each) output regulator. This flexibility enables system designers to rely on one simple and compact µModule regulator for the various voltage and load current requirements of FPGAs, ASICs, and microprocessors as well as other board circuitry. The LTM4644 is ideal for communications, data storage, industrial, transportation, and medical system applications.

The LTM4644 regulator includes DC/DC controllers, power switches, inductors and compensation components. Only eight external ceramic capacitors (1206 or smaller case sizes) and four feedback resistors (0603 case size) are required to regulate four independently adjustable outputs from 0.6 to 5.5 V. Separate input pins enable the four channels to be powered from a common supply rail or different rails from 4 to 14 V.

At an ambient temperature of 55°C, the LTM4644 delivers up to 13 A at 1.5 V from a 12-V input or up to 14 A with 200-LFM airflow. The four channels operate at 90° out-of-phase to minimize input ripple whether at the 1-MHz default switching frequency or synchronized to an external clock between 700 kHz and 1.3 MHz. With the addition of an external bias supply above 4 V, the LTM4644 can regulate from an input supply voltage as low as 2.375 V. The regulator also includes output overvoltage and overcurrent fault protection.

The LTM4644 costs $22.85 each in 1,000-unit quantities.

Linear Technology Corp.
www.linear.com

Places for the IoT Inside Your Home

It’s estimated that by the year 2020, more than 30 billion devices worldwide will be wirelessly connected to the IoT. While the IoT has massive implications for government and industry, individual electronics DIYers have long recognized how projects that enable wireless communication between everyday devices can solve or avert big problems for homeowners.

February CoverOur February issue focusing on Wireless Communications features two such projects, including  Raul Alvarez Torrico’s Home Energy Gateway, which enables users to remotely monitor energy consumption and control household devices (e.g., lights and appliances).

A Digilent chipKIT Max32-based embedded gateway/web server communicates with a single smart power meter and several smart plugs in a home area wireless network. ”The user sees a web interface containing the controls to turn on/off the smart plugs and sees the monitored power consumption data that comes from the smart meter in real time,” Torrico says.

While energy use is one common priority for homeowners, another is protecting property from hidden dangers such as undetected water leaks. Devlin Gualtieri wanted a water alarm system that could integrate several wireless units signaling a single receiver. But he didn’t want to buy one designed to work with expensive home alarm systems charging monthly fees.

In this issue, Gualtieri writes about his wireless water alarm network, which has simple hardware including a Microchip Technology PIC12F675 microcontroller and water conductance sensors (i.e., interdigital electrodes) made out of copper wire wrapped around perforated board.

It’s an inexpensive and efficient approach that can be expanded. “Multiple interdigital sensors can be wired in parallel at a single alarm,” Gualtieri says. A single alarm unit can monitor multiple water sources (e.g., a hot water tank, a clothes washer, and a home heating system boiler).

Also in this issue, columnist George Novacek begins a series on wireless data links. His first article addresses the basic principles of radio communications that can be used in control systems.

Other issue highlights include advice on extending flash memory life; using C language in FPGA design; detecting capacitor dielectric absorption; a Georgia Tech researcher’s essay on the future of inkjet-printed circuitry; and an overview of the hackerspaces and enterprising designs represented at the World Maker Faire in New York.

Editor’s Note: Circuit Cellar‘s February issue will be available online in mid-to-late January for download by members or single-issue purchase by web shop visitors.

Q&A: Marilyn Wolf, Embedded Computing Expert

Marilyn Wolf has created embedded computing techniques, co-founded two companies, and received several Institute of Electrical and Electronics Engineers (IEEE) distinctions. She is currently teaching at Georgia Institute of Technology’s School of Electrical and Computer Engineering and researching smart-energy grids.—Nan Price, Associate Editor

NAN: Do you remember your first computer engineering project?

MARILYN: My dad is an inventor. One of his stories was about using copper sewer pipe as a drum memory. In elementary school, my friend and I tried to build a computer and bought a PCB fabrication kit from RadioShack. We carefully made the switch features using masking tape and etched the board. Then we tried to solder it and found that our patterning technology outpaced our soldering technology.

NAN: You have developed many embedded computing techniques—from hardware/software co-design algorithms and real-time scheduling algorithms to distributed smart cameras and code compression. Can you provide some information about these techniques?

Marilyn Wolf

Marilyn Wolf

MARILYN: I was inspired to work on co-design by my boss at Bell Labs, Al Dunlop. I was working on very-large-scale integration (VLSI) CAD at the time and he brought in someone who designed consumer telephones. Those designers didn’t care a bit about our fancy VLSI because it was too expensive. They wanted help designing software for microprocessors.

Microprocessors in the 1980s were pretty small, so I started on simple problems, such as partitioning a specification into software plus a hardware accelerator. Around the turn of the millennium, we started to see some very powerful processors (e.g., the Philips Trimedia). I decided to pick up on one of my earliest interests, photography, and look at smart cameras for real-time computer vision.

That work eventually led us to form Verificon, which developed smart camera systems. We closed the company because the market for surveillance systems is very competitive.
We have started a new company, SVT Analytics, to pursue customer analytics for retail using smart camera technologies. I also continued to look at methodologies and tools for bigger software systems, yet another interest I inherited from my dad.

NAN: Tell us a little more about SVT Analytics. What services does the company provide and how does it utilize smart-camera technology?

MARILYN: We started SVT Analytics to develop customer analytics for software. Our goal is to do for bricks-and-mortar retailers what web retailers can do to learn about their customers.

On the web, retailers can track the pages customers visit, how long they stay at a page, what page they visit next, and all sorts of other statistics. Retailers use that information to suggest other things to buy, for example.

Bricks-and-mortar stores know what sells but they don’t know why. Using computer vision, we can determine how long people stay in a particular area of the store, where they came from, where they go to, or whether employees are interacting with customers.

Our experience with embedded computer vision helps us develop algorithms that are accurate but also run on inexpensive platforms. Bad data leads to bad decisions, but these systems need to be inexpensive enough to be sprinkled all around the store so they can capture a lot of data.

NAN: Can you provide a more detailed overview of the impact of IC technology on surveillance in recent years? What do you see as the most active areas for research and advancements in this field?

MARILYN: Moore’s law has advanced to the point that we can provide a huge amount of computational power on a single chip. We explored two different architectures: an FPGA accelerator with a CPU and a programmable video processor.

We were able to provide highly accurate computer vision on inexpensive platforms, about $500 per channel. Even so, we had to design our algorithms very carefully to make the best use of the compute horsepower available to us.

Computer vision can soak up as much computation as you can throw at it. Over the years, we have developed some secret sauce for reducing computational cost while maintaining sufficient accuracy.

NAN: You wrote several books, including Computers as Components: Principles of Embedded Computing System Design and Embedded Software Design and Programming of Multiprocessor System-on-Chip: Simulink and System C Case Studies. What can readers expect to gain from reading your books?

MARILYN: Computers as Components is an undergraduate text. I tried to hit the fundamentals (e.g., real-time scheduling theory, software performance analysis, and low-power computing) but wrap around real-world examples and systems.

Embedded Software Design is a research monograph that primarily came out of Katalin Popovici’s work in Ahmed Jerraya’s group. Ahmed is an old friend and collaborator.

NAN: When did you transition from engineering to teaching? What prompted this change?

MARILYN: Actually, being a professor and teaching in a classroom have surprisingly little to do with each other. I spend a lot of time funding research, writing proposals, and dealing with students.

I spent five years at Bell Labs before moving to Princeton, NJ. I thought moving to a new environment would challenge me, which is always good. And although we were very well supported at Bell Labs, ultimately we had only one customer for our ideas. At a university, you can shop around to find someone interested in what you want to do.

NAN: How long have you been at Georgia Institute of Technology’s School of Electrical and Computer Engineering? What courses do you currently teach and what do you enjoy most about instructing?

MARILYN: I recently designed a new course, Physics of Computing, which is a very different take on an introduction to computer engineering. Instead of directly focusing on logic design and computer organization, we discuss the physical basis of delay and energy consumption.

You can talk about an amazingly large number of problems involving just inverters and RC circuits. We relate these basic physical phenomena to systems. For example, we figure out why dynamic RAM (DRAM) gets bigger but not faster, then see how that has driven computer architecture as DRAM has hit the memory wall.

NAN: As an engineering professor, you have some insight into what excites future engineers. With respect to electrical engineering and embedded design/programming, what are some “hot topics” your students are currently attracted to?

MARILYN: Embedded software—real-time, low-power—is everywhere. The more general term today is “cyber-physical systems,” which are systems that interact with the physical world. I am moving slowly into control-oriented software from signal/image processing. Closing the loop in a control system makes things very interesting.

My Georgia Tech colleague Eric Feron and I have a small project on jet engine control. His engine test room has a 6” thick blast window. You don’t get much more exciting than that.

NAN: That does sound exciting. Tell us more about the project and what you are exploring with it in terms of embedded software and closed-loop control systems.

MARILYN: Jet engine designers are under the same pressures now that have faced car engine designers for years: better fuel efficiency, lower emissions, lower maintenance cost, and lower noise. In the car world, CPU-based engine controllers were the critical factor that enabled car manufacturers to simultaneously improve fuel efficiency and reduce emissions.

Jet engines need to incorporate more sensors and more computers to use those sensors to crunch the data in real time and figure out how to control the engine. Jet engine designers are also looking at more complex engine designs with more flaps and controls to make the best use of that sensor data.

One challenge of jet engines is the high temperatures. Jet engines are so hot that some parts of the engine would melt without careful design. We need to provide more computational power while living with the restrictions of high-temperature electronics.

NAN: Your research interests include embedded computing, smart devices, VLSI systems, and biochips. What types of projects are you currently working on?

MARILYN: I’m working on with Santiago Grivalga of Georgia Tech on smart-energy grids, which are really huge systems that would span entire countries or continents. I continue to work on VLSI-related topics, such as the work on error-aware computing that I pursued with Saibal Mukopodhyay.

I also work with my friend Shuvra Bhattacharyya on architectures for signal-processing systems. As for more unusual things, I’m working on a medical device project that is at the early stages, so I can’t say too much specifically about it.

NAN: Can you provide more specifics about your research into smart energy grids?

MARILYN: Smart-energy grids are also driven by the push for greater efficiency. In addition, renewable energy sources have different characteristics than traditional coal-fired generators. For example, because winds are so variable, the energy produced by wind generators can quickly change.

The uses of electricity are also more complex, and we see increasing opportunities to shift demand to level out generation needs. For example, electric cars need to be recharged, but that can happen during off-peak hours. But energy systems are huge. A single grid covers the eastern US from Florida to Minnesota.

To make all these improvements requires sophisticated software and careful design to ensure that the grid is highly reliable. Smart-energy grids are a prime example of Internet-based control.

We have so many devices on the grid that need to coordinate that the Internet is the only way to connect them. But the Internet isn’t very good at real-time control, so we have to be careful.

We also have to worry about security Internet-enabled devices enable smart grid operations but they also provide opportunities for tampering.

NAN: You’ve earned several distinctions. You were the recipient of the Institute of Electrical and Electronics Engineers (IEEE) Circuits and Systems Society Education Award and the IEEE Computer Society Golden Core Award. Tell us about these experiences.

MARILYN: These awards are presented at conferences. The presentation is a very warm, happy experience. Everyone is happy. These things are time to celebrate the field and the many friends I’ve made through my work.