A framework for hardware/software codesign - Computer - CiteSeerX

COMPUTING PRACTICES

A

Welcome to Computing Practices, a new section created in response to your requests for shorter articles that are timely, technically accurate, and easy to read. Often, advances in one research area aren’t applied to others because the technology remains buried in literature seldom read by those outside the field. Computing Practices is therefore devoted to hastening technology transfer by making “bridging” technologies in the design and use of computers and software easily accessible. Identifying these technologies will let scientists and engineers exploit the advances achieved by the various subgroups of the IEEE Computer Society. We begin, appropriately enough, with two artides on hardwarelsoftware codesign. “A Framework for Hardwarel Software Codesign,” by S. Kumar et al., presents a model for evaluating hardware/software trade-offs and a model for hardware/software integration that sup ports abstractions and different levels of detail. “Codesign of Communication Protocols,” by A. Wenban et al., provides a practical illustration of a codesign process for translating communication protocol specifications into implementationsconsisting of both custom hardware and software. In future issues, we will look at software tools for managing large Ada systems, at VLSl tools, at object-oriented techniques, and more. Please feel free to contact me directly about articles you liked, didn’t like, or would like to see in this section (Oman@ cs .uidaho.edu). - Paul Oman

A Framework for Hardware/Software Codesign Sanjaya Kumar, James H. Aylor, Barry W. Johnson, and Wm. A. Wulf University of Virginia

urrent design practice dictates the separation of hardware and software design paths early in the design cycle.’ These design paths remain independent. having Lery little interaction until system integration. In particular, designers often specify hardware without fully appreciating the computational requirements of the software. Also. software development does not influence hardware design and does not track changes made during the hardware design phase. This design approach restricts the ability to explore hardwareisoftware trade-offs. such as the movement of functionality from the software domain to the hardware domain (and vice versa) or the modification of the hardwareisoftware interface. When the software and hardware are finally combined. system integration problems may require modification of the software and/or hardware. Potentially significant cost increases. schedule overruns. and performance losses can result from the premature selection of hardware whose inadequacies the software must attempt to correct.2 Furthermore. the advcnt of certain technolosics has changed design methodologies for computer systems. For example. improved electronic design-automation tools and application-specific integrated circuits ( ASICs) allow complex algorithms t o be implemented quickly and cheaply in silicon as dedicated hardware. Conversely. reduced instruction-set computer technology lets designers transfer functionality from the processor to the sofnvare. Thus. the decision to allocate functionality to hardware or software is not straightforward. Given these developments. the design of hardwareisoftware systems requires a more unified approach that considers both hardware and software options. This approach is called hardwareisoftuare codesign. or simply codesign.’ Codesign is a concurrent and cooperative desisn approach that includes as a fundamental component the capability to explore hardwareisoftware trade-offs. This capability leads to more efficient implementations and improves overall system performance. reliability. and cost-effectiveness. Also. because decisions

~

Hardware/software partition

Hardware Software

~

alternative

(b) Figure 1. Hardwarelsoftware partitioning (a) and refinement (b) .

regarding the implementation o f functionality in software can impact hardware design (and vice versa). problems can be detected and changes made earlier in the design process. Hardwarehftware trade-off5 - decisions about whether hardware can be sacrificed for software in the derivation of an implementation - are a common theme in discussions of fault-tolerant computers. buffer memories. software reliability, minicomputers. pipeline interlocks. and real-time systems. In f a c t , m a n y t r a d e - o f f s occur at t h e instruction-set level. for example. during instruction-set design. Moreover. because of the new technologies mentioned above. trade-offs extend beyond those at the instruction-set level. I n particular. hardwareisoftware tradeoffs can o c c u r a t s e v e r a l levels of the design process and lead to other types of trade-offs. such as p e r f o r mance versus cost. Thus. model conrinuirv,' a system model's capability to span these levels. is essential for the validation of system-level models and their hardwareisoftware implementations. Finally. codesign can aid the design of e m b e d d e d systems' consisting o f hardware and software tailored for a particular application (for example. a dishwasher. a robot controller. o r an aircraft autopilot). T h e requirements of embedded systems include performance. reliability. and form factor (size. weight. and power constraints). The increasing complexity of embedd e d s y s t e m s n e c e s s i t a t e s design approaches that scale up to more complicated systems. Because a detailed

description of a system can be a s complex as the system itself. it is increasingly important to employ decomposition techniques and abstractions to keep analysis from becoming intractable. Thus. a hardwareisoftware codesign methodology should support the following capabilities:

p e n d e n t of w h e t h e r t h e function is implemented in hardware or software.

Hardwarekoftware partitions and alternatives. T h e d e r i v a t i o n of a n implementation for a function consists of t\vo steps. T h e first s t e p is h a r d itwre/softL