Should i pipeline s-boxes?

The more you look at problems, the more options do you see. Some time ago I would mostly try to find “solutions”, now I often find the process at least as interesting. So, I would like to document my options as I see them today, so that I can laugh at my own ignorance (or genious, in that case it should be appropriate with evil laughter) in a year or so in the future. And it is material for my report: “First I thought this, but surprisingly I found this.”

In electronics there are mainly three physical constraints to optimize against: Speed, area and power. My focus should be on power, but the three are often connected in intricate ways. And while TANSTAAFL, it is motivating to get the design fast, small and elegant as well.

Technically speaking, I am looking at pipelining and concurrency. In my current draft, the S-boxes (16 of them) are implemented with lookup tables, which might or might not be good for power. Others have found that combinatorial implementations give greater speed, and it opens up for pipelining.

(from Wikipedia)

While some scientists have achieved great speed with pipelined AES-implementations, it isn’t a great idea, as the only mode which can exploit this pipelining is the Electronic Code Book mode. The ECB-mode has a one-to-one mapping of plaintext and ciphertext, and is obviously insecure, as the penguin illustrates. Never doubt the penguin.

What I am considering to pipeline, is the s-boxes to reduce the number of them (lessen area), without greatly hurting the speed. I am also very curios on how this will affect the power consumption. I have not yet established a way to quantify power consumption, but I suppose I’ll end up with the synopsis-tools when the semester starts again at the university. Meanwhile, I’ll just keep implementing various variations over the theme “AES”.

Now, it’s combinatorial s-boxes and beyond! The future is bright, and the bloggin’ architects I wrote about in my first post have found me. Thanks to them for the shoulder clap, and may your buildings rule and improve the world!

Logic mechanics (picture from wikipedia)

It’s ugly, it’s big, it’s slow, but it is asynchronous. Here it is. It’s not verified, but validated for some example input. It instantiates 4*16 8-bit galois-field multiplicators, 16 sboxes and then some. It’s all mostly parallel, though.

The next step now, is to map to some technology. One of the perks with asynchronous design is that it is somewhat more technology-agnostic than clocked designs. Do we know that the future is in silicon or with semiconductors at all? There are some cool (literally, for the moment) research of logic on superconductors that don’t do well with big fan-outs like clocks. And why wouldn’t you want to build a mechanical computer (like the one in the picture) based on asynchronous logic?

On the more realistic side, I own a Spartan 3E starter kit. Is it possible to cram this AES into there? Should I bother? I might learn something by building a asynchronous building blocks.

It also seems that there are wishes that I shoud use the more mature and maintained tools from Handshake solutions. Their language, Haste, looks a lot like Balsa in concepts, and also have the same roots in Tangram. They also support some solutions for scan-testing asynchronous circuits, but their tools costs a lot. Will my university pay?

Oh, and by the way: I formally got my assignment today. Great!

The animation shows the handshaking, which is the key to designing clockless circuits. As you can see, there are four colors involved, as it uses four phase handshake:

Four phase handshake (from the Balsa-tutorial)

1. Red: “request” is high
2. Green: “acknowledge” is high, and any bundled data should now be valid
3. Blue: “request” is low, and data don’t have to be valid any more.
4. Grey: “acknowledge” is low

Note that there are two kinds of ports in Balsa: “Active” and “Passive” with filled and unfilled circles respectively. This marks the directions of the request/acknowledge signals, but data can go either way.

A technology with an interesting twist is Null convention logic, where the acknowledge signal is in the data itself. This is done with a kind of one-hot encoding of every value, so that for example one bit is encoded with two wires: 00 means NULL (acknowledge low), 01 means 0, 10 means 1 and 11 is an error.

For the interested, i used recordmydesktop to make the video.

The idea of blogging about my thesis came from my work in Altund, a group for promoting education methods at NTNU which lead my focus to the conference Hitech-Lotech, and two architect students who had good experience with blogging about their master thesis work in their blog “Ready. Set. Go back!“.

Now, while I formally haven’t got my assignment yet, I’ve anyway started to read up on what I hope I’ll get: Clockless design of an AES-circuit.

While reading is fun, I’ve found playing around with Balsa, a high level opensource synthesis tool for asynchronous circuits, even more amusing. I’m also obliged to learn something about AES, so I’ve started to implement a naive AES-module in Balsa. My goal is to quickly make a big, power hungry, slow and correct implementation. I’ll publish my embarrassing code here when it’s somewhere near complete.

I have previously been interested in reed-solomon and raid6′s “magical” insides, and it seems that I’ve met my friend Galois field arethmitic again in the AES-algorithm. This blogpost shows a nice and tidy combinatorial implementation of multiplication in GF(8) with GPL3-licence. 10 xor + 1 and critical path isn’t bad for multiplication.

And then for some inspirational stuff from my favorite comic-writer xkcd: