Posted by Achim Nohl on August 23, 2012
Finally, nine months after the next-generation SoC project was kicked off, the first prototype board has finally arrived! There are just six months left to get Android and Linux up and running. Since Android should take full advantage of the latest hardware additions, let’s make sure we get it ported as quickly as possible. Unfortunately, it is not that easy. Before you can care about porting your OS and developing the drivers for your special hardware, you have to deal with the boring, but necessary initialization of the hardware. This is typically done by a so-called boot monitor. A boot monitor is a software program in ROM that gets launched after pressing the power-on button on your hardware. Even though the boot monitor is not a large piece of software (compared to the OS etc.), it provides complex functions and interacts with many hardware peripherals. As an example, the classic minimal functions of a boot loader are given below:
Often, the boot monitor is not executed on the main CPU, but by a small companion controller. With the introduced functions, the boot monitor easily sums up to a few 100KB of highly platform-hardware-dependent source code. So, the boot up effort you thought you wouldn’t need to be concerned about when the first hardware sample board arrives now requires quite some development. Instead, you would prefer to start programming and validating the advanced features of your new product, such as the new GPU, but the hardware initialization step cannot be side stepped.
Due to the complexity of ROM code development and because this task is right in the critical path of your time-to-market window, it has evolved to become one of the main use cases for virtual prototyping. After the board arrives, our experience tells us that the bring-up and validation of the OS and higher-level software can start immediately (same day). The ROM code, which has been developed using a virtual prototype (VP), is sufficiently equipped and tested to no longer be a gating task for the main software bring-up. Interestingly, VPs for ROM code development are relatively easy to build. The hardware peripherals that are used by the ROM code are–to a large extent–commodity peripherals, like UART, timer, clock generator, etc. Here, the necessary TLM models typically exist. Thus, the VP can be easily assembled using the available TLM models, and the respective driver development or porting can start. Other important components are the various system configuration controllers needed to program the oscillators, voltage regulators, etc. Those models are not complex from a hardware perspective as they mainly consist of configuration registers that drive certain signals on a configuration bus. However, they are tricky and complex to program as a bad configuration may prevent the system from booting or can even damage the board. Having a VP that models the effects of clock and voltage settings correctly is very helpful in verifying that the ROM code works on the hardware. Summarizing, the return on investment for using a VP has turned out to be relatively high for this type of software development.
The other advantage of using a VP in this early stage of a project is that a VP does not actually need ROM code to boot the OS. Many of the functions that are provided by the boot monitor, such as loading images into RAM/NOR flash, can be done instantly. As a result, a project dependency is broken and OS kernel porting can start simultaneously with ROM code development. We have seen our users booting Android just 3 days after the sample board has arrived.
After one year of blogging, this is my last post for “A View From the Top”. Going forward, my colleague Nithya Ruff will bring some fresh new thoughts and continue to post for this blog. Thank you for your interest and comments during the past year.
Patrick Sheridan
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.