EECS 249 Embedded System Design

Final Project Report

Rong Chen

Mentors: Roberto Passerone, Bassam Tabbara

Supervised by

Prof. Alberto Sangiovanni-Vincentelli

December 9, 1999

University of California at Berkeley

Dept. of Electrical Engineering and Computer Sciences

I Objective

1 Motivations

Embedded system design has been an important research area for a long time, and currently there are many design tools such as POLIS, VCC, and Ptolemy available. On one hand, they are very powerful and can achieve different stage design goals for different users. On the other hand, however, they are often provided by different vendors and thus usually not very well integrated. Further more, very seldom do they explicitly show the internal design flow to users.

2 Project Objectives

In this project, we designed a metatool that aims to improve the aforementioned situation. Specifically, it:
  • integrates different tools’ functions,
  • does necessary analysis for the user,
  • shows the design flow to the user,
  • automates tools’ interactions,
  • provides a graphic user interface.

Below, we introduce these features in turn.

II Tool Description Model

1 Tools’ Characteristics

Essentially, all design tools can be described by the following format:

  • tool name,
  • inputs and their formats
  • outputs and their formats
  • commands and options
  • etc.
2 Internal Tool-Description Model

Since the above format is applicable to all tools, we can construct an internal tool-description model, which consists of some link list, and each node in the link list has a structure containing the above format, i.e. a tool’s name, inputs/formats, outputs/formats and commands. The relative position where a node sits in the link list represents the internal design flow.

3 Modeling Tool: Together/J

Though the current model is small (consisting of a couple of classes), it is expected to grow up into a large one (consisting of many classes and possibly multiple packets). So it is important for us to use the Unified Modeling Language (UML) to describe our model such that a good scalability will be maintained for further development. Specifically, Together/J was chosen as the UML modeling tool.

Figure 1 Example of Together/J Visual Design

Together/J is a visual design UML modeling tool for Java language. The user simply uses drag-and-drop method to visually describe the model, i.e. to specify relations among classes (such as association, generalization, etc.), between a class and an object (instance of), and among objects (dependence, etc.), and the corresponding source codes will be automatically generated. For example, the user described some simple model behaviors in Figure 1, and the corresponding automatically generated codes were shown in Figure 2.

Figure 2 Example of Together/J Code Generation

III Design Flow Navigation

1 Internal Flow Representation

At current stage, our metatool deals mainly with POLIS. It represents the internal design flow of POLIS by constructing some link list. Figure 3 shows the internal flow representation. When implemented by link list, “esterel” will become the starting point, “shift” will be its next node, “partition” will be the next next node, and so on.

2 Design Flow Navigation

As stated, one of our objectives is to help the user do some analysis. Basically, the following three types of analysis are provided:
given a certain input, find out all possible outputs,

 The metatool starts from the input node, visits all following nodes until it reaches the ending nodes (may be multiple), then represents all visited nodes as possible outputs.

  • given a certain pair of input and output, find out the design flow,
 The metatool starts from the input node, searches the output node until finds it, then represents the passing path as the design flow.
  • given a certain output, find out the necessary inputs.

 The metatool starts from the output node, retrieves backwards all the preceding nodes until reaches the starting point, then represents the preceding nodes as possible inputs.

Figure 3 Internal Flow Representation

IV Automating Tool Interaction

1 Why It Is Needed

When a user designs an embedded system, several design tools might be involved. Currently the user has to manually feed some input into one tool, then launch another tool and take the previous tool’s output as current tool’s input, and so on. Obviously, this procedure is both time-consuming and error-prone. So, it is desirable if our metatool can automatically do this for the user.

2 Approaches

One easy way is to let the metatool contact the operating system to get the run-time environment, and then from there launch different design tool programs. Figure 4 illustrates the idea.

Figure 4 Automating Tool Interaction

V Implementation

1 Programming Language

We chose Java to implement our metatool because we want our tool to be platform independent. One problem arising is that as Java does not support pointer, it is very difficult to implement link list.

2 GUI Design Tool: AWT

Also for good transportation, we chose Abstract Window Toolkits (AWT) as our GUI design tool. But it is not very convenient to do a good job using AWT, later we probably will try some other tools (e.g. SWING).

VI Conclusions

  • The metatool developed here is aiming to integrate different design tools that are currently available in order to facilitate the embedded system design process.
  • Four parts of work have been done in this project:

 building the internal tool-description model,

 analyzing the design flow,

 automating the tools interaction,

 developing the GUI.

  • The core of the whole work is to build a proper tool-description model.
  • Formal specification method (UML) is used to maintain good scalability for the future evolution.

VII Future Works

  • Tool-description model needs to be further extended to include more tools.
  • Inner data model needs to be developed in order to handle intermediate results and achieve better performance.
  • Efficient way of implementing link list using Java needs to be found.
  • Enhanced GUI features are needed.

VIII Acknowledgements

The original idea of this project was suggested by Prof. Alberto Sangiovanni-Vincentelli. As mentors, Roberto Passerone and Bassam Tabbara gave out good advises on how to describe the POLIS design flow and handle with the runtime system.