Austin, TX 78759-6509. Abstract ... function into hardware and software components more complex and ... software development into a more unified process,.
An Overview of Hardware/Software Codesign Martin K. Purvis, David W. Franke Microelectronics and Computer Technology Corporation 3500 West Balcones Center Drive Austin, TX 78759-6509
Abstract Advances in computing technology have blumd the traditional boundaries between hardware and software, and this has ma& the problem of allocating system function into hardware and software components more complex and difficult. Yet this problem is one that critically affects the ultimate cost, performance, functionality, manufacturability, and evolution of the system. It is not only important that the initial partitioning into hardware and software be made properly, but also that the ensuing system development proceed along lines that benefit from an integration of the hardware and software perspectives. The fundamental issues and some proposed approaches will be covered.
1 The Need For Codesign Traditionally, electronic systems have been developed by hardware and software engineers proceeding along parallel but separated tracks. In fact, this separation is so established that it has received the implicit endorsement of the U.S.Government in terms of the military standard for computer system development (DoD-STD-2167). As a result, software practitioners have felt safe in the assumption that they need not overly concern themselves with the “low-level” details of computer hardware. Besides, software design was seen as difficult enough on its own. But, now, advances in computing technology have called into question the value of maintaining this separation between software and hardware development. Instead, there is a growing interest in the notion of combining hardware and software development into a more unified process, called “codesign”. The advances that have brought about this change are primarily on the hardware side of things -- improved CAD design technology, coupled with the relentless pace of miniaturization and clock speed enhancement, have changed the playing field for system designers. Given the fact that it is now possible to develop an application-specific integrated circuit (ASIC) in a matter of days, it has become reasonable to consider
implementing any algorithmic component of a system as an ASIC, with potentially significant performance gains realized as a consequence. Thus we are beginning to see products that have custom-designed chips implementing string pattem-matching for large systems of text, image compression algorithms for multi-media systems, and neural net computations for artificial intelligence and natural-language applications. In each case a set of computation-intensive algorithms are implemented in hardware instead of software to get large performance improvements. Sometimes it works the other way, though. By redesigning the hardware (making it simpler, smaller, etc.) and putting some of the traditional microprocessor functionality back into software, RISC designers have obtained performance improvements over some older CISC microprocessor architectures. The point is that each application area has an individual, optimal mixture of hardware and software that is best suited to that specific problem domain. Improvements in software design and software engineering have also taken place, of course, and, while less dramatic, they have nevertheless had the effect of enabling the development of bigger, more complex and reactive systems that can comprise a wide array of hardware and software components. Consequently designers today have the option of implementing virtually any functional component of a system in terms of hardware, software, or (more likely) a complex mixture of hardware and software. To solve the problem of determining the right mix of hardware and software will more and more require a design team capable of understanding the various trade-offs and interactions that exist between hardware and software. These trade-offs exist, of course, across a wide range of product dimensions besides the one of performance. In general, alternative system implementations with various mixes of hardware and software often exhibit considerable differences with respect to all of the following parameters: performance manufacturing cost in-house expertise
2665 0-7803-0593-0192$3.00 1992 IEEE
time-to-market reliability physical aspects (size, weight, dissipation, etc.) modifiability maintainability product evolution
2.2 Concurrent Engineering heat
Another issue concerns the subject of concurrent engineering (CE). Concurrent engineering seeks to promote “a freer interchange of information between multiple engineering disciplines such as testing, manufacturing, reliability, maintainability, and all other disciplines that can contribute to making a better product”[I].
The problem faced by those who seek to advance hardware/software codesign is how to improve the design process so that (1) the best decisions can be made concerning the allocation of system functionality into hardware and software, and (2) during design and development, the interfaces between hardware and software are optimized so that, for example, hardware developers are aware of the associated software for the system on which they are working (and, correspondingly, software developers are aware of the associated hardware).
2 Codesign Issues 2.1 Modular Development is Desirable The first issue is fundamental, but it is sometimes overlooked. Given the complexity of modern electronic systems, it is almost invariably appropriate to break the system down into smaller, more easily manageable modules. This is the strategy of divide-and-conquer.So, given the fact that hardware and software specialists have different tools and methods, what could be more natural than breaking the system down initially into hardware and software modules? Isn’t hardware/ software codesign just going to get in the way of already effective development procedures? The answer here is that modules are usually best created that are (1) cohesive (their components have more internal connectivity than they do across the module interfaces) and are
So how does hardware/software codesign differ from
CE? Codesign actually is a key component of concurrent engineering. Electronic system can be described with respect to many different aspects. All of these aspects are the concern of concurrent engineering in general. However the time evolution of a system under design is characterized by a dynamic model that can be simulated. This dynamic model is ultimately represented by the system’s hardware and software models. When these two models are brought together, a more unified hardwardsoftware representation can capture the overall dynamic aspects of the system. Hardware/ software codesign is that component of CE that seeks, first of all, to bring together the hardware and software dynamics models. This has the advantage that nondynamic CE information, such as testability, mean-timeto-failure, etc., can be attached to the appropriate dynamic model components, making it easier to evolve and maintain CE information. With this information available, it means that hardware/software codesign models can then be evaluated with respect to all the significant product function parameters. Thus a model can be evaluated not only in terms of performance (by simulation)), but can also be evaluated with respect to other CE dimensions (reliability, maintainability, manufacturability, etc.)
3 Codesign Approaches
(2) natural €or the application domain. Sometimes it may be appropriate for modular components to be entirely hardware or software, but not always. Hardwarehoftware codesign seeks to free designers from the sometimes artificial boundaries imposed by current hardware and software practice. Often a modular component will be best designed around a specific functionality of the system and will comprise both hardware and software elements.
Some commercial products have been released that offer the designer the opportunity to see the software executing in an emulation environment prior to the actual construction of the hardware. With these products, the software and hardware must first be designed to some degree of detail in the customary manner, and then their combined behavior can be examined in the emulation environment. These products are usually oriented around specific types of hardware architectures; examples of this approach can be seen in CodeLink Station (Mentor Graphics), VRTXdesigner
2666
100
Life Cycle Phases
9
6
75
1 Define Use Patterns 2 Define Alternatives 3 Develop Alternatives 4 Freeze Subsystems 5 Prove Feasibility 6 Preliminary Designs 7 Detailed Drawings 8 Manufacturing Plans 9 Product
7
50
25
0 Concept Formulation
-
40 60 Full Scale Development
I
80
Production
Figure 1: Cumulative Percent of Life Cycle Cost Affected (Ready Systems), and IDAS (JRS Research Laboratories. In IDAS, for example, a design of the proposed device is first produced in VHDL. IDAS will then generate a simulator for that device and an Ada-tomicrocode compiler for it. The greatest interest in the hardwarehoftware codesign arena, however, has been on efforts to bring hardware and software together at an earlier or more “upstream” phase of the design process. The reason for this interest is that commitments concerning hardware and software allocations are typically made at the earliest stages of design, prior to the subsequent, separate developments of the hardware and software design teams. It is at these early stages of design that critical decisions are made that most greatly determine the cumulative life-cycle costs of a system (see figure 1, which is based on the recent National Research Council Report on a National Design Strategy 121).
configuration graph. A software-to-hardware mapping keeps track of the hardware used by the dataflow processing nodes. When the system simulation is run, performance bottlenecks can be identified for the given architecture. Several other products have been released that are based on the same approach [SI. Most recently, interest has been focused on representing hardwarel software system models in terms of a generalized directed graph that can support simulation and can be hierarchically decomposed. This approach seeks a central “integrated” modelling representation which can be mapped to more specific hardware and software descriptions (figure 2). Among those who have approached hardware/software design f “ this perspective are Zebo Peng (Linkoping University, Sweden) and his associates have dereloped a formal intermediate design representation based on an extended timed This notation is extended to Petri net notation include a set of dataflow graphs so that each Petri net place is associated with a dataflow graph.
[a.
An early effort in this area was that of Elliot Organick, who attempted to use Ada as a software engineering language and as a hardware description language, an approach he referred to as “heterosystems engineering” [3]. The idea was to start with a system model at a high level of abstraction and proceed with refinement until individual, lower-level components were eventually described in terms of hardware or software.
Robert Shapiro (Meta Software Corporation) has used the hierarchical Colored Petri Net (CPN) notation developed by Kurt Jensen (Aarhus University, Denmark) to model both hardware and software at various levels of abstraction 171 181. This suggests that CPNs may offer promise as an intermediate codesign representation.
Another earlier approach was the ADAS system tool developed at the Research Triangle Institute and marketed by Cadre Technology [4]. In this system, software is represented as a dataflow graph, and hardware is represented in terms of a block diagram
James Aylor (University of Virginia, Charlottesville) is working on a hybrid modeling approach, which he refers to as a mixture of
2667
National Research Council, “Improving Engineering Design: Designing for Competitive Advantage”, Committee on Engineering Design Theory and Methodology, Manufacturing Studies Board, March 1991. E. L. Organick, T. M. Carter, M. P. Maloney, A. Davis, A. B. Hayes, D. Klass, G. Lindstrom, B. E> Nelson, K. F. SMith, “Transforming an Ada Program Unit to Silicon and Verifying Its Behavior in an Ada Environment A First Experiment”, in IEEE Sofware, Vol. 1, No. 1 (January 1984), pp. 31-49. C. U. Smith, J. L. Cuadrado, G. A. Frank, “An Architecture Design and Assessment System for Software/Hardware Codesign”, in Proceedings of the 22nd Design Automation Conference, Las Vegas, June 1985, pp. 417-424.
Figure 2: Integrated Modeling Environment
D. W. Franke, M. K. Purvis, “Design Automation Technology for CoDesign: Status and Directions”, to be presented at the 1992 IEEE International Symposium on Circuits and System, May 1992.
“interpreted” modeling (such as VHDL) and “uninterpreted” modeling, which is also based on extensions to Petri nets [9]. Although his focus has primarily been on the connection to VHDL, his approach could be applied generally to codesign.
Z. Peng, K. Kuchcinski, J. Fagerstrom, “A Unified Approach to Evaluation and Design of Hardware Software Systems”, in WorkingPapers of the 1991 Workshop on Hardware Sofware CoDesign, MCC Technical Report MCC-CAD-156-91.
J. C. Browne (University of Texas and Scientific and Engineering Software) is working on a hierarchical directed graph notation to serve as an intermediate design representation for hardware and software [lo].
All of the above approaches have common features (guarded transitions, representation of state, hierarchical decomposition, concurrency), and this seems to indicate that they point to a promising way to address the codesign problem so that an integrated hardward software design representation is employed. By using this approach, the dynamic evolution of the system is represented in the graph notation and the associated concurrent engineering information (the “ilities”) may be attached to the various nodes or places. Consequently the codesign model (or models) may be “evaluated” with respect to the various significant product dimensions (in addition to performance). In the coming years it will be interesting to see how well these methods fare when they are applied to significant codesign appFcations.
References
R. M. Shapiro, “Validation of a VLSI Chip Using Hierarchical Colored Petri Nets”, in Proceedings of the 11th International Conference on Application and Theory of Petri Nets, (Park1990), 224-243. K. Jensen, “Coloured Petri nets: A high-level language for system design and analysis”, in Advances in Petri Nets 1990. G. Rozenberg ed. Lecture Notes in Computer Science, vol. 483, Springer-Verlag 1991,342-416. J. H. Aylor, R. Waxman, B. W. Johnson, R. D. Williams, “The Integration of Performance and Functional Modeling in VHDL,”, in Performance and Fault Modeling with VHDL, J. M. Schoen, ed., Prentice-Hall 1992. [lo] J. C. Browne, “An Integrated Approach to Design of Hardware/Software Systems” (working paper), Scientific and Engineering Software, Austin, TX, 1991.
[l] S . Evanczuk, “Concurrent Engineering: The New Look of Design”, in High Performance Systems, April 1990.
2668
