Powering Up

They were completely unprepared for what they saw when they stumbled upon it. This was supposed to be wild, untouched back-country. As far as anyone knew, no one lived this far out in the woods. And yet there it was: an old cabin, dilapidated but for the primitive upkeep that kept it intact.

There was only one inhabitant; no one knew who he was. From what they could guess, his parents had died when he was a kid. At the time, he must have been old enough to have learned to talk and scratch out an existence but not old enough to have been exposed to the outside world, an activity likely undertaken rarely by his parents. They affectionately referred to him as Wild Thing.

His reaction to them when they found him was surprise and suspicion, but it also reflected the vague stirrings of a memory long forgotten: the existence of other humans. At the time of his discovery, he had been making some repairs, replacing some old screws in the woodwork. Despite a wiry, muscular frame toughened from years of menial work, the effort of turning screws into decades-old hardwood was starting to show.

This gave them an idea for a simple way to build some trust: they gave him a new electric drill/screwdriver. Wild Thing examined it, puzzling over the odd shape. It looked in some ways like the old screwdriver, but it had a greatly exaggerated barrel and gun-like handle. Neither of which made sense to him. In fact, it made it really hard for him to drive screws – the head of the screwdriver kept turning inside the big barrel thing. He did figure out that you could replace the screw head with a Phillips head, so that seemed like something. And if he sort of gripped the head while turning the body, he could sort of make it work, but it took a lot of effort. He had no idea whatsoever about the weird box that came with the tool. It had a protruding wire with two metal prongs at the end; he just set it aside.

What no one had considered was the fact that there was no electricity here. Wild Thing had no concept of what it was or what it was good for. As far as he was concerned, this electric screwdriver was no better – and perhaps worse – than the one he’d been using all along. Someone had done a lot of work to create the new gadget, but, without electricity, its potential benefits remained untapped.

Meanwhile, he was becoming something of a media sensation, drawing the attention of a documentary producer. The team was able to convince the local utility to bring electricity the last few miles from a high-tension transmission corridor nearby. And the world watched as Wild Thing was shown how to plug the protruding wire’s prongs into a socket, charge the battery in the drill, and then let the drill do most of the hard work. Now that someone had finally taken the remaining steps to make the drill useful, it could demonstrate its benefits over the old hand screwdriver.

It has happened countless times. Someone comes up with a fantastic new silicon feature, carefully specs out the technical details, designs, verifies, and builds it, and then its potential is never realized. There are two reasons why this happens. Back in the old days, when hardware and software were distinctly different, and when self-respecting practitioners of one kept a disdainful distance from the other, complacent silicon managers would simply turn their new circuit out into the world, confident that its value would instantly create a band of followers that would bring riches untold. Of course, what really happened is that, because there was no software to support the hardware, no one ever used the new hardware feature, flummoxed protestations of the chip manufacturer notwithstanding.

We’ve come beyond that now so that, instead of avoiding each other, hardware and software entities reluctantly acknowledge each other’s respective roles in the creation of things and nominate partnership representatives to talk to each other so the rest of the people in the company can continue to ignore their counterparts. And with this comes the second failure mode: the software partner doesn’t want to support the hardware feature until the hardware vendor can demonstrate incredible sales of the feature, which won’t occur until there is software to support it.

Separately, off in the land of networking equipment, repeated network break-ins and tales of distributed service denied have brought security to the fore, and an important weapon in the secure arsenal is encryption, various flavors of which are used in a number of critical protocols. Encryption is a compute-intensive pastime, and there are numerous options for both hardware and software implementations. But for a long time, most didn’t have enough performance, and many engineers created their own accelerators, particularly in FPGAs.

But let’s face it; encryption is now so pervasive that it’s nonsensical to invent your own over and over again. No logic designer creates a transistor anymore; no software writer creates his or her own printf library routine; those are commodities, available off the shelf. And encryption is getting to the point where it should be a simple piece of IP that just works.

Problem is, each system may use a different security structure, layering on various protocols according to the function and intended price point. So designers need to be able to mix and match different encryption engines as needed to suit the design spec. This is a problem Mocana is trying to solve with its DSF suite of security protocols that can be plugged together in a modular fashion.

But the fact remains that encryption can be a sluggish beast, and when it’s really just an overhead job required to get at the contents of some packet that needs to be worked on, flags are raised when it gobbles more than its fair share of the CPU time.

Enter Freescale. They decided to provide some relief for this performance issue in their PowerQUICC “E” devices by adding a dedicated Integrated Security Engine. This hardware accelerator consists of a pipeline fed by four “crypto-channels.” By filling up the channels, the engine could be kept busy handling the encryption duties, giving the main CPU some well-needed rest.

But there was one problem: standard software didn’t make effective use of this architecture. The channels couldn’t be kept full, and the CPU was constantly being interrupted such that, for very high speeds, you could use 100% of the CPU managing encryption – and that’s with the assistance of an offload accelerator. Because the offload wasn’t well-managed, it didn’t have as much acceleration impact as it should. The classic case of great hardware sitting on the bench, waiting for the coach to put him in so he could show what he could really do.

So Mocana has recently announced an Acceleration Harness for Freescale that brings this accelerator to life. They spent eighteen months building the capability to chain encryption jobs together and pack the channels such that the accelerator is always busy, and the harness requires far less CPU involvement. Based on the amount of work and the joint marketing efforts upon release, it would seem that Freescale and Mocana eschewed the traditional “throw it over the fence” model and worked closely together. And the payoff for all this effort? Encryption algorithms can be executed twenty to thirty times faster.

It’s like somebody finally ran electricity to the old cabin and plugged in the tools.