Case study: Challenges in incarnating a credit card sized SBC

2The initial goal in creating the Raspberry Pi credit card sized, Linux-based Single Board Computer (SBC) – targeted primarily at education – was to develop a response to the decline of students engaging with computer science and related engineering disciplines. Our desire was to reverse the trend of children becoming consumers rather than creators. The following case study follows the hardware development process from an early failure, initial prototypes, and through to the finished production design.

Over recent years there has been an increasing trend for children to be consumers of digital content rather than be future creators or engineers. This trend is driven by manufacturers looking to provide a seamless experience for target customers on a variety of electronic platforms, from gaming consoles to tablets and laptop computers.

As a result, access to raw I/O has become restricted. Similarly, any packaged provision of a programming environment is an anathema to the products’ commercial goals. The knowledge required to create “hello world” or flash an external LED has become simply too vast and the opportunity to learn vital skills such as structuring/codifying ideas and debugging has been largely subsumed by a click-and-shoot world. Any motivation to get under the hood and see how these products work is largely dissipated by the impenetrable barriers presented by these “locked down” systems.

The challenge in developing the Raspberry Pi credit card sized, Linux-based SBC was to break down these barriers and provide access at a sufficiently low cost so any fear of breaking the hardware was effectively removed. Having the hardware is only half the story; the provision of a rich set of programming environments such as Scratch and Python with libraries to allow control of peripheral hardware provides an engaging toolset for learning through experimentation and play in either the formal classroom or at the many school and independent maker (hackspace) clubs. The following case study shows how Raspberry Pi was developed from the ground up.

Initial designs

The initial concept was a small form factor single board computer with good graphics performance that would boot directly into a Python IDE. There was never any doubt that an SoC solution was required; however, we needed to compromise to align target requirements with the feature set of any chosen SoC. Providing support for peripherals external to the SoC would typically add cost and complexity.

In late 2008 we pursued a design using a BCM2727 multimedia processor. It was apparent that the (23 x 18 array) 0.4 mm ball pitch of the BCM’s BGA package would challenge the fabrication of a low-cost PCB (PWB). Coupled with the cost of space requirements of the supporting silicon we missed our target cost point by approximately 50 percent for the 10,000 unit volumes initially targeted.

In 2010, Broadcom developed the BCM2835 Media Applications Processor SoC with a substantial GPU capability and relatively modest, in terms of performance, ARM1176JZ-F application processor. Notably, several members of the design team were active supporters of the Raspberry Pi foundation and had intimate knowledge of the BCM2835 SoC, significantly reducing the implementation risk involved with using the part, even when compared with one in commercial distribution. From a software viewpoint, our initial target had been a single language implementation of Python. Linux was now a realistic possibility providing access to wide range of preexisting languages and tools, which would have huge benefits in broadening the scope of applications for the SBC.

Development started in earnest in summer 2011. A team at Broadcom led by Gert van Loo produced an Alpha evaluation platform specifically targeted for the Raspberry Pi project with all the features that the final design might require. This was used to implement Linux while in parallel the foundation team started work on an optimized (pared back) design that became the final hardware launched in January 2012.


A key design goal throughout development of the Raspberry Pi was project transportability. Other systems such as PCs have the OS and core programming environment on a local hard disk. Often subtle setup and configuration changes on one system will frustrate the running of an application developed on another. In the Raspberry Pi SBC (Figure 1), all application, OS, and boot information is carried on the SD card. The absence of any user or OS NV storage onboard ensures a clean working environment. The Raspberry Pi can be completely repurposed, with a different OS or application just by the use of a different SD card. SD cards can be sized (4-64 GB) to suit the application and additional storage can be achieved through a USB stick or USB HDD. This flexibility provides a minimal entry cost with a massive range of memory expansion options.

Figure 1: In the Raspberry Pi SBC, all application, OS, and boot information is carried on the SD card.
(Click graphic to zoom by 1.9x)

The SoC utilizes a Package on Package (PoP) design for primary RAM. The dynamics of the memory market enabled an upgrade from 256 MB to 512 MB only five months following the launch. An important technical benefit of the PoP is the removal of the SDRAM connectivity from the SoC/PCB interface, reducing ball count, overall footprint, and routing and timing complexity for only a small increase in assembly complexity.

Physically the processor has a 0.65 mm pitch almost full 18 x 18 array (299 balls) in a 12 mm square package; the SDRAM interface is two peripheral rows 23 x 23 (168 pads) at 0.5 mm pitch.


One design dilemma was VGA. We had integrated HDMI and composite video for default legacy support, but the lack of VGA was troubling as many surplus school and college monitors were typically VGA. In the home, however, the situation is reversed and HDMI is more common. The availability of external third-party HDMI-to-VGA converters would have to meet this need.

Thus, we implemented a Dual Videocore IV GPU, with full 1080p30 Full HD H.264 video encode/decode capabilities to allow for the creation of a low-cost media center – a cornerstone application for the board as it provides an important route for interactive teaching material deployment.


Internet connectivity is a critical feature that the SoC did not provide directly. This was resolved with the addition of an integrated USB 2.0-based triple hub and 10/100 Ethernet end point. The single SoC USB host supports Ethernet traffic and basic USB peripherals. Wi-Fi would have been more desirable but we would need 10/100 as a backstop. As USB Wi-Fi modules are freely available, the decision was 10/100.


The strategy we adopted in all elements of the design was to provide as many opportunities for incremental expansion as possible. The idea was this expandability would track the increasing knowledge and enthusiasm of the user and provide avenues for further experimentation. One important area was the interfacing of peripheral electronics. The GPIO port was therefore designed to support key low-level peripheral interfaces including I2C, SPI, RS-232, and PWMs. The provision of these interfaces has yielded a wide variety of third-party modules for digital, ADC/DAC, motor control, RTC, PoE, and prototyping boards to encourage users to create their own circuits.

The USB ports provide further, more standardized expansion, especially if connected to a powered hub. Originally these were intended for simple HID peripherals and limited to 100mA. Later production builds recognized users’ expanded utilization of these ports and this restriction was removed.

A camera had always been on the road map as the processing of image data would open up a wide variety of learning and experimental opportunities. Thus, the Camera Serial Interface on the SoC provides video capture without overloading either the CPU or the USB as is the case with USB-based Webcams. With data rates of 1 Gbps per lane (2 lanes), it comfortably supports a 5 M Pixel sensor (2592 x 1944) at 15fps. Raw camera data is processed in the GPU to render an RGB image, and the GPU can also be used to provide compression for single frames or streamed video. Also included is a dual-lane DSI that will ultimately provide a low-cost interface to a flat panel display as an alternative to the HDMI or composite video.

Power tree

The initial alpha design and the early beta design utilized a 6-12 V input and a dual SMPS to generate +5 V and +3.3 V. The threatened European Directive for common (R&TTE) chargers created almost universal adoption of the micro USB. Evaluation of implementation costs led us to design revisions to utilize this standard. This removed one SMPS and the use of a linear for the +3.3 V removed the second, giving a fourfold cost point improvement for this element of the design, at the expense of 700 mW additional dissipation onboard.

The result: With a full operational load exercising the GPU, ARM, Ethernet, and USBs, the power requirement of the board is 3.2 W. Approximately 1,100 mW is utilized by the SoC and memory and 760 mW by the LAN/USB hub with 850 mW being dissipated in the power tree itself. Certainly not ideal but necessary.

Form factor and PCB technology

Achieving a small form factor was an important design goal, as it reduced PCB cost and allowed multiple boards (6) to be built on the same manufacturing panel, thus saving production handling. With users providing interconnect cables, cost and availability were important, hence full-size HDMI, SD, and USB connectors and 0.1" pitch header for the GPIO were retained in the final design. Ultimately the connectors drove the form factor rather than the silicon.

The alpha board PWB design utilized full HDI technology with buried, blind, and micro via in pad. As part of the production engineering exercise, we were able to reduce this to a conventional six-layer design with one minor HDI concession. We introduced laser-drilled blind vias between the BGA placement layer and the underlying ground plane, providing space for critical decoupling on the rear directly under the processor/memory PoP stack.

We paired down the GPIO and removed unnecessary lanes from the CSI and DSI ports present on the original design to ease the routing from the SoC. The loss of these signals was not going to negatively impact our design goals but it allowed the use of just three of the six layers to carry the BGA escape avoiding compromising ground and power plane integrity.

Looking ahead

Going forward, the design team is evaluating incremental improvements in both the design and manufacturing techniques. These will translate to the addition of more features and extended performance at the same price point. The accessible nature of the Raspberry Pi SBC allows the curious to delve “under the hood” right down to the smallest detail of the systems operation. It encourages learning through exploration and experimentation. Importantly, it is also interesting, engaging, and fun.

Pete Lomas is a cofounder and trustee at the Raspberry Pi foundation, a UK registered charity. He was responsible for the hardware design and development of the Raspberry Pi SBC. He is also Director of Engineering at Norcott Technologies, an electronics design and contract manufacturer based in Warrington (UK). Pete holds a B.Sc. and M.Sc. in Computer Science from the University of Manchester (UK). He can be contacted at

Raspberry Pi

Follow: Twitter Facebook Google+