Published in September / August 2008 issue of Chip Design Magazine
Today, three statements about software are generally accepted as fact. The ï¬?rst is that software is the key to the success of current electronic products. Secondly, software development is more than half the development cost for a system-on-a-chip (SoC) at the 65-nm technology node. Finally, most of the development costs for system original-equipment manufacturers (OEMs) are in software rather than hardware. These three aspects have propelled software development to the forefront of problems facing the chip-design industry. To answer this challenge, this traditionally hardware- oriented industry is striving to facilitate OEM software development. This means developing software stacks ready-made to the OEMs and providing ways to develop software in parallel to hardware development by using virtual platforms. It also is possible to go beyond these approaches and actually have end-customer software development guide hardware design. This tactic would turn chip design into a truly software-driven and application-driven business.
Currently, the dominant model of chip development includes a feedback loop in which market input is used to plan the next generation of a family or platform. (And all successful chip designs will be the basis for some family of platform and will have a sequel, just like Hollywood movies.) Together with the experience, foresight, vision, and creative imagination of chip architects, the market feedback drives the feature set and requirements for each successive chip generation. This approach has worked fairly well in the past. Yet as target applications start changing faster and more value is being put into innovative software, the feedback loop needs to become tighter.
Figure 1 shows the long development loop that leads up to feedback from system OEMs. The chip has to be designed and manufactured and have basic software, such as operating systems (OSs), put on it. At this point, the salespeople can probably make a customer commit to the new chip. In addition, system development inside an OEM (or a chain of companies) ensues where middleware, databases, network stacks, Java virtual machines, and other software components are added to form a complete platform. This system platform is then used to develop an actual application or product. Finally, a complete system is ready to be tested. At this point, shortcomings or overkill in features and performance are clear. Feedback from the complete system-development process is used in the product planning for the next chip.
Virtual platforms are the latest industry solution for developing software in parallel to the hardware as well as for validating the performance of a chip when running a particular software load. Yet such validation usually just involves core algorithms, benchmarks, and small bodies of code from the data-plane side. The virtual platforms are mostly created by and conifined to the hardware design groups. The software design groups and end customers are rarely involved.
To get the software designers and system OEMs involved, virtual platforms have to reach outside the hardware design teams. This means making virtual platforms available to internal software-development groups and external customers as early as possible in the design cycle. To be useful, these early virtual platforms have to be able to run “realistic” software loads—in particular operating systems. Application developers can then use them to run and test application code. In Figure 2, the result of putting a virtual platform into the hands of system OEMs and software partners is a better, faster feedback loop. It brings thinking that is prevalent in modern software development to hardware development with the principle: “Test early with end users, iterate often.” This approach increases the chances of developing the right thing for the market at the right time.
If all hardware models and supporting software had to be developed from scratch for each new chip, getting a virtual platform and supporting software out to application developers and system OEMs would be extraordinarily time consuming. In practice, however, almost all new chip designs reuse many elements from previous designs. Virtual platforms can therefore be built quicker by reusing existing device models. In addition, hardware drivers and ï¬?rmware code can be made reusable simply by adjusting the memory map in an existing board support package (BSP). Once an operating system runs on a particular chip, most software targeting a similar processor and OS also will run. This advantage can be attributed to the layered nature of modern software.
Note that early virtual-platform drops don’t have to be complete or deï¬?nite. The very point is that they represent a sketch that can be adjusted. As soon as the basic components required to support an OS boot are in place, the developer can start seeding the development of fundamental software. Today, that means a processor core (or a few), interrupt controller, serial port, Ethernet connection, and memory. Such a simple platform will allow an OS kernel to be ported, which paves the way for the addition of more BSP details and running software. This use of virtual platforms makes it possible to get feedback on the programmability and general usability of a chip very early—in time to actually adjust the design and feature set before committing the design. Areas of risk should be modeled first, such as novel virtualization support or new, complex hardware accelerators.
The virtual-platform approach provides feedback in two stages. First, be sure to have a modeling group separate from the hardware design group. Having a second set of eyes read the design documents and create an executable model of the design is a great way to test and improve the design documentation and the design itself. Second, write software drivers for new or updated devices and integrate them into an OS. This task tests whether the design is easy to use and works in the context of an OS and complex software stack.
The individual device models don’t need to be particularly detailed when one starts seeding partners and OEMs. What matters is what the hardware functionality is and how it’s programmed—not the detailed how of the implementation and timing. Functional models can be created much faster than detailed models and also run orders of magnitude faster. Very high execution speed is the key to enabling the software feedback loop, as seemingly simple tasks like booting an OS or running network traffic through a firewall application easily involve tens of billions of target instructions that have to be executed. Another important simplification to get device models out early is that only the most important operational modes have to be in place initially. The scope of the model is therefore reduced.
Once the software runs, it’s possible to start investigating the detailed performance of a chip design at the workload points where it’s relevant. The fast functional model is used to run the software load and get the system into a state that’s of interest, and then change a part (or the whole) system to use detailed models (once they’re made available). The graphic in Figure 3 shows the concepts of changing over at various points in time and mixing models at different levels of detail within a single simulation. This is the only reasonable way
to gather performance details from large software loads, as running billions of instructions in detailed mode would simply take years.
Looking at this from an organizational perspective, it requires marketing and sales to get involved with a new chip design quite early in the process. Those departments have to contact customers and software partners and secure their support and commitment to trying the virtual platform. Chip customers are often happy to be involved. For a system-level OEM, to be able to influence the design of the components that will go into its next-generation systems is an opportunity to gain competitive advantage while reducing development risk. By using a virtual platform in house, the system- level OEM doesn’t need to be concerned about software IP issues. It only needs to give the chip manufacturer the statistics gathered during the run—not their actual code. For OEMs, a virtual platform also opens up the ability to design in a new chip before hardware availability, drastically reducing time to market for new products.
(click on image for a larger version)
To effectively test their software, OEMs will usually need to extend the virtual platform with models of custom chips, specific memories, network configurations, and other virtual systems. For example, one can have a setup in which the generic virtual board for a new SoC has been customized to create mockups of future boards based on the SoC (see Figure 4). The setup also is connected into a system environment built for existing products.
Early virtual platforms also have beneifits other than producing a better hardware design, which are equally important to help a semiconductor vendor capitalize on its new hardware design. Apart from the product management team, which has obvious beneifits from product design feedback, other parts of marketing can find a virtual platform quite useful. It makes it possible to get a software ecosystem in place before the launch of the chip and to run (preliminary) benchmarks and produce marketing materials. Training materials can be developed and tested before the chip becomes available.
For sales teams, a virtual platform is a great sales tool when utilized correctly. It can be used to prove to customers that design decisions that look “odd” are actually the right thing to do and that the product strategy embodied in a design is actually sensible. It also makes it possible to go before key accounts and show them a new product in action, rather than just a set of slides extolling the greatness of the promised SoC (which is especially nice when the competition only has slides). In addition, the use of a virtual platform makes it possible to perform the design-in work while the hardware is being finalized. This aspect shortens the time-to-volume shipments and the real sales commission. A virtual platform also can overcome the initial ramp-up phase of a new chip where development systems tend to be in tight supply, limiting the ability to engage with customers.
In summary, chip designers must garner feedback from the software people faster than they receive it today. The way to get there is to provide virtual platforms to not just internal development teams, but also marketing, sales, and external customers. this approach will lead to better-designed and architected chips and chip families and more satisified end customers.