The Hardware/Software Interface, or "HSI" for short, is a term used to describe both the configuration and the functionality of SoC peripherals and how they interact with CPUs.

The sheer volume of different factors here - from register bits to access types, properties and the functionality they control - can be absolutely staggering in a modern SoC. If you have a 32 bit address bus, for example, you can access 2^32 memory mapped registers. If each of those registers are themselves 32 bits wide, the total number of register bits becomes (32 * 2^32) or 2^37, or 137,438,953,472!

But what if the address bus is 64 bits? What if there are multi-CPU cores in the SoC? Clearly to say that the typical SoC architecture is complicated is a bit of an understatement.

Undeniably, current industry trends will only lead to more advanced SoCs with an increasing number of peripherals for more functionality than ever before. In order to make sense of it all, much less manage it, it's going to require us to totally re-think the Hardware/Software Interface. This is true both in terms of how far we've come... and where we're headed.

The Hardware/Software Interface as it Exists Today

At any given moment, you've got a wide range of different elements that you're dealing with. Multiple processors, including specially designed ones. Surrounding them are a huge number of programmable peripherals. Everything comes together via the network on chip interconnect. The list goes on and on.

Within the context of the modern-day CPU, the HSI and the Instruction Set Architecture (ISA) are essentially the exact same thing. It's the layer at which the software "talks" to the hardware. The CPU could be ARM, RISC-V - it doesn't actually matter because the process stays the same. You write a C or C++ program for your desired goals, you compile it and then place onto the CPU. That's how you interact with both the registers and the external busses, along with the I/O.

In terms of the actual SoC, you also have to deal with the interconnect fabric, which is what connects your CPU to the various programmable slaves. These slaves could have their own memory or could even be a bridge to a slower bus depending on the unique situation you're talking about. The slaves are programed by reading and writing to the embedded registers. When you look at things from this type of a macro perspective, the registers and the interrupt are the IPs (or slaves) HSI.

While this has worked well until now, it's also difficult to argue with the fact that it brings some significant challenges to any project. In a recent study that took a closer look at the root causes of functional flaws in chips, design error was the key contributor. Changes in specification and incorrect or incomplete specification were also accounted for. All of these problems are as severe as they are common, and all of them have the same thing in common: over 50 percent of issues that fall into any one of those three categories tie directly back into the HSI layer.

Take registers, for example. You always have to remember that you're dealing with a wide range of different types. Indirect, UART, shadow, lock, interrupt, FIFO and paged are all just a few of the many examples. Complex registers like indirect registers and trigger buffer registers all present their own potential complications, as do register groups or arrays of groups, which are obviously very different.

Based on that alone, it should be easy to see why more than half of all issues can be tied directly back to the Hardware/Software Interface. Equally complicating things is the fact that oftentimes companies have their own unique SoC specific challenges and requirements.

It's easy to take a pessimistic approach to this news and see it as something to be feared. Thankfully, it's also something to be celebrated. It means that if you take the time to fix the HSI layer, you also fix the lion's share of the root causes of functional flaws in chips that shouldn't even be there in the first place.

The Flexible, Innovative Future You Need

When you think about all of the various consumers of HSI information, the list is likely a lot longer than people realize. In addition to factors like device drivers, firmware and hardware verification, you also need to think about technical documentation, diagnostics, application software, hardware design and more. One change to the underlying specification necessitates a major shift in all of these areas, which is why it's so important to find a solution that allows those changes to automatically permeate out to all of the associated views.

Agnisys' own IDesignSpec (IDS) is just one of the many, many examples of advancements that are making significant progress in terms of addressing all of these issues moving forward. These types of solutions are typically compatible with a wide range of different outputs depending on your needs, including but not limited to ones like Verilog/VHDL, the C Model, UVM and more. They're often available in everything from batch (think: the command line) to Word and Excel to even open sourced options like Open Office.

It's now possible to generate a single, UVM-based register model that covers ALL verification elements like covergroups, coverpoints, coverbins, illegal bins and more - freeing up valuable time for your actual human employees to focus on bigger and more important things.

Finally, one can use a single tool to create test sequences and environments, to create formal properties and assertions, to create UVM sequences and firmware routines from the specification and to help bring about cross-platform HSI layer specification that serves all parties equally in a way that should have been present all along. Agnisys has a recorded webinar on how to specify and improve productivity when working within the HSI if you’d like to learn more.

This all goes above and beyond simple automation. It represents a major step toward the next evolution of hardware and software as concepts.

Again, it doesn't matter which tool in particular you're talking about. The next generation of Hardware/Software Interface solutions have very much arrived and not only do they help solve the vast majority of the challenges that were present in the "old school" way of doing things, but they also present a number of major implications for nearly every industry you can think of that are far too powerful to ignore.

Functional Safety

One of the many areas in which the HSI plays an important role has to do with functional safety and the ISO 26262 standard. Automotive engineers, for example, need to ensure that there is no single point of failure in their design and they adhere to this standard for ECC - CRC and parity, or other techniques like triple module redundancy (or TMR).

The HSI has also been historically important to certain applications for the purposes of security. You see a lot of instances where the memory map is locked with a key sequence where one has to write a series of writes to a certain address with certain values in order to get the state machine to go through the processes necessary to unlock the entire memory map.

Finally, we have the medical field - an area where the Hardware/Software Interface is important because complying with certain requirements is mission critical. Additionally, they also all put their own unique requirements on the HSI layer itself, having an impact on how you implement certain factors and what things are going to look like in the future.

Unfortunately, as important as the HSI is in theory, in execution it is very much in a stasis in the worst possible way. It's just as essential as it ever was, but certain challenges are present that are absolutely holding back innovation, not propelling it forward.

In the End

It absolutely goes without saying that there are a lot of challenges present when dealing with a sophisticated Hardware/Software Interface. As is true more often than not, however, there is also a massive amount of opportunity present, too. Advancements in this area, with IDesignSpec being just one of many examples, have made it possible for people to change the way they think about the HSI for the better.

The ideas behind the Hardware/Software Interface have certainly come a long way, and they still have a long way to go. But at the same time, good things are worth fighting for, as "the right approach" all but guarantees significant productivity gains across the board. "The wrong approach" guarantees losing a lot of cycles debugging, among other issues, meaning that it isn't really a choice at all.