Collaborative semiconductor business platform: the future of industry partnerships | Executive strategy deep-dive- Part 3
In this third installment of our interview series, we dive into Pillar 2 of Michael Munsey’s three-pillar strategy for semiconductor industry transformation. Host Gabriella Leone sits down with Michael Munsey, Vice President of Semiconductors and Electronics at Siemens Digital Industries Software, to explore how software-defined products are fundamentally changing the way companies approach semiconductor design, verification, and product development.
Understanding software-defined products beyond mobile and automotive
Q: Michael, in Pillar 1 we discussed the importance of collaboration. Now with Pillar 2, you’re focusing on the software-defined product. Can you unpack what this pillar means and why it’s so crucial for the semiconductor industry right now?
A: When you look at products today, whether it’s a mobile phone or automobile, there’s more and more software. When we talk about a product being software-defined, it really goes to the way that the product itself – the functionality, the use, the way the consumer interacts with the product – is more and more through a software layer.
It’s obvious when you think about a mobile phone that you’re interacting through applications and an OS. But it goes deeper – the individual components like the camera, microphones, battery, and processor are all controlled by software in some way. The same thing is true of other products. When we talk about cars now, we talk about the software-defined vehicle where the way you interact with your car is very much software-defined.
This is leading to a paradigm shift in the industry. In the past, you would start designing semiconductors first and then worry about the software layer that would run on top. But now with functionality being defined by the software, it’s really about starting with software and doing semiconductor development in parallel. That paradigm change is leading us to think about what the software-defined product means and the implications on the entire product development flow from software to semiconductors to electronics to packaging to the entire product.
Q: As we’re talking about the shifting value from hardware to software, what trends are pushing this transformation forward? Are there other examples related to the semiconductor industry that are pushing this transformation faster?
A: It really goes down to flexibility, upgradability, and increased functionality. When you buy an iPhone, when new software releases come out, that iPhone itself is more capable than when you first bought it. Same thing is true with automobiles – when you buy a car, because of software updates, that car could be more capable and more valuable than when you first bought it.
To drive the point home: anybody that had an iPhone and upgraded to the latest OS saw fundamental changes that made the iPhone better. Software changes made the battery life better on a single charge because there was better control of the power profile of the chips. The actual lifetime of the battery became longer because of better battery conditioning during recharge cycles. The microphones were better because of improved DSP algorithms for noise cancellation. The camera took better pictures because of upgrades to DSP algorithms.
This is all enabled by the fact that software works more tightly than ever with hardware, and design decisions were made upfront to allow for these improved functionality increases that were software-controlled. The semiconductors have to be developed with knowledge of what functionality the software’s going to be doing so you can account for future functionality improvements through software layers.
From hardware platforms to custom compute solutions
Q: How would you say semiconductor companies are adapting to this shift as software becomes more defining of the end user experience?
A: We used to talk about platforms and hardware platforms that you would build products around – making a decision to build a system around an Intel platform or a PowerPC platform. Those types of platform-based designs are starting to go away because the software workload is so high and there’s so much custom software that the actual underlying compute platform has to be more customized.
This has led to companies like ARM offering processor cores where a company could license a processor core and build custom silicon around it. It’s even evolved to just licensing the instruction set and building your own processor platform around the instruction set and additional logic.
We’re seeing a shift from picking a platform to be the basis of the product to more of defining the functionality what the product needs to be, deciding what’s going to be done in software and hardware, then building custom compute platforms to support the workload of the software.
One critical consideration: if you’re developing a mobile phone or computer and somebody drops a call because of workload overload, or you get the spinning wheel on your laptop because you have too many programs running, those are inconveniences. But if you’re developing semiconductors for automotives, airplanes, or other critical devices, you can’t have the processor lock up because it’ll lead to catastrophic consequences.
Co-design and co-verification challenges
Q: What kind of challenges are companies facing when it comes to integrating software into traditional hardware-dominated workflows as software becomes more central and complexities increase?
A: It goes right to co-design and co-verification when you’re doing software and semiconductor development at the same time. Since they’re both happening in parallel, you need a way to verify the software on the hardware platform to make sure it’s going to work correctly. The problem is that hardware platform is not going to be complete.
Now we have to start talking about virtualization and creating verification platforms that allow you to virtualize as much of the hardware as possible upfront so you can do software development and verification on functionality or cycle-accurate models. Then as you develop semiconductors more and get more of the RTL done, start moving from these virtualized environments into hybrid environments where you have some combination of virtual elements and RTL.
You have to do this keeping in mind that the more accurate model you have, the less performance you’re going to have to do the actual software validation against the hardware model. It’s about creating environments where you can virtualize a lot upfront, move from virtual environments to hybrid flows, then into full hardware functionality specified models, and then accelerate those through emulation or other types of acceleration to get the fidelity and speed you need for software verification.
Configuration management for over-the-air updates
Q: Are we just talking about embedded software or is it broader? How do things like AI, connectivity, and over-the-air updates factor into the software-defined product vision?
A: It certainly is broader. Using the term embedded code, while still accurate, we like to think of it as more broader – we call it “in-product software.” There still is a software stack and embedded code and software that runs on top of the embedded code all the way up to the OS level. But even past the OS level, there are still applications that need to access register elements in the design.
When you start talking about automobiles and other products that receive over-the-air software updates, you get into configuration management issues where you have to make sure the version of software fits the version of hardware you’re trying to update. When you have a fleet of vehicles with different options that may have had different versions of hardware installed, you want to make sure you’re updating software correctly.
We’ve already heard stories where after a software update, somebody rolls down their windows and can’t roll them up again, or a software update causes the vehicle to stop working and not even a reboot will get the car working – which is a big problem if you’re in the high-speed lane of a highway.
You can think of the software and version of software being a very important part of the overall BOM of the product, making sure you’re pushing the right software updates to the right versions of the BOM. When we talk about AI applications running on hardware platforms and getting access to data, it becomes an entirely broader set of configurations because now it’s about data being associated with a given set of software and hardware.
Rethinking the traditional V-curve development model
Q: How does a software-first mindset change the way we approach chip design, verification, and validation? Are companies rethinking their entire development process?
A: If you look at the traditional V-curve of system design, we start with requirements, decompose them, then work on different parts of the product. That’s traditionally the left side of the V, with the right side being verification where you verify at the lowest level at the component level, then at integration level bringing up larger pieces.
What we’re seeing now is that even starting at requirements and decomposition of requirements, going into product-level specifications for different work streams, there’s a certain amount of validation that has to go along with each step. Even as you start doing actual product development, you see the need for validation at each step while making sure everything ties back to requirements.
We can call this digitally threaded verification where constantly, every decision that’s made that’s backed up by some amount of verification or validation gets threaded back to the original set of requirements. You’re starting to see that it’s not a V-curve with design on one side and verification on the other, but it’s a “V-care” where there’s a large amount of verification even on the left-hand side of that V. The right side with integration verification and system-level verification and validation still links back to verification being done on the left side, making sure everything is mapped back to the original requirements to guarantee you’re meeting the functionality specified at a very early stage.
What’s next?
The transformation to software-defined products represents a fundamental shift in how the semiconductor industry approaches product development. From custom compute platforms replacing standard hardware platforms to the need for sophisticated co-design and co-verification workflows, companies must adapt their entire development methodology.
The implications extend far beyond just design and verification – they touch every aspect of product lifecycle management, from configuration management of over-the-air updates to the critical safety considerations in automotive and aerospace applications. This software-first mindset is reshaping the traditional V-curve development model into something more comprehensive and verification-intensive throughout the entire process.
Stay tuned for part four of our interview with Michael Munsey, where we will continue exploring the technical foundations of software-defined products and dive deeper into how digital twin architectures enable cross-domain optimization and new business models.
Frequently asked questions
What exactly makes a product “software-defined”?
A software-defined product is one where the core functionality, user interaction, and even individual component behavior are primarily controlled through software layers rather than fixed hardware implementations. This allows for upgrades and improvements through software updates rather than hardware replacements.
Why are companies moving away from standard hardware platforms?
The high software workload and custom software requirements mean that standard platforms like Intel or PowerPC can no longer efficiently support the specific compute needs. Companies now build custom compute platforms around licensed processor cores or instruction sets to optimize for their particular software stack.
What are the safety implications of software-defined products?
In critical applications like automotive or aerospace, processor lockups can have catastrophic consequences. This requires much more rigorous co-verification of software and hardware to ensure the compute platform can reliably support the software workload under all conditions.
How do over-the-air updates work with different hardware versions?
Configuration management becomes critical when you have fleets of products with different hardware versions and options. The system must track the bill of materials (BOM) for each device and ensure software updates are compatible with the specific hardware configuration to prevent failures.
What is “digitally threaded verification”?
Unlike traditional V-curve development where verification happens mainly at the end, digitally threaded verification means every design decision is validated against requirements throughout the development process, creating a continuous thread of verification from initial requirements through final implementation.
