“The only real sports are bullfighting, mountain climbing, and automobile racing. All others are mere games.” – Ernest Hemingway

We’ve all made the joke, “If it was easy, everyone would be doing it.” And in the professions of engineering, programming, debugging, or testing, that’s actually true. It’s not easy because it’s not supposed to be easy. In fact, we do our best to prevent our jobs from ever being easy.

It’s not out of masochism. Or a Hemingway-esque sense of challenge. It’s because that’s the nature of engineering: to always be a little tougher than we’d like. 

Throwing a ball is easy. We can do it from childhood. But throwing a 95MPH fastball to an MLB slugger is hard. Hitting a tennis ball is easy. Throwing horseshoes is easy. So is driving a car. But driving a racecar is another thing entirely. Hitting a golf ball into a hole is hard because the game is structured to make it that way. If the holes were bigger and closer together there’d be no challenge and, hence, no game. (I won’t call it a sport.)

Similarly, engineering and programming are hard, and they always will be. Because if they weren’t hard, we’d make them hard. It’s a constant struggle against what we can just barely achieve with our current skills, tools, and components. When we got the first integrated circuits in the 1950s, did we stop there? No, we just designed bigger and more complex devices using those ICs. When we got CAD software, did we continue to draw simple one-page schematics? No, they enabled us to start on bigger projects that stretched our capabilities. Each step just leads to the next step on an infinite path of professional improvement. It will never stop. It will never get easy.  

In a game/sport, the rules are generally fixed for all time, and the competitors gradually get better and better at it until (in some instances) it becomes almost too easy. Running a four-minute mile is no longer remarkable, yet the parameters of the challenge certainly haven’t changed. A mile is still a mile. Bowling a 300 game, hitting an eagle in golf, climbing Mt. Everest (it’s been done more than 5,000 times), and other feats of sporting prowess have become almost commonplace. 

Not so in our business. In engineering we keep moving the goalposts, as it were. We can be at the top of our game, but we’re never on top of the game. Experience and practice don’t enable us to do the same thing better and better. They allow us to push the finish line further out again. It’s like the cartoon image of the carrot on the end of the stick: we keep running forward but the carrot forever remains tantalizingly out of reach. Of Hemingway’s three sports, one seems to be getting easier (169 climbers summited Everest in one day), one stays the same (neither the bulls nor the matadors have altered their strategy much), and one gets more difficult (as cars gets faster). The old man was just keepin’ it real. He could’ve been an engineer.

Athena & Intrinsic-ID

Speaking of difficult engineering challenges, maintaining security has to be one of the toughest. It’s a never-ending treadmill; an arms race; a chess match. Choose your metaphor. But chip-level security is becoming a must-have feature for a lot of SoC designers – and their customers.

Readers may remember intrinsic-ID, a Dutch security-IP company that we’ve covered here and here. A company we haven’t mentioned is Athena, a Florida-based company operating in the same general space. While Intrinsic-ID made its name with enabling technologies like PUF (physically un-clone-able functions) and random-number generators, Athena makes a custom cryptography microprocessor.

It so happens that a lot of SoC designers were licensing technology from both firms and using one to complement the other. Before too long, nature took its course and the two companies starting talking to each other about their shared customer base. Pens were uncapped, papers were drawn up, and these two independents struck a co-development and co-marketing deal.

Rejoice! You can now license both companies’ IP from a single source. Athena and Intrinsic-ID did some work in the lab to preconfigure the former’s crypto processor with the latter’s PUF and RND functions to create a more efficiently integrated unit.

The integration is a boon for purchasing managers, but that’s only the easy part. By combining the two companies’ blocks into a single unit, sensitive key data now stays “inside the black box,” so to speak. That makes the resulting design that much more secure, and removes one more integration task from the developer.

Athena’s Dragon-QT crypto processor is a real processor: it’s programmable, has a Harvard architecture (i.e., separate data and code spaces), a CISC instruction set, real registers, and everything. Don’t bother looking for the C programming manual, however, because Athena does all the programming for you. From the user’s point of view, it’s an accelerator for elliptic-curve cryptography, ten different modes of AES, public-key encryption, SHA, and more. It’s designed to be paired with a general-purpose processor, sort of like the old floating-point coprocessors used to be. The host CPU fires off commands and passes data to the Athena processor, and then goes back to its knitting.

Like most soft processors, there are optional features that you can either include or not, trading off performance and capability for size and power. Size starts at about 25,000 gates, but that can easily double or triple with options added in. And, because it’s a processor and not a hard-wired accelerator, it can be upgraded (or patched) over time.

See, now – that wasn’t so hard.