SoylentNews is people
SoylentNews
The company that failed to acquire Lattice Semiconductor will acquire Imagination Technologies instead:
Imagination Technologies Group Plc agreed to be acquired by China-backed private equity firm Canyon Bridge Capital Partners.
Canyon Bridge said it will pay 182 pence a share in cash, or more than 500 million pounds ($675 million), for the U.K. designer of graphics chips. That's 42 percent more than Imagination's closing share price on Friday.
As part of the deal, Imagination will sell its U.S.-based embedded processor unit MIPS to Tallwood MIPS, a company indirectly owned by California-based investment firm Tallwood Venture Capital, Canyon Bridge said.
Canyon Bridge was keen to structure a bid to avoid scrutiny from U.S. regulators, Bloomberg reported earlier this month.
Earlier in September President Donald Trump rejected a takeover by Canyon Bridge of U.S. chipmaker Lattice Semiconductor Corp., just the fourth time in a quarter century that a U.S. president has ordered a foreign sale of an American firm stopped for security reasons.
Also at The Verge, AnandTech, and Financial Times.
Previously:
Related:
- Imagination Technologies Group Up for Sale
- Imagination Technologies will Continue to Make GPUs after Losing its Biggest Customer
(Score: 3, Insightful) by TheRaven on Tuesday September 26 2017, @09:27AM (6 children)
ImagTec tried to compete with ARM in the mobile market. They managed to get less than 1% of the Android market for a huge investment in toolchain, OS, and so on. This cost them a lot for no return and in their last annual statement to shareholders, they admitted that it was a terrible idea and they were giving up. They decided to refocus on the low end embedded market, but there they're squeezed between RISC-V and ARM. The RISC-V ecosystem isn't very strong, but neither is MIPS anymore: OS support is poorly maintained, LLVM support is only just there. GCC support ahas always been a bit flakey because every MIPS vendor forked GCC, added their own incompatible extensions, broke everyone else's, and never upstreamed them. RISC-V is in a similar state but, unlike MIPS, a load of companies are investing in improving the ecosystem. No one really cares about MIPS and the big MIPS vendors like Cavium have moved on to ARMv8. RISC-V cores are going to be a lot cheaper than MIPS at the low end. If you are willing to pay more for a mature and well-supported ecosystem and very low power chip designs, ARM will sell you M-profile cores and a load of good development tools.
At this point MIPS is basically dead, so who thought it was worth $65m? Normally, this kind of acquisition would be from someone who intended to become a patent troll, but before ImagTec bought MIPS a consortium including ARM bought all of the MIPS patents precisely to avoid this kind of thing.
sudo mod me up
(Score: 0) by Anonymous Coward on Tuesday September 26 2017, @10:09AM (5 children)
About four years ago I remember strange things being afoot. About then I started to look for a new job and I got a few calls from recruiters telling me about this wonderful opportunity at Imagination Technologies who were buying MIPS and going to take on ARM. I tried very politely to explain why it wasn't a great idea. Now if only I could do the same for the lottery numbers.
(Score: 3, Insightful) by TheRaven on Tuesday September 26 2017, @11:14AM (4 children)
ImagTec really bungled MIPS. They failed to understand the value of a healthy ecosystem. Most MIPS products in the wild are based on R7K-derrived things - MIPS IV ISA. There are a huge number of these in routers and things, but MIPS IV is now over 20 years old and so out of patent (therefore you don't need a MIPS license, just a license for the IP core, which ImagTec didn't own). ImagTec therefore completely ignored this part of the ecosystem (for example, LLVM support for MIPS IV and III completely sucked until I and a couple of colleagues started upstreaming some of our patches) in favour of MIPS32 and MIPS64 things that were still (possibly) in patent. Because of this, they never managed to convince their natural partners that they had a good migration path from the old and cheap MIPS cores to newer ones.
At the same time, they pushed out MIPSr6, which recycled a bunch of 'deprecated' opcodes for newer instructions. MIPSr6 is actually a pretty reasonable ISA, but unfortunately those 'deprecated' instructions were still generated by GCC (and other compilers) and so there was no way of running old MIPS binaries on new MIPS cores without a hypothetical binary rewriting program that ImagTec never released (and which wouldn't have worked for JITs). You couldn't even do the trap-and-emulate dance, because they reused the opcodes. This basically meant that there was no incremental migration path from MIPS IV to MIPSr6, and if you're going to go to what is effectively a new ISA then you may as well go to ARM (where, at least, you buy into a large and thriving ecosystem for your entrance fee).
To make matters even worse, they didn't release any MIPS64r6 cores and focused entirely on MIPS32r6. There are basically two kinds of customer who buy 32-bit cores now: those for whom price is the primary concern and those for whom power is the primary concern. For the latter, the ImagTec parts couldn't compete with ARM M-profile. For the former, the ImagTec parts couldn't compete with MIPS R7k or ARM7 / ARM11 cores (old, and with a bunch of companies that licensed them for a lot of money for an unlimited-copy license that is now completely paid off, so they cost a few percent above the cost of fabrication).
And, just as they were being squeezed here, RISC-V came along and companies like Micron who use ARM cores in places where they really don't care about the ISA (because it's not public, such as on SSD controllers), don't care much about power consumption (because the core is a tiny proportion of overall power consumption), and really just need a working C compiler started looking at migrating, as did a bunch of companies like nVidia that used an in-house ISA and didn't want to be the only ones maintaining a toolchain.
sudo mod me up
(Score: 0) by Anonymous Coward on Tuesday September 26 2017, @01:24PM (3 children)
Yes, it's amazing in this day and age how many businesses people still don't understand Imaginary Property. It's pretty clear that unless you're one of the major x86 people or ARM you're going to have a very hard job competing unless you have something very special to offer.
The other thing is that Free/Open Source hasn't caught on with many of the hardware people yet in the same way it has with software. I'm a software enthusiast and know very little about hardware (wish I had the time and the brains) but if I did, I'd play with the stuff on opencores.org.
I have a feeling that ARM is going to slowly be overtaken by RISC-V in the way that traditional Unix was by Linux and friends.
(Score: 2) by TheRaven on Tuesday September 26 2017, @01:57PM (2 children)
This might happen, but RISC-V has a delicate balance to strike. The thing that killed MIPS (before ImagTec bought it) was ecosystem fragmentation. ARM has been very careful to reduce the number of incompatible versions. You now basically can't make incompatible ARM cores, even if you have an architecture license, you have to differentiate by other cores on your SoC and by different pipeline designs. In contrast, MIPS let anyone add specialised instructions in the coprocessor space (ARM did early on, but stopped quite a while ago). This meant that every MIPS vendor would fork GCC to add support for their custom instructions and no one upstreamed their forks because they broke everyone else's. Everyone hacked up Linux or FreeBSD to handle their extra register sets and other processor state, often not upstreaming their changes for similar reasons. Running software for vendor X MIPS on vendor Y MIPS involved a significant porting effort.
RISC-V faces a similar fate: everyone is implementing the base specification plus a subset of the standard extensions and soon they're going to start adding non-standard extensions too. This is great for some of the vendors who want something very custom, but it's bad for the ecosystem as a whole. It's difficult to do this in an open source model, because the strength of open source is the lack of a central authority preventing people from doing what they want with the project.
sudo mod me up
(Score: 0) by Anonymous Coward on Tuesday September 26 2017, @02:14PM (1 child)
Would it be possible to implement the base specification plus have some run-time configurable (microcode, FPGA...?) parts to be able to emulate any extensions as required? What about the Transmeta approach? But then you might as well choose a more common instruction set to translate.
(Score: 2) by TheRaven on Wednesday September 27 2017, @10:03AM
Obviously, it's possible (from the Church-Turing Thesis), but if compilers are emitting an instruction because it's fast and on your implementation it goes from being a single-cycle instruction to one that takes 200 cycles then that's not so great. FPGAs don't tend to use the same fabrication techniques as ASICs and don't run at the same clock speed, so that wouldn't be so great. You can always trap-and-emulate instructions, though this gets messy if you have two shared libraries that both want the different extensions. The hardest things to emulate are things like the A extension (emulating atomicity is insanely hard) and things like lowRISC's tagged memory extensions (which add extra semantics to all load and store instructions).
sudo mod me up