Achieving first day multicore SoC software success
The past few years have seen a dramatic shift in how companies design and market their system-on-chip (SoC) offerings. Designs that used to contain large amounts of homegrown or internal intellectual property (IP) are becoming increasingly reliant upon pre-built blocks from third-party suppliers. It’s not uncommon for a new SoC design to contain 80-90% of its content from outside suppliers.
This shift is forcing companies to rethink how their products are differentiated from competitive offerings. When the vast majority of the design is based upon components that can be used by anyone, how do you make your product stand out?
In response to this trend, companies are seeking differentiation in a few key areas, including architectural configuration, software features and time to market.
Architectural configuration is the process of assembling the SoC IP from disparate sources in such a way that the configuration options and overall layout maximize the designer’s goals that can range from faster throughput to lower power consumption to overall cost optimization.
Software features are probably the number one area of differentiation as the capabilities of the underlying hardware can only be exploited with properly written software at every level of abstraction.
Time to market is self-explanatory, the faster a product comes to market the easier time it with typically have gaining critical market share.
As a result of this shift, the design process from architectural analysis through software debug and hardware verification needs to take account of this new reality. Since there is a great deal that can be written about each of the three topics mentioned above, the remainder of this article will focus more on the second and third. It will show how design teams are achieving differentiation using software features and accelerating time to market.
Software-Driven Differentiation
The challenge is to ensure that when the SoC prototype returns from the fab it will achieve first day software success and run immediately. Otherwise, one of two problems is created.
First, there may be errors in the silicon not detected previously which require a respin of the chip, creating additional delay and driving up cost. Secondly, an extended software development and integration period is required, once again increasing cost and delaying time to market.
In order to develop and test the software in parallel with the SoC development, a model of the actual chip must be used because, by definition, the chip is not available yet. If the RTL code of the chip is complete, then there are various approaches to model the chip using field programmable gate arrays (FPGAs) or hardware emulation.
A better approach that can be used much earlier is to create a software model of the chip. This model is known as a virtual platform. Virtual platforms have existed for years but have not been as widely deployed as their benefits would seem to indicate due to the difficulties of creating models.
An integrated model creation ecosystem avoids these pitfalls and makes virtual platforms a clear choice for modern electronic systems where the software and hardware can only be validated together.
An integrated model creation ecosystem has a few vital components: a process for obtaining the accurate models required by the architecture and firmware teams; a method for tying in the high speed models in the system to enable the software team; an approach to tie these models together into a single platform to avoid redundant development efforts; and, finally, some capability –– preferably web-based –– to manage all of these internal and external models at various levels of abstraction.
Virtual Platforms
A virtual platform (Figure 1 below) is a software model of the hardware of a system with enough fidelity that it can run the software load of the system including, in particular, bringing up the operating system(s) being used.
Figure 1. Virtual platforms allow developers to operate in a unified design environment that allows seamless movement between the various stages of development: architectural analysis, firmware development and software development.
In a modern system-on-chip or electronic system, there really isn’t any way of verifying the hardware other than running the full software load. Although each of the individual system components has, hopefully, been individually verified, the only true way to test the system is to execute all of the components together with the actual system software. This is especially true for low-level software, such as device drivers and power management. Software and hardware must be co-verified.
Historically, this has been a major problem because a virtual platform that is fast enough for software developers to do their job is not accurate enough to be useful for debugging the hardware and a cycle-accurate model that is has enough fidelity to be useful to hardware developers is too slow for software developers: they need to be able to boot the operating system in seconds not hours or days.
Another recurring problem with virtual platform modeling has been the cost and delay of creating models. Well-funded teams sometimes build two complete sets of models.
One set of models would be accurate enough to be useful to hardware designers while still being fast enough to be able to run at least some of the software. A second set of models would be fast enough to be used by the software team but of no use to hardware developers since the signals they need to do their job are simply not modeled.
Counting the RTL code as a third, there are now three complete and unrelated sets of models hitting different speed-accuracy tradeoffs. Since it is time-consuming, tedious and sometimes impossible to validate all of these models against each other, this seemingly vital task is often ignored. As a result, software developed on many virtual platforms is never validated on real hardware until the final silicon arrives in the lab, greatly endangering the possibility of first day software success.
Loading comments... Write a comment