Wave Computing Adopts Low Power MIPS 64-bit Multi-Threaded Core
Wave Computing [...] announced today that it has selected a 64-bit Multi-Threaded processor core from MIPS Technologies for future AI solutions. Wave will use the MIPS core in its next generation of Dataflow Processing Unit (DPU) chips that will ship in Wave's future deep learning systems to handle device control functions including management of the real-time operating system (RTOS) and system-on-chip (SoC) subsystem.
As design complexity and software footprints continue to increase, the 64-bit MIPS architecture is being used in an even broader set of datacenter, connected consumer devices, networking products, and emerging AI applications. In addition to Wave, companies including Mobileye, Fungible, ThinCI, and DENSO, among others, are using the MIPS 64-bit processor core as they develop ground-breaking AI applications. [...] Last August, Denso group company NSITEXE, Inc. announced that it licensed the newest MIPS CPU to drive enhanced in-vehicle electronic processing.
Related: MIPS Strikes Back: 64-bit Warrior I6400 Arrives
PEZY's Next Many-Core Chip Will Include a MIPS 64-Bit CPU
ARM Cortex-A35, Snapdragon 820, and New Imagination MIPS Processors
Linux-Based, MIPS-Powered Russian All-in-One PC Launched
Imagination Technologies Acquired for $675 Million, MIPS to be Sold Off
Related Stories
The recently Anandless AnandTech is reporting that Imagination Technologies/MIPS has ARM in their crosshairs.
Based on the 64-bit MIPS64 instruction set (release 6), the Warrior I6400 core is the middle-class CPU core in a family of three, each targeting a different point in the power/performance curve. Imagination is releasing the I6400 core last, which is at the middle of the pack balancing performance with power. Imagination has already released their high-end P56xx series and low-end M51xx series.
Intel's Knights-branded Xeon Phi chips remain the most familiar "many-core" accelerators or coprocessors. However, another name has emerged recently: PEZY, whose 1,024-core chips were used in the top 3 most efficient supercomputers. Tom's Hardware reports that PEZY's next generation of chips will boost the core count to 4,096 and integrate Imagination's 64-bit MIPS Warrior CPU onto a system-on-a-chip:
PEZY Computing, a Japanese firm that makes the top three most efficient supercomputers in the world, according to the Green500 list, announced that it will integrate Imagination's highly efficient 64-bit I6400 CPUs into its many-core architecture.
The PEZY SC-2 will be PEZY's next-generation system, which will increase the 1024 core count of the first generation PEZY SC to 4096 cores, or four times more. PEZY's many-core accelerator has been combined with Intel CPUs from top supercomputers to significantly increase their efficiency for computing tasks. For instance, the Shoubo supercomputer, which uses Haswell XEON CPUs and PEZY SC many-core accelerators, was able to break the world record with 7 GFLOPS/W performance.
In the November edition of Green500, the top 23 supercomputers used a heterogeneous architecture with many-core accelerators. In the updated June edition of this year, that number increased by 40 percent, and now the top 32 supercomputers are using many-core accelerators. These supercomputers all use accelerators from AMD, Intel, Nvidia and PEZY. The current top 3 supercomputers are manufactured by PEZY Computing and Exascaler Inc, and include Haswell or Ivy Bridge Xeons as well as PEZY many-core accelerators.
Presumably the integration of the MIPS CPU could allow relatively power-hungry Intel Xeons to be ditched entirely.
Previously: MIPS Strikes Back: 64-bit Warrior I6400 Arrives
ARM Announces New Cortex-A35 CPU - Ultra-High Efficiency For Wearables & More
... as part of the volley of announcements at ARM's TechCon conference we discover ARM's new low-power application-tier CPU architecture, the Cortex-A35. [...] As such, the A35 is targeted at power targets below ~125mW where the Cortex A7 and A5 are still very commonly used. To give us an idea of what to expect from actual silicon, ARM shared with us a figure of 90mW at 1GHz on a 28nm manufacturing process. Of course the A35 will see a wide range of implementations on different process nodes such as for example 14/16nm or at much higher clock rates above 2GHz, similar to how we've come to see a wide range of process and frequency targets for the A53 today.
Most importantly, the A35 now completes ARM's ARMv8 processor portfolio with designs covering the full range of power and efficiency targets. The A35 can also be used in conjunction with A72/A57/A53 cores in big.LITTLE systems, enabling for some very exotic configurations (A true tri-cluster comes to mind) depending if vendors see justification in implementing such SoCs.
ARM Announces ARMv8-M Instruction Set For Microcontrollers – TrustZone Comes to Cortex-M
Previously only available to ARM-A architecture CPUs, TrustZone is now being extended to ARM based microcontrollers. And like their bigger siblings, ARM's aim here with TrustZone is to lay the groundwork for their customers to build highly secure devices, for all the benefits and drawbacks such a device entails. This includes protecting cryptography engines and certain stored assets (e.g. the secure enclave) against attack, locking down systems to prevent userland applications from breaking into the operating system itself, and various degrees of DRM (one example, as ARM gives is, is firmware IP protection).
Qualcomm Snapdragon 820 Experience: HMP Kryo and Demos
In power, Qualcomm published a slide showing average power consumption using their own internal model for determining days of use. In their testing, it shows that Snapdragon 820 uses 30% less power for the same time of use. Of course, this needs to be taken with appropriate skepticism, but given the use of 14LPP it probably shouldn't be a surprise that Snapdragon 820 improves significantly over past devices. The other disclosures of note were primarily centered on the CPU and modem. On the modem side, Qualcomm is claiming 15% improvement in power efficiency which should eliminate any remaining gap between LTE and WiFi battery life.
Imagination Announces New P6600, M6200, M6250 Warrior CPUs
Starting off with the P6600, this is Imagination's new MIPS flagship core succeeding the P5600. The P5600 was a 3-wide out-of-order design with a pipeline depth of up to 16 stages. The P6600 keeps most of the predecessor's characteristics such as the main architectural features or full hardware virtualization and security through OmniShield, but adds compatibility for MIPS64 64-bit processing on top. Imagination first introduced a mobile oritented 64-bit MIPS CPU back with the I6400 a little more than a year ago but we've yet to see vendors announce products with it.
Liliputing reports
Most modern desktop and notebook computers ship with Intel or AMD processors and Windows or OS X software. A few companies are positioning products with ARM-based chips as desktop computers. But the Tavolga Terminal TB-T22BT(русский [1]) is something different.
This all-in-one desktop PC has a MIPS-based processor and runs Debian 8 Linux software.
The computer is made by Russian company T-Platforms, which also offers an SF-BT1 processor module for those that want to build their own hardware.
Both devices use a Baikal-T1 processor which is a 32-bit dual-core MIPS P5600 processor. Like the computers, the chip was designed in Russia, although it's based on work from Imagination Technologies (the company behind the MIPS architecture).
The all-in-one desktop features a 21.5 inch IPS display, support for up to 8GB of DDR3-1600 memory, and up to 64GB of flash storage. It has four USB 2.0 ports, a PS/2 port, Gigabit Ethernet, and a fanless case for silent operation. There's also support for smart cards.
T-Platforms is positioning the TB-T22BT as a device that can either be used as a standalone computer with support for Linux-based apps such as LibreOffice and Firefox, or as a thin client system that you can use to connect to remote machines using remote desktop software.
[1] The translation dropdown menu did not work. Google translation
Previous: Russia Plans to Dump Some American CPUs for Homegrown Technology
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
Submitted via IRC for takyon
Wave Computing today announced that it has acquired MIPS Tech, Inc. (formerly MIPS Technologies), a global leader in RISC processor Intellectual Property (IP) and licensable CPU cores. The acquisition will accelerate Wave's strategy of offering AI acceleration from the Datacenter to the Edge of Cloud by extending the company's products beyond AI systems to now also include AI-enabled embedded solutions.
[...] For example, Datacenter-centric AI applications today need many weeks to train using coprocessors such as GPUs, only to require a different architecture for inferencing at the Edge. The lack of a common AI platform, from Datacenter to Edge, slows market growth and reduces productivity of data scientists in fields such as autonomously driven vehicles, IoT sensors and more.
[...] "Wave's integration of two industry-leading compute architectures in a single data plane/control plane solution – Dataflow and Von Neumann – will be truly unique and an industry-first. It will fuel new, ground-breaking innovations in AI and other fields."
Source: Wave Computing Acquires MIPS Technologies
Related: Imagination Technologies Acquired for $675 Million, MIPS to be Sold Off
Wave Computing and Others Adopt 64-Bit MIPS Cores
(Score: 3, Interesting) by TheRaven on Thursday March 08 2018, @02:39PM (3 children)
We don't have an ecosystem, so we can't sell anywhere where people have existing software that they expect to work. We don't really understand how to build an ecosystem, so we're not imposing any constraints on customers who want to make incompatible versions of our ISA. This it really attractive to customers that think in the short term and want to benefit from the fact that we kind-of have some half-arsed compiler support and want to ride a wave of hype and sell their company before they have to think about long-term support. MIPS is perfect for these people!
Yes, I am bitter that we chose MIPS as the base ISA for our research processor. Until RISC-V came along, MIPS was the only 64-bit ISA with some vague software support that was old enough to be out of patent. The lack of patents is the main thing that MIPS IV has going for it. MIPSr6 doesn't even have that, nor does it have any existing software.
sudo mod me up
(Score: 4, Informative) by RamiK on Thursday March 08 2018, @05:26PM (1 child)
1. Complete mainlining for RISC-V isn't scheduled to be completed until 4.16/4.17 so it's not so much as short-term as it is time-to-market.
2. Rumor has it Meltdown/Spectre pushed back multiple RISC-V core designs to CAD with generous ETAs scheduled around 3-6month.
3. The MIPS tool-chain is maturely optimized for in-order operations with width flags and the like all in-place and well understood algorithmic choices. RISC-V is going to have multiple in and out-of-order designs of varying width all coming out in a span of a couple of years... Even if ARM's and MIPS's work on the device tree sorted the kernel out (give or take), you're going to have some serious delays in the compilers and libraries as conflicting branches get merged and libraries adjusted. Depending on the project it could spell a lot of grief and time lost.
Mind you, I'm still a strong RISC-V proponent. Just say, there's still a business case for MIPS. Even a research one depending on schedule and focus... No?
compiling...
(Score: 2) by TheRaven on Friday March 09 2018, @10:30AM
We picked MIPS 8 years ago. If RISC-V had been in the state now that it was then, we'd have picked RISC-V. You have two choices with MIPS now: new MIPS (r6) or old MIPS (r2 or earlier). These are different ISAs that are not compatible. ImagTec wibbled a lot about binary translation for old MIPS code to MIPSr6, but never actually shipped a binary translator. If you go MIPSr6 (which were the cores that ImagTec was trying to sell, because those were the ones definitely still in patent) then you lose existing toolchain support.
GCC is a clusterfuck for MIPS, because all of the vendors made their own incompatible extensions and didn't do the compiler work properly (with the exception of Cavium, which has now switched entirely to ARM) and so broke every other MIPS vendor's targets and couldn't upstream things. This means that the state in GCC is pretty bad. Modifying GCC is also just pain. MIPS in LLVM is mediocre. It now works (in part because I've upstreamed a load of fixes), but it generates pretty poor code for a few common patterns and the design of the MIPS ISA makes it difficult to improve. A lot of the ImagTec work was directed at things like MIPS16 / microMIPS, which no one actually cares about, rather than improving performance and correctness.
The entire ecosystem is broken and dying. If you want something that works now, MIPS might be it if you squint, but you're going to be taking on most of the ecosystem maintenance costs yourself because everyone else is migrating their stuff away from MIPS as fast as humanly possible.
Oh, and LLVM's scheduler currently generates much better code for OoO cores, so if you've got an in-order design then it's less than idea. Not sure about GCC, because it's been years since I worked with any companies that cared about it.
sudo mod me up
(Score: 2) by Dr Spin on Thursday March 08 2018, @05:43PM
The lack of patents is the main thing that MIPS IV has going for it.
No it is not HOracle - that is an even bigger plus!
Warning: Opening your mouth may invalidate your brain!
(Score: 3, Interesting) by Snotnose on Thursday March 08 2018, @03:39PM (9 children)
Back around the turn of the century, if a manufacturer wanted to be certified for WinCE they had to pass a Microsoft-written test suite. My job was to get various CPUs to pass this test suite. One of the tests was to ensure the entire 32 bit address space was addressable. MIPs had this hardware quirk where something like 1/4 of their address space was dedicated to I/O. Microsoft had plans in place to get waivers on certain requirements, but I'm guessing I was the first one to try and make use of them. The guy I dealt with clearly didn't want to work with me, thought he was much smarter than me, and flat out didn't want to deal with my emails. Finally got MIPs certified, but man what a pain.
That was a fun job. I got to certify the ARM, MIPS, and SH-4 for WinCE (took 2-3 month each to get the test suite running). Then a few months later I had to actually use WinCE. What a royal pain in the ass that was. WinCE was designed for embedded systems. Embedded systems need hard limits on things like interrupt latency, stack size, etc etc etc. WinCE didn't support any of these. I was trying to play video. It would go great for a minute or so, then start stuttering for no apparent reason. The root cause was WinCE doing it's nails, or whatever. There was no way to avoid it, bigger buffers didn't help because the problem was WinCE's latency issues.
Relationship status: Available for curbside pickup.
(Score: 2) by RamiK on Thursday March 08 2018, @05:44PM (8 children)
FYI Last I checked your typical x86-64 can't address more than 48bit directly or 52bit with PAE.
Just some pointless trivia...
compiling...
(Score: 0) by Anonymous Coward on Thursday March 08 2018, @07:57PM (5 children)
And often underappreciated. Most operating system level code is going to have to be rewritten when that gets expanded out, and given that everything bit 52 and above is used means that there might be userspace code out there that actually DOES either poll or filter those bits, meaning old code may need some major rewrites to work with full 64 bit addressing. Honestly I dislike the fact that they call them 64 bit processors without more clearly defining if they mean 64 bit addressing, or simply 64 bit integer processing.
(Score: 0) by Anonymous Coward on Thursday March 08 2018, @08:02PM (2 children)
Operating systems are ready for full 64-bits since the beginning of amd64 support. There is no reason to implement any type of filtering in "userspace code" since it never does see the underlying physical address (every process has its own virtual address space). I'd suggest you look into how an operating system works in terms of memory management, it might be useful...
(Score: 2) by TheRaven on Friday March 09 2018, @10:34AM (1 child)
sudo mod me up
(Score: 2) by FatPhil on Friday March 09 2018, @02:09PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by shortscreen on Friday March 09 2018, @06:57AM (1 child)
The CPU insists that those unused bits remain zero (rather than just ignoring them like a 68000), so people wouldn't be tempted to put random garbage in there that would only cause problems in the future.
(Score: 2) by TheRaven on Friday March 09 2018, @10:43AM
sudo mod me up
(Score: 0) by Anonymous Coward on Thursday March 08 2018, @07:59PM (1 child)
Pointless and incorrect. There is no PAE for amd64. You're thinking of virtual and physical address spaces. Neither is truly 64-bit wide in any current implementation.
(Score: 0) by Anonymous Coward on Friday March 09 2018, @07:43PM
( Intel® 64 and IA-32 Architectures Software Developer’s Manual [intel.com] Ch. 4.5 IA-32E PAGING )
The tables and diagrams explain what "direct" means here.
(Score: 2) by Subsentient on Friday March 09 2018, @11:04AM
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti