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?

Let's compare the main use models and care-abouts that can be satisfied by the different characteristics of prototypes.

???Application software developers need a representation of the hardware as early as possible. It needs to execute as fast as possible and needs to be functionally accurate. This type of software developer would like to be as independent from the hardware as possible, and specifically does not need full timing detail. For example, detailed memory latency and bus delays are generally not of concern.
???Similarly, hardware-aware software developers also would like representations of the hardware to be available as early as possible. However, they need to see the details of the register interfaces and they expect the prototype to look exactly like the target hardware will look. Depending on their task, timing information may be required. In exchange, this type of developer is likely to compromise on speed to gain the appropriate accuracy.
???System architects care about early availability of the prototype, as they have to make decisions even before all the characteristics of the hardware are defined. They need to be able to trade off hardware versus software and make decisions about resource usage. For them, the actual functionality counts less than some of the details. For example, functionality can be abstracted into representations of the traffic it creates, but for items like the interconnect fabric and the memory architecture, very accurate models are desirable. In exchange, this type of user is willing to compromise on speed and does not typically require complete functionality as the decisions are often made at a subsystem level.
???Hardware verification engineers typically do need precise timing accuracy of the hardware, at least on a clock cycle basis for the digital domain. Depending on the scope of their verification assignment, they need to be able to model the impact of software as it interacts with the hardware. Accuracy definitely trumps speed, but the faster the prototype executes, the better the verification efficiency will be. This type of user also cares about being able to reuse testbenches once they have been developed.
???HW/SW validation engineers make sure the integration of hardware and software works as specified, and they need a balance of speed and accuracy to execute tests of significant length to pinpoint defects if they occur. This type of user especially needs to be able to connect to the environment of the chip and system to verify functionality in the system context.
Some characteristics are important to all users, but some of them are especially sensitive to some users. Cost is one of those characteristics. While all users are cost-sensitive, software developers may find that a prototype is not feasible in light of cheaper alternatives, even though the prototype may have the desired accuracy or early availability in the project flow. In addition, the extra development effort that prototypes require beyond standard development flows needs to be considered carefully and weighed against prototype benefits.

Variety of prototypes
The types of prototypes can be categorized easily by when they become available during a project. Prior to RTL development, users can choose from the following prototypes:

???Software development kits (SDKs) typically do not run the actual software binary but require re-compilation of the software. The main target users are application software developers who do not need to look into hardware details. SDKs offer the best speed but lack accuracy. The software executing on the processors, as in the SoC examples given earlier, runs natively on the host first or executes on abstraction layers like Java. Complex computation, as used in graphics and video engines, is abstracted using high-level APIs that map those functions to the capabilities of the development workstation.
???Architectural virtual platforms are mixed accuracy models that enable architecture decision making. The items in question!bus latency and contention, memory delays, etc.!are described in detail, maybe even as small portions of RTL. The rest of the system is abstracted as it may not exist yet. The main target users are system architects. Architecture virtual platforms are typically not functionally complete and they abstract environment functionality into their traffic. Specifically, the interconnect fabric of the examples given earlier will be modeled in full detail, but the analysis will be done per subsystem. Execution speed may vary greatly depending on the amount of timing accuracy, but normally will be limited to 10s to low-100s ofkHz.
???Software virtual platforms run the actual binary without re-compilation at speeds close to real time!50s of MHz to 100s of MHz. Target users are software developers, both apps developers and "hardware-aware software developers." Depending on the need of the developer, some timing of the hardware may be more accurately represented. This prototype can be also used by HW/SW validation engineers who need to see both hardware and software details. Due to the nature of "just-in-time binary translation," the code stream of a given processor can be executed very fast natively on the host. This makes virtual prototypes great for software development, but modeling other components of the example systems!like the 3D engines!would result in significant speed degradation.

?First Page?Previous Page 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