Impedance Matching Matters (EE Tip #145)

RF designers, as well as more and more digital-oriented designers, are used to thinking about impedance matching. But it is very easy to forget it when you are designing a non-RF project. A non-matched circuit will generate power losses as well as nasty reflection phenomena. (Refer to my article, “TDR Experiments,” Circuit Cellar 225, 2009.)

Impedance matching must be managed at the schematic stage, for example, by adding provisional matching pads for all integrated antennas, which will enable you to correct a slightly mis-adapted antenna (see Figure 1).

Figure 1: Impedance matching requirements must be anticipated. In particular, any embedded antenna will surely need manual matching for optimal performance. If you forget to include some area for a matching network like this one on your PCB, you won’t achieve the best performance.

Figure 1: Impedance matching requirements must be anticipated. In particular, any embedded antenna will surely need manual matching for optimal performance. If you forget to include some area for a matching network like this one on your PCB, you won’t achieve the best performance.

Impedance matching is also a PCB design issue. As rule of thumb, you can’t avoid impedance-matched tracks when you are working with frequencies higher than the speed of light divided by 10 times the board size. A typical 10-cm board would translate to a cutoff frequency of 300 MHz. A digital designer would then say: “Cool, my clock is only 100 MHz. No problem!” But a 100-MHz square-ware clock or digital signal means harmonic frequencies in the gigahertz range, so it would be wise to show some concern.

The problem could also happen with very slow clocks when you’re using fast devices. Do you want an example? Last year, one of my colleagues developed a complex system with plenty of large and fast FPGAs. These chips were programmed through a common JTAG link and we ended up with nasty problems on the JTAG bus. We still had issues even when we slowed down the JTAG speed to 100 kHz. So, it couldn’t have been an impedance matching problem, right? Wrong. It was. Simply because the JTAG is managed by the FPGA with the same ultra-fast logic cells that manage your fast logic so with stratospheric skew rates which translated into very fast transitions on the JTAG lines. This generated ringing due to improper impedance matching, so there were false transitions on the bus. Such a problem was easy to solve once we pinpointed it, but we lost some days in between.—Robert Lacoste, CC25, 2013


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


Q&A: Electrical Engineer & FPGA Enthusiast

Chris Zeh is a San Jose, CA-based hardware design engineer who enjoys working with FPGA development boards, application-specific integrated circuits, and logic analyzers. He recently told us about the projects he is involved with at STMicroelectronics and explained what he’s working on in his free time.

CIRCUIT CELLAR: Tell us about Why and when did you decide to start a blog?

ZehCHRIS: I started blogging in the winter of 2009, a little more than a year after I graduated Colorado State University with a BSEE. I realized that after graduating it was important to continue working on various projects to keep my mind and skills sharp. I figured the best way to chronicle and show off my projects was to start a blog—my little corner of the Internet.

CIRCUIT CELLAR: What types of projects do you feature on your site?

CHRIS: I like working on a wide range of different types of projects, varying from software development to digital and analog design. I’ve found that most of my projects highlighted on have been ones focusing on FPGAs. I find these little reprogrammable, multipurpose ICs both immensely powerful and fascinating to work with.

My initial plan for the blog was to start a development project to create an FPGA equivalent to the Arduino. I wanted to build a main board with all the basic hardware to run an Altera Cyclone II FPGA and then create add-on PCBs with various sensors and interfaces. My main FPGA board was to be named the Saturn board, and the subsequent add-on “wings” were to be named after the various moons of Saturn.

a—Chris’s Saturn board prototype includes an Altera Cyclone II FPGA and JTAG FPGA programmer, two linear regulators, a 5-V breadboard power supply, and a 24-MHz clock. b—A side view of the board

a—Chris’s Saturn board prototype includes an Altera Cyclone II FPGA and JTAG FPGA programmer, two linear regulators, a 5-V breadboard power supply, and a 24-MHz clock. b—A side view of the board

The project proceeded nicely. I spent some time brushing up on my Photoshop skills to put together a logo and came up with a minimized BOM solution to provide power to the nine different voltage supplies, both linear regulators and switched-mode supplies. One aspect of FPGAs that can make them costly for hobbyist is that the programming JTAG cable was on the order of $300. Fortunately, there are a few more affordable off-brand versions, which I used at first. After many weeks of work, I finally had the total solution for the main FPGA board. The total cost of the prototype system was about $150. Eventually I came up with a way to bit bang the FPGA’s programming bitstream using a simple $15 USB-to-UART IC breakout board driven by a tiny Python application, eliminating the need for the pricey cable. This Future Technology Devices International FT232RL USB-to-UART IC also provided a clock output enabling me to further reduce the component count.

The project was a success in that I was compelled to completely digest the FPGA’s 470-page handbook, giving me a solid grasp of how to work with FPGAs such as the Cyclone II. The project was a failure in that the FPGA breakout board I wanted to use for the project was discontinued by the manufacturer. Creating and fabricating my own four-layer board and hand soldering the 208-pin package was both prohibitively expensive and also a little daunting.

Fortunately, at that time Terasic Technologies introduced its DE0-Nano, a $79 commercial, $59 academic, feature-packed FPGA evaluation board. The board comes with two 40-pin general I/O plus power headers, which has become a perfect alternative base platform for FPGA development. I now intend to develop add-on “wings” to work with this evaluation board.

CIRCUIT CELLAR: Tell us more about how you’ve been using Terasic Technologies’s DE0-Nano development and education board.

CHRIS: The main project I’ve been working on lately with the DE0-Nano is creating and adding support for a full-color 4.3” (480 × 272 pixel) thin- film transistor (TFT) touchscreen LCD. Because of the large pin count available and reconfigurable logic, the DE0-Nano can easily support the display. I used a Waveshare Electronics $20 display, which includes a 40-pin header that is almost but not quite compatible with the DE0-Nano’s 40-pin header. Using a 40-pin IDC gray cable, I was able to do some creative rewiring (cutting and swapping eight or so pins) to enable the two to mate with minimal effort. Eventually, once all the features are tested, I’ll fabricate a PCB in place of the cable.

There are many libraries available to drive the display, but for this project I want to develop the hardware accelerators and video pipeline from the ground up, purely though digital logic in the FPGA. I recently picked up an SD card breakout board and a small camera breakout board. Using these I would like to start playing around with image processing and object recognition algorithms.

CIRCUIT CELLAR: What do you do at STMicroelectronics and what types of projects are you working on?

CHRIS: My official title is Senior Hardware Design Engineer. This title mainly comes thanks to the first project I worked on for the company, which is ongoing—an FPGA-based serial port capture and decoding tool named the HyperSniffer. However, my main role is that of an application engineer.

I spend most of my time testing and debugging our prototype mixed-signal ASICs prior to mass production. These ASICs are built for the hard disk drive industry. They provide several switch-mode power supplies, linear regulators, brushless DC motor controllers, voice coil motor actuation, and a shock sensor digital processing chain, along with the various DACs, ADCs, and monitoring circuits all integrated into a single IC.

Our ASIC’s huge feature set requires me to stay sharp on a wide variety of topics, both analog and digital. A typical day has me down in the lab writing scripts in Python or Visual Studio, creating stimuli, and taking measurements using my 1-GHz, 10-GSPS LeCroy WavePro 7100A oscilloscope, several 6.5-digit multimeters, dynamic signal analyzers, and noise injection power supplies among other instruments. I work closely with our international design team and our customers to help discover and document bugs and streamline the system integration.

A few years back I was able to join my colleagues in writing “Power Electronics Control to Reduce Hard Disk Drive Acoustics Pure Tones,” an Institute of Electrical and Electronics Engineers (IEEE) paper published for the Control and Modeling for Power Electronics (COMPEL) 2010 conference. I presented the paper, poster, and demonstration at the conference discussing a novel technique to reduce acoustic noise generated by a spindle motor.

Chris designed the HyperSniffer logic analyzer, which is shown with the HyperDrive main board. (The PCB was designed by Vincent Himpe and Albino Miglialo.)

Chris designed the HyperSniffer logic analyzer, which is shown with the HyperDrive main board. (The PCB was designed by Vincent
Himpe and Albino Miglialo.)

CIRCUIT CELLAR: Tell us more about the HyperSniffer project.

CHRIS: The HyperSniffer project is an FPGA- based digital design project I first created right out of college. (My colleagues Vincent Himpe and Albino Miglialo did the board design and layout.) The tool is basically an application-specific logic analyzer. It enables us to help our customers troubleshoot problems that arise from serial port transmissions between their system-on-a-chip (SoC) and our ASIC. Through various triggering options it can collect and decode the two or three wire data transmissions, store them on on- board memory, and wait for retrieval and further processing by the application running on the PC. One of this tool’s nice features is that it is capable of synchronizing and communicating with an oscilloscope, enabling us to track down problems that happen in the analog domain that arise due to commands sent digitally.

You can read the entire interview in Circuit Cellar 290 (September 2014).

DE0-Nano Cyclone FPGA Development Board

With a DE0-Nano Cyclone FPGA Development Board, you can create your own sophisticated hardware using programmable logic. The development board includes an Altera Cyclone IV and additional components to connect and test hardware designs. It comes a pre-wired Cyclone IV FPGA for programming and connection to internal or external devices and circuit.

Source: Parallax

Source: Parallax

With the board, you can create sophisticated logic hardware fairly quickly using a hardware description language. Possible applications include dedicated digital logic processors, robotics, and DIY autonomous systems.

Source: Parallax

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


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

The Altera SDK for OpenCL is currently available for download on Altera’s website ( 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 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 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?


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.


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

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