What is the embedded systems developer to do in an application environment in which hardware has become software-differentiated and software is depending more than ever on powerful hardware to run on
Gone are the days when a designer’s job was done as soon as the ASIC went into tape-out. In fact, getting the hardware - the chip - right is not even the biggest challenge anymore. The focus has rapidly shifted to getting the software right, and getting it working with the hardware.
But, you might say, having to re-spin the chip will cost millions of dollars, so we have to get it right the first time! True, but what will you do with that “right the first time” chip if the software is not ready?
So which is it? The software or the hardware?
It’s a software-differentiated world!
During the past few years, we have seen a dramatic change in how consumers select a certain product and, consequently, the key components that go into these consumer products have changed even more.
Let’s take, for example, the good old cellphone. Ten years ago, even five years ago, when you were in the market for a new phone, you probably looked at and compared HARDWARE features:
* Dual-band or tri-band
* How big are the buttons on the keyboard
* How big is the display
* Integrated MP3 player or not
* (Handset) sound quality
If you are looking for a new cell phone today, chances are you will select a smartphone, something that’s more a small form-factor multimedia PC than a phone. Size, weight, screen size are pretty much the same, so how do you choose between the different brands and models? You will look at the software that runs on it and the applications that you can load onto your shiny new phone.
This is true for more and more products: TVs are Web-connected, cars have voice recognition to set the climate control, and so on. It has undoubtedly become a software-differentiated world, and the suppliers of the chips that go into these devices have to supply a lot more than just the chip - they have to supply much of the software that enables these chips in a system. This software has become a key differentiator and a competitive advantage – or disadvantage!
Challenge or opportunity?
While it is definitely a challenge dealing with and developing all this software (not to mention the ASIC itself), it also represents a unique opportunity for those who get it right. Having software-differentiated hardware has the potential for longer hardware (chip) product lifecycles, which is an interesting aspect considering the staggeringly high development costs for 65nm and smaller geometry devices.
That said, what are the new challenges and how do they affect traditional design and verification flows? For one, an ASIC is no longer just evaluated based on its hardware capabilities, but increasingly on how well software can be executed on it.
Not all of that software, however, is available at the time the ASIC goes into production. Some of the software may only become available a year or so later, with a new software update. This puts a huge burden on verifying all the hardware features, especially those that might not be used initially.
Secondly, designers will have to make architectural decisions about what to put into hardware and what to put into software, and validating those decisions and the resulting system performance, power consumption and so on before even RTL development. This is a key to having a successful final product.
Last but not least, you want to execute as much software as possible, as early as possible, on a cycle-accurate, post-RTL yet pre-silicon, model of the chip.
This step is probably the most critical one in the whole development process, as here the hardware and the software truly come together to work in unison. This where system validation is happening.
In addition, this cycle-accurate model serves another equally important purpose: it is a pre-silicon representation of the chip and, therefore, the ideal platform for hardware-close software development - mostly drivers, firmware and other parts of the software stack.