feature article
Subscribe Now

Prpl With Envy

Foundation Aims to Prevent MIPS Fragmentation

If a microprocessor is nothing but a machine that executes software, then it’s probably important to make sure that all of the machines are compatible with all of the software. That’s a lot harder than it sounds.

Some CPU families have a long and storied history of binary compatibility. Intel’s x86 architecture comes to mind, because of its slavish devotion to binary compatibility dating back to the 1970s. Love it or hate it, at least you know that every x86 processor ever made will run any x86 program ever written. It’s a huge burden to bear, lugging all of that ‘70s-era baggage around, but it’s also one of the architecture’s greatest strengths.

At the other extreme, you have DIY processor architectures that can be customized like LEGO blocks. ARC, Tensilica, and others let advanced users add, remove, or define their own instructions. Without too much trouble, you can create a CPU instruction set that’s unique to your application. It won’t run a lick of third-party code, but not everybody cares about that. Indeed, some developers deliberately define oddball instruction sets so they can thwart a competitor’s code disassembly and reverse engineering.

Most processors lie somewhere in the middle: more or less compatible with their forebears, but not obsessively so. Freescale tweaked its venerable 68K family to produce ColdFire. ARM replaced Thumb with Thumb2, sacrificing compatibility in the process. MIPS, Power, and other architectures have all “streamlined” their ISA at some point, usually to jettison unused instructions that were slowing down the pipeline, or to make room for new instructions that handle media- or signal-processing. Sometimes both.

The unwritten assumption in all this is that the software community follows along. If the CPU vendor wakes up one morning and decides to perform surgery on its own opcode map, it’s a good bet that the company has cleared this in advance with most of the compiler writers, operating system vendors, and third-party codesmiths. Otherwise – surprise! –you’ve got a compatibility nightmare on your hands.

This gets especially tricky when the CPU instruction set is, shall we say, not tightly controlled. In x86 land, the ISA is controlled by Intel (and, in a few cases, AMD). In ARM’s world, the boffins in Cambridge write the ISA bible. IBM more or less controls everything about the Power instruction set, although there were some vendor-specific variations a few years ago that complicated things. And MIPS? Well, MIPS has taken a hands-off attitude toward ISA fragmentation.

Back in the days when MIPS and ARM were competing neck-and-neck for design wins, MIPS differentiated itself by (among other things) allowing its licensees to create their own hardware accelerators and define their own software instructions. The idea was to allow clever people do clever things, even if they didn’t work at MIPS. ARM, on the other hand (ahem), maintained iron-fisted control over the ISA, so that every ARM chip had exactly the same repertoire as every other. The net result was that all ARM chips run all ARM code, but not all MIPS chips can make the same claim.

Where does this leave us? With a weakened MIPS ecosystem that doesn’t have quite the impact that it could. The minor MIPS fragmentation makes third-party code a dicey prospect. And since MIPS, like ARM, is licensed as IP that’s rolled into a larger SoC device, the inevitable hardware incompatibilities don’t make things any easier.

Enter the Prpl Foundation. This oddly named group of MIPS aficionados works to unify and rationalize the MIPS software ecosystem. They want to make sure that MIPS-based code and development tools don’t fork off in strange directions. They’re not interested in defining the MIPS architecture itself – that’s Imagination Technologies’ job – only in guiding its ecosystem.

Chief among Prpl’s projects are QEMU and PrplWrt. (Prpl Foundation evidently has nothing against vowels. Just fully spelled-out words.) For those not familiar, OpenWrt is a stripped-down version of Linux intended for small-scale networking devices. The idea is to squeeze it into a small memory footprint by leaving off any Linux features not absolutely necessary for a modem or small router. (Why the name OpenWrt? Because the first version ran on the ubiquitous black-and-blue LinkSys WRT54G wireless router.) PrplWrt is obviously a Prpl-flavored OpenWrt.

QEMU is a processor-to-processor emulator. That is, it allows you to run code compiled for one CPU on a different CPU. Like running ARM code on a MIPS processor, for instance. QEMU is open-source code that has proven very popular with developers who want to port their old code to a new chip family, and it’s particularly useful for less-popular architectures that don’t have as much third-party code lying around. If x86 code is plentiful, say, but MIPS-based equivalents are hard to find, QEMU can get you up and running pretty quickly.

Prpl Foundation has no full-time employees. Like a lot of industry consortia, it’s staffed by volunteers from interested corporations. In Prpl’s case, the headcount comes from Broadcom, Qualcomm, Cavium, and other MIPS-related businesses. They all cooperate for their mutual benefit, guiding the development ecosystem and interface standards where they want them to go.

Prpl operates a lot like the Open Power Foundation, which we covered in July. Neither group concerns itself with chip design or CPU architecture, just with everything that happens downstream from that. Both aim to avoid fragmentation. Both labor to help their chosen CPU family.

Interestingly, Prpl Foundation describes itself as CPU-independent, which would seem to be completely at odds with the group’s stated goal. How can a group of MIPS boosters not be, well, MIPS boosters? Amit Rohatgi, the foundation’s president, explains that the group works to define standards and interfaces that could be applicable to any CPU architecture, not just MIPS. If other groups adopt the same standards, so much the better. A natural side effect of avoiding fragmentation is… avoiding fragmentation. There’s no reason their community can’t encompass immigrants, too.

Oh, and as for the name? Purple is the color of Imagination Technologies’ logo. And spelling it funny makes it unique and Internet-searchable. You see? These guys have the business savvy to go with their technical smarts. 

Leave a Reply

featured blogs
Apr 11, 2021
https://youtu.be/D29rGqkkf80 Made in "Hawaii" (camera Ziyue Zhang) Monday: Dynamic Duo 2: The Sequel Tuesday: Gall's Law and Big Ball of Mud Wednesday: Benedict Evans on Tech in 2021... [[ Click on the title to access the full blog on the Cadence Community sit...
Apr 8, 2021
We all know the widespread havoc that Covid-19 wreaked in 2020. While the electronics industry in general, and connectors in particular, took an initial hit, the industry rebounded in the second half of 2020 and is rolling into 2021. Travel came to an almost stand-still in 20...
Apr 7, 2021
We explore how EDA tools enable hyper-convergent IC designs, supporting the PPA and yield targets required by advanced 3DICs and SoCs used in AI and HPC. The post Why Hyper-Convergent Chip Designs Call for a New Approach to Circuit Simulation appeared first on From Silicon T...
Apr 5, 2021
Back in November 2019, just a few short months before we all began an enforced… The post Collaboration and innovation thrive on diversity appeared first on Design with Calibre....

featured video

Meeting Cloud Data Bandwidth Requirements with HPC IP

Sponsored by Synopsys

As people continue to work remotely, demands on cloud data centers have never been higher. Chip designers for high-performance computing (HPC) SoCs are looking to new and innovative IP to meet their bandwidth, capacity, and security needs.

Click here for more information

featured paper

Understanding Functional Safety FIT Base Failure Rate Estimates per IEC 62380 and SN 29500

Sponsored by Texas Instruments

Functional safety standards such as IEC 61508 and ISO 26262 require semiconductor device manufacturers to address both systematic and random hardware failures. Base failure rates (BFR) quantify the intrinsic reliability of the semiconductor component while operating under normal environmental conditions. Download our white paper which focuses on two widely accepted techniques to estimate the BFR for semiconductor components; estimates per IEC Technical Report 62380 and SN 29500 respectively.

Click here to download the whitepaper

Featured Chalk Talk

Bulk Acoustic Wave (BAW) Technology

Sponsored by Mouser Electronics and Texas Instruments

In industrial applications, crystals are not ideal for generating clock signal timing. They take up valuable PCB real-estate, and aren’t stable in harsh thermal and vibration environments. In this episode of Chalk Talk, Amelia Dalton chats with Nick Smith from Texas Instruments about bulk acoustic wave (BAW) technology that offers an attractive alternative to crystals.

More information about Texas Instruments Bulk Acoustic Wave (BAW) Technology