System Level Design Languages:Unified Modeling Language

Today, the complexity of designs has increased. This implies that the computational parts of the designs have become larger, and more important, communication between various design modules have become more complex. This complexity makes these designs harder to test and verify.

In contrast, most of the designs have software parts and hardware modules. In the traditional design methodologies, a software team has to postpone software tests to the time when the hardware models have been mapped to an actual hardware. This sequence delays the whole design and development process.

The need to have shorter time-to-market leads to the fact that designers should parallelize hardware and software development processes. This concept directs them to hardware/software codesign, coverification, and cosimulation.

Partitioning is another issue which becomes more critical when designs grow more complex. As the design complexity increases, the effect of module partitioning or hardware/software partitioning on intra- module communications becomes more important. If partitioning is not done properly, communication between modules becomes a bottleneck. Therefore, partitioning in a design plays a very important role in performance, speed, power dissipation, and area requirement of the final hardware.

The problems stated above (hardware test and verification, hardware/software codesign, and partitioning) can be eased by electronic system level (ESL) design. In recent years, designers have moved their design methodology to system level. The heart of the ESL design methodology is a high-level language that is used for specification of a complete system. This language can be C/C++, Java, SystemC, and perhaps other high-level programming languages. There are other languages known as system level design languages (SLDL), like Rosetta, for developing a design at the system level, which are now in their development stages. At the present time, most designers use C/C++ and its application-specific libraries (like SystemC, Handel-C, and ArchC) as their system level design language.

ESL Methodology—The point that makes system level design a more powerful methodology than register transfer level (RTL) is that in ESL, designers are not concerned with design details. Since most modules are described at a high level of abstraction, a designer has an overall view of the complete system. Therefore, the designer can decide on problems like partitioning, system functionality, and developing testbenches in a more organized fashion. Other problems like the exact delay of each part, signal glitches, and other problems, which need the details of a design can be solved during the conversion process from system level to RT level or in the RT (or even gate) level design.

Figure 86.1 shows the necessary steps in a system level design. It is important to note that the ESL design methodology in Figure 86.1 is not the only proposed methodology for ESL. A design team can have its own customized design methodology and the methodology in Figure 86.1 is only shown to clarify the ESL concept.

In Figure 86.1, most of the steps like system partitioning and converting to RTL could be performed automatically. However, the lack of ESL tools forces designers to perform such steps manually or semi- manually. Although many ESL tools have become available to the System on Chip (SoC) market, they do not completely support the ESL concepts. The reason is that an ESL design is a new concept and many of its aspects are still in the study phase (e.g., analyzing the design for partitioning and complete behavioral synthesis).

The use of several high-level languages, like UML 2.0, C/C++, and SystemC have become more common than other programming and hardware languages for description of an ESL system. Although SystemC is a library developed in C++ and it is not a separate language, it is generally regarded as a language by the hardware design community.

In what follows, we will describe UML 2.0, C/C++, and SystemC as ESL design languages in separate sections. In the final section of this chapter, an important concept in ESL known as Transaction Level Modeling (TLM) will be discussed. As stated above, the complexity of today’s designs results in the complexity of the communication between various parts of a system. Using TLM, these communications can be modeled in higher levels of abstraction which will result in a faster simulation process and an easier verification.

Unified Modeling Language

As stated above, the necessity of having high-level languages for modeling large systems has become very important in the recent years. The complexity of software systems grows faster than hardware designs. Therefore, the need for a standard methodology for system design in software engineering became evident sooner than that of hardware designs.

In late 1994, Booch and Rumbach began the study of unifying Booch and object modeling technique (OMT) methods. This led to the generation of a graphical modeling language called Unified Modeling Language (UML). UML 0.9 and 0.91 were released in mid-1996. After receiving several feedbacks, a Request For Proposal (RFP) was issued by Object Management Group (OMG). As a result, organizations and companies produced a joint RFP response which led to the definition of UML 1.0. The companies which contributed most to the definition of UML 1.0 include Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI SystemHouse, Microsoft, Oracle, Rational Software, Texas Instruments, and Unisys. UML 1.0, which was a well-defined and powerful modeling language, was submitted to OMG in 1997 as an initial RFP response. During the following years, these companies and several other companies joined UML partners for contribution. Several revisions were released and several Computer-Aided Software Engineering (CASE) tools were developed for supporting UML language during these years.

In the next section, the role of UML in hardware design will be discussed. Then, a small system will be shown in Section 86.1.2. Parts of this system are used to demonstrate examples for different UML diagrams. Since UML has many details and it is a very large and complete language, we will not be able to discuss all its details. Therefore, in the last section, after describing a few UML terms, we will only describe UML diagrams briefly. An example, which is a part of the small system demonstrated earlier, will be shown for each diagram. For more details on this language, the reader can refer to Refs.[1,2].