Virtual Prototyping — The Future’s So Bright

Virtual prototyping has been making its appearance in the embedded software arena since the late 1990s, steadily gaining acceptance as a valuable software development target. It initially rode the wave of rapid advances in chip process technology, which enabled multiple programmable cores on a single chip. This triggered a domino effect in product capabilities, with deep convergence of multiple functions in the same device becoming possible (smartphones being the most idiomatic example). In the semiconductor business landscape, ASIC companies needed to grow into system-on-chip (SoC) companies. The force of growing software content, complexity in general and the specialized nature of the low-level SoC software specifically was amplified by increased time-to-market pressure. Traditional development practices (mostly post-silicon) and targets (physical boards, FPGAs, etc.) couldn’t answer the call for true pre-silicon software development. In its first decade, virtual prototyping has established itself as the key “shift left” enabler in SoC development.Synopsys Diagram2

During the past five years, virtual prototyping has silently enabled embedded software to get past key inflection points and challenges. In the mid-2000s, the introduction of multi-core architectures was a key hurdle for embedded software, requiring considerable refactoring of existing single-threaded/-core software stacks. Virtual prototyping’s debug and visibility advantages facilitated the transition. Around the same time, security hardware was introduced in leading mobile SoCs to provide the basis for a secure computing platform, enabling user services like mobile commerce. The complexity of the new security software and hostility of a physical target for development—a device is supposed to be hacking resistant—made a good case for virtual prototyping, which provided ample visibility into the complex secure/non-secure domain interactions and a less hostile development target.

More recently, we observed adoption to address the SoC power consumption challenge. Power efficiency correlates directly with longer battery times, and dedicated chip hardware, both on- and off-chip, was introduced to manage power. The hardware flexibility offered is large, with final control left to the software. Complex power management software layers were introduced in high-level software stacks, and as virtual prototyping uniquely allows for an accurate representation of the complex hardware clocking and voltage schemes (other technologies like FPGAs can’t easily tackle this), it not only became an enabler for this new development, but also proved its value in software optimization for power and energy.

Today virtual prototyping is powering the architecture transition from 32- to 64-bit in the embedded space, through its use for early instruction-set market introduction, by enabling the porting of large existing stacks prior to the first 64-bit physical implementation and by helping the SoC companies transition their software.

The above inflection points appear in different markets earlier than others, with mobile being on the leading edge of embedded software advances, typically followed by networking and automotive. For instance, automotive is only now facing the multi-core challenge. As such, virtual prototyping repeatedly will play a key role in tackling a specific inflection point.

Looking towards the future, the technology will make further advances on two major fronts: contribution to software quality testing and deeper anchoring into other parts of the SoC design flow, through integration with technologies like hardware emulation and FPGA-based prototyping. With its value for the development phase of software accepted, tackling the next phase, software testing, is natural. The software nature of virtual prototypes allows for large parallel deployment, ideal for regression testing. Moreover, with continuous integration now accepted as a regular practice in desktop and web software development, we expect the embedded market to follow this trend. And with a virtual target making continuous integration straightforward, we expect virtual prototypes to play an important role in the trend’s adoption. Markets including automotive (and mil/aero) have stringent safety and reliability requirements, and virtual prototypes’ unique fault injection capability is starting to show its value. Security testing and analysis is still an unexplored area, which not only has potential for the Internet of Things market, but can have a broad impact as security is becoming commonplace for any connected system.

Having simulation performance track the increasing SoC design scale and keeping the modeling effort under tabs to deliver value sufficiently early are not small engineering challenges. Just-In-Time compilation gave a major boost in the 2003–2004 timeframe, but the number of SoC subsystems requires another turbocharge right now. Exploiting the subsystem-level parallelism through new technologies that map subsystem simulations to different cores in the host machine, and deep-insight performance profiling tools that allow performance tuning, will carry the technology forward for another 5-10 years. Raising the modeling abstraction level, increasing automation and promotion of subsystem-based re-use and assembly methodology are effective arms to tackle the modeling effort challenge.

With its challenges being dealt with, virtual prototypes will continue to drive a further shift left and to converge with the numerous inflection point challenges of embedded software ahead. In 5-10 years, this embedded virtualization technology will likely be as accepted as virtualization technology is in the IT space today. A bright future indeed!

Filip Thoen is the principal engineer for virtual prototyping products at Synopsys, the Silicon to Software partner for innovative companies developing the electronic products and software applications we rely on every day. Thoen is responsible for the technical direction and architecture of the virtual prototyping products. Previously, he co-founded Virtio, a virtual prototyping leader later acquired by Synopsys, and served as its CTO. He has more than 15 years of experience in system simulation and embedded software, and has authored several articles, books, and patents in these areas. He holds MS and PhD degrees in Electrical Engineering from Catholic University of Leuven (Belgium).

This essay appears in Circuit Cellar 299 (June 2015).

SoC FPGA Development Kit for Audio & Processing Applications

Coveloz recently announced the availability of its Pro Audio Ethernet AVB FPGA Development Kit, which is a ready-to-play platform for building scalable, cost-effective networked audio and processing applications built on modular hardware.Covelozpro-audio-dev-kit

Coveloz introduced its Networked Pro Audio SoC FPGA Development Kit during the Integrated System Europe (ISE) show in Amsterdam. According to the company, the new platform will enable manufacturers to achieve faster AVnu certification for new AVB solutions, creating an ideal development environment for live sound, conferencing systems, public address, audio post production, music creation, automotive infotainment and ADAS applications.

At the heart of the Coveloz development platform is a highly integrated System-on-Module (SOM), featuring an Altera Cyclone V SoC FPGA, which includes a dual-core ARM A9 processor, DDR3 memory and a large FPGA fabric, all in a low cost and compact package. The kit includes a multitude of networking and audio interfaces, including three Gigabit Ethernet ports as well as I2S, AES10/MADI, AES3/EBU and TDM audio.

Coveloz provides FPGA and Linux firmware enabling designers to quickly build AVnu Certified products for the broadcast, pro-audio/video and automotive markets. The platform is aimed at time-synchronized networks and includes grandmaster, PPS and word clock inputs and outputs as well as high quality timing references.

The Coveloz development kit is also host to the BACH-SOC platform, which integrates AES67 and Ethernet AVB audio networking and processing. Both SoC and PCIe-based FPGA implementations are available.

The Coveloz Bach Module is a full-featured and programmable audio networking and processing solution for easily integrating industry-standard AES67 and/or Ethernet AVB/TSN networking into audio/video distribution and processing products. The solution enables products with over 128+128 channels of digital streaming and 32-bit audio processing at 48, 96, or 192 kHz.

Supporting a wide range of interfaces, Coveloz complements the development platform with a comprehensive software toolkit and engineering services to help manufacturers reducing time to market. Coveloz also provides application examples to demonstrate the capabilities of the BACH-SOC platform.

The programmable BACH-SOC can be customized to a particular application in many ways—for instance, from selecting the number and type of audio interface to choosing audio processing alone, transport alone, or a combination.

Source: Coveloz

Single-Board, Arduino Uno Shield-Compatible Dev Kit

Nordic Semiconductor’s new Arduino Uno shield-compatible nRF51 DK development kit supports Bluetooth Smart, ANT, and 2.4-GHz designs. Nordic also announced the availability of its nRF51 Dongle, which is a 16 mm × 28 mm USB dongle for the testing, analysis, and development of Bluetooth Smart, ANT, and 2.4-GHz applications.Nordic-nRF51 DK_1

The nRF51 DK is based on Nordic’s nRF51 Series SoC, which combines a 2.4-GHz multiprotocol radio, 32-bit ARM Corte M0 processor, flash memory, and 16- or 32-KB RAM. The SoCs can support a wide range of peripherals and are available in quad flat no-lead (QFN) and wafer level chip scale package (WLCSP) options.

Key points about the nRF51 DK and nRF51 Dongle

  • You can use the nRF51 DK with a variety of third-party Arduino shield expansion boards. It also supports ARM mbed for rapid prototyping projects.
  • The nRF51 DK allows access to all device peripherals, interfaces, and I/Os.
  • The nRF51 DK includes four user-programmable buttons and LEDS plus voltage and current pins to measure device power consumption.
  • nRF51 DK and nRF51 Dongle are supported by standard tool-chain options including Keil, IAR, and Gnu Compiler Collection (GCC).
  • The 63 mm × 101 mm nRF51 DK includes a coin-cell battery holder for field testing
  • You can use nRF51 DKhe DK as a programmer for other target boards that use the nRF51 Series SoC.

The nRF51 DK costs $69. The nRF51 Dongle is $49.

Source: Nordic Semiconductor

2014 SoC Conference Early Bird Registration Now Open

Early Bird Registration is now open for the 12th International System on a Chip (SoC) Conference, which will take place at the University of California, Irvine (UCI) from October 22–23, 2014. Early Bird Registration ends October 10, 2014.

The conference will include technical presentations, exhibits, networking opportunities, panel discussions, and keynotes.

About the conference:

  • Keynotes
    • Dr. Takahiro Hanyu, New Paradigm VLSI System Research Group, Laboratory for Brainware Systems Research Institute of Electrical Communication, Tohoku University, Japan
    • Jim Aralis, Chief Technology Officer (CTO), and Vice President of R&D,  Microsemi
    • Dr. Peter L. Gammel, Chief Technology Officer (CTO), Skyworks Solutions, Inc.
    • Hughes Metras, VP, Strategic Partnerships CEA-LETI, France.
  • Special IC Technology Tutorial
    • “IC Technology at New Nodes Made Easy!,” Dr. Alvin Loke, IEEE Solid-State Circuits Distinguished Lecturer, Qualcomm Technologies, Inc.
  • Sessions
    • “Optical Computing with Silicon Photonics.” Yunshan Jiang, Peter DeVore, Jacky Chan, Bahram Jalali, UCLA
    • “Widely Tunable MMMB Wireless Front-Ends Using RF-CMOS MEMS,” Jeffrey L. Hilbert, CEO & Founder, WiSpry, Inc.
    • “Packaging and Assembly for Internet of Things Electronics: SoC Performance at SiP Cost,” Dr. Jayna Sheats, CEO, Terecircuits
    • “Full SoC Emulation from Device Drivers to Peripheral Interfaces,” Jim Kenney, Marketing Director for Mentor Mentor Graphics’ Emulation Division
    • And more.

Source: 2014 SoC Conference


SmartFusion2 Advanced Dev Kit

Microsemi Corp. has announced a new larges-density, low-power SmartFusion2 150K LE SoC FPGA Advanced Development Kit. It’s meant for board-level designers and system architects who need to rapidly create system-level designs.

Source: Microsemi Corp.

Source: Microsemi Corp.

The kit’s features include:

  • Largest 150K LE development device
  • 2x FMC connectors (HPC and LPC)
  • Purchase of kits comes with a free one-year Libero SoC design software platinum license (valued at $2,500)
  • DDR3, SPI flash
  • 2× Gigabit Ethernet connectors
  • SMA connectors
  • PCIe x4 edge connector
  • Power measurement test points

Source: Microsemi


Windows-Compatible Dev Board

Intel, Microsoft, and Circuit Co. have teamed up to produce a development board designed for the production of software and drivers used on mobile devices such as phones, tablets and similar System on a Chip (SoC) platforms running Windows and Android operating systems with Intel processors.



The 6″ × 4″ Sharks Cove board and features a number of interfaces including GPIO, I2C, I2S, UART, SDIO, mini USB, USB, and MIPI for display and camera.

Its main features include:

  • Intel  ATOM Processor Z3735G , 2M Cache, 4 Core, 1.33 GHz up
    to 1.88 GHz
  • Intel HD Graphics
  • 1 GB 1×32 DDR3L-RS-1333, 16-GB EMMC storage, micro SD Card
  • HDMI full size connector, MIPI display connector
  • Twelve (5 × 2) Shrouded pin header connectors, 1 (2 × 10) sensor header, 2 × 60 pin MIPI connector for display, camera and 5 (2 × 2) headers for power
  • One USB 2.0 type A connector
  • One micro USB type A/B for debug
  • Audio Codec Realtek ALC5640, speaker output header and onboard digital mic
  • Ethernet or WiFi via USB
  • Intel UEFI BIOS
  • Power, volume up, volume down, home screen and rotation lock
  • One micro USB type A/B for Power
  • SPI debug programming header

You can preorder the board for $299. It includes a Windows 8.1 image together with all the necessary utilities for it to run on Sharks Cove.

Kernel RTOS Evaluation Kit

eSOL has started offering the eT-Kernel Evaluation Kit for Xilinx’s Zynq-7000 All Programmable SoC, which combines the dual-core ARM Cortex-A9 MPCore processor with Xilinx’s 28-nm programmable logic fabric. The Evaluation Kit integrates eSOL’s eT-Kernel Multi-Core Edition real time operating system (RTOS), its dedicated eBinder integrated development environment (IDE), middleware components, and device drivers. This complimentary 30-day Evaluation Kit permits developers to easily and quickly evaluate the performance and quality of Xilinx Zynq-7000 All Programmable SoC and eT-Kernel. Since eT-Kernel inherited the functions and architecture of uITRON, the most popular RTOS in Japan and Asian countries, developers can reuse their uITRON-based software assets without further work.

Run-time software in the Evaluation Kit includes the eT-Kernel Multi-core Edition, eSOL’s PrFILE2 FAT file system, the SD memory card driver, and the HDMI display driver, all of which are integrated and immediately run on the Zynq-7000 All Programmable SoC Evaluation Board. The eBinder IDE is available for eT-Kernel Multi-Core Edition-based software development. Besides ARM’s genuine compiler, eBinder offers various development tools and functions to strongly support multi-programming, debugging, and analysis for complex multi-core software development.

Zynq-7000 All Programmable SoC tightly integrates two ARM Cortex-A9 MPCore processors and FPGA fabric. The hardware and software programmability of Zynq-7000 AP SoC enables system development with high performance, flexibility, and scalability, while achieving lower power consumption and cost.

The eT-Kernel/Zynq-7000 All Programmable SoC Evaluation Kit allows developers to jump-start their evaluation using packaged device drivers, which saves the time and money of developing them. Zynq-7000 All Programmable SoC and the eT-Kernel Platform are an ideal combination for advanced embedded systems in the automotive, industrial, and medical arenas, including Automotive Driver Assistance Systems (ADAS), high-resolution graphic systems, machine vision systems, and network systems.

[Source: eSOL Co., Ltd]

8-Bit Microcontroller IP Core

DigitalCoreDesignThe DF6808 IP core is binary-compatible with the industry-standard Motorola 68HC08 8-bit microcontroller. The IP core uses sophisticated on-chip peripheral capabilities to perform 45 to 100 million instructions per second. FAST architecture implemented in DF6808 enables the 68HC08 microcontroller to run at least three times faster than the original solution.

The DF6808’s 16-bit, free-running timer system has two input-capture lines and two output-compare lines. The IP core is equipped with proprietary safety functions, including self-monitoring circuitry, which helps protect against system errors; the computer operating properly (COP) watchdog system, which protects against software failures; and an illegal opcode detection circuit, which provides a non-maskable interrupt if an illegal opcode occurs.

For power conservation, the IP core includes two software-controlled power-saving modes (Wait and Stop). These modes make the DF6808 IP core well suited for automotive and battery-driven applications.

The DF6808 includes the DoCDTM real-time hardware debugger, which provides built-in support for Digital Core Design’s hardware debug system and the debugging capability of an entire system-on-a-chip (SoC). The DoCDTM enables nonintrusive debugging of running applications. It can halt, run, step into, or skip an instruction and read/write any microcontroller contents, including all registers, user-defined peripherals, data, and program memories.

Contact Digital Core Design for pricing.

Digital Core Design

Low-Power Micromodule

The ECM-DX2 is a highly integrated, low-power consumption micromodule. Its fanless operation and extended temperature are supported by the DMP Vortex86DX2 system-on-a-chip (SoC) CPU. The micromodule is targeted for industrial automation, transportation/vehicle construction, and aviation applications.
The ECM-DX2 withstands industrial operation environments for –40-to-75°C temperatures and supports 12-to-26-V voltage input. Multiple OSes, including Windows 2000/XP and Linux, can be used in a variety of embedded designs.

AvalueThe micromodule includes on-board DDR2 memory that supports up to 32-bit, 1-GB, and single-channel 24-bit low-voltage differential signaling (LVDS) as well as video graphics array (VGA) + LVDS or VGA + TTL multi-display configurations. The I/O deployment includes one SATA II interface, four COM ports, two USB 2.0 ports, 8-bit general-purpose input/output (GPIOs), two Ethernet ports, and one PS/2 connector for a keyboard and a mouse. The ECM-DX2 also provides a PC/104 expansion slot and one MiniPCIe card slot.

Contact Avalue Technology for pricing.

Avalue Technology, Inc.

Compact Computer-on-Module

ADLINKThe cExpress-HL computer-on-module (COM) utilizes an Intel Core processor (formerly known as Haswell-ULT) to provide a compact, high-performance COM solution. The cExpress-HL is well suited for embedded systems in medical, digital signage, gaming, video conferencing, and industrial automation that require a high-performance CPU and graphics, but are constrained by size or thermal management requirements.

The cExpress-HL features a mobile 4th Generation Intel Core i7/i5/i3 processor at 1.7 to 3.3 GHz with Intel HD Graphics 5000 (GT3). The COM delivers high graphics performance while still keeping thermal design power (TDP) below 15 W. Intel’s system-on-chip (SoC) solution has a small footprint that enables it to fit onto the 95 mm × 95 mm COM.0 R2.0 Type 6. The COM provides rich I/O and wide-bandwidth data throughput, including three independent displays (two DDI channels and one LVDS), four PCIe x1 or one PCIe x4 (Gen2), four SATA 6 Gb/s, two USB 3.0 ports, and six USB 2.0 ports.

The cExpress-HL is equipped with ADLINK’s Smart Embedded Management Agent (SEMA), which includes a watchdog timer, temperature and other board information monitoring, and fail-safe BIOS support. SEMA enables users to monitor and manage stand-alone, connected, or remote systems through a cloud-based interface.
Contact ADLINK for pricing.

ADLINK Technology, Inc.

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.)

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 Several tutorials for the Zynq device are available at and, so there isn’t any point in duplicating work! I’ve linked to some specific tutorials from the April 2014 post on 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.

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

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.

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

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).

ARM mbed Platform for Bluetooth Smart Applications

OLYMPUS DIGITAL CAMERAThe nRF51822-mKIT simplifies and accelerates the prototyping process for Bluetooth Smart sensors connecting to the Internet of Things (IoT). The platform is designed for fast, easy, and flexible development of Bluetooth Smart applications.

The nRF51822 system-on-chip (SoC) combines a Bluetooth v4.1-compliant 2.4-GHz multiprotocol radio with an ARM Cortex-M0 CPU core on a single chip optimized for ultra-low-power operation. The SoC simplifies and accelerates the prototyping process for Bluetooth Smart sensors connecting to the IoT.

The nRF51822-mKIT’s features include a Bluetooth Smart API, 31 pin-assignable general-purpose input/output (GPIO), a CMSIS-DAP debugger, Programmable Peripheral Interconnect (PPI), and the ability to run from a single 2032 coin-cell battery.

Through mbed, the kit is supported by a cloud-based approach to writing code, adding libraries, and compiling firmware. A lightweight online IDE operates on all popular browsers running on Windows, Mac OSX, iOS, Android, and Linux OSes. Developers can use the kit to access a cloud-based ARM RVDS 4.1 compiler that optimizes code size and performance.

The nRF51822-mKIT costs $59.95.

Nordic Semiconductor ASA

AMD Embedded G-Series SoC Solution

AvalueThe ECM-KA SBC is powered by the AMD Embedded G-Series 1st generation system-on-chip (SoC) accelerated processing unit (APU) based on 28-nm design technology. The AMD processors are built on Jaguar microarchitecture and integrate Quad-core CPU and next-generation graphics core.

The small-footprint ECM-KA provides extremely low power consumption, high graphic performance, multimedia, and I/O. The SBC is designed for embedded applications including industrial controls and automation, gaming, thin clients, retail/digital signage, SMB storage server, surveillance, medical, communication, entertainment, and data acquisition.

The ECM-KA supports one 204-pin DDR3 SODIMM socket that supports up to 8 GB DDR3 1600 SDRAM. It also supports dual-channel 18-/24-bit LVDS as well as HDMI, LVDS, and VGA multi-display configurations. The I/O deployment includes two SATA III, one mini PCIe, one CF, two USB 3.0, six USB 2.0, two COM, 8-bit DIO, and 2-Gb Ethernet. Multiple OS support including Windows 8, Windows 7, and Linux can be used in various embedded designs.

Contact Avalue for pricing.

Avalue Technology, Inc.

A Love of Teaching, a Lifetime of Robotics: An Interview with John Blankenship

John Blankenship

John Blankenship

John Blankenship has spent decades teaching robotics—and written many books on the subject. His love of teaching inspired him to co-develop the RobotBASIC robot programming language. I recently caught up with John to discuss some highlights from his teaching career and what’s next for RobotBASIC—Nan Price, Associate Editor

 NAN: How did you become interested in robotics?

JOHN: As a child, I often saw robots on television but was fully aware that there were no computers capable of making such fictional creations a reality. In the 1970s, microprocessors such as Intel’s 8080 and MOS Technology’s 6502 gave me hope that real robots would eventually become part of our future.

I found I could motivate my students by linking lab projects to robotic topics. For example, instead of just graphing the output from an active filter, I had my students use op-amps to detect an ultrasonic wave so they could later build a ranging sensor. I firmly believe that if you want to motivate students, you must give them projects with a purpose.

 NAN: You spent more than 30 years teaching programming, electronics, and robotics. What did you gain from that experience?

 JOHN: I enjoyed teaching electronics, but I loved teaching programming. Nothing else even comes close to develop critical thinking skills in students. Watching those skills develop was the reason I taught.

After seeing how my hardware robotic projects motivated students, I knew I wanted something similar for my programming classes. Eventually I developed a library of C routines that simulated a simple on-screen robot. What made the simulated robot special is that it supported numerous sensors (an electronic compass, two levels of proximity sensors, a ranging sensor, line detection, beacon detection, color tracking, and more) that enabled students to solve relatively complex, real-world robotics problems without building any hardware.

This structure made programming fun because it gave programming assignments a purpose. Students no longer had to be convinced that it was important to learn the syntax for a loop or how “if” statements controlled flow to make decisions—they wanted to learn details so they could use them to solve the exciting problems being proposed for them. Which would you find more exciting: writing a program to count the number of words in a string or teaching a robot to follow a line? Better yet, imagine motivating students by having a contest to see whose robot could follow a line the fastest.

NAN: How and why did you develop the RobotBASIC programming language?


RobotBASIC can control real robots just as easily as the simulation.

 JOHN: When I retired from teaching I wanted a way for other teachers to utilize a simulated robot to motivate their students. I could have just published my C libraries, but that generally would have limited their use to college classes where C is usually taught. I felt strongly that much younger students needed to be introduced to programming so they could develop not just logical thought, but also an appreciation for math and engineering.

I love the C language (RobotBASIC is written in C), but in my opinion, it is far too cryptic to be used as a first language. I wanted to encase my routines in a BASIC-like language that would enable nearly anyone to program a simulated robot.

I began writing my own language and was reasonably pleased with the initial efforts. I demonstrated the program to a good friend of mine, Samuel Mishal, who is easily the greatest programmer I have ever known. After politely applauding my efforts, he showed me an interpreter he had been working on to help him with a DSP project. His language was very polished and far superior to my work. He integrated my simulator with his interpreter and we named it RobotBASIC.

Even though we planned from start to freely distribute RobotBASIC, we knew teachers could not devote time to learning a language that was just a robot simulator. We began adding new features and capabilities. The more we added, the more excited we became. We started testing the new language by developing robotic behaviors and writing simple video games. Every time we needed something special, we added it to the language.


RobotBASIC has all the commands necessary to write simple video games.

RobotBASIC currently has nearly 900 commands and functions—far more than most languages. More importantly though, since there are built-in functions to handle many things programmers normally have to do themselves, the language is very fast for an interpreter.

We felt RobotBASIC was an ideal language for introducing high school students to programming, but we wanted more. We added hardware I/O capabilities and created a wireless protocol that enabled RobotBASIC to control real robots with the same programs that control the simulation. At that point, the language could easily handle college-level projects but we knew the BASIC stigma would be a problem. To help with this, we added the option to use a modified C-style syntax, making it easier for students to transition to C or even Java.


This simulation shows the effects of friction on a spring’s movement.

We also decided to address some backward capability by adding legacy-style I/O commands, making it easy to teach basic programming skills to even fifth graders. This enables school systems to utilize RobotBASIC from lower grades through high school without having to teach a new environment when new capabilities are needed. And if the C-style syntax is introduced in the upper grades, students will be better prepared for college programming courses.

 NAN: What are some uses for RobotBASIC?

JOHN: Even though students’ needs were a driving force in our development process, RobotBASIC’s I/O capabilities make it a great language for hobbyists involved with robotics or other electronic-oriented projects. For example, it only takes a few lines of code to gather data from a remote temperature sensor using a wireless link and to transmit that information to another user over the Internet.

RobotBASIC also has many commands that facilitate flicker-free animation and simulation. This means teachers have the option of motivating students by teaching how to write simple video games.

As much as I love the robot simulator, I have to admit that many students get even more excited about animation than they do about robots. The point is that RobotBASIC provides many options.


The simulated robot can be programmed to solve a maze.

 NAN: You offer several types of RobotBASIC seminars geared toward children, university students, and robot clubs. You also lead seminars introducing programming and robotics. What do you enjoy most about teaching? What do attendees gain from your seminars?

 JOHN: I love teaching and I especially love showing teachers new ways to motivate their students. I understand that every school and teacher is different and I make sure I satisfy their goals by customizing each and every presentation based on their individual needs. I am always amazed that schools can’t believe that RobotBASIC is totally free. There are no acquisition costs, no upgrade fees, and no licenses—ever! RobotBASIC is free for hobbyists too. Circuit Cellar readers can download a copy from

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


The speed and flight path of these darts is controlled with finger movements on a tablet’s touchscreen.

JOHN: Many RobotBASIC users have been asking for a more advanced book on animation and video games. Unfortunately, my work on our new RobotBASIC Robot Operating System (On a Chip) has been monopolizing all my time for the last couple of years. Now that it is finally finished, I have started writing again.  I think the new book will be worth the wait because it also discusses how RobotBASIC can interact with the new Windows 8 sensors (e.g., cameras, compass, accelerometer, touchscreen, etc.) The chapter I am currently working on enables darts to be thrown using finger movements on a tablet’s touchscreen.

NAN: Do you have any advice for Circuit Cellar readers who are considering building their own autonomous robots?

 JOHN: I think the biggest mistake most robot hobbyists make is they spend far too much time constructing a robot before having a detailed understanding of its sensory needs and the algorithms necessary to accomplish their goals. If they would test their ideas first with our simulator, they would have the information necessary to build a platform that can actually meet their needs. Furthermore, they could control their real robot with the very same programs they developed on the simulator.