[Dave] wanted to learn more about the ARM architecture, so he started with an image of the ARMV1 die. If you’ve had some experience looking at CPU die, you can make some pretty good guesses at what parts of the chip have certain functions. [Dave], however, went further. He reverse engineered the entire ALU–about 2,200 transistors worth.
From the image, he worked out the transistor structures and how they map to gates. Since the ARM is a 32-bit processor, there are 32 separate slices of the ALU, each with about 70 transistors (see below). There are slight differences between certain slices to support zero and carry propagation. A PLA generates control signals that route data through the ALU to perform the desired operation.
[Dave] was inspired by the visual6502 project as well as [Ken Shirriff’s] 8085 reverse engineering, both of which we’ve covered in the past. If the FET transistor logic isn’t to your liking, you could always try Minecraft.
Dave certainly has the experience at looking a CPU die… In the year twooo-thousand, in the year twooo-thousaaaaaaand and one
Superb. I’d also missed the visual6502/ARM guys’ project too. Still my all-time favourite CPU (well, maybe ARM2 – mul is useful…)
Interesting write-up. Silicon chips are a work of art. Reverse engineering on the silicon level likewise.
Acorn doesn’t produce any chips themselves. They sell the IP. Its up to the fabricators to turn the IP in to real chips. Some of the IP are available in VHDL or “blackbox”. I’ve used ARM-cores before in an FPGA. I’m wondering if it would possibly be easier to rip the files generated for the FPGA than reverse engineering the silicon. The output will change with the optimisation settings… So it will not be exactly the same.
Other than that writing a behavioural model in VHDL would give the same functionality.
FPGA implementation will be completely different though.
Arm1, Arm2, Arm250 (used in the Archimedes A3020) all the way to Arm600 precede Arm Ltd and weren’t licensed designs.
https://en.m.wikipedia.org/wiki/List_of_ARM_microarchitectures
Does anybody know of any ARM1/ARM2 documentation ?
At what level? There’s plenty of assembler-level around. Not sure about lower than that as at the time it was all Acorn proprietary info.
At the assembly level, including details on all instructions. Something like the ARM Architecture Reference Manual, but for v1/v2.
Online, try http://www.riscos.com/support/developers/asm/
This any use to you?
http://morrow.ece.wisc.edu/ECE353/arm_reference/ddi0100e_arm_arm.pdf
Thanks. I had looked at that before, but looking again, I see there’s a useful chapter on v1/v2 differences, called “Overview of the 26 bit architectures” that explains the differences.
I have the “Dab Hand Guide to ARM assembler” by dabs press. It just covers the simpler 26-bit addressed ARM.
The earlier ARM cpu’s had no thumb mode, only one spare set of registers for FIQ interrupts; only byte and long word addressing (no half-word access); condition codes were combined with PC , the top 6 bits so that a return would always restore them.
Isn’t it illegal to do this? IP?
Depends on why you do it. Could be legal for certain reasons in some countries.
The chip layout file was made available in agreement with ARM.
http://blog.visual6502.org/2015/11/the-visual-arm1.html
Really surprised about how big the barrel shift is. It occupies a lot of silicon. It must help a lot increasing the code density…
With 32 bit operands, you can’t really afford not to have a barrel shifter.
You say that, but barrel-shift for free on every instruction was a new (and very useful) thing.
To wring real speed out the ARM1, you also needed linear code (no cache), so barrel-shift and conditionalisation on every instruction was a major help.
This got me thinking a littlebit, does anyone know if there is an open hardware processor chip out there? That would be amazing!
RISC V
The day it’s economical to map states of silicon is the day software isolation and hiding keys in hardware will no longer work..