I am more familiar with the F18A predecessors, such as the F21, than with this design. So it is quite possible that it is a proper asynchronous processor even i

I am more familiar with the F18A predecessors, such as the F21, than with this design. So it is quite possible that it is a proper asynchronous processor even if the older ones were not. I am biased by some confusion I observed about the F21. There are two ways to design an ALU: an efficient solution is to combine the inputs and control signals using as little logic as possible to generate the results or to have a separate circuit for each operation and then have the control signals use a multiplexer to select the desired result. A great example of the first style is the ALU in the ARM1: http://daveshacks.blogspot.com/2015/12/inside-alu-of-armv1-first-arm.html http://daveshacks.blogspot.com/2015/12/inside-alu-of-armv1-f... Many simple educational processors use the second style, as did the F21. In addition, the adder in the F21 was a simple ripple carry adder. In theory, you would have to use a clock slow enough that the + instruction would have enough time to generate the correct result even in the worst case. In the first ALU style that would certainly be true, but with how the F21 was actually designed just executing one or two NOP instructions before the + would work just as well. As soon as the values of the T and N registers were stable the adder would start to ripple and calculate no matter what instructions were being executed. Only when we get to the end of the + instruction does the result need to be ready. This allowed the amazing demonstrations of some F21 chips, which used 800nm technology, running at 800MHz. This hand scheduling of code to allow frequencies beyond what some instructions could handled was described at the time by several people as being an asynchronous processor design, which is wasn't. That is why I am a bit wary when I see that term used for the descendants of the F21 even if it turns out to be correct. Another interesting issue with running the F21 at 800MHz was that Chuck Moore's OKAD tools did not originally simulate heat transfer. As a result two transistors were a little smaller than they should have been and could burn out at such high frequencies. Inserting NOPs between instructions allowed these transistors to cool down enough not to be a problem. His next version of OKAD included a neat thermal model in order to avoid that mistake in future designs.