feature article
Subscribe Now


Look It Up

Webster’s Dictionary defines “Platformification” as – OK, you got us.  It’s not in Webster’s.  Even Microsoft Word gives us the squiggly red line telling us we’re treading on dangerous ground.  Wikipedia – no better.  We got diverted to some articles about Mario Brothers and other games where characters jump around from platform to platform – not unlike embedded systems designers choosing and then abandoning various combinations of processors, operating system, and peripherals powering their creations.

Intel tried to stick us with the word “Platformization”, and we briefly considered that, but their definition – the combination of several chips into a standardized platform, is too specific.  “Platforming” is apparently a long-recognized method for separating petroleum products during refining, so that one was out as well.  We decided on “Platformification,” and a quick Google search validated our decision.  Our hope, of course, is that Google will list this article among the authorities on Platformification soon enough, with Webster’s and the other Luddites to follow. So, with apologies to both Intel and the English Language – here we go.

Platformification is the polar opposite of “NIH” — the Not Invented Here syndrome.  We’ve all faced NIH in our engineering careers.  Some engineers suffer from acute and seemingly incurable NIH.  At home, if they want bread for a sandwich, they plant their own grain in the back yard, grind it with their own millstone, take yeast from their own culture… you get the idea.  While this purist approach gives the engineer absolute control over the finished product, one has to look at the tradeoffs involved.  Use of a commercially-produced flour would definitely reduce the effort involved in baking the bread.  While the engineer would give up some control, the quality of flour produced by a company that specializes in that operation might also be higher. 

In product design, the make-versus-buy decision is usually shrouded in accounting and finance language – what is the true total cost of building versus buying or licensing from a third party?  Do you account for market window revenue lost if building takes longer than buying? (This factor can easily trump all your engineering-related costs, if you’re not careful.) 

As engineers and marketers of technology products, however, we need to think from a different perspective.  We need to pay particular attention to what value and innovation we bring to the table and how that innovation creates real differentiation in our product.  Technology products, you see, are usually not commodities like flour, where consistency, quality, price, and availability are the driving factors.  Technology thrives on the magic of product differentiation, and that is where we need to laser-focus our engineering efforts. 

In embedded design, we could start each project by engineering a new processor architecture and instruction set.  We might be able to optimize each one for the particular demands our product will place on it, saving some power and area and gaining some performance in the process.  Most of us can agree, however, that project-specific processors would be a bad idea (unless, of course, you’re using some automated technology like, say, Tensilica’s, to automatically generate specialized, optimized processor cores, but that’s not what we’re talking about here.)  We typically grab a processor or core from the people who specialize in those things and spend our energy on parts of the product where we can add more value.

Platformification, then, is the packaging of those “not to be invented here” parts for our ready consumption.  If we want to build our product on an ARM-based platform, for example, we get a lot of stuff done for us for free as part of the platform.  We gain access to IDEs, operating systems that basically plug right in, middleware for many common peripherals and interfaces… — the list of stuff we don’t have to invent is staggering.  Platformification is hierarchical, too.  Inside your ARM-based platform are other components that are similarly packaged.  Somebody has developed a key technology, realized that it has broad applicability to a number of products, and decided to bundle it all up so we can buy it.  Other developers wrap that platform inside a platform of their own and sell us the result.

While we’re accustomed to the Platformification (can we stop capitalizing it yet?) of things like processor architectures and operating systems, a number of other key system components are becoming platforms as well.  Interconnect standards like PCI (particularly the “express” flavor), USB (and the 2.0 version), and all the rounds of Ethernet from 10 to bazillion-base-T have long been packaged as platforms, and we’d do well to take advantage of it.  It’s a rare product that will blow away the competition because it has a REALLY COOL implementation of the Ethernet interface.  No matter how clever your design may be, it just isn’t going to happen. 

More recently, user interface components are falling into platforms as well.  If you’re using a touch screen, a standard LCD display, a keyboard, a microphone, a speaker… – you’re really not going to make your product stand out from the pack by one-upping the off-the-shelf options already on the market.  You’ll save time and get done faster (leaving the marketing people more window weeks to milk money from the masses) using a platform than designing your own.  The only exceptions are if you have a truly innovative user interface technology that sets your product apart, but even these ideas – voice recognition, advanced image processing and the like, are starting to be available as pre-packaged platforms for your ready adoption.

So, should we all just give up and go home?  We could readily relegate the process of picking and combining platformified hardware components to our twelve-year-olds and forget all that engineering school.  As more capable and optimized platforms become available for just about every component of our system, how will we differentiate ours from the pack?  Will industrial designers take over technology’s reins as the metal-flake paint job becomes the big item that attracts buyers?

Certainly for awhile it has seemed that the answer is “software.”  While the hardware side of embedded technology continues to become more and more generic, the complexity of the application layer leaves enormous opportunity for product differentiation.  Even though the underpinnings like operating systems and middleware have rolled into the off-the-shelf domain, the applications layer remains a defensible fortress.  Consumers are already making the mental adjustment to comparing the user experience of various products based on the contribution of the software, even if they’re not aware that software is what they’re comparing.

Innovation in hardware is by no means dead, either, however.  It’s just that, as a trend, we’ll see more of that innovation poured into re-usable, multi-application platforms rather than individual products.  This makes sense, if you think about it.  If you have a world-changing idea for a hardware innovation, why relegate it to a single product when it could potentially be licensed across a vast array of products in different industries – all sharing the same standard platform as a building block.  The return on technological investment is potentially much greater. 

Platformification does mean a slow evolution of our careers as electronics engineers, though.  If you’re doing low-level engineering on components that are becoming available as standard platforms, you need to either raise your personal level of abstraction and expertise or find a new job at one of the companies producing the platform.  Otherwise, you’ll witness firsthand the ugly side of platformification.  As engineers, we need to always be aware of our personal value-added and not let platformification sneak up on us so that we outlive our usefulness.  Otherwise, we won’t see “platformification” as a happy word  — like “productivity tools” or “design re-use” — that makes our jobs easier.  We’d be more likely to see it more in the category with words like “redeployment” or “downsizing” – not the best friends of the average engineer.

9 thoughts on “Platformification”

  1. Pingback: Bdsm
  2. Pingback: best seedbox
  3. Pingback: gvk biosciences
  4. Pingback: juegos friv
  5. Pingback: TS Escorts
  6. Pingback: Aws alkhazrajii

Leave a Reply

featured blogs
Apr 9, 2021
You probably already know what ISO 26262 is. If you don't, then you can find out in several previous posts: "The Safest Train Is One that Never Leaves the Station" History of ISO 26262... [[ Click on the title to access the full blog on the Cadence Community s...
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

Selecting the Right MOSFET: BLDC Motor Control in Battery Applications

Sponsored by Mouser Electronics and Nexperia

An increasing number of applications today rely on brushless motors, and that means we need smooth, efficient motor control. Choosing the right MOSFET can have a significant impact on the performance of your design. In this episode of Chalk Talk, Amelia Dalton chats with Tom Wolf of Nexperia about MOSFET requirements for brushless motor control, and how to chooser the right MOSFET for your design.

More information about Nexperia PSMN N-Channel MOSFETs