editor's blog
Subscribe Now

A Software View of Hardware

One of the defining characteristics of an embedded system is that you should have no expectations about what it’s made of or how it’s arranged. There are no architecture standards, and that’s how everyone likes it.

Well, ok; not everyone: the poor dudes writing tools for embedded systems have a heck of a challenge dealing with all the variety. And, frankly, some of those tools come full circle and help architects decide how to optimize their systems. But if each variant takes a major project to configure the tools, then that’s not going to work.

Of course, we could try and standardize hardware architectures…

Yeah, good luck getting that one to go anywhere.

Instead, there’s a middle ground being explored by the Multicore Association: it’s called SHIM, which stands for Software-Hardware Interface for Multi-many-core. The idea is to give software tools a way to discover the hardware configuration via an XML file.

This is one of those projects where “restraint” is the name of the game. It would be really easy for something like this to get out of control and far exceed its scope, but the folks driving this – in particular Masaki Gondo of eSOL – are taking great pains to define what this is and isn’t.

For instance, it’s not a complete hardware description of everything in the system. It’s restricted to documenting hardware that matters to software, and it describes the hardware in a manner that makes sense to software (unlike IP-XACT, which is intended for hardware designers). Things like defining the type and number of processor cores, synchronization mechanisms, inter-core communications, memory architecture, interconnect, and virtualization scheme.

They also take pains to ensure that this is not a functional hardware model – you’re not going to plug it into some simulator and have it work. It’s just a description. It’s also not a tool in and of itself; it’s a format for data that can be consumed by tools that others create. So there’s really no threat to anyone in the ecosystem.

It’s partly intended to allow performance estimation of a given architecture, but it won’t be 100% cycle-accurate. It will help with the creation of – but will not auto-create – hardware abstraction layers.

The specific news here is that a working group is starting up to define the details; the first spec should be out sometime next year. You can find more info on the effort and how to participate in their release.

Leave a Reply

featured blogs
Jan 21, 2022
Here are a few teasers for what you'll find in this week's round-up of CFD news and notes. How AI can be trained to identify more objects than are in its learning dataset. Will GPUs really... [[ Click on the title to access the full blog on the Cadence Community si...
Jan 20, 2022
High performance computing continues to expand & evolve; our team shares their 2022 HPC predictions including new HPC applications and processor architectures. The post The Future of High-Performance Computing (HPC): Key Predictions for 2022 appeared first on From Silico...
Jan 20, 2022
As Josh Wardle famously said about his creation: "It's not trying to do anything shady with your data or your eyeballs ... It's just a game that's fun.'...

featured video

Synopsys & Samtec: Successful 112G PAM-4 System Interoperability

Sponsored by Synopsys

This Supercomputing Conference demo shows a seamless interoperability between Synopsys' DesignWare 112G Ethernet PHY IP and Samtec's NovaRay IO and cable assembly. The demo shows excellent performance, BER at 1e-08 and total insertion loss of 37dB. Synopsys and Samtec are enabling the industry with a complete 112G PAM-4 system, which is essential for high-performance computing.

Click here for more information about DesignWare Ethernet IP Solutions

featured paper

MAX22005 Universal Analog Input Enables Flexible Industrial Control Systems

Sponsored by Analog Devices

This application note provides information to help system engineers develop extremely precise, highly configurable, multi-channel industrial analog input front-ends by utilizing the MAX22005.

Click here to read more

featured chalk talk

ROHM Automotive LED Driver IC

Sponsored by Mouser Electronics and ROHM Semiconductor

There has been a lot of innovation in the world of automotive designs over the last several years and this innovation also includes the LED lights at the rear of our vehicles. In this episode of Chalk Talk, Amelia Dalton chats with Nick Ikuta from ROHM Semiconductor about ROHM’s automotive LED driver ICs. They take a closer look at why their four channel outputs, energy sharing function, and integrated protection functions make these new driver ICs a great solution for rear lamp design.

Click here for more information about ROHM Semiconductor Automotive Lighting Solutions