Slashdot Mirror
iPhone 5 A6 SoC Teardown: ARM Cores Appear To Be Laid Out By Hand
MrSeb writes "Reverse engineering company Chipworks has completed its initial microscopic analysis of Apple's new A6 SoC (found in the iPhone 5), and there are some rather interesting findings. First, there's a tri-core GPU — and then there's a custom, hand-made dual-core ARM CPU. Hand-made chips are very rare nowadays, with Chipworks reporting that it hasn't seen a non-Intel hand-made chip for 'years.' The advantage of hand-drawn chips is that they can be more efficient and capable of higher clock speeds — but they take a lot longer (and cost a lot more) to design. Perhaps this is finally the answer to what PA Semi's engineers have been doing at Apple since the company was acquired back in 2008..."
Pretty picture of the chip after using an Ion Beam to remove the casing. The question I have is how it's less expensive (in the long run) to lay a chip out by hand once instead of improving your VLSI layout software forever. NP classification notwithstanding.
That must be a very fine tipped resist pen...
The question I have is how it's less expensive (in the long run) to lay a chip out by hand once instead of improving your VLSI layout software forever. NP classification notwithstanding.
Coding in assembly still remains a superior method of squeezing extra performance out of software. It's just that few people do it because compilers are "good enough" at guessing which optimizations to apply, and where, and usually development costs are the primary concern for software development. But when you're shipping hundreds of millions of units of hardware, and you're trying to pack as much processing power in a small and efficient form factor, you don't go with VLSI for the same reason you don't go with a compiler for realtime code: You need that extra few percent.
#fuckbeta #iamslashdot #dicemustdie
There are a lot of layout methodologies that are between the (frankly mythical) "X cache, Y FPUs, and Z cores" and fully hand layout. The top level may have more or less amounts of hand assembly, some blocks can be hand optimized, etc.. Usually, there is lots of glue logic which must be designed in RTL, synthesized and only then laid-out. And, for most blocks the process to create the logic design (RTL or perhaps gates) is separate from the process of laying-out these blocks. So there is room for manual involvement in each of the steps.
The real "Libtards" are the Libertarians!
Looking closely I see a bunch of ram - probably half laid out by hand (caches) - and a many may small standard cell blocks almost certainly not laid out by hand - what I don't see is an obviously hand laid out datapath (the first part of your CPU you spend layout engineers on) - look for that diagonal where the barrel shifter(s) would be. There are some very regular structures (8 vertically) that I suspect are register blocks.
Still what I see is probably someone managing timing by synthesizing small std cell blocks (not by hand), laying those blocks out by hand then letting their router hook them up on a second pass - - it's probably a great way to spend a little extra time guiding your tools into doing a better job to squeeze that extra 20% out of your timing budget and give you a greater gate density (and lower resulting wire delays)
So - a little bit of stuff being done by hand but almost all the gates being lait out by machine
I've put the picture (which is what everyone wants) up here:
http://i.imgur.com/vqCAu.jpg
This is not by hand.
To take a programming analogy, it's looking at what the compiler generated, and then giving it hints so the resultant code/chip is laid out as you expect.
Chips stopped being able to be laid out 'properly' by hand some time ago.
Doing this has much the same benefits as doing it with code.
You know stuff the compiler does not.
You can spot silly stuff it's doing, that is not wrong, but suboptimal, and hold its hand.
Brilliant, this is what I love about Slashdot, I can be the biggest geek in whatever field I pick and I will still get outgeeked! I enjoyed reading the comments above mostly because I have absolutely no idea what the detail is, and I'd never even realised that hand-drawn vs machine was a issue.
:)
Can anyone supply a concise explanation of the differences and how it's all done? I'm guessing we're talking about people drawing circuits on acetate or similar and then it's scaled down photo-style to produce a mask for the actual chip?
Yes, I know I can just Google it, and I will, but as the question came up here I thought I'd add something to a real conversation, it beats a pointless click of some vague "like" button any day
Please consider this account deleted, I just can't be bothered with the spam anymore.
I'm guessing that the search space is too large to brute force the optimization. For similar reasons we can't write a program that can beat a Go master. It's just too hard a problem without heuristics, and the heuristics in the human brain are better. Figure out why, and you've solved AI.
Give me Classic Slashdot or give me death!
What you're missing is that chip layout is NP-complete. For anything beyond very trivial chips, no computer algorithm can yield the optimal solution in a reasonable time.
As I understand it, automated layout algorithms are still, when you get down to it, largely quite dumb. I'm sure this is oversimplifying and someone who writes place-and-route software will probably want to kill me, but the algorithm is closer to "throw stuff together, measure performance, tweak things randomly, measure performance, keep the change if it got better" than to anything likely to yield an optimal solution. Eventually, you'll converge on a decent layout, sure, but not an optimal one.
It's pretty much guaranteed that this chip wasn't completely hand-crafted (modern chips are much too complicated to do that). Instead, most likely, engineers guided the placement of major blocks and data paths, and let the automated place-and-route software choose the rest. By constraining the design based on intelligent decisions, you can guide the automated process to converge on a better solution.
Display is LG. Flash is mostly Hynix and Toshiiba.
Yeah, but the software is Samsung, and everyone knows that's what really counts.
The CPU is manufactured by Samsung, and that's what really counts for Fandroids.
Nah, I was referring to the well sourced fact that iOS is actually just a gimped version of Android.
Remember Schmidt was on the Apple board, and he provided preview copies of Android to Jobs.
When someone buys a design from ARM, they buy one of two things:
Which is not what Apple did.
Apple has probably collaborated with ARM to get a hand layout done with apples chosen modifications. I can't see anything new or innovative here.
No, they designed it themselves since they are an architectural licensee like Qualcomm. You remember how they bought PA Semi?
I think you underestimate how good compilers have become.
I think you may have misunderstood the realities of what a modern expert assembly language programmer does.
An expert assembly language programmer knows when to write assembly language and when not to write assembly language. Assuming that raw performance is the metric by which programmers are judged (which isn't necessarily the case), an expert assembly language programmer will still win over any high-level language programmer because they can also use the compiler.
It's the same with hand-laid-out VLSI. It's not like some team of hardware designers placed every single transistor. That would cause just as much of an unmaintainable mess as writing a large application entirely in assembly language. Rather, the hand-layout designer worked in partnership with the automated tools.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
The question I have is how it's less expensive (in the long run) to lay a chip out by hand once instead of improving your VLSI layout software forever. NP classification notwithstanding.
It's simple math. At what volume will the chip be produced? A modern fab costs $X Billion, and you know pretty much exactly how many wafers you can run during the 3 years it is state-of-the-art. After that, add $Y Billion for a refit, or just continue to run old processes. Anyway, say a new fab at refit time would cost $Z Billion. Refitting the old fab instead costs $Y Billion. So you save $Z-$Y by doing a refit. So the original fab cost you $X-($Z-$Y). Divide by number of wafers the fab can run during its life, that is the cost per wafer. Now compute die area for hand layout versus auto layout, and adjust for imporved yield for smaller die. Divide by die per wafer. That is how much less each die costs you. Now since the die is smaller, it probably runs faster, so adjust your yield-to-frequency-spec upwards, or adjust your average selling price upwards if the speed difference is "large" (enough MHz to have marketing value). That is the value of hand layout. It isn't rocket surgury to work out a dollars-and-cents number.
Anyway, even at Intel for at least the past 20 years only highly repetive structures like datapath logic has been hand laid out. Control logic is too tedius to lay out by hand, doesn't yield much area benefit, and is where the bulk of the bug fixes end up so it's the most volatile part of the layout from stepping to stepping.
So, can hand layout have a positive return on investment? Yes, if you run enough wafers of one part to make the math work out. These days the math will only work out for higher volume parts.
(Yes, I'm ex-Intel).
Okay - I'm stepping in here because I actually do chip design for a living. The difference between hand laid-out and machine generated chips can be as much as a 5X performance difference. The facts are that physical design isn't the same as compiler writing. It's a harder problem to crack - first it's a multi-dimensional problem. Next, it has to follow the laws of physics, themselves complicated ;-)
Both processes DO rely on the quality of input. When my designs don't run fast enough, the likely fix is to go back to the source and fix it there instead of trying to come up with some fix within placement and routing. The other simple fact is that in timing a physical design - you have to consider EVERY path that the logic takes in parallel. There is not such thing as the "inner-most" loop of the algorithm for determining where the performance goes. Finally once you have a good architecture for timing, the placement of the physical gates dominates the process.
A human - with their common sense is always going to give better performance than an algorithm. I mentioned a 5X difference between hand-drawn & compiled hardware. That is about what I see on a daily basis between what my tools can do for me, and what Intel gets out of their hand-drawn designs for a given technology node.
Have you compiled your kernel today??
I'm a chip designer too (although probably not as good as you are), and one thing I wanted to mention for the benefit of others is that in today's chips, circuit delays are dominated by wires. It used to be dominated by transistor delays now, but today, a long interconnect in your circuit is something to avoid at all costs. So careful layout of transistors and careful arrangement of interconnects is of paramount importance. Automatic layout tools use AI techniques like simulated annealing to take a poorly laid-out circuit and try to improve it, but they're even now still poor at doing placement while taking into account routing delays. Placement and routing used to be done in two steps, but placement can have a huge effect on possible routing, which dominates circuit delay. Automatic routers try to do their jobs without a whole lot of high-level knowledge about the circuit, while a human can be a lot more intelligent about it, laying out transistors such with a better understanding of the wires that will be required for that gate, along with the wires for gates not let laid out.
Circuit layout is an NP-hard problem, meaning that even if you had the optimal layout, you wouldn't be able to determine that in any simple manner. Computers use AI to solve this problem. There is no direct way for a computer to solve the problem. So until we either find that P=NP or find a way to capture human intelligence in a computer, circuit layout is precisely the sort of thing that humans will be better at than computers.
Compilers for software are a different matter. While some aspects of compiling are NP-complete (e.g. register coloring), many optimizations that a compiler handles better are very localized (like instruction scheduling), making it feasible to consider a few hundred distinct instruction sequences, if that's even necessary. Mostly, where compilers beat humans is when it comes to keeping track of countless details. For instance, with static instruction scheduling, if you know something about the microarchitecture of the CPU that informs you about when instruction results will be available, then you won't schedule instructions to execute before their inputs are available (or else you'll get stalls). This is the sort of mind-numbing stuff that you WANT the computer to take care of for you. Compilers HAVE been getting a lot more sophisticated, offering higher-level optimizations, but in many ways, what the compiler has to work with is very bottom-up. You can get better results if the human programmer organizes his algorithms with knowledge of factors that affect performance (cache sizes, etc.). There is only so much whole-program optimization can do with bad algorithms.
Interestingly, at near-threadhold voltages (an increasingly popular power-saving technique), circuit delay becomes once again dominated by transistors. When lowering supply voltage, signal propagation in wires slows down, but transistors (in static CMOS at least) slow down a hell of a lot more.