Rise of the ARM Clones

An anonymous reader writes "Clones of the ARM processor intellectual property are again becoming available for free from the open source hardware community. ARM was rigorous in shutting cloners down in the past but the clones are rising again under codenames Amber, Storm and Atlas, albeit of older instruction set architectures."

Comments

Rise of the clones

[Kopachris]

You can finally have your very own clone ARMy.

Re:Rise of the clones

[Anonymous Coward]

Oh? What do you call this ARMy? Beowulf's Bridgade? Are they well ARMed? Should we form a Compaq or sign an ARMistice? Or simply do a call to ARMs?

Re:Rise of the clones

[ArcadeMan]

Thank you, AC, that was the joke.

Re:Rise of the clones

[linear a]

Better warn Niven.

Re:Rise of the clones

[davester666]

SEND IN THE CLONES!

Re:Rise of the clones

[Anonymous Coward]

Intel would have if they could get away with it. But the IBM PC was developed during a time when the manufacturers still demanded a second source for every IC in their products. If Intel had refused to license the x86 instruction set (and complete layouts) to AMD they wouldn't have gotten the contract from IBM.

Why not?

[hairyfeet]

Personally I'm more interested in some of the MIPS chips like the Loognson Dragon that has built in X86 hardware acceleration, supposedly you get 80% of X86 speed when it comes to emulation but while having the longer battery life. Sadly we'll never see it in the states thanks to IP laws but if the chip designed were truly opened up I bet we'd see all kinds of new ideas and approaches. Remember when we had choices in X86 besides AMD and Intel? They had chips like WinChip that were more of a RISC design, you had more media leaning like Cyrix, it gave us a wealth of choice and if that happens with the ARM clones I'm all for it.

Re:Why not?

[JDG1980]

You actually miss Cyrix?

Re:Why not?

[evilviper]

Personally I'm more interested in some of the MIPS chips like the Loognson Dragon that has built in X86 hardware acceleration, supposedly you get 80% of X86 speed

Last I heard, the latest Loongson processors were performing about on-par with the earliest 1GHz Pentium-4 processors. A processor well over a decade old. That's something to look forward to...

Re:Why not?

[jonwil]

Worst mistake I ever made in all my years of buying (and building) computers was when I bought a 300MHz Cyrix part as an upgrade to fit into my PC (at the time the Cyrix part was the only real way to upgrade beyond the Pentium 166 MMX that I had without buying an expensive new motherboard). That Cyrix part was a piece of junk and never worked all that great (although to be fair some of that was because I was stupid and used the heatsink and fan from the Pentium 166 MMX on the Cyrix part instead of getting a heatsink/fan that was suitable for the Cyrix part).

Ever since that mistake I have only bought Intel chips and have always bought the correct Intel-approved heatsink/fan combo to go with them.

Re:Why not?

[jones_supa]

Apart the crappy thermal solution, what kind of problems did you have with the Cyrix CPU?

Re:Why not?

[AliasMarlowe]

And I have only happy memories of Cyrix. In particular, I had a Toshiba T5200 with an alleged 20MHz 386. This exhibited the protected-mode bug which was only supposed to afflict 16MHz early 386 chips (maybe it was just overclocked). So although it worked fine with OS/2 2.0, the command shell had a curious bug in the beta of OS/2 2.1 (it only affected command line editing). It also crashed regularly with Windows 3.0
The T5200 behaved perfectly with Windows 3.0 and OS/2 2.1 once the Intel 386 was upgraded to the Cyrix 40MHz pseudo-486. No heat-sink needed, of course.

Re:Why not?

[unixisc]

Personally I'm more interested in some of the MIPS chips like the Loognson Dragon that has built in X86 hardware acceleration, supposedly you get 80% of X86 speed when it comes to emulation but while having the longer battery life. Sadly we'll never see it in the states thanks to IP laws but if the chip designed were truly opened up I bet we'd see all kinds of new ideas and approaches. Remember when we had choices in X86 besides AMD and Intel? They had chips like WinChip that were more of a RISC design, you had more media leaning like Cyrix, it gave us a wealth of choice and if that happens with the ARM clones I'm all for it.

I'd argue that we have a bonanza/plethora of choices as far as ARM clones go - you have them coming from Phillips, TI, Qualcomm, Freescale, Marvel, NVIDIA, Atmel and who knows who else. These are all licensees of ARM Holdings. Similarly, MIPS has/had its many licensees. Intel was more restricted, and I'd argue that it was for a worse CPU.

If you are thinking about an open CPU, a good one would be OpenRISC/OpenCore. Currently, it's a soft CPU, which any company could pick up, license and fab. So all sorts of great stuff could be done w/ such a chip. However, the people w/ the skills to make it run long on a battery, or make it fly would probably be working for one of those chip designers, which has little to gain by opening up their designs. Open source hardware is a great concept, but just falls flat on its face when the rubber meets the road.

But the current x86 IP trump card lies in the hands of AMD, and I think that they probably would have a better future if they continued manufacturing just the ATi GPU, while licensing the x64 design to anyone who's interested. As is well known, nobody can compete w/ Intel on its fabs, so it's pointless for AMD to even try. But if they were to do what ARM Holding does, and license the x64 design to anybody who's interested, and let anybody - Apple, Freescale, NVIDIA, et al license it and make CPUs and sell it, it should make AMD a bundle, keep the company afloat, but not have to deal w/ manufacturing headaches that it's always been ill equipped to deal with. Then you could see a company come out w/ a multicore CPU - 2 AMD64 cores, 2 ARM cores and anything else that they fancy. Maybe something that can natively run both Android and Windows apps.

Re:Why not?

[snadrus]

AMD's failing in direct x86 competition. Hybrids may be interesting, though could be done at the board level. x86+Video integration hasn't worked well, and part of this is expense when putting too much on the same die.

MS pushes WinRT to confuse, which would threaten something like that.
Now that Intel can make 6+ hour laptops and Android can run on x86, what's the advantage of all that work?

Re:Why not?

[Bert64]

The Cyrix chips were supposed to be extremely unstable, and yet i had several linux systems running cyrix processors with uptimes exceeding a year. Perhaps they were only unstable when running windows?

As for the poor mp3 decoding performance, the cyrix chips were very good at integer code but lacked floating point capabilities... For most general use cases the better integer performance (especially for the price) outweighed the weak floating point.

Re:Why not?

[xanclic]

supposedly you get 80% of X86 speed when it comes to emulation but while having the longer battery life.

Actually, it's rather x86 applications run at about 80% the speed of native MIPS applications.

Re:Why not?

[unixisc]

I'm not talking about putting too much on a single die. I'm talking about taking 2 x64 Thuban cores, 2 ARM core and making a hybrid MCM CPU. The idea being that any system based on this could natively run Windows apps written for x64 as well as Android apps written for ARM. Android does exist on x86, but most of the apps would need to be ported. The base OS could be something like Minix, w/ Windows 8 and Android jails inside.

Intel can make what it can due to its process advantage over everybody else. I know that there isn't much getting around it, but then Intel also has the prices that make it unattractive. A design like what I suggest above, and ported to an inexpensive foundry could potentially come up w/ a winning design, provided the foundry is not a third rate foundry. Or a design house could even try fabbing their stuff out of Intel, in addition to others, if it provides really compelling advantages.

Re:Why not?

[hairyfeet]

I had one running BeOS and it ran fricking great, IIRC I also ran OS/2 Warp on it and it ran well there too. Everybody has to remember than it really was Wintel back then, MSFT would incorporate every little thing that Intel did into their OSes while the other guys? Not so much.

Hell that happens to this very day, look at how the Linux guys are claiming great performance out of the AMD bulldozer chips because somebody came up with a patch that shows the OS how to treat BD modules, while if you want anything even remotely similar in windows you HAVE to take that POS Windows 8, as MSFT has already said backporting the scheduler is a "will not fix" as far as they are concerned.

While I prefer Win 7 over Linux (going strong since 09 without a single driver failure) even I will admit Linux has an advantage in that situation, as support for non mainstream chips gets added a LOT quicker than in windows.

Re:Why not?

[drinkypoo]

Cyrix had the same problem with many of their CPUs as the K6 and K6/2, inferior FPU with not enough bits. Also, it had crap performance clock for clock compared to intel, unlike the K6 which I found to be quite competitive any time it wasn't involved in fp math. A K6/3 would give a P2 a good run for its money, clock for clock, but they didn't scale quite as far except occasionally.

Re:Why not?

[higuita]

IIRC, the last true x86 CISC chip was the pentium (not the pro) and the first x86 RISC chip was the AMD K5.. after that all x86 are internally RISC chips with a CISC compatibility layer

naming converntions

[Anonymous Coward]

If they are ARM clones...similar to ARMs but not quite the same...can we call them LEGs?

Re:naming converntions

[jones_supa]

Or prosthetic ARMs...

What restrictions apply to CPU architectures?

[JDG1980]

ARM will license out their cores to whoever pays. Intel and AMD (and Via, but no one cares about them) are apparently the only ones allowed to make x86 chips. But what type of "IP" is relevant here? What is the legal basis for the restrictions? If someone decided to make their own x86 clone, for instance, what would they be violating? It can't be trademarks, since that could be circumvented simply by changing the wording on the product and literature. I don't see how it could be copyrights, unless the implementers actually copied the original die mask or made a derivative work of it. So that leaves patents. Can you patent opcodes? Or is it only specific methods of implementing the opcodes that are covered by the patents?

The original Intel Pentium was released in March 1993. This means that the patents on it should either be expired or nearing expiration. Would there be any demand for an open implementation of a 20-year-old x86 CPU? In embedded systems, maybe. And as more time goes by, a greater and greater portion of the x86 ISA could be implemented.

Re:What restrictions apply to CPU architectures?

[DuckDodgers]

From the second to last paragraph in the article, "It is the case that patents usually have a 20 year life and therefore those that were in force in 1990 have now expired. However, modern implementations of old instruction sets could infringe on techniques that have been patented more recently by ARM or other companies – so I don't think the age of the instruction set is a water-tight defense."

Re:What restrictions apply to CPU architectures?

[NixieBunny]

It doesn't matter, because the owners of the "IP" (which is not a real thing) will tie up the cloner in court for a long time, whether or not they have a valid claim. That's how the legal system appears to work.

Re:What restrictions apply to CPU architectures?

[tlhIngan]

ARM will license out their cores to whoever pays. Intel and AMD (and Via, but no one cares about them) are apparently the only ones allowed to make x86 chips. But what type of "IP" is relevant here? What is the legal basis for the restrictions? If someone decided to make their own x86 clone, for instance, what would they be violating? It can't be trademarks, since that could be circumvented simply by changing the wording on the product and literature. I don't see how it could be copyrights, unless the implementers actually copied the original die mask or made a derivative work of it. So that leaves patents. Can you patent opcodes? Or is it only specific methods of implementing the opcodes that are covered by the patents?

MIPS did it - they held patents on several things that were required in order to implement certain instructions. I'm sure ARM has some patents on CPU architecture as well.

As for implementing 20 year old architectures - nothing's wrong with that - there's plenty of use in embedded systems. They won't power your smartphone, but they'll do for small things.

And most vendors probably aren't worried - because the people using these open cores will generally be putting them on FPGAs, and excepting the newest and latest ones (which can cost $20-30k *each*, yes, some of the latest FPGAs are easily between $20,000 - $30,000 each. In quantities of 1,000.). So your design is already speed limited and you're really not going to be using very complicated newer designs anyways (it won't fit).

If you're trying to put it on an ASIC, well, the ARM licensing costs will end up being just a small part of the entire VLSI costs. After all, a single mask is still in the 6-figure range, and modern processes with 10 metals require close to 20 masks, which puts you in the couple of million dollar range.

It's why the MIPS clone was basically done with support of the Chinese government - any other fabless company would just ante up and pay the licensing fees because they're just a small part in the end.

Re:What restrictions apply to CPU architectures?

[AmiMoJo]

All ARM can really do is certify chips as 100% ARM compatible. That's where the value of licensing lies.

If you are building an ARM based system you are going to want a certified chip so you know that all the ARM software out there will run on it. If you use an non-certified core there might be odd implementation bugs that break things in subtle ways, or maybe a future version of Android crash, or have some other undesirable effects.

Re:What restrictions apply to CPU architectures?

[evilviper]

But what type of "IP" is relevant here? What is the legal basis for the restrictions?

If you had RTFA you would have seen nice little quotes like this one:

"not covered by patents so can be implemented without a license from ARM."

The original Intel Pentium was released in March 1993. This means that the patents on it should either be expired or nearing expiration

Before June 1995, patents in the US weren't 20-years from filing date. If they were, MP3, and perhaps AAC (-LC) and MPEG-2 would be free and clear by now. Instead, patent expiration was based on the patent issue date, which could be many YEARS after filing. And filing can also be up to a year after first publishing the method. I've seen pre-1995 patents that are valid for as much as 25 years after first publication, so you need to look up the USPTO patent issuance date for each patent.

Re:What restrictions apply to CPU architectures?

[JDG1980]

and if they do, ARM is the much more logical choice. Better energy profile...

This assumes you care only about battery life and not performance. x86 platforms have always outperformed ARM platforms on a clock-for-clock basis, and probably always will, since the CISC instruction set allows more work to be done per cycle. And on a modern CPU, the decoder that converts x86 instructions to internal micro-ops is a tiny portion of the die space, even on portable devices.

Meanwhile, Intel still fakes efficiency figures by putting the power-hungry parts of the Atom into its north-bridge. And people still fall for it, despite the shitty battery life.

Your information is years out of date. The first Atom CPUs were paired with an old i945 chipset, which did indeed use far more power than the CPU itself (the chipset had an absurd TDP of 22W, compared to 2W-4W for the processor itself). In 2009, however, Intel moved many of the functions into the CPU and stopped producing the chipset on such an outdated process, and this dramatically reduced TDP to low single digits. Yes, you still have to add the PCH+CPU to get total TDP; anyone who doesn't realize this shouldn't be trying to design an embedded system. The upcoming new generation of Atoms (Silvermont) will be full-fledged SoC designs with no need for a PCH. They are expected to have considerably better performance and lower power consumption. And the truth is that the existing Atom design is really bad, and was in part designed that way to avoid cannibalizing sales of Intel's more expensive desktop CPUs. But with the mobile device market being what it is now, Intel can't afford to hold back any more.

Re:What restrictions apply to CPU architectures?

[thisisauniqueid]

I say go for it without certification. "100% ARM compatible" is a joke now, given the large number of different, mutually-slightly-incompatible ARM architectures made by ARM and ARM licensees.

Re:What restrictions apply to CPU architectures?

[Anonymous Coward]

I would say that I can't build anything using electronic components today without infringing on some patent. There are simply too many patents. I think that is sort of a big problem.

Re:What restrictions apply to CPU architectures?

[evilviper]

It seems you replied to the wrong comment. Oops.

Re:What restrictions apply to CPU architectures?

[Waffle Iron]

The whole reason AMD exists, is because there are no protections on x86.

No, the reason AMD exists (aside from their cool 70s-era bitslice ALU chips that allowed you to roll your own CPU) is because ~30 years ago it entered a licensing deal with Intel to second-source the 8086 so that IBM would agree to use it in the PC. They didn't want to risk using a single-sourced chip for their new system.

So no, nobody stops anybody from making an x86/amd64 chip. (SSE is a different thing.)

I'm sure any modern version of those CPUs are patented out the wazoo, including much of the x64 instruction set itself. Intel and AMD have had patent cross-licensing agreements in place for decades; that's why Intel gets to use x64 without restriction. Other parties would have to pay.

Re:What restrictions apply to CPU architectures?

[DuckDodgers]

Agreed.

Re:What restrictions apply to CPU architectures?

[WaywardGeek]

I've got to call you on the CISC statement, though the RISC/CISC debate has been dead for many years now. As you pointed out, modern CISC processors translate CISC instructions into micro-ops that look a lot like a RISC instruction set, and every modern RISC processor has added so much hardware that it's a joke to call them "reduced" anything. At this point, the density of the instruction set is important in that it reduces cache misses, and some CISC processors beat some RISC processors in this space, but the ARM Thumb architecture blows x86 out of the water, IIRC, in code side. However, data cache misses far out weigh instruction cache misses now days, so even instruction density isn't very useful anymore for speed. I think now days the only real difference has been the applications driving CPU design. ARM is low power and small first, and powerful second. x86 is the other way around. It's cool to see these variations of these architectures invading each other's turf.

Back in 1986 (when I took Dave Patterson's computer architecture course), CISC processors used microcode. That was practically their definition. RISC processors were more pipelined, and did more per clock. They often had Harvard architectures with separate instruction and data busses, while CISC processors clung onto a single bus. The microcode architecture was inherently slow (a whole clock was used just to read the microcode ROM), and was only commonly used because of the great flexibility it provided, in addition to the simplified design effort. For example, it helped propel IBM to greatness by having machines with compatible instruction sets decade after decade, even though the hardware changed radically, and it helped Intel win the CPU wars because of compatibility rather than CPU performance. While Intel worried about compatibility and keeping costs down, Sun Microsystems built fantastic RISC based workstations that put Intel CPUs to shame. However, Moore's Law was on Intel's side. When transistors were cheap enough, Intel switched from microcode to effectively a CISC-to-RISC translator (micro-ops). That ended the RISC/CISC debate, AFAIK, and enabled Intel to compete with CPUs from Sun. The complexity of that translator is just too small to worry about compared to all the stuff both CISC and RISC architectures have bolted on since then. High end RISC and CISC processors have very little difference of any significant meaning now days. At first, RISC won, by being faster. Then CISC won by becoming RISC and remaining compatible with Windows, and then RISC lost by becoming complex. Then RISC won by being smaller and lower power (ARM). Now CISC is being shrunk and made low power again. I think this all has a ton more to do with ARM vs Intel then the encoding of their instruction sets.

Re:What restrictions apply to CPU architectures?

[K. S. Kyosuke]

Lawsuit with whom? If an excellent free and open HDL design for an ARM core appears on ThePirateBay, uploaded by Anonymous, with whom are they going to litigate?

Re:What restrictions apply to CPU architectures?

[GumphMaster]

with whom are they going to litigate?

With anyone that tries to manufacture and market a physical device from said plans. They can start with FUD that the plans were stolen and move on to stitching you up with a patent lawsuit for everything in the chip that's even slightly non-generic. None of it has to be entirely true, just not entirely false (or they will be done for wasting court time). In the meantime you are bled dry financially by legal costs and prospective buyers going elsewhere for fear their derived product will be subject to injunctions.

If APIs can not be patented

[Anonymous Coward]

then why can the API of a processor, i.e. the instruction set, be patented?

Re:If APIs can not be patented

[jellomizer]

Because it isn't abstract.

Re:If APIs can not be patented

[Anonymous Coward]

How is an instruction set less abstract than any other API? They are all lists of ways to make a machine do specific things.

Re:If APIs can not be patented

[White Flame]

ARM does not sell physical devices. They sell HDL that implements the API.

Re:If APIs can not be patented

[ikaruga]

1) Software can't be patented argument is a lazy and misleading argument. I can describe any piece of hardware(electronics, mechanisms, chemical formulas, etc) as a set of numbers and formulas. Either we get rid of all patents or we make the system harder/more intelligent(no more slide to unlock crap). I don't care which we do as long it makes the lives of us engineers easier. But using misleading arguments do NOT help our cause.
2) Processor architecture is much more than the instruction set. The way interrupts are triggered, the way clock is distributed, the way the pipeline works, how many instructions per clock it can do, along many other factors that change how the actual instructions are arranged. So even if a certain instruction happens to have the same binary for different architectures, depending on the state the processor is it may not work because the internal implementation is different.
3) Processor architectures(and any chip) by themselves are not patented but instead copyrighted(the circuit pattern is basically a set of images). The circuit blocks that compose these chips and architectures may or may not be patented.

Re:If APIs can not be patented

[jellomizer]

Beats me I was just being a Smart Ass

Re:Why not? No Choice!

[BoRegardless]

This time around "Choice" of CPU is virtually impossible for the customizer or customer because none of the hardware that typically use these chips are in sockets. Different era; different mods.

Another Da Vinci prediction soon to come true?

[dmomo]

...The Vitruvian Man.
http://en.wikipedia.org/wiki/Vitruvian_Man
Now we just need a LEG clone.

Re:Another Da Vinci prediction soon to come true?

[K. S. Kyosuke]

...The Vitruvian Man. http://en.wikipedia.org/wiki/Vitruvian_Man Now we just need a LEG clone.

Nah, that's just Leonardo's Tomcat inside the box.

Re:Attack of the..

[robthebloke]

Are the arm clones being poised aggressively on the market?

Possibly not if their marketing budget only stretches as far as an article on slashdot.....

Re:Why not? No Choice!

[NixieBunny]

Choice of CPU is at the board level, sure, but with a Raspberry Pi selling for $35, is that really a problem?

Not for Brooke Nelson McArthur

[tepples]

Now we just need a LEG clone.

If you have ARMs, you don't especially need LEGs. (Article or video)

Do it in China

[rodrigoandrade]

They have the manufacturing ability and steamroll over patents, trademarks, intellectual property, etc.

Really, was that so hard??

Re:Do it in China

[wasteoid]

If I had mod points, you'd get +1 Insightful. Why not make use of existing capabilities to increase competition?

So it's basically a GBA-era ARM chip without thumb

[Dwedit]

The article mentions that it is compatible with the ARMv2a instruction set, though it may not be implemented the same way regarding pipelining and caching. The ARMv2a instruction set is basically the same instruction set as the ARM7TDMI, but without THUMB, and without the BX instruction. Any pure ARM code that doesn't use newer features (such as saturating arithmetic) should work on it fine. GCC should support this with no problems.

Re:So it's basically a GBA-era ARM chip without th

[Dwedit]

It also appears to be missing 32x32=64-bit multiplication instructions.

Re:So it's basically a GBA-era ARM chip without th

[dmitrygr]

This. It will hurt. A lot. This means that 64x64 -> 64 multiply (what gcc will do if you multiply two uint64_t values) will now need 10 multiplies, at least 20 shifts (16 to cut off tops 16 bits of intermediates, 5 for result alignment), and 9 additions, instead of just 2 long multiplies and one long multiply accumulate. Ouch...

Re:So it's basically a GBA-era ARM chip without th

[Narishma]

ARM7TDMI is ARMv4.

Re:16 years too late

[jones_supa]

BTW the the spiritual successor Planetary Annihilation is nearing completion. It seems to be shaping quite nicely.

Re:The Core Commander says...

[kesuki]

i loved total annihilation i am ok with supreme commander and am looking forward to planetary annihilation. though i won't pay $90 to have alpha access. especially since the youtube bloggers seem to crash in their demos of the game.

Re:So it's basically a GBA-era ARM chip without th

[dfghjk]

"what gcc will do if you multiply two uint64_t values"

stop doing that then.