Thanks for the feedback. I specifically used the words "fun" and "fact" in the second paragraph since I was trying to mix the two.
I can see that it wasn't to everyone's liking, I'll try to keep it more dry and factual next time.
If your definition of PCs includes tablets, wearables and home entertainment boxes, then MIPS has a visible presence there too. MIPS enjoys a large market share in home entertainment for example; we're starting to make headway into mobile and wearables too.
But for me PCs are desktop computers.
Here is an entry from the NetBSD official blog on their progress for Creator Ci20 (the same board used for the Fedora port).
It looks like there has been some good progress made already.
There are multiple SBCs you can buy that use MIPS; chipKITs using PIC32 MCUs from Microchip are one example but there are also tons of boards using Qualcomm Atheros or MediaTek Ralink silicon that run OpenWrt. A quick search on Linux Gizmos reveals at least half a dozen MIPS-based boards were launched just in the last year.
We are not aiming for PCs and servers at the moment, our target markets are mobile and embedded devices (phones, tablets, wearables, IoT, networking, home entertainment, automotive, etc.). In that space, MIPS has an advantage and quite an important ecosystem built over the last decades. And MIPS shipments are growing; for example, this year we saw a 9% increase over the previous one.
There are a few publicly announced SoCs using MIPS Warrior CPUs: Baikal-T1 (networking), Altair FourGee-1150/1160 (4G modems) and Mobileye EyeQ4 (ADAS). More recent Cavium OCTEON III and Broadcom XLP II SoCs are also based on the same Release 5 architecture used to build the Warrior family. Regarding Creator, Ci20 was the first board we built using the silicon we had available at the time. But we plan to expand it to include more feature-rich members.
Great question (I get asked about this a lot). Here are a few points:
(1) Hardware multi-threading support: MIPS offers SMT support for the latest Warrior CPUs; for a slight increase in area (~10%), you can scale up the number of hardware threads (1, 2, 4) and get a 40-50% boost in performance. ARM CPUs do not support SMT and can only scale in number of cores.
(2) Better hardware virtualization support: MIPS Warrior CPUs support hardware virtualization at the low end (e.g. microcontrollers) as well as the high end (application processors). ARM CPUs support hardware virtualization only at the high end. Moreover, MIPS CPUs support multiple trusted execution environments (up to 7 in MCUs, up to 31 at the high end) while ARM CPUs have only one TEE.
(3) Better raw DSP performance: MIPS Warrior CPUs offer superior DSP performance vs. equivalent ARM CPUs (e.g. up to 2.5x better DSP performance in MCUs)
(4) Better performance efficiency: MIPS CPUs offer equivalent performance but at smaller area/power consumption over equivalent ARM cores (e.g. up to 30% area savings at the cluster level and 40% savings at the core level relative to similar performance competition)
(5) More mature 64-bit ecosystem in networking and embedded: MIPS 64-bit CPUs have a rich history in high-performance enterprise networking (examples include Broadcom XLP and Cavium OCTEON processors); there is a whole ecosystem formed around OpenWrt on MIPS for example.
Cool, thanks for the feedback. I will try to mention which architecture each CPU implements in the future so that it's clear for everyone.
Regarding the ISA changes, let me explain further. For the cases you've mentioned we offer a software/hardware compatibility strategy which includes trap-and-emulate, trap-and-patch, and binary translation. To this end, although you are correct that some legacy instructions have been deprecated, binaries should still run because of this three pronged approach.
Have a look at http://www.imgtec.com/mips/arc... and please use our forums for any questions since the guys there are quite good at replying.
Somehow you have the impression that MIPSfpga is Release 6 - it is not. MIPSfpga is a simplified version of microAptiv, the same CPU that is inside the Microchip PIC32MZ family of MCUs. microAptiv is based on Release 3.
Regarding breaking compatibility, that is also not (exactly) the case. Although you are correct that the ISA has been updated in Release 6, the instructions that have been removed are really old and not used by existing software. Even so, we still have trap and emulate mechanisms that ensure we do not break compatibility.
This is NOT a response to RISC-V; there are many good RISC architectures out there designed for academic purposes (and beyond) and RISC-V is definitely one of them.
What this is: we wanted to give professors teaching the MIPS architecture access to real RTL.
Please understand that this is in no way trolling or any for of patent gathering/expansion.
The reality behind this program was that teachers needed more resources for their coursework. We reached out to a few universities and everyone was very excited about using real RTL in their courses; for example, most computer architecture courses presenting RISC CPUs have a section on the load/store unit - once presenting the theory, being able to then point to the Verilog code and say "and here is how this is implemented in a MIPS32 CPU" is extremely valuable for students. Then students will go in the lab and use FPGAs to boot Linux and write C or assembly code.
This is what will happen in the classroom. Theoretical "what ifs" don't really apply here since we are absolutely working with universities to support them - and not against them. That was never our intention and never will be.
Coming back to your point, we expect universities to respect our agreement when they sign up to the program (which essentially says they can't go into silicon production and can't patent changes to our code unless they talk to us first). If they find this agreement too restrictive, we will try to adapt the terms but so far absolutely everyone has been very supportive and positive about this.
I think you are painting an incomplete picture of what we have done here. Absolutely every university we've talked to has embraced this agreement with open arms. This package is mainly designed for students who are learning about computer architecture at the undergraduate/graduate level and who need lab support material for the course. Giving them access to the open RTL which they can study during their labs is in no way enslaving them to anything - they will be getting a chance to see how a CPU architecture used in millions of devices is being implemented using Verilog.
It is not a lure, the terms of the agreement are clear: 1) you are not allowed to put into silicon and 2) you must consult with Imagination before you change it. Most universities teach courses based on MIPS CPUs so having access to the real RTL code was something they were very excited about - this is relevant in the quotes from many well-known professors.
http://www.imgtec.com/news/det...
If these highly respected professors thought this was a lure and unethical, they would not have signed up for the programme.
The reality is we've consulted with tens of universities and this is what they wanted (i.e. full access to the RTL) so we were able to give it after many months of hard work from our engineering team.
FPGAs are usually used for prototyping although they have been used recently in application-specific cases (e.g. OpenCL acceleration for automotive or networking).
Basically, FPGAs are programmable logic arrays which are re-arranged logically according to the hardware description language used (e.g. Verilog). Every time you change the RTL code, you have to go through a flow: translate (merges the incoming netlists and parameter constraints into a design file), map (fits the design into the available resources on the target device, and optionally, places the design), place and route (places and routes the design to the timing constraints), generate programming file (creates a bitstream file that can be downloaded to the device),
When you have the bitstream file, you download it to the FPGA.
We're not going to do 32-bit cores only, we have 64-bit 'Warrior' CPUs in the pipeline too. 64-bit CPUs have area and power implications that are too complicated to go into detail here; for affordable mobile devices and microservers, 32-bit MIPS + XPA + EVA should be more than enough.
Regards,
Alex.
Slashdot Mirror
Thanks for the feedback. I specifically used the words "fun" and "fact" in the second paragraph since I was trying to mix the two. I can see that it wasn't to everyone's liking, I'll try to keep it more dry and factual next time.
I am the author of the article, the submitter and the person who is replying to your comment. I guess comedy is not my strong suit?
We we learnt us some good English too while we were at it?
Yeah, we kinda did. http://grammarist.com/spelling... Regards, Alex.
Here's a quick demo we've written for SIGGRAPH that compares Vulkan and OpenGL ES performance for Android on a prototype driver.
If your definition of PCs includes tablets, wearables and home entertainment boxes, then MIPS has a visible presence there too. MIPS enjoys a large market share in home entertainment for example; we're starting to make headway into mobile and wearables too. But for me PCs are desktop computers.
Here is an entry from the NetBSD official blog on their progress for Creator Ci20 (the same board used for the Fedora port). It looks like there has been some good progress made already.
There are multiple SBCs you can buy that use MIPS; chipKITs using PIC32 MCUs from Microchip are one example but there are also tons of boards using Qualcomm Atheros or MediaTek Ralink silicon that run OpenWrt. A quick search on Linux Gizmos reveals at least half a dozen MIPS-based boards were launched just in the last year.
We are not aiming for PCs and servers at the moment, our target markets are mobile and embedded devices (phones, tablets, wearables, IoT, networking, home entertainment, automotive, etc.). In that space, MIPS has an advantage and quite an important ecosystem built over the last decades. And MIPS shipments are growing; for example, this year we saw a 9% increase over the previous one.
There are a few publicly announced SoCs using MIPS Warrior CPUs: Baikal-T1 (networking), Altair FourGee-1150/1160 (4G modems) and Mobileye EyeQ4 (ADAS). More recent Cavium OCTEON III and Broadcom XLP II SoCs are also based on the same Release 5 architecture used to build the Warrior family. Regarding Creator, Ci20 was the first board we built using the silicon we had available at the time. But we plan to expand it to include more feature-rich members.
Great question (I get asked about this a lot). Here are a few points:
(1) Hardware multi-threading support: MIPS offers SMT support for the latest Warrior CPUs; for a slight increase in area (~10%), you can scale up the number of hardware threads (1, 2, 4) and get a 40-50% boost in performance. ARM CPUs do not support SMT and can only scale in number of cores.
(2) Better hardware virtualization support: MIPS Warrior CPUs support hardware virtualization at the low end (e.g. microcontrollers) as well as the high end (application processors). ARM CPUs support hardware virtualization only at the high end. Moreover, MIPS CPUs support multiple trusted execution environments (up to 7 in MCUs, up to 31 at the high end) while ARM CPUs have only one TEE.
(3) Better raw DSP performance: MIPS Warrior CPUs offer superior DSP performance vs. equivalent ARM CPUs (e.g. up to 2.5x better DSP performance in MCUs)
(4) Better performance efficiency: MIPS CPUs offer equivalent performance but at smaller area/power consumption over equivalent ARM cores (e.g. up to 30% area savings at the cluster level and 40% savings at the core level relative to similar performance competition)
(5) More mature 64-bit ecosystem in networking and embedded: MIPS 64-bit CPUs have a rich history in high-performance enterprise networking (examples include Broadcom XLP and Cavium OCTEON processors); there is a whole ecosystem formed around OpenWrt on MIPS for example.
Actually, a lot of them are Wi-Fi and networking chips that run Linux (mostly OpenWrt, Debian, etc.).
About 800 million devices using a MIPS CPU shipped in the last 12 months.
Cool, thanks for the feedback. I will try to mention which architecture each CPU implements in the future so that it's clear for everyone. Regarding the ISA changes, let me explain further. For the cases you've mentioned we offer a software/hardware compatibility strategy which includes trap-and-emulate, trap-and-patch, and binary translation. To this end, although you are correct that some legacy instructions have been deprecated, binaries should still run because of this three pronged approach. Have a look at http://www.imgtec.com/mips/arc... and please use our forums for any questions since the guys there are quite good at replying.
Somehow you have the impression that MIPSfpga is Release 6 - it is not. MIPSfpga is a simplified version of microAptiv, the same CPU that is inside the Microchip PIC32MZ family of MCUs. microAptiv is based on Release 3. Regarding breaking compatibility, that is also not (exactly) the case. Although you are correct that the ISA has been updated in Release 6, the instructions that have been removed are really old and not used by existing software. Even so, we still have trap and emulate mechanisms that ensure we do not break compatibility.
This is NOT a response to RISC-V; there are many good RISC architectures out there designed for academic purposes (and beyond) and RISC-V is definitely one of them. What this is: we wanted to give professors teaching the MIPS architecture access to real RTL.
Please understand that this is in no way trolling or any for of patent gathering/expansion. The reality behind this program was that teachers needed more resources for their coursework. We reached out to a few universities and everyone was very excited about using real RTL in their courses; for example, most computer architecture courses presenting RISC CPUs have a section on the load/store unit - once presenting the theory, being able to then point to the Verilog code and say "and here is how this is implemented in a MIPS32 CPU" is extremely valuable for students. Then students will go in the lab and use FPGAs to boot Linux and write C or assembly code. This is what will happen in the classroom. Theoretical "what ifs" don't really apply here since we are absolutely working with universities to support them - and not against them. That was never our intention and never will be. Coming back to your point, we expect universities to respect our agreement when they sign up to the program (which essentially says they can't go into silicon production and can't patent changes to our code unless they talk to us first). If they find this agreement too restrictive, we will try to adapt the terms but so far absolutely everyone has been very supportive and positive about this.
I think you are painting an incomplete picture of what we have done here. Absolutely every university we've talked to has embraced this agreement with open arms. This package is mainly designed for students who are learning about computer architecture at the undergraduate/graduate level and who need lab support material for the course. Giving them access to the open RTL which they can study during their labs is in no way enslaving them to anything - they will be getting a chance to see how a CPU architecture used in millions of devices is being implemented using Verilog.
It is not a lure, the terms of the agreement are clear: 1) you are not allowed to put into silicon and 2) you must consult with Imagination before you change it. Most universities teach courses based on MIPS CPUs so having access to the real RTL code was something they were very excited about - this is relevant in the quotes from many well-known professors. http://www.imgtec.com/news/det... If these highly respected professors thought this was a lure and unethical, they would not have signed up for the programme. The reality is we've consulted with tens of universities and this is what they wanted (i.e. full access to the RTL) so we were able to give it after many months of hard work from our engineering team.
FPGAs are usually used for prototyping although they have been used recently in application-specific cases (e.g. OpenCL acceleration for automotive or networking). Basically, FPGAs are programmable logic arrays which are re-arranged logically according to the hardware description language used (e.g. Verilog). Every time you change the RTL code, you have to go through a flow: translate (merges the incoming netlists and parameter constraints into a design file), map (fits the design into the available resources on the target device, and optionally, places the design), place and route (places and routes the design to the timing constraints), generate programming file (creates a bitstream file that can be downloaded to the device), When you have the bitstream file, you download it to the FPGA.
We're not going to do 32-bit cores only, we have 64-bit 'Warrior' CPUs in the pipeline too. 64-bit CPUs have area and power implications that are too complicated to go into detail here; for affordable mobile devices and microservers, 32-bit MIPS + XPA + EVA should be more than enough. Regards, Alex.