The SpiNNaker project is again in the news at EETimes Europe (see “A million ARM cores to host brain simulator”) and the idea of harnessing one million ARM processor cores is certainly a big idea. It excites me. However, we’re still at the humble beginnings of the project.

The SpiNNaker project’s first test chip harnesses 18 ARM9 cores on one 130nm chip manufactured by UMC in Taiwan. This is a 100M-transistor chip and, like most many-processor SoCs, the SpiNNaker SoC mostly consists of memory. The memory needs to be close to the processors for speed and for low-power consumption and there are 55 32Kbyte SRAM blocks on the SpiNNaker die. That’s 14 million bits of SRAM and, frankly speaking, that’s really not very much SRAM. Eighteen processors isn’t really a large number of processors either when your stated goal is one million.

The ARM processors on the SpiNNaker chip use packet communications to emulate the electrical spike communications that occur among the neurons in human and animal brains. From a hardware perspective, I think it’s easy to conceive of a system-level design like this and even conceptually scaling the design to a million connected ARM9 processors isn’t really hard, as long as you don’t try to enumerate all of the processors in your mind. However, with 18 processors per chip, you’ll need approximately 55,600 chips to build an interconnected network of one million processors. That’s still a mighty big box of hardware. More on that in a bit.

The rub is that we really don’t have many good ideas for programming such a massively parallel system. The SpiNNaker project seems to be mostly a hardware endeavor with the explicitly stated intent of developing a hardware testbed for brain researchers who will use SpiNNaker systems for studying various theories of brain function. Presumably, we’ll learn more about massively parallel programming by working with these systems and no doubt we will. As Furber says in a quote published in the EETimes Europe article, “We don’t know how the brain works as an information-processing system, and we do need to find out. We hope that our machine will enable significant progress towards achieving this understanding.”

Each SpiNNaker chip in the current design is bundled with a 166MHz, 1Gbit DDR SDRAM and packaged in a 300-pin BGA package. But we’re not going to be building million-processor testbeds with 18 processors per packaged chip. I’m almost absolutely, positively certain about that. This first SpiNNaker prototype just doesn’t scale to one million processors very easily. So the question is, how to get there?

Well, possible clues to answer that question can be found in two recent blogs that I wrote on the EDA360 Insider blog. First, Samsung has just announced successful tapeout of a 20nm test chip incorporating an ARM Cortex-M0 processor core. (See “Samsung 20nm test chip includes ARM Cortex-M0 processor core. How many will fit on the head of a pin?”) Now an ARM Cortex-M0 processor is not as powerful as an ARM9 processor, but then it’s not supposed to be. It’s designed for control-oriented applications and its 3-stage execution pipeline isn’t designed to get maximum speed from any given process technology. However, we’re building a system that emulates a brain that operates at a few hundred Hertz (that’s Hertz, not kilohertz, megahertz, or gigahertz) so I really don’t think the clock speed is all that critical when you’re talking about a million processors. The ARM Cortex-M0 processor core is still a 32-bit RISC processor and I am guessing with a high degree of confidence that it’s fully up to the task of executing the required electrical-spike calculations, albeit not quite as quickly as an ARM9 processor.

What’s interesting about a 12-to-14Kgate ARM Cortex-M0 processor implemented in 20nm process technology is that my calculations suggest that more than half a million ARM Cortex-M0 processors would fit on a chip the size of an Intel “Tukwila” Itanium processor (OK, that’s a big chip, but it’s a commercial one) and that calculation is based on the published number for the area required by an ARM Cortex-M0 implemented in 90nm process technology, not 20nm. Now there’s a lot of slop in this calculation. First, there’s the disparity of using 90nm numbers instead of 20nm numbers. Then there’s the disparity caused by putting no memory at all into the calculation. I just mentally tiled processors edge to edge. Ditto, there’s no on-chip interconnect.

So you probably won’t get half a million ARM Cortex-M0 processor cores on one 20nm chip. But you might get 100,000 or 200,000 ARM Cortex-M0 processor cores on a chip along with an interesting amount of memory and the required interconnect. Now we’re talking about only a handful of chips to get to one million processors. We’re talking about a tabletop box. Now we’re getting into the realm of the feasible for million-processor systems.

The second related blog entry I recently wrote in EDA360 Insider that also bears on this very interesting endeavor was about an announcement from Imec, a global research company. Just days ago, Imec announced that it and its partners successfully assembled a custom logic chip with two DRAMs in a stacked 3D configuration. (See “3D Thursday: IMEC prototypes 3D chip stack, finds some thermal surprises”.) This 3D stacked-chip prototype allowed Imec to test out some process ideas for manufacturing 3D stacked chip assemblies and to make some critical thermal tests to verify thermal models that will be so necessary when 3D assembly goes mass market. The 3D chip stack uses copper-tin micro-bumps and compression bonding for the electrical and mechanical assembly of the chip stack and you can see photos of the assembled stack below.

Here’s a photo of the overall chip stack:

And here’s a close-up of the edge of the chip stack to show the three stacked die.

The 3D Stack’s base chip is approximately 750µm thick. The two top components in the chip stack are each 25µm thick. There’s more technical info in the referenced EDA360 Insider blog.

I am convinced that 3D stacking of logic and RAM chips will be absolutely essential to developing massively parallel, low-power systems like the ones envisioned by the SpiNNaker project. First, the only way to feed data and instructions to massively parallel processing chips is through large amounts of on-chip memory and through high-bandwidth, low-energy channels connected to large off-chip memories. 3D assembly techniques permit both Wide I/O and high-speed serial I/O channels to work most effectively and at minimal energy levels and I expect to see rapid adoption of 3D assembly—even and perhaps especially in high-volume, cost-sensitive applications such as mobile phone handsets—in the next few years. This is precisely the sort of manufacturing technology we require to think seriously about million-processor systems.

Now all we need to do is figure out how to program them.

But back to Furber. Today, he’s the ICL Professor of Computer Engineering at the School of Computer Science, Manchester University, UK and his CV sports a long list of impressive achievements. Let’s just say he’s been busy since leaving ARM. These days, he and his group at Manchester University are developing digital ways to emulate organic brain functions. In essence, his group is developing digital analogs of neural networks. Now electronic neural networks aren’t something new. I can remember discussing them when I was a college freshman. That was 1971. Not new. Not recent.

The Manchester University team is developing an SoC with a “massively” parallel network of eighteen ARM 968 RISC processors all mutually interconnected through a Silistix self-clocked network on chip (NoC). Furber had a hand in the early development of this NoC, also at Manchester University. (See, he’s been busy, like I said.) The project is called SpiNNaker. (http://apt.cs.man.ac.uk/projects/SpiNNaker/)

Now there’s a reason for repeatedly emphasizing Furber’s connections to Manchester University and he discussed it in his keynote. Any serious discussion of the history of computing must include the Manchester University Mark I “Baby,” which was the first fully programmable, stored-program digital computer to go online. Baby executed its first program in 1948. ENIAC, developed at the Moore School of Electrical Engineering at the University of Pennsylvania and usually called the first fully electronic computer, was operational two years before the Manchester Baby. But ENIAC was physically programmed with wires—at least initially. Eventually, ENIAC was retrofitted with some programmability but the Manchester Baby was first.

When operational, the Manchester Baby computer executed roughly 800 instructions per second. That was a heck of a lot faster than the mechanical calculators and punched-card equipment of the day but it’s laughably slow when compared to today’s processors. (Even the Intel 4004, the world’s first commercial microprocessor introduced in 1971, executed 108,000 instructions/second.) More to the point for the purposes of this blog, the Manchester Baby consumed approximately 5 Joules of energy to execute each instruction.

Fast forward to today and those ARM 968 microprocessors in the SpiNNaker chip. An ARM 968 processor executes roughly 20 million instructions per second, dissipating 10^-10 Joules per instruction. In other words, the per-instruction energy consumption needed to execute a machine instruction has improved by a factor of about 50 billion in 60 years.

Now the old, worn comparison usually asks you to consider what the world would be like today if automobile manufacturers had improved the energy consumption of their products by a factor of 50 billion in 60 years. That’s not the point here.

Furber’s point is this: if the energy cost per instruction had not improved by such a huge amount since 1948, this world would be a very different place. There would be no cell phones, no iPads, no personal computers, no personal music players, and very few embedded systems of any sort. These would simply be impractical for reasons of all three “P”s: price, performance, and power.

We have relied almost exclusively on Moore’s Law to get to this point.

That ride’s over.

At today’s bleeding-edge IC fabrication process lithographies, 28nm, we’re imaging individual atoms. Layers are a handful of atoms thick. The number of atoms in a transistor is so shockingly few that dopant atoms no longer operate statistically. The resulting on-chip parametric variability is becoming a very real problem that forces physical designers to use bigger and bigger guard bands on design rules. Speed and power gains are slowing from IC generation to generation. We have arrived at the point of rapidly diminishing returns and we’re clearly not getting another factor of 50 billion improvement in the power needed to execute a machine instruction from here on.

Yet the guidepost pointing to lower power operation is frustratingly close and familiar. It sits between your ears. We have chosen to design processors that execute one (or perhaps a few) instructions at one time, but at a very high execution rate. The higher the better. The brain is designed with an entirely different approach. It’s a highly parallel machine where “parallel” means a lot more than 18 processors. The brain contains approximately 10^11 neurons with 10^15 synapses. The neurons are the brain’s processors and the synapse connectivity is the brain’s memory and programming.

Neurons are very simple and very slow processors, but there are a lot of them working in parallel.

The entire brain human operates at roughly 100W—about the power consumption of a PC processor—but the brain runs at 100Hz. Although we can certainly get a lot of processing done with 100W, it’s not a drop in the bucket compared to the brain’s audio and visual processing abilities, let alone its ability for abstract thought. And we can’t get anything done at 100Hz. Our programming models cannot currently accommodate brain-style processing. We do not yet understand parallelism on the brain’s scale.

In addition, our processing systems are remarkably intolerant of failure. Microprocessors represent single-point failure nodes in most embedded designs with a few exceptions such as majority-voting avionics systems where single-point failure usually means death, so we go “massively” parallel with three processors.

The brain however is very tolerant of failure. Our brains lose neurons all the time. In fact, some of us hurry that process a bit by regularly drinking alcohol and killing off a few extra neurons a day. So what? When you’ve got 10^11 neurons, you’re not going to miss a few and of course the brain doesn’t.

The goal of the SpiNNaker project is to create an early parallel platform that will allow brain researchers to study the operation of a machine that can digitally emulate mechanisms that the brain uses to process a wide range of sensory data, to control an incredibly complex system of muscles and organs, to deal with the complex issues of written and spoken language, and to make huge leaps in abstract thought. SpiNNaker will not produce a leap by a factor of 50 billion, but perhaps it will get us going on the right path, now that we’ve managed to come this far.

Three decades ago, computer networking was in chaos. Each of the major mainframe and minicomputer vendors had a unique and mutually incompatible networking scheme. The electronics didn’t match. The bit rates didn’t match. The packetizing and de-packetizing schemes didn’t match. The error-detection and –correction schemes didn’t match. And just as important, the cables and connectors didn’t match. Any data center than supported hardware from multiple computer vendors needed a big box of cables with all sorts of connectors just to handle the incompatible networking schemes.

Chances are good that you have a similar box of cables at home to help you connect all of your multimedia devices together. I know I can connect one of my televisions with an RF coax cable, simple audio and video coax cables terminated with RCA plugs, RCA RGB component cables, or HDMI cables. My audio connections include simple RCA-plug audio cables, coaxial and optical TOSlink cables, and speaker wire without connectors. I do indeed have boxes full of AV cables that no longer match any of the AV components I now use. Worst of all, these are all dumb, dumb, dumb connections. The AV system components have no idea what’s coming over these cables. I need to configure each box (usually through a remote control I can’t find) to tell it which of the many back-panel ports to use for the audio and video signals and how the streamed information is encoded. For example, I need to manually tell my system which of the DVD audio streams to use while watching a video. You would think that reasonably good equipment would be able to detect and optimize the experience automatically, but my equipment can’t.

So it’s not much of a reach to envision a world where Ethernet-enabled AV equipment automagically discovers the abilities of the other equipment in a local AV network cloud and then collaborates with the other connected equipment to optimize each viewing or listening experience. That end is precisely the goal of the IEEE 802.1 AVB (audio video bridging) working groups. However, the goals go much farther than that. Imagine AV systems with multiple content sources and multiple listeners. Then imagine a network of AV components that can automatically optimize the listening and viewing experience for each AV network user simultaneously in real time. That scenario is also within the goals of the 802.1 AVB efforts. Part of the need is for components to discover the capabilities of other Ethernet-connected devices in the local AV component cloud. Part of the need is to reserve a substantial part of the cloud’s networking bandwidth for content streams that absolutely require low-latency, high-bandwidth content delivery.

This effort relies on three interwoven specifications:

• IEEE 802.1-AS – A timing synchronization standard
• IEEE 802.1-Qat – A stream-reservation protocol
• IEEE 802.1-Qav – A packet forwarding and queuing protocol that can accommodate isochronous and non-isochronous AV traffic using reserved bandwidth and regular data-type Ethernet traffic using best-effort packet delivery.

Together with the Energy Efficient Ethernet specification (802.1-az)  discussed in the previous blog entry (even AV components sleep sometimes), the IEEE 802.1 AVB specifications ensure even longer life for the Ethernet protocol, now going on its fourth decade of ever-widening deployment.

The interoperability of today’s Ethernet-enabled devices is staggering. To see an iPad in a Starbucks coffee shop surfing Web servers in far-flung places such as Eastern Europe, India, Asia, or even North America through a casual WiFi connection is stunning—yet it is so commonplace that the feat rarely reaches our conscious minds these days. It just happens. Conjoined with that ease of connectivity however is a dark cloud: wasted energy to keep those billions of Ethernet connections alive even when they’re not carrying data. The energy numbers boggle the mind. In a recent Webinar, John Swanson from Synopsys listed a few jolting power-consumption figures. In the US alone, Ethernet ports attached to servers, network storage devices, routers, switches, and other networking equipment burn about 0.5 terawatts per year! Ethernet ports on computers, printers, edge switches, and other local devices installed in commercial, research, and educational institutions burn another 1.5 terawatts per year! Home-based ports burn about 2 terawatts per year! In all, that’s about 5 terawatts or $400 million worth of electricity per year just to keep the bits moving along all of the Ethernet ports in the US alone. And you know that all of those ports aren’t active all the time, yet most of them burn power 24/7. No wonder that the IEEE is now addressing the issue of wasted networking power through several new standards designed to make Ethernet use more efficient.

The key low-power standard under development is called the 802.1-az specification and it employs LLDPDU (link layer discovery protocol data units) to allow a switch and a device to negotiate sleep and quiet times when the Ethernet ports can actually be powered down. Implementations based on the 802.1-az specification will require new hardware and software but these new ports are backward compatible with the old, power-wasting kind of Ethernet port. If there’s no negotiation, there’s no sleep time and the ports will operate normally. However, when negotiation between two 802.1-az ports does take place, both ends of an Ethernet connection can time out and can power down their respective Ethernet MACs and PHYs, which will result in substantial power savings.

Currently, version D3.2 of the working group specification is circulating. More important perhaps, Ethernet controllers with 802.1-az port compatibility are already available as are some early PHY chips. The MAC part of the 802.1-az specification has not changed in a while according to Synopsys’ Swanson and only PHY changes are expected in the future.

Data applications for Ethernet can benefit greatly from the power reductions made possible by the 802.1-az specification but throughput- and latency-sensitive applications such as audio and video over Ethernet need additional support, which I’ll cover in the next blog post.

First, the company was founded by experts in networking and lighting including Dave Leonard, the company’s CEO, who was formerly General Manager of Cisco’s Ethernet Switching Business Unit and Mark Covaro, the company’s CTO, who was formerly the principal power design engineer for Cisco’s Power-over-Ethernet (POE) platform. So you might guess that two standards, Ethernet and POE are involved here. And indeed, a March 8 article in the online version of LEDs Magazine says as much. Redwood Systems has developed network switches that supply power and networking over a single cable specifically for LED lighting systems. The LEDs Magazine article mentions 60V @ 350mA power, which roughly corresponds to standard POE specifications, so it’s not much of a stretch to assume that the company is planning to adopt standard POE protocols even though none of the company’s literature specifically mentions Ethernet or POE. Adopting these standards is certainly one way to assure luminaire manufacturers of a ready supply of controller chips for all of the LED lighting fixtures they’ll need to develop. Otherwise, the industry would need to develop yet another new set of power+communication chips and there are plenty of those already.

Next, the LEDs Magazine article mentions that Ethernet Category 5/6 cable runs of 100 to 200 feet can deliver adequate power to lighting fixtures (one per cable) and more expensive 18-gauge wiring is needed for longer runs to 100m. The Cat 5/6 cable specification again closely ties the Redwood Systems’ technology with Ethernet and POE. As mentioned in an earlier blog, the ability to run low-voltage wiring for light fixtures rather than electrician-installed, government-inspected Class 1 ac power cables greatly reduces installation costs, which helps to compensate for the increase in the cost of the dimmable LED lighting fixtures compared to incandescent, fluorescent, and gas-vapor lighting fixtures. One fixture vendor clearly involved appears to be LED vendor Cree.

Redwood Systems is targeting the huge market for green lighting solutions. According to a White Paper on the company’s Web site, commercial buildings will use approximately 400 billion kilowatt-hours (BkWh) of primary energy for interior illumination this year. Further, says the White Paper, fully 75% of that energy is wasted because the lighting is being applied where it’s not needed: during the day when ambient light is more than adequate or when only a little supplemental lighting is needed to fill in darker areas and at other times when there’s no one around so illumination isn’t required. Redwood Systems’ smart sensing technology can profile lighting fixtures and the area being illuminated and then control the associated lighting network to light only where needed and to provide only as much light as needed, thus substantially reducing power costs. The ceiling-mounted network sensor incorporates ambient and task light sensors, a 360-degree PIR motion sensor, an ambient temperature sensor, and current and voltage sensors for smart control of the associated lighting fixture. These sensors allow the system to self-calibrate lighting levels and, combined with the low-voltage power distribution, allow the installation and replacement of lighting fixtures into live lighting networks.

The irony of using dc to power lighting, a battle Thomas Edison lost more than 100 years ago to Westinghouse, isn’t lost on Redwood Systems. “Edison was right!” proclaims the company White Paper. Well maybe not then, but maybe now.