Hardware/Software Codesign - introducing an interdisciplinary course
Why is this topic important? First of all, we must take into consideration the advances in new architectures based on programmable hardware circuits - namely Field Programmable Gate Arrays (FPGA's) and Digital Signal Processors (DSP's). Their introduction as alternative computational units and the flexibility they offer have required different methodologies in the design process, reflecting the large number of choices. Today's computing systems deliver increasingly higher performance to end users; thus we require architectural support for operating systems, or particular hardware to expedite application-specific software (product evolution). The new architectures based on programmable hardware circuits are usually geared to accelerate the execution of specific computations or emulate new hardware designs, before they are committed to a specific (more expensive) ASIC chip. The key item here is "reconfiguration": exploiting the synergy between hardware and software.
Figure 1 represents a more utopian view, where codesign and codesign tools provide an almost automatic framework for producing a balanced and optimized design from some initial high level specification. The goal of codesign tools and platform is not to push towards this kind of total automation; the designer interaction and continuous feedback is considered essential. The main goal is instead to incorporate in the "black box of codesign tools" the support for shifting functionality and implementation between hardware and software, with effective and efficient evaluation. At the end of the process, either the prototypes or the final products are output, based on currently available platforms (software compilers and commercial hardware synthesis tools). Codesign as an area of research does not aim to reinvent the wheel of system design; however, the necessary flexibility must be effectively incorporated and enhanced. For example, in the design of a real time system as a graduate project, a sub path in the figure above may indeed be followed. The difference is that the designers are given predetermined choices of hardware and software allocation and must meet the timing constraints within the specifications. Codesign introduces the research into the trade-offs of that allocation, dynamically throughout the entire process.
Mostly though we look at the largest application area of hardware/software codesign: embedded systems [3,6]. They are application specific systems which contain both hardware and software tailored for a particular task and are generally part of a larger system. Examples range from the automotive fields (ABS brake controllers, almost any other monitoring subsystem), the portable communication or computing systems (the Palm Pilot, any cellular phone), to the medical area (as in portable heart monitors). Embedded systems often fall under the category of reactive systems, that is, containing sensors or similar elements which constantly interact with the external environment. The components used usually include a general purpose processor, one or more special purpose processors and some ASICs. For example, real-time systems are types of reactive systems which must meet some time constraints. A major issue in an embedded system is to provide design approaches that scale up, without a total redesign for a legacy product.
Finally the interdisciplinary aspect between computer science and computer engineering, and the intradisciplinary aspect within computer science poses a challenge to us as educators and pivots for effective technology transfer; how to provide senior and graduate students with a framework such that they can learn to work concurrently.
3.0 What is the problem with current practice and how does codesign circumvent these problems?
Model continuity is important because:
It is not the purpose of this presentation to teach a whole course in hardware/software codesign and present the many solution given to the issues just described. However it is useful to list the main research areas, which are:
3.1 What would be a typical context for a hardware / software codesign process?
The red "interaction and feedback" arrow is the crucial part. Another important aspect is the central "Interface" submodule, which in normal system design is often left on the sideline, causing disastrous effects at the time of integration. Given that many embedded systems which use codesign methodologies are often implemented at a very low level of programming and details (e.g. assembly code), the proper development of an effective interface becomes extremely important, even more so from the view that any reconfiguration of the design will change the critical interface modules!
4.0 How we teach Codesign
The items in points 2, 3 and 6 represent a summary of hardware and VLSI design, which is much needed by both the computer science and, often, by the computer engineering students . The labels may look ambitious, but clearly only a survey of the topics is given. The difficulty is indeed in finding the necessary balance between depth and breadth. The reward was that all students find these subjects particularly interesting and extremely "empowering", by giving them the confidence that they could hold their own in almost any design environment by being able to grasp the essentials and know where to find more information of details for both system, software and hardware issues.
The software tools we introduced prove to be a pivot for the students' experience, as they gave them direct exposure and the power to develop significant projects (see below).
The first framework introduced is Ptolemy, distributed free from U.C. Berkeley and also available commercially. Ptolemy models systems with functional building blocks (stars, galaxies) and is ideal as a design platform at a high level, as it contains choices for many subdomains. Ptolemy can also be useful for other courses not necessarily on codesign, but focused on more general design, as it provides a sturdy platform for models based on Petri nets, CSP, etc. It contains tools for simulation and cosynthesis, but it is weak on partitioning and reconfiguration.
The second, more recent, system is SpecSyn/SpecCharts. A design is modeled using SpecCharts which supports concurrency, state transitions, hierarchy and synchronization; SpecSyn takes care of design space exploration and cosynthesis in a very effective manner. The advantage of this platform is that it is based internally on VHDL and the user programmability can be interfaced with VHDL as well. Thus it is well suited to both computer science and computer engineering students who find themselves very comfortable with a high level programming language. As an aside, VHDL is a new item for most students, and, notwithstanding any industrial or academic discussion as its advantages and disadvantages, it proved to be fascinating and powerful in its flexibility (the behavioral, structural and dataflow paradigms that VHDL allows).Figure 5 shows a schematic of Specsyn/SpecCharts and its flow of operation for a designer.
Last, but not least, programmable hardware, in the form of FPGAs is introduced in the course , but it is beyond the scope of this presentation. The use of FPGAs is the first step towards the research area called "Configware", referring to dynamically reconfigurable subsystems. A short introduction to VHDL as a programming language is also given through one lecture and an assignment.
5.0 Projects: Students and Research
In summary, the following points became clear in the overall evaluation of the course itself, the impact on the students and curriculum, and the students' level of satisfaction.
firstname.lastname@example.org Copyright © 1998, WCCCE Conference 1998. All rights reserved.