Rapid Development with HW Building Blocks: Raspberry Pi SoM

In recent years there has been a lot of innovation in the System on Module (SoM) market.  The choices are plentiful for processor sub-systems integrated with memory and peripherals and packaged on a small module.   A Google search for “SoM, system on module” returns about 648,000 results!  Scanning through the results reveals a range of options  from 8 bit micro controllers to 32 bit processors capable of running Linux.  In this post I will discuss one of the more innovative developments in the SoM marketplace– the Raspberry Pi.


Raspberry Pi2

Raspberry Pi:  The Darling of the Maker Movement

Somewhere between full Open Source Hardware and traditional Commercial-Off-The-Shelf processing modules sits the Raspberry Pi.  Although some of the design documentation is freely available from the Raspberry Pi foundation Broadcom holds a lot of the key intellectual property because their highly integrated processing chip is the heart of the design.  This credit-card size, low power (~5W), low cost ($35) processing engine has proven to be a real game changer for the Maker community and it is earning serious consideration for several types of embedded systems.

The original Raspberry Pi is based on the Broadcom BCM2835 SoC, which includes a single ARMv6 processing core running at 700 Mhz along with a Graphics Processing Unit (GPU) capable of MPEG-2 and VC-1 encode/decode. The Raspberry Pi B+ announced in February 2015 has a quad core ARMv7 processor, a GPU,  and more RAM.

DRAM on the Pi ranges from 256 Mbytes on original systems up to 1 Gbyte available on the Raspberry Pi2. Note that the GPU shares DRAM memory with the processor.  High definition video decode can eat up significant amounts of shared memory so careful analysis is necessary here.  Nonvolatile memory for boot, OS, and all persistent storage is via Secure Digital (SD) or micro SD sockets depending on model. This makes it easy to upgrade nonvolatile memory capacity but presents problems for security sensitive embedded systems.  SD cards also pose problems for embedded systems that need to survive shock and vibration events.

The PI has a rich mix of peripheral interfaces for many applications: USB, 10/100 Mbps Ethernet, GPIO, I2C, SPI, and an analog audio output. It has a 15 pin CSI connector to allow direct attachment of a camera module and it has both HDMI and composite video outputs.  We have used it for applications as diverse as testing Analog to Digital converters to video monitoring to building cheap storage devices.

Originally intended as a platform for kids to learn about computers the Pi is now receiving interest as an embedded system component.  Responding to this interest, the Raspberry Pi Foundation created a new module in SODIMM format called the Raspberry Pi Compute Module.  The compute module uses the same Broadcom SoC chip as the original Raspberry Pi so it has the single ARMv6 processing core along  with a GPU.


Raspberry Pi Compute Module

Note that the Compute Module does not use a removable SD card, which makes it more suitable for vibration and security sensitive applications.   The Raspberry Pi Compute Module is an interesting option for some embedded systems.  I am not a big fan of SODIMMs though if a system has to survive shock and vibration.

Operating Systems

The Raspberry Pi runs a variety of Linux based operating systems. Arguably the most popular is Raspbian, which is based on a Debian port called Wheezy. There are many others. The Raspberry Pi Community has created an install manager called NOOBS that can load your OS of choice from the SD card on initial boot up.  Note that the original Raspberry Pi cannot run Windows or Ubuntu. The new Raspberry Pi 2 is rumored to be able to run Windows 10 and an Ubuntu distribution called Snappy Core.

The Raspberry Pi has a huge following of devoted users and developers providing support and there are many related products available. You can run a wide variety of open source software on the Pi.  The Pi offers decent performance, multimedia capability, and a mix of useful interfaces at a low price point.   And because of its dedicated community of developers it is very easy to use.  In fact, it is so cheap and easy to use it can be a great tool to speed up embedded system development.  We have several in our lab and keep finding more ways to use them.  That’s a topic for another post I guess!

Rapid Development with HW Building Blocks: Reference Designs

Second in a series…..

In the first post in this series we looked at using System on Chip technology to save time in developing an embedded system.  In this posting we look at the use of hardware reference designs.

Another resource that can save development  time is a reference design that uses components you want to use in your system.  These reference designs are typically provided by a semiconductor vendor but were designed by a third party.   A good reference design will at least include a working board, schematics, and physical design files that allow you to build your own hardware based on a working design.  This can be a real time saver.  Occasionally the source schematics are included and if you use the same schematic capture tool you can save a lot of time that would have been spent creating symbols and drawing schematics.  Most often though the schematics are in PDF format.

Sometimes you can get low level firmware, software drivers, codecs, or even higher level software included in a reference design.  A good reference design board will allow software developers to get going with a lot of their low level software and firmware before actual hardware development.  A working reference design board can also allow experimentation and verification of things like a critical task’s real time performance capability, boot up and reset issues, and power and thermal issues. There are tests you can run in seconds on a lab bench that are not practical in a hardware simulator.

There are important issues to consider when using a reference design.  A thorough design review of the reference design is necessary to avoid problems later on. The  assumptions for acceptable design practice made by the developer of the reference design  may not be the same as yours.  Find out this stuff up front, not via a call from an angry customer.  Also, carefully check any licensing issues or terms and conditions for copying a reference design.  Hardware licenses can be different than software licenses because they are based on  patent law not copyright law.  It’s important to know the difference.   A patent based license can control the use and manufacturing of your device based on their design documentation.   A copyright based license just controls the distribution of the design documents.  Having a lawyer review the license up front is always a good idea.

Rapid Development with HW Building Blocks: System on Chip

First in a series of posts……

When discussing rapid development of complex embedded systems the issue of using third party hardware and software building blocks inevitably comes up.  There are a lot of options and issues when it comes to using embedded system building blocks.  Nobody wants to re-invent the wheel but picking the wrong wheel can overturn your chariot!  In this series of posts we will look at some options and issues for speeding up hardware development using different building blocks.  In a later series we will look at some of the software issues.

Semiconductor vendors offer an amazing range of System-On-Chip (SoC) devices.  Choosing the right SoC can really shorten development time if most of what you need is already in the silicon.  A critical area that is sometimes missed though is an analysis of how your system’s desired performance running your application compares to the SoC’s likely performance running your application in your system.  What parts of an SoC you use and how your traffic flows affects performance.  How your system is physically partitioned and how you interface the SoC to your system can also have dramatic effects on performance.  The thermal environment in your system can impact how much performance you can squeeze out of an SoC.

If you develop an FPGA based SoC for your system you can use some pretty powerful low-cost vendor provided design tools and no charge (nothing is totally free my friend!)  FPGA vendor cores.  These cores can be a big time saver in chip design.   The FPGA vendor has  knowledge of its cores, tools, and silicon so they can help with development problems at a deeper level than a third party core vendor.  Also, your interests and the FPGA vendor’s interests are aligned.  They want you to get to market as fast as possible so they can make money too.  Be aware FPGA vendor core licenses often specify you can only use them in the vendor’s chips.   This can present problems if you want to port your design later.  It’s best to study the license details and be up-front with the FPGA vendor on what you plan to do.

In our next post we will look at the use of hardware reference designs.

Raspberry Pi based NAS

The Wall Street Journal recently ran a story called “Building Your Own Cloud” by Joanna Stern.  It’s a fun, well written piece.  I would link to it but it is behind their pay-wall unfortunately.  It talks about purchasing commercial Network Attached Storage (NAS) servers called Personal Cloud systems and using them on your home network.  The author reviews offerings from Western Digital and Seagate and discusses her experience with these off-the-shelf solutions.  The systems she reviewed run about $300.

Joanna’s story reminded me of a fun project we did one afternoon at Black Brook Design — building our own NAS for the lab.  We had some Raspberry Pi single board computers lying around along with a couple of portable USB hard drives.  The question was how hard would it be to make our own redundant NAS.  After rooting around in the lab for some parts and doing a bit of searching on the Internet it turns out it is fairly simple and cheap to build a redundant NAS device for yourself.  We found some excellent instructions online here:

Raspberry PI NAS Instructions

We found two things we particularly liked about the above instructions. First,  the use of NTFS formatted disks so we can always unplug one of the USB hard drives from the Linux based Raspberry Pi and plug it into a Windows computer.  This was very handy in initially transferring files to our NAS.  Second,  we have to share files between both Linux and Windows machines so Samba was a good choice for our network share software.

We decided to build 1 TB of redundant storage into our NAS.  We used two Seagate Backup Plus Slim 1TB portable hard drives ($64 each), a powered USB hub ($8 – $12),  and a Raspberry Pi ($35) running the Raspbian operating system. We recommend using a powered USB hub to connect the USB hard drives to the Raspberry PI as the drives drew a bit too much current for our Pi to source via its USB ports.   So we built a 1 TB redundant NAS device for about $175 in a couple of hours.  We attached our NAS to our network using a Fast Ethernet connection on a nearby Ethernet switch.

Tradecraft: Source Synchronous Bus Timing Problem

Interfacing to a source synchronous bus with an FPGA can be a bit tricky.  Today’s FPGA tools provide lots of resources to help achieve timing closure inside the chip.  Sometimes though, the FPGA needs a little help external to the chip to meet timing.

I recently ran into a case where an FPGA connected to an Ethernet PHY over a GMII bus.  The GMII bus uses simplex point to point connections for transmit and receive.  The source end of the connection drives the clock.  Both the clock and data for the GMII “Transmit” connection were sourced from the FPGA.  Close inspection of the FPGA timing report revealed that the data could come out 118 picoseconds before the clock came out. It is important that both the setup and hold time requirements of the PHY be met.

It was necessary to ensure the clock arrived at the PHY before the data lines changed (zero hold time) and that the PHY’s setup time requirements were met.   The easiest way to do this was to delay the data lines a small fixed amount by running them as longer nets than the clock line.   This ensures most of the clock period for setup time at the PHY and still maintains a 0 ns hold time.    The exact board propagation delay number is based on the dielectric constant of the circuit board and can be calculated by a circuit board vendor given the details of a board.   My general rule of thumb for delay in a stripline trace is about 165 ps/inch.  Sometimes a little propagation delay is a good thing!

Why It’s Best to Use a Bootloader for Your Product

Xilinx has a technology called SystemAce that allows you to boot Linux directly from a Compact Flash device.  People see this and ask us: “why use a bootloader in my project?”   The short answer is that, while it’s quick and easy to boot directly from CF for development and demo purposes, for production there are other things you should consider.

Key issues for production hardware include:

  1. How will you set permanent information such as per board Ethernet MAC addresses and serial numbers?  This needs to be quick and simple for a manufacturing environment.  Clumsy scripts and hokey workarounds bring no end of headaches here.
  2. How will you store persistent information, such as static IP addresses, that may change occasionally but must be recalled after a power cycle or reset?
  3. How will you upgrade your operating system?  Do you need to do this in the field?
  4. Do you need diagnostics?  How will whoever manufactures your device test it?  Typically, manufacturing diagnostics are required to support debug of faulty units for any processor based system.  Also, some devices need to run a power-on-self-test (POST) before becoming operational for safety or other reasons.
  5. Will you ever need to change system behavior at boot time?  For example, would it be handy to easily switch between an NFS mounted and a RAM based root file system to debug certain problems?

A well developed, flexible bootloader, such as U-boot,  provides ways to bring these important features to a product.