Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Address hardware/software integration issues with combined prototyping solutions

Posted: 11 Jan 2012 ?? ?Print Version ?Bookmark and Share

Keywords:prototyping? hardware/software integration? Application software?

As it realized the value of software, the electronics industry has come to accept the fact that system development without prototyping is too risky, and today most companies demand the use of prototyping prior to silicon tapeout. There are, however, several different types of prototypes that allow hardware/software integration and debugging. In addition, different users within a design team have potentially different needs for prototype capabilities. Just exactly what type of prototype to choose is not always 100% clear, and the multitude of choices can make it hard for design teams to find the right combination of prototypes to support their needs.

While there are certainly differences in other application domains, let's consider prototyping in applications for wireless communications. When comparing the block diagrams of some of the enabling systems on chip (SoCs) like the Qualcomm MSM8960 Snapdragon S4 processor , the TI OMAP4 platform, the NVIDIA Tegra 2, and ST Ericsson's DB9500, a couple of common characteristics can be derived: All of these devices have multiple processing cores, 2D/3D graphics engines, video and audio acceleration engines, complex interconnect, and peripherals to connect to the environment. All these different components have different characteristics as they relate to processing and throughput needs, which significantly impacts the ways they can be prototyped.

Prototyping characteristics
There are five main types of users who can benefit from prototypes, and they can be directly derived from the example design flow shown in figure 1.

Figure 1: A chip design flow and its efforts.

Figure 1 shows a classic design flow. The height of the blocks along the Y axis indicates the percentage of effort each of the tasks takes on average as measured by IBS over several example projects. For example, of the combined hardware/software (HW/SW) development effort, application software development consumes about 30% of the effort. The width of the blocks along the X axis indicates the time each of the tasks took as part of the overall project, measured as percentage of the time from RTL development to silicon tape out, which was necessary to normalize to the different project length. For instance application software development took an average 72% of the time taken to get from RTL to tape out.

The indicated classic waterfall flow starts with specification development executed by architects, followed by RTL development and verification performed by hardware verification engineers. Software development happens in two main categories: hardware-aware software development for OS porting and utility development, and application software development. While not clearly called out as an independent step, the integration of hardware and software needs to be validated by HW/SW validation engineers prior to tapeout and then on silicon once actual chip samples are available. As it becomes clear from figure 1, starting software development as early as possible greatly contributes to schedule improvements.

1???2???3???4?Next Page?Last Page

Article Comments - Address hardware/software integratio...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top