Propeller Multicore MCU Released as Open-Source Design

Parallax released its source code design files for the Propeller 1 (P8X32A) multicore microcontroller at the DEFCON 22 Conference in Las Vegas, where the chip was also featured on the conference’s electronic badge. Parallax managers said they anticipate the release will inspire developers. Hobbyists, engineers, and students can now view and modify the Propeller Verilog design files by loading them into low-cost field programmable gate array (FPGA) development boards. The design was released under the GNU General Public License v3.0.

Source: Parallax

Source: Parallax

With the chip’s source code now available, any developer can discover what they need to know about the design. The open release provides a way for developers who have requested more pins, memory, or other architectural improvements to make their own version to run on an FPGA. Universities who have requested access to the design files for their engineering programs will now have them.

The Propeller multicore microcontroller is used in developing technologies where multiple sensors, user interface systems, and output devices such as motors must be managed simultaneously. Some primary applications for Parallax’s chip include flight controllers in UAVs, 3-D printing, solar monitoring systems, environmental data collection, theatrical lighting and sound control, and medical devices.

For more information on Parallax’s open source release of the Propeller P8X32A, visit www.parallax.com.

 

Embedded SOM with Linux-Based RTOS

National Instruments has introduced an embedded system-on-module (SOM) development board with integrated Linux-based real-time operating system (RTOS).NIsom

Processing power in the 2” x 3” SOM comes from a Xilinx Zync-7020 all programmable SOC running a dual core ARM Cortex-A9 at 667 MHz. A built-in, low-power Artix-7 FPGA offers 160 single-ended I/Os and Its dedicated processor I/O include Gigabit Ethernet USB 2.0 host, USB 2.0 host/device, SDHC, RS-232, and Tx/Rx. The SOM’s power requirements are typically 3 to 5 W.

The SOM integrates a validated board support package (BSP) and device drivers together with the National Instruments Linux real-time OS. The SOM board is supplied with a full suite of middleware for developing an embedded OS, custom software drivers, and other common software components.

The LabVIEW FPGA graphical development platform eliminates the need for expertise in the design approach using a hardware description language.

[Via Elektor]

 

SDK for OpenCL Dev Flow

Altera Corp. has simplified a programmer’s ability to accelerate algorithms in FPGAs. The Altera SDK for OpenCL version 14.0 includes a programmer-familiar rapid prototyping design flow that enables users to prototype designs in minutes on an FPGA accelerator board. Altera, along with its board partners, further accelerate the development of FPGA-based applications by offering reference designs, reference platforms and FPGA development boards that are supported by Altera’s OpenCL solution. These reference platforms also streamline the development of custom FPGA accelerators to meet specific application requirements.

Altera is the only company to offer a publicly available, OpenCL conformant software development kit (SDK). The solution allows programmers to develop algorithms with the C-based OpenCL language and harness the performance and power efficiencies of FPGAs. A rapid prototyping design flow included in the Altera SDK for OpenCL version 14.0 allows OpenCL kernel code to be emulated, debugged, optimized, profiled and re-compiled to a hardware implementation in minutes. The re-compiled kernels can be tested and run on an FPGA immediately, saving programmers weeks of development time.

Altera and its board partners further simplify the experience of getting applications up and running using FPGA accelerators by offering a broad selection of Altera-developed reference platforms, reference designs and FPGA accelerator boards. Altera provides a variety of design examples that demonstrate how to describe applications in OpenCL, including OPRA FAST Parser for finance applications, JPEG decoder for big data applications and video downscaling for video applications.

Design teams that want to create custom solutions that feature a unique set of peripherals can create their own custom FPGA accelerators and save significant development time by using Altera-developed reference platforms. The reference platforms include an SoC platform for embedded applications, a high-performance computing (HPC) platform and a low-latency network enabled platform which utilizes IO Channels.

One notable enhancement is production support for I/O Channels that allow streaming data into and out of the FPGA as well as kernel channels allowing the result reuse from one kernel to another in a hardware pipeline for significantly higher performance and throughput with little to no host and memory interaction. Another enhancement is production support for single-chip SoC solutions (Cyclone V SoC and Arria V SoC), where the host is an embedded ARM core processor integrated in the FPGA accelerator.

Altera’s SDK for OpenCL allows programmers to take OpenCL code and rapidly exploit the massively parallel architecture of an FPGA. Programmers targeting FPGAs achieve higher performance at significantly lower power compared to alternative hardware architectures, such as GPUs and CPUs. On average, FPGAs deliver higher performance at one-fifth the power of a GPU. Altera’s OpenCL solutions are supported by third-party boards through the Altera Preferred Board Partner Program for OpenCL. Visit www.altera.com/opencl.

The Altera SDK for OpenCL is currently available for download on Altera’s website (www.altera.com/products/software/opencl/opencl-index.html). The annual software subscription for the SDK for OpenCL is $995 for a node-locked PC license. For additional information about the Altera Preferred Board Partner Program for OpenCL and its partner members, or to see a list of all supported boards and links to purchase, visit the OpenCL section on Altera’s website.

[Source: Altera Corp.]

Robotics, Hardware Interfacing, and Vintage Electronics

Gerry O’Brien, a Toronto-based robotics and electronics technician at R.O.V. Robotics, enjoys working on a variety of projects in his home lab. His projects are largely driven by his passion for electronics hardware interfacing.

Gerry’s background includes working at companies such as Allen-Vanguard Corp., which builds remotely operated vehicle (ROV) robots and unmanned ground vehicles (UGVs) for military and police bomb disposal units worldwide. “I was responsible for the production, repair, programming and calibration of the robot control consoles, VCU (vehicle control unit) and the wireless communication systems,” he says.

Gerry recently sent Circuit Cellar photos of his home-based electronics and robotics lab. (More images are available on his website.) This is how he describes the lab’s layout and equipment:

In my lab I have various designated areas with lab benches that I acquired from the closing of a local Nortel  R&D office over 10 years ago.

All of my electronics benches have ESD mats and ground wrist straps.  All of my testing gear, I have purchased on eBay over the years….

PCB flip rack

PCB flip-rack

To start, I have my “Electronics Interfacing Bench” with a PCB flip-rack , which allows me to Interface PCBs while they are powered (in-system testing). I am able to interface my Tektronix TLA715 logic analyzer and other various testing equipment to the boards under test. My logic analyzer currently has two  logic I/O modules that have 136 channels each. So combined, I have 272 channels for logic analysis. I also have a four-channel digital oscilloscope module to use with this machine. I can now expand this even further by interfacing my newly acquired expansion box, which allows me to interface many more modules to the logic analyzer mainframe.

Gerry's lab bench

Gerry’s lab bench

Gerry recently upgraded his  Tektronix logic analyzer with an expansion box.

Gerry recently upgraded his Tektronix logic analyzer with an expansion box.

Interface probes

Logic analyzer interface probes

I also have a soldering bench where I have all of my soldering gear, including a hot-air rework station and 90x dissecting microscope with a video interface.

Dissecting microscope with video interface

Dissecting microscope with video interface

My devoted robotics bench has several robotic arm units, Scorbot and CRS robots with their devoted controllers and pneumatic Interface control boards.

Robotics bench

Robotics bench and CRS robot

On my testing bench, I currently have an Agilent/HP 54610B 500-MHz oscilloscope with the GPIB to RS-232 adapter for image capturing. I also have an Advantest model R3131A 9 kHz to 3-GHz bandwidth spectrum analyzer, a Tektronix model AFG3021 function generator, HP/Agilent 34401A multimeter and an HP 4CH programmable power supply. For the HP power supply, I built a display panel with four separate voltage output LCD displays, so that I can monitor the voltages of all four outputs simultaneously. The stock monochrome LCD display on the HP unit itself is very small and dim and only shows one output at a time.

Anyhow, my current testing bench setup will allow me to perform various signal mapping and testing on chips with a large pin count, such as the older Altera MAX9000 208-pin CPLDs and many others that I enjoy working with.

The testing bench

The testing bench

And last but not least… I have my programming and interfacing bench devoted to VHDL programming, PCB Design, FPGA hardware programming (JTAG), memory programming (EEPROM  and flash memory), web design, and video editing.

Interfacing bench and "octo-display"

Interfacing bench and “octo-display”

I built a PC computer and by using  a separate graphics display cards, one being an older Matrols four-port SVGA display card; I was able to build a “octo-display” setup. It seamlessly shares eight monitors providing a total screen resolution size of 6,545 x 1,980 pixels.

If you care to see how my monitor mounting assembly was built, I have posted pictures of its construction here.

A passion for electronics interfacing drives Gerry’s work:

I love projects that involve hardware Interfacing.  My area of focus is on electronics hardware compared to software programming. Which is one of the reasons I have focused on VHDL programming (hardware description language) for FPGAs and CPLDs.

I leave the computer software programming of GUIs to others. I will usually team up with other hobbyists that have more of a Knack for the Software programming side of things.  They usually prefer to leave the electronics design and hardware production to someone else anyhow, so it is a mutual arrangement.

I love to design and build projects involving vintage Altera CPLDs and FPGAs such as the Altera MAX7000 and MAX9000 series of Altera components. Over the years, I have a managed to collect a large arsenal of vintage Altera programming hardware from the late ’80s and early ’90s.  Mainly for the Altera master programming unit (MPU) released by Altera in the early ’90s. I have been building up an arsenal of the programming adapters for this system. Certain models are very hard to find. Due to the rarity of this Altera programming system, I am currently working on designing my own custom adapter interface that will essentially allow me to connect any compatible Altera component to the system… without the need of the unique adapter. A custom made adapter essentially.  Not too complicated at all really, it’s just a lot of fun to build and then have the glory of trying out other components.

I love to design, build, and program FPGA projects using the VHDL hardware description language and also interface to external memory and sensors. I have a devoted website and YouTube channel where I post various hardware repair videos or instructional videos for many of my electronics projects. Each project has a devoted webpage where I post the instructional videos along with written procedures and other information relating to the project. Videos from “Robotic Arm Repair” to a “DIY SEGA Game Gear Flash Cartridge” project. I even have VHDL software tutorials.

The last project I shared on my website was a project to help students dive into a VHDL based VGA Pong game using the Altera DE1 development board.

 

FPGA Partial Reconfiguration

Many field-programmable gate array (FPGA) design modules have parameters, such as particular clock and I/O drive settings, that can only be adjusted during implementation, not at runtime. However, being able to make such adjustments in an FPGA design during operation is convenient.

In Circuit Cellar’s June issue, columnist Colin O’Flynn addresses how to use partial reconfiguration (PR) to sidestep such restrictions. Using difference-based PR, you can adjust digital clock module (DCM) attributes, I/O drive strength, and even look-up-table (LUT) equations, he says. O’Flynn’s article describes how he used PR on a Xilinx Spartan-6 FPGA to solve a specific problem. The article excerpt below elaborates:

Perfect Timing
The digital clock module (DCM) in a Xilinx Spartan-6 FPGA has a variety of features, including the ability to add an adjustable phase shift onto an input clock.

There are two types of phase shifts: fixed and variable. A fixed shift can vary from approximately –360° to 360° in 1.4° steps. A variable shift enables shifting over a smaller range, which is approximately ±5 nS in 30-ps steps.

Note the actual range and step size varies considerably for different operating conditions. Hence the problem: the provided variable phase shift interface is only useful for small phase shifts; any major phase shift must be fixed at design time.

To demonstrate how PR can be used to fix the problem, I’ll generate a design that implements a DCM block and use PR to dynamically reconfigure the DCM.

Figure 1—The system’s general block diagram is shown. A digital clock module (DCM) block synthesizes a new clock from the system oscillator and then outputs the clock to an I/O pin. The internal configuration access port (ICAP) interface is used to load configuration data. The serial interface connects the ICAP interface to a computer via a first in, first out (FIFO) buffer.

Figure 1—The system’s general block diagram is shown. A digital clock module (DCM) block synthesizes a new clock from the system oscillator and then outputs the clock to an I/O pin. The internal configuration access port (ICAP) interface is used to load configuration data. The serial interface connects the ICAP interface to a computer via a first in, first out (FIFO) buffer.

Streaming Bits
I used Xilinx’s ISE design suite to generate a design (see Figure 1). I did the usual step of creating the entire FPGA bitstream, which could then be programmed into the FPGA. The FPGA bitstream is essentially a completely binary blob tells you nothing about your design. The “FPGA native circuit description (NCD)” file is one step above the FPGA bitstream. The NCD file contains a complete description of the design mapped to the blocks available in your specific chip with all the routing of signals between those blocks and useful net names.

The NCD file contains enough information for you to do some edits to the FPGA design. Then you can use the NCD file to generate a new binary blob (bitstream) for programming. A critical part of PR is understanding that when you download this new blob, you can only download the difference between the original file and the new file. This is known as “difference-based PR,” and it is the only type of PR I’ll be discussing.

So what’s in the bitstream? The bitstream actually contains several different commands sent to the FPGA device, which instructs the FPGA to load configuration information, tells it the address information where the data is going to be loaded, and finally sends the actual data to load. Given a bitstream file, you can actually parse this information out. I’ve posted a Python script on ProgrammableLogicInPractice.com that does this for the Spartan-6 device.

A frame is the smallest portion of an FPGA that can be configured. The frame’s size varies per device. (For the Spartan-6 I used in this article, it is 65 × 16-bit words, or 1,040 bits per frame.) You must reload the entire frame if anything inside it changes, which brings me to the first “gotcha.” When using PR, everything inside that “frame” will be reloaded (i.e., parts of your design that haven’t changed may become temporarily invalid because they share a configuration frame with the part of your design that has changed).

O’Flynn’s full article goes on to explain more about framing, troubleshooting challenges along the way, and completing the reconfiguration. The article is available in the June issue, now available for membership download or single-issue purchase.

To further assist readers, O’Flynn has posted more information on the website that complements his monthly Circuit Cellar column, including a video of his project running.

“You can also see an example of how I integrated PR into my open-source ChipWhisperer project, which uses PR to dynamically program a phase shift into the DCMs inside the FPGA,” he says.

Experimentation and Engineering

Frederic Vecoven is software engineer living in Luxembourg who enjoys experimenting with everything from his home’s central heating controller to FPGAs. He has been designing micrcontroller-based projects for more than a dozen years and is currently working on an EPROM emulator.—Nan Price, Associate Editor

 

NAN: What is your current occupation?

FREDERIC:: I am a software principal engineer at Oracle.

NAN: Your website Vecoven.com features projects involving capacitors, microcontrollers, and EEPROM and hardware emulators. Tell us a little about the projects and your design process.

vecovenFREDERIC: At work I design firmware for high-end servers. At home I like to design my own stuff, so I have full control and can create new devices and/or enhance existing ones. I work on various projects and I don’t find enough time to document all of them on the website. For example, I designed a controller for the central heating in my house, but never documented it (it’s too “custom”). I love retrocomputing, which is how my FreHD project started. This is a hard-drive emulator for TRS-80 computers.

My design process starts from an idea (I have too many, so I must carefully select one) then a lot of thinking about the future implementation (as always, designing something is about compromises). Once I have a clear view in my mind about how things should work, I start prototyping. If possible, I use a breadboard or I create a PCB. Sometimes I do a lot of simulation before starting the prototyping, as this will save a lot of time. However, that cannot be done for all projects.

NAN: How long have you been designing microcontroller-based systems?

FREDERIC: More than 15 years.

NAN: How did you become interested in technology?

FREDERIC: When I was 13 years old I fell in love with computers when I saw a TRS-80 model in high school. I am thankful to my parents, who gave me a computer one year later.
I went to college and got a master’s degree in computer science. But I wasn’t satisfied, so I studied some more years to get another master’s degree, this time in electrical engineering. The combination of software and hardware is really powerful. A few years later, I relocated to the San Francisco Bay Area, but I am back in Europe now.

NAN: Describe the first embedded system you designed. Where were you at the time? What did you learn from the experience?

FREDERIC: My first big experience with a real embedded system was when I was working for Sun Microsystems. My group was writing the firmware for the system controllers of the SunFire 3800-6900 line. The embedded system was a small SPARC CPU running Wind River Systems’s VxWorks and the firmware was almost entirely written in Java.

NAN: What was the last electronics design-related product you purchased and how did you use it?

FREDERIC: I bought some FPGAs recently. I haven’t released any project with it yet, it is still a work in progress. My hobby time is very limited.

My idea is to use a CPU core and enhance it with new instructions to enable the generation of real-time signals. FPGAs are very powerful in that area, where a microcontroller would spend most of its time processing interrupts.

NAN: Are you currently working on or planning any projects?

Vecoven_PWM

This is Frederic’s PWM prototype for his Roland Super JX synthesizer.

FREDERIC: Yes, I have rewritten the Roland JX-10/MKS-70 firmware from scratch because I wanted to add PWM waveforms. This quickly turned into a big project. Currently, the prototype setup involves a simulator running the “assigner” code on my laptop. The laptop sends the sound board commands in System Exclusive (SysEx) Musical Instrument Digital Interface (MIDI) messages, which go to a microcontroller that extracts the payload from the SysEx. The payload is then sent to the sound board, which believes it got its instructions directly from the assigner. The sound board (which runs its own microcontroller) uses an EPROM emulator connected over USB, so I can easily modify the assigner code (running in the simulator) or the sound board code (running in the EPROM emulator) without having to program any chip. Note that I didn’t have an EPROM emulator, so I designed mine.

Vecoven_scope

This oscilloscope capture shows the generated PWM signal.

FREDERIC: The power of CPUs and GPUs are really exciting. You can pretty much do everything with software now (a 32-bit core costs less than $5).
On the other side, people don’t pay enough attention to optimization, so I am sad anytime I see poorly written code. I am also excited with all the tools and hardware available today for so little cost. That wasn’t the case in the past, so it opens door to students and hobbyists.

NAN: Last question. Let’s say you had a full year and a nice budget to work on any embedded design project you wanted. Call it your “dream project.” What would it be?

FREDERIC: I would love to do some robotic design, but I am not an expert in mechanics and I don’t have the tools (e.g., lathe, milling machine, etc.). That would fill the gap: hardware, software, and mechanics.

June Issue: Vehicle Tracking, Bit Banging, and More

Circuit Cellar’s June issue is now online, outlining DIY projects ranging from an automated real-time vehicle locator to a  GPS-oriented solar tracker and offering solid advice on bit banging, FPGA reconfiguration, customizing the Linux kernel, and more.

June issueA persistent problem typically sparks the invention of projects featured in our magazine. For example, when the campus at Penn State Erie, The Behrend College, had a growth spurt, the local transit authority provided a shuttle bus to help students who were rushing from class to class. But ridership was low because of the bus’ unpredictable schedule.

So a college engineering team constructed a mobile application to track the bus. That system inspired the cover of our June issue and complements its communications theme.

The three-part system consists of a user’s smartphone running a HTML5-compatible browser, a base station consisting of an XTend 900-MHz radio connected to a Raspberry Pi single-board computer, and a mobile tracker including a GPS receiver, a Microchip Technology PIC18F26K22 microcontroller, and an XTend module.

The Raspberry Pi runs a web server to handle requests from a user’s smartphone. The user then receives accurate bus arrival times.

Also aligning with June’s theme, we present an article about implementing serial data transmission through bit banging. You’ll gain a better understanding of how serial data is transmitted and received by a microprocessor’s hardware UART peripheral. You’ll also learn how bit banging can achieve serial communication in software, which is essential when your embedded system’s microprocessor lacks a built-in UART.

Recognizing a rapidly unfolding communications trend, this issue includes an inventor’s essay about how the presence of Bluetooth Low Energy (BLE) in the latest mobile devices is sparking a big boom in innovative hardware/sensor add-ons that use your smartphone or tablet as an interface. Other communications-related articles include Part 2 of a close look at radio-frequency identification (RFID). This month’s installment describes the front-end analog circuitry for the RFID base station of a secure door-entry project.

In addition, we offer articles about adjusting your FPGA design while it’s operating, modifying the Linux kernel to suit your hardware and software designs, tools and techniques to boost your power supply, digital data encoding in wireless systems, GPS orientation of a solar panel, and an interview with Quinn Dunki, an embedded applications consultant and hacker.

The June issue is available for membership download or single-issue purchase.

A Serene Workspace for Board Evaluation and Writing

 Elecronics engineer, entrepreneur, and author Jack Ganssle recently sent us information about his Finksburg, MD, workspace:

I’m in a very rural area and I value the quietness and the view out of the window over my desk. However, there are more farmers than engineers here so there’s not much of a high-tech community! I work out of the house and share an office with my wife, who handles all of my travel and administrative matters. My corner is both lab space and desk. Some of the equipment changes fairly rapidly as vendors send in gear for reviews and evaluation.

ganssle-workspace

Ganssle’s desk is home to ever-changing equipment. His Agilent Technologies MSO-X-3054A mixed-signal oscilloscope is a mainstay.

The centerpiece, though, is my Agilent Technologies MSO-X-3054A mixed-signal oscilloscope. It’s 500 MHz, 4 GSps, and includes four analog channels and 16 digital channels, as well as a waveform generator and protocol analyzer. I capture a lot of oscilloscope traces for articles and talks, and the USB interface sure makes that easy. That’s pretty common on oscilloscopes, now, but being an old-timer I remember struggling with a Polaroid scope camera.

The oscilloscope’s waveform generator has somewhat slow (20-ns) rise time when making pulses, so the little circuit attached to it sharpens this to 700 ps, which is much more useful for my work. The photo shows a Siglent SDS1102CML oscilloscope on the bench that I’m currently evaluating. It’s amazing how much capability gets packed into these inexpensive instruments.

The place is actually packed with oscilloscopes and logic analyzers, but most are tucked away. I don’t know how many of those little USB oscilloscope/logic analyzers vendors have sent for reviews. I’m partial to bench instruments, but do like the fact that the USB instruments are typically quite cheap. Most have so-so analog performance but the digital sampling is generally great.

Only barely visible in the picture, under the bench there’s an oscilloscope from 1946 with a 2” CRT I got on eBay just for fun. It’s a piece of garbage with a very nonlinear timebase, but a lot of fun. The beam is aimed by moving a magnet around! Including the CRT there are only four tubes. Can you imagine making anything with just four transistors today?

The big signal generator is a Hewlett-Packward 8640B, one of the finest ever made with astonishing spectral purity and a 0.5-dB amplitude flatness across 0.5 MHz to 1 GHz. A couple of digital multimeters and a pair of power supplies are visible as well. The KORAD supply has a USB connection and a serviceable, if klunky, PC application that drives it. Sometimes an experiment needs a slowly changing voltage, which the KORAD manages pretty well.

They’re mostly packed away, but I have a ton of evaluation kits and development boards. A Xilinx MicroZed is shown on the bench. It’s is a very cool board that has a pair of Cortex-A9s plus FPGA fabric in a single chip.

I use IDEs and debuggers from, well, everyone: Microchip Technology, IAR Systems, Keil, Segger, you name it. These run on a variety of processors but, along with so many others, more and more I’m using Cortex-M series parts.

My usual lab work is either evaluating boards, products and instruments, or running experiments that turn into articles. It pains me to see so much engineering is done via superstition today. For example, people pick switch contact debounce times based on hearsay or smoke signals or something. Engineers need data, so I tested about 50 pairs of switches to determine what real bounce characteristics are. The results are on my website. Ditto for watchdog timers and other important issues embedded people deal with.

Ganssle notes that his other “bench” is his woodworking shop. To learn more about Ganssle, read our 2013 interview.

Real-Time Processing for PCIe Digitizers

Agilent U5303A PCIe 12bit High-Speed DigitizerThe U5303A digitizer and the U5340A FPGA development kit are recent enhancements to Agilent Technologies’s PCI Express (PCIe) high-speed digitizers. The U5303A and the U5340A FPGA add next-generation real-time peak detection functionalities to the PCIe devices.

The U5303A is a 12-bit PCIe digitizer with programmable on-board processing. It offers high performance in a small footprint, making it an ideal platform for many commercial, industrial, and aerospace and defense embedded systems. A data processing unit (DPU) based on the Xilinx Virtex-6 FPGA is at the heart of the U5303A. The DPU controls the module functionality, data flow, and real-time signal processing. This feature enables data reduction and storage to be carried out at the digitizer level, minimizing transfer volumes and accelerating analysis.

The U5340A FPGA development kit is designed to help companies and researchers protect their IP signal-processing algorithms. The FPGA kit enables integration of an advanced real-time signal processing algorithm within Agilent Technologies’s high-speed digitizers. The U5340A features high-speed medical imaging, analytical time-of-flight, lidar ranging, non-destructive testing, and a direct interface to digitizer hardware elements (e.g., the ADC, clock manager, and memory blocks). The FPGA kit includes a library of building blocks, from basic gates to dual-port RAM; a set of IP cores; and ready-to-use scripts that handle all aspects of the build flow.

Contact Agilent Technologies for pricing.

Agilent Technologies, Inc.
www.agilent.com

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.

CC281: Overcome Fear of Ethernet on an FPGA

As its name suggests, the appeal of an FPGA is that it is fully programmable. Instead of writing software, you design hardware blocks to quickly do what’s required of a digital design. This also enables you to reprogram an FPGA product in the field to fix problems “on the fly.”

But what if “you” are an individual electronics DIYer rather than an industrial designer? DIYers can find FPGAs daunting.

Issue281The December issue of Circuit Cellar issue should offer reassurance, at least on the topic of “UDP Streaming on an FPGA.” That’s the focus of Steffen Mauch’s article for our Programmable Logic issue (p. 20).

Ethernet on an FPGA has several applications. For example, it can be used to stream measured signals to a computer for analysis or to connect a camera (via Camera Link) to an FPGA to transmit images to a computer.

Nonetheless, Mauch says, “most novices who start to develop FPGA solutions are afraid to use Ethernet or DDR-SDRAM on their boards because they fear the resulting complexity.” Also, DIYers don’t have the necessary IP core licenses, which are costly and often carry restrictions.

Mauch’s UDP monitor project avoids such costs and restrictions by using a free implementation of an Ethernet-streaming device based on a Xilinx Spartan-6 LX FPGA. His article explains how to use OpenCores’s open-source tri-mode MAC implementation and stream UDP packets with VHDL over Ethernet.

Mauch is not the only writer offering insights into FPGAs. For more advanced FPGA enthusiasts, columnist Colin O’Flynn discusses hardware co-simulation (HCS), which enables the software simulation of a design to be offloaded to an FPGA. This approach significantly shortens the time needed for adequate simulation of a new product and ensures that a design is actually working in hardware (p. 52).

This Circuit Cellar issue offers a number of interesting topics in addition to programmable logic. For example, you’ll find a comprehensive overview of the latest in memory technologies, advice on choosing a flash file system for your embedded Linux system, a comparison of amplifier classes, and much more.

Mary Wilson
editor@circuitcellar.com