• No results found

AN ANALYSIS AND CLASSIFICATION OF SYSTEM LEVEL DESCRIPTION LANGUAGES. Andrew Mihal

N/A
N/A
Protected

Academic year: 2021

Share "AN ANALYSIS AND CLASSIFICATION OF SYSTEM LEVEL DESCRIPTION LANGUAGES. Andrew Mihal"

Copied!
9
0
0

Loading.... (view fulltext now)

Full text

(1)

AN ANALYSIS AND CLASSIFICATION OF

SYSTEM LEVEL DESCRIPTION LANGUAGES

Andrew Mihal

University of California, Berkeley

EECS Department

211 Cory Hall #1772

Berkeley, CA 94720–1772

mihal@eecs.berkeley.edu

ABSTRACT

Many research projects have been centered on the design of a single, unified language for system design. In most cases, these projects have built upon or extended existing lan-guages such as C++ or VHDL in an attempt to make them more amenable to writing abstract descriptions of compli-cated systems. In this paper, we classify several system lev-el description language (SLDL) projects according to their foundation languages and analyze their strengths and weak-nesses. We present a formal set of SLDL requirements and propose a new direction for future SLDL research based on these findings.

1. INTRODUCTION

It is a clear trend that embedded systems are becoming more complex as semiconductor technology improves. One particular facet of this trend is the increasing use of hetero-geneous architectures. As architecturally diverse systems continue to grow in complexity, the need for powerful design tools will also grow. The role of the system level descrip-tion language is to fill this need. In the last few years, there has been an abundance of research projects aimed at find-ing a complete and definitive SLDL. These projects have achieved varied levels of success.

Most embedded system co-design projects attempt to address the issue of system level design by taking an ex-isting domain-specific language and layering on additional features. The goal of these attempts is usually to improve the expressiveness of the language in respect to communi-cations and data modeling abstraction.

Typically, the language in question suffers from one of two problems. On one side, the language does not allow the designer to describe the concurrency, communications, and synchronization required for the application. On the other side, the language does not allow the designer to model da-ta in a sufficiently abstract fashion. Proposed solutions to these problems have included schemes ranging from thread libraries for process-level concurrency to extra syntactical constructs for object-oriented data. In this paper, we ana-lyze a comprehensive set of these proposals in depth.

The motivation behind these proposals is simple in that conventional languages have a wide user base and a rich set

of design tools already available. Designers are often reluc-tant to learn languages that are based on abstract modeling techniques because it requires giving up the fine-grain con-trol over implementation that they are accustomed to. As we will show, extensions to conventional languages will only take us so far.

Add-on libraries and extended semantics are stopgap measures that are unable to address all of the requirements of a formal SLDL. Such languages simply do not support the degrees of abstraction required for complex heterogeneous system design, and this problem will become more relevant as the complexity of embedded systems increases.

2. SLDL REQUIREMENTS

The System Level Design section of the Industry Standards Roadmap[8] lists a comprehensive set of criteria for system level design languages that focuses on the necessity for a rich set of abstractions. The given criteria favor a top-down design approach that allows a designer to gradually refine a design through several layers of abstraction. The pro-posed layers of abstraction strongly consider the deficien-cies in communications interfaces and data modeling that have proven problematic for conventional languages. More importantly, the Roadmap considers the issues that typical language-extension projects have not yet faced, such as con-straints specification. In the following list, we summarize the key points of the Roadmap and related work[3, 19] to set the groundwork for our analysis of current system level description languages.

Composeable and Hierarchical. A SLDL must al-low designers to describe systems as a hierarchy of sub-systems. The hierarchy must supportpartial specification, wherein a portion of the subcomponents are not completely described. Subsystems can be easily added or removed from a larger system, and they can be independently designed, verified, and implemented.

The concepts of hierarchy and composition are often taken for granted in modern design languages, but their im-portance must not be overlooked. Hierarchical languages support the intuitive divide-and-conquer design strategy. As design reuse and intellectual property issues become more prevalent, composition will also grow in importance.

(2)

A SLDL must allow designers to describe, simulate, and verify systems at many levels of abstraction. As design de-cisions are made based on the results of experimental simu-lations, various portions of the system design will be gradu-ally refined with more implementation-specific descriptions. This is the classic top-down design methodology. In the early stages of heterogeneous system design, it is seldom known what the exact performance requirements of various subsystems will be, or what the partitioning and interface between components will be. It is therefore necessary at first to model the system at a level of abstraction above that of partitioning and communications so that proper ex-periments may be carried out. This issue appears across the spectrum of design decisions from high-level partition-ing to low-level bit manipulation, thus justifypartition-ing the need for multiple levels of abstraction.

Requirements Specification and Assignment. A SLDL must allow designers to document the various re-quirements the system must meet. These may include area, power, real-time constraints, and many other requirements. The SLDL must allow the designer to divide up the respon-sibility for the satisfaction of these requirements among the subsystems in the design.

Typically, engineers seldom want the hassle of anno-tating designs with constraint information, especially when such constraints are only viewed as “comments” that have no affect on the implementation of a design when it is pro-cessed by CAD tools. Proper documentation is essential for three reasons. First, performance and constraint data is necessary for thorough simulation of high-level abstract models. When experiments are being carried out upon var-ious architectural tradeoffs, the constraint information will make it easy to evaluate alternatives according to the fun-damental design requirements. Second, the constraint in-formation is important for the refinement stages of a design. As each subsystem is implemented, designers can see exact-ly what constraints must be followed. Last but not least, the constraints come into play during design verification. A common complaint in the field of systems verification is the lack of formal specifications to judge an implementation against. In all, even if constraints specification seems a su-perfluous task, it is important to make the documentation process a key part of the design flow.

Constraints Propagation. The system of constraints documentation must adhere to the multilevel-abstraction design methodology. First of all, constraints must propa-gate from high-level models to low-level models alongside the subsystems they affect. This occurs as global design requirements are broken up and assigned to individual sub-systems, and closely mirrors the top-down design refine-ment methodology. Second, performance data and other implementation-specific metrics propagate up the layers of abstraction from low-level to high-level. This allows design-ers to verify that the individual subsystems adhere to the fundamental design constraints at any level of abstraction. In summary, constraints propagation is a two step pro-cess. Constraints follow along with subsystems as their im-plementations are refined. The results of the implementa-tion are then propagated backwards through the levels of abstraction so that it is possible to verify that design con-straints have been satisfied.

Concurrency and Communication. A SLDL must allow designers to describe concurrency on many levels, from concurrent processes to instruction-level parallelism to bit-level parallelism. The way in which processes com-municate, synchronize, and react to their environment must also be expressible.

Concurrency has long been an issue in software de-sign for parallel architectures. Compiler technology has not found much success in the automatic extraction of paral-lelism from sequential languages, yet technologies such as multiprocessing, superscalar machines, and SIMD architec-tures are common. To make full use of these architecarchitec-tures, it is best left to the designer to explicitly state the nature of the parallelism in the design. This is a critical feature of a SLDL.

Concurrency alone is only marginally useful, however. A SLDL must also express communication, synchronization, and reactivity at multiple levels of abstraction. For exam-ple, a designer could specify a set of asynchronous processes at an early stage in the design process that communicate over an abstract bus. Refinement of the communications interface will later yield a specific protocol, and eventually an implementation of that protocol. The main issue is that designers must not be forced into using a specific commu-nications model simply because the design language is tied to a particular one.

Computation. The above requirements satisfy the needs of thecontrol-oriented aspects of a system. To model thedata-orientedaspects of a system, the SLDL must allow for abstract modeling of data and computation.

Languages such as Statecharts[14] and Esterel[10] are lopsided in that they favor the description of control-dom-inated systems and lack the expressiveness to describe com-plex computation. A SLDL should not favor one side over the other. It is possible to apply many of the object-oriented programming concepts from traditional software engineer-ing to systems design. This not only improves the modelengineer-ing of data and computation, but it also allows data to be mod-eled within the framework of multiple abstraction layers.

Implementation Independence. Even though we have stated that a SLDL must be sufficiently expressive to handle both control and data modeling at many levels of abstraction, we do not mean to imply that a SLDL should be a monolithic language used exclusively throughout the design process. In some cases, it may not be possible to adequately describe the solution to a problem in a language that tries to “do everything.”

Instead, the SLDL should expect that designers occa-sionally want to implement certain sections of a design using conventional domain-specific languages. The SLDL should make the process of integration with domain-specific lan-guages as painless as possible. Specifically, the SLDL should not adversely bias the decisions concerning the implementa-tion of a system. The proper role of the SLDL is to provide a framework for systems design, not an inescapable trap.

3. CLASSIFICATION AND ANALYSIS

In this section, we analyze two categories of SLDL projects according to the criteria given above. The projects are grouped according to the type of language that is used as

(3)

a foundation.

3.1. C++

The first group of languages build upon C++. C++ is the ubiquitous software programming language. It not only has a wide user base, but it has a large set of development tools already in place. C++ may appear at first to be a good candidate for systems design, but it lacks many of the features that are imperative for a complete SLDL. Some of these features can be added on with extra libraries and syntax constructs, and others cannot.

Two advantages of C++ are that it is hierarchical and composeable, and that it allows for expressive modeling of data and computation. The functional nature of C++ makes it easy to break down the behavior of a design into sub-behaviors, and there are no undue limits on the degree of the hierarchy. It is understood, however, that C++’s lack of concurrency limits the sense in which a process can be decomposed into a set of independent sub-processes. The a-bility to easily construct C++ programs from software com-ponents is perhaps more interesting. This style of design is becoming more popular as technologies such as JINI and Vi-sualBASIC mature. Although these technologies are geared towards software, the same concepts can be applied to sys-tems design in a language like C++. We expect this issue to become significantly more prevalent as more designers choose to use intellectual property cores for standard com-ponents instead of re-engineering previously created design-s. When custom or non-standard components need to be created, the object-oriented features of C++ provide an ef-ficient means for modeling data in an abstract fashion.

The most significant drawback that prevents C++ from being a good SLDL is its lack of concurrency. Without this feature, it is impossible to model independent communicat-ing processes. It follows from this that there is no support in C++ for describing abstract communications or synchro-nization. Aside from this shortcoming, there is no support in C++ for describing design constraints such as timing or performance. These issues are not important for software design but are necessary for system design. All of these disadvantages have not dissuaded researchers from trying to use C++ as a foundation for a SLDL. In the following sections we analyze two projects that carefully address the deficiencies in the C++ language.

3.1.1. Weiler, Kebschull, and Rosenstiel

The work of Weiler, Kebschull, and Rosenstiel[23] intro-duces an approach to system design using C++ in conjunc-tion with special base classes for concurrency. The main concept behind this paper is that C++’s object-oriented features and inheritance mechanisms can be used to de-scribe concurrent processes as derivatives of a base class that provides runtime support for parallelism using ordi-nary threads. To use this system, designers simply ignore the regular semantics of C++ objects and think about class-es as definitions of discrete procclass-essclass-es. The concept of in-stantiating a C++ object derived from the base class e-quates to the dynamic creation of a parallel thread. When such an object is destructed, the parallel process is termi-nated. This works well for systems that can be decomposed

into a hierarchy of dynamic processes. Typically, the C++ program will instantiate a single copy of a toplevel object which will in turn spawn subprocesses as it sees fit. Once the toplevel object is created, the inherent sequential na-ture of the C++ program gives way to the parallel process-es and the “program” is driven by mprocess-essagprocess-es passed between the parallel objects. This is the same theory that drives the object-oriented message-passing interface commonly found in GUI programming toolkits.

The base class presented in the paper provides an ab-stract function for communications. Instances of processes communicate by calling each other’s overridden copies of this function. This action may be non-blocking. When passing a message, a process must specify exactly which concurrent process they wish to pass a message to. The content of the message and the action taken by the recipi-ent are programmed by the designer in the public interface functions.

Given the dynamic process environment, it is not clear in the paper how two processes are supposed to find each other. In the simple case, a parent object can keep track of the children it has spawned and communicate with them di-rectly. Communication between unrelated processes would be more challenging.

The benefits of this approach are clear. First, process-level concurrency can be described in C++ without chang-ing the syntax of the language. The new semantics are not too different from the message-driven programming style used to write GUI software applications. Second, all of the complexity of communication and parallel process creation (using threads) are kept behind the scenes in the base class. The end result is that the system description is kept intu-itive and free from unnecessary overhead, and the system’s behavior can be simulated simply by compiling and execut-ing the program with an ordinary C++ compiler.

The paper goes further to explain how a system de-scribed using these class objects can be refined into an actu-al implementation on a heterogeneous target architecture. The authors present a partitioning methodology wherein results from system simulations are used to aid in auto-matically assigning individual processes to the computa-tional resources in the system. The emphasis is on general hardware/software partitioning. Once resource assignments have been made, implementations for the software portions of the design can be trivially extracted from the original C++ code. The hardware components are another mat-ter. Although additional independent research has shown the feasibility of synthesizing hardware directly from se-quential code [21], the authors feel that the quality of the results is not acceptable. Instead, the authors suggest that refinements to the hardware-specific portions of the system be made manually using domain-specific languages such as VHDL or Verilog.

In all, this work succeeds at improving on some of the problems that C++ has as a SLDL. Process-level concur-rency is provided with a library of base classes for thread-ing. An infrastructure for communications is provided that is based on message passing, allowing the designer to model communication at an abstract level. Designs can be simu-lated and analyzed as well, but implementation for the most part requires a hand-off to domain-specific languages.

(4)

Unfortunately, there are many issues this research does not address. First of all, the implementation of concur-rency is incomplete. The base classes allow designers to model process-level concurrency, but there is no support for instruction-level or bit-level concurrency. It is not pos-sible to describe local parallel computations or operations on data types other than C++’s generic int, char, and other types. This rules out SIMD-like operations. Second, the model for communications is incomplete. The message passing interface does not support pre-emptive behavior. This makes the communications interface not truly reac-tive. There is no concept in C++ of a class object having a regular behavior that can be interrupted by a call to one of the object’s member functions. One example of where this becomes a problem is in the handling of external event. Pro-cesses can communicate to other proPro-cesses using messages, but it is unclear how to define a process that performs an action while waiting for an event such as a trigger, alarm, or timer expiration. Third, the support for constraints def-inition, assignment, and propagation is nonexistent. Some implementation metrics are used to help in the partition-ing process, but this does not replace a complete system of constraints management that allows designers to documen-t and analyze documen-the performance of a sysdocumen-tem adocumen-t many levels of abstraction. Real-time constraints in particular are not considered. While this work does present a possible solu-tion to the concurrency problem, C++ is still a long way from a workable SLDL.

3.1.2. Scenic

The Scenic Design Environment[17], now known as Sys-temC, was developed by researchers at the University of California at Irvine and Synopsys. Scenic goes further to extend the functionality of C++ as a SLDL. This system also uses base classes to add features without changing the syntax of the language or requiring customized compilers. Like the work of Rosenstiel et al., Scenic provides a base class for describing concurrent processes. Communication between processes is signal-driven.

Scenic offers three major improvements over the work of Weiler, Kebschull, and Rosenstiel. They include an im-proved system of communication and reactivity, support for bit-level custom data types, and enhancements favoring simulation and automatic synthesis.

First, Scenic does away with the system of explicitly defining member functions as the sole interface by which concurrent processes can communicate. That methodology restricts the extent to which reactivity can be described be-cause the concept of a signal and the concept of a function call are inseparable. Scenic supports pre-emptive commu-nication by modeling signals as abstract objects based on C++ exceptions. This makes it possible to define object-s that have regular, continuouobject-sly executing behaviorobject-s that react to events. Signals themselves must be defined as ob-jects. Special functions called lambda functions are used to evaluate events on signals. The name lambda is used because the semantics of the lambda function resemble the λ-abstraction inλ-calculus. Scenic provides a wait until

function and awatchingfunction that processes use to in-dicate what lambdas they want to be sensitive to. The

wait untilfunction puts a process to sleep until the lamb-da evaluates totrue. Thewatchingfunction is used to indi-cate that a process wants to be preempted (bycatch-ing an exception) when the lambda evaluates totrue. Scenic uses operator overloading to make the instantiation of lambda functions transparent. For example, a designer can write:

wait until(start == ’1’);

to create an instance of a lambda that waits for thestart

signal to be asserted while simultaneously adding sensitiv-ity to the exception thrown by that lambda. This makes the use of lambdas more intuitive.

Second, Scenic does not restrict the designer to the use of C++’s built-in data types. A set of template classes pro-vide the functionality of arbitrary-width, multi-logic-valued bit vectors. Signed and unsigned arithmetic is defined on these objects. The functionality is similar to thestd ulogic

andstd ulogic vectorpackages in VHDL. This is done in accordance with Scenic’s strategy to make C++ more like a conventional hardware description language.

Third, Scenic has some advantages over the previous work in regards to simulation and synthesis. The authors recognize the fact that in system simulations a high amoun-t of overhead is incurred in amoun-the conamoun-texamoun-t swiamoun-tches beamoun-tween concurrent processes. This is especially true when process-es only execute briefly to check the status of the signals they are waiting on and then immediately go back to sleep. The purpose of the lambda functions is to solve this prob-lem. If a process simply executed a comparison to check the condition of a signal, the process would have to be period-ically woken up to perform this action. Instead, processes in Scenic instantiate lambda functions asvirtual expression-sthat can be evaluated outside the context of the process. Hence, a context switch does not have to be performed to test if a process should be woken up. This speeds up simu-lation by about 20%.

The improved model of reactivity and the inclusion of templates for custom bit-vector data types makes it easi-er to map Scenic applications into hardware. Because the semantics of the communications interface is closer to that of VHDL, it is easy to translate the C++ into a subset of VHDL suitable for processing by a behavioral synthesis tool. With some additional work, the goal of automatic synthesis from a high-level Scenic description to physical hardware and software implementations may be possible.

In all, Scenic is an improvement over the previous C++-based SLDLs, but it still leaves out some important issues. Constraints modeling is absent from Scenic. Also, it is un-clear how processes will react to simultaneous or closely spaced events. The behavior in these cases will likely rely on the implementation of the C++ exception mechanism. The exception mechanism may not provide a sufficiently ab-stract model of reactivity for some complex behaviors. The bit-level data types provided by Scenic bring up another is-sue. This feature is practical and useful, but it is essentially an implementation-specific low-level modeling tool. In ad-dition to arbitrary bit-level data types and the conventional C++ data types, a SLDL should provide a mechanism for modeling abstract data types. This ensures that designers will be able to model data at many levels of abstraction. C++ classes have the potential to be used to create more abstract models of data. Finally, the methodology Scenic

(5)

uses for hardware synthesis is not truly implementation in-dependent. Since the C++ to VHDL back end converts C++ expressions into behavioral VHDL on a line-by-line basis, small changes in the way a system is described can lead to drastically different automatically generated imple-mentations. Literal translations should be avoided. This is as challenging issue for behavioral hardware synthesis sys-tems.

3.1.3. Conclusions

In summary, we have analyzed two research projects that use C++ as a foundation language for a SLDL framework. Both projects recognize the deficiencies in the C language and attempt to overcome them without changing the syn-tax of the language or requiring modifications to the ex-isting tools. It is clear that the lack of concurrency in the C++ language can be partially overcome through use of threading libraries. Templates can be used to define bit-vector data types for bit-level operations. Neither of these schemes quite matches the functionality or intuitiveness of a language that has native support for concurrency. For example, these two projects have not shown any support for instruction-level parallelism within the context of a pro-cess. The closest approximation is to define a process as a composition of two or more parallel processes. The support for modeling communications is also not as good as that of a natively reactive language. Both projects tie communi-cations to the semantics of an underlying C++ construct (function calls or exceptions). Therefore, it is not always clear how to model some behaviors.

Neither project has attempted to handle the issue of constraints specification or verification. This is not han-dled even in conventional real-time software programming practice. As discussed earlier, it is a necessary feature for systems design. Projects such as VSpec[1] and Rosetta[2] have looked into ways to formally specify the constraints on a system, but these methodologies have not been put into practice yet.

Recently, CynApps Inc. has announced a commercial product called CynLib that aims to put a C++ class li-brary for system-level design into popular use. Like Scenic, CynLib uses C++ classes to provide an environment for modeling concurrency and communications. Emphasis is placed on the issue of automatic synthesis from the high-level system description. This attempt at vertical integra-tion may clarify the role of a product like CynLib in the market.

Overall, it is difficult to say whether C++ is a viable foundation language for a SLDL. The trend so far has been to eschew changes to the semantics of the language, yet the implementations of concurrency and communications that have appeared do not always provide the exact and pre-dictable behaviors that designers expect. This is the main problem in trying to massage the elements of a language to provide a set of semantics that were never intended to be there. We believe that it will be necessary to make changes in the syntax to produce a framework for concurrency and communications that matches the formal definitions of par-allelism and reactivity. Hopefully, more research in this area will help to elucidate these issues.

3.2. VHDL and Verilog

The second group of languages build upon hardware de-scription languages such as VHDL and Verilog. This ap-proach to defining a SLDL can be thought of as being dia-metrically opposite of the C++ approach. Instead of trying to make a software language more hardware-oriented, these projects try to make a hardware language more software-oriented.

The strengths of VHDL and Verilog coincide with the weaknesses of C++. First, HDLs have native support for concurrency and reactivity. This is helpful considering the challenges that have appeared in implementing these fea-tures within an inherently sequential language. Second, HDLs have a basic framework for multiple levels of abstrac-tion and design refinement. A designer can create behav-ioral and structural models in VHDL that share the same interface. Any combination of these abstractions can be simulated together. As expected, designs can be built in a hierarchical fashion and composed out of pre-defined com-ponents.

One should expect the weaknesses of HDLs to loosely match the strengths of software languages, and this is in fact the case. VHDL and Verilog do not have any mechanism for modeling abstract data. The designer is forced into describing circuits and not dynamic systems of interacting processes. It is not possible to describe a process that can be instantiated when the system needs it and then destroyed when no longer in use.

Unlike C++, it is possible to use a HDL to model the timing behavior of a process, but it is difficult to do so in an abstract fashion. The timing model in HDLs is very low-level. Timing statements model detailed events such as propagation and gate delays even when circuits are being designed at the behavioral level of abstraction. Further-more, the timing model is not intended to be used to specify design constraints. These is no formalism for documenting general design parameters and assigning them to various subsystems. Likewise, the implementation-specific timing data that can be modeled cannot be back-annotated in such a way as to allow the verification of design constraints.

Several papers have directly addressed the issue of mak-ing extensions to HDLs to support system-level specifica-tions [4, 5, 19]. The general consensus is that VHDL’s Ada-like syntax makes it a good candidate for object-oriented extensions. We analyze two similar projects, Vista OO-VHDL[22] and SUAVE[6] in the following section. These projects attempt to address VHDL’s data modeling defi-ciencies by adding object-oriented features to the language in a manner that impacts the existing functionality the least. An alternative approach, known as VSpec, address-es VHDL’s lack of a methodology for specifying abstract functional requirements and performance constraints. This approach is analyzed in the second section.

3.2.1. Vista OO-VHDL and SUAVE

Vista OO-VHDL and SUAVE are very similar in their ob-jectives. By adding object-oriented features to VHDL, the designers hope to improve VHDL’s support for high-level behavioral modeling, communications modeling, and design reuse. The result is a language that is a superset of VHDL

(6)

in the same way that C++ is a superset of C. New syntax constructs are made available without the loss of any of the original VHDL functionality.

Vista OO-VHDL adds the concept of an EntityObject that is used to describe an abstract design module. The EntityObject is an extension of the VHDL entity and can be used alongside ordinary entities. EntityObjects give sys-tems designers a new degree of freedom in modeling data and computation in an abstract fashion by allowing for data encapsulation, inheritance, and polymorphism.

VHDL’s existing support for data encapsulation is not general enough to support object-oriented design. The most that designers can do is to hide the computational part of a module behind the port map interface. The port map does not provide a sufficiently abstract interface to the en-tity. The port map provides a list of signals but it does not provide any knowledge on how to use the signals to get the entity to perform the desired behavior. OO-VHDL’s En-tityObject construct allows designers to specify functions, known asoperations, as an abstract interface to the objec-t. EntityObjects interact by calling each other’s interface functions. This is a notable improvement over the standard VHDL communications mechanism wherein entities must communicate by directly manipulating bit-level signals ac-cording to the requirements of ill-defined protocols. In all, the system is similar to the message-passing interface in section 3.1.1.

The new methodology for defining component interfaces lends itself to a new model of inheritance. In standard VHDL, designers can create many architectures based on the same entity that implement a component at differen-t levels of absdifferen-tracdifferen-tion. Any implemendifferen-tadifferen-tion model can be substituted for another when the design component is in-stantiated. In the Vista OO-VHDL language the same thing is true but on a different level of granularity. When a new architecture is created for a VHDL entity, only the port map and none of the functionality of other architectures is inherited. In OO-VHDL it is possible to refine an Entity-Object without discarding any of the original functionality immediately. When an EntityObject is derived from anoth-er EntityObject, it inhanoth-erits all of the intanoth-erface opanoth-erations of the parent. Designers can elaborate their objects by over-riding the parent’s interface operations one at a time. It is not necessary to start from a clean slate at each step in the design refinement process. The feature makes design refine-ment more intuitive and productive, which is a requirerefine-ment of a good SLDL.

The SUAVE project accomplishes many of the same goals by integrating some of the object-oriented features of Ada-95 into VHDL. SUAVE’s object-oriented features are not restricted to entities but can be applied to data types in general. The fact that signals in SUAVE can be object-oriented data types presents some unique challenges in the area of communications. If an object is used to implemen-t communicaimplemen-tion beimplemen-tween implemen-two concurrenimplemen-t processes, implemen-then there may be synchronization issues regarding access to the object. In particular, if the data type maintains any internal state and allows processes to modify the state through inter-face functions, the data type must be considered a shared resource and access to it must be carefully scrutinized to avoid possible race conditions and deadlocks. The

design-ers of SUAVE sidestep this issue by requiring all such state variables to be explicitly labeled with the keywordsaccess private. This precludes the data type from being used as a signal. One example presented in the SUAVE paper is a data object implementing a list. This is a useful compo-nent, but synchronization issues would abound if a list were indiscriminately shared by two or more concurrent process-es. The restriction is not meant to limit the expressiveness of the language but to alleviate the burden on the designer to consider complex synchronization issues.

Overall, these two projects make significant progress in improving VHDL’s support for modeling data and compu-tation in an abstract fashion. The changes require modifi-cations to the VHDL language syntax but the modifimodifi-cations are small and do not hinder the normal functionality of the language. It remains to be seen how productive these fea-tures will be in a real-world design environment.

One of the best features of VHDL is the ease with which a design can be automatically synthesized into a hardware implementation. To do the same with the new abstract modeling constructs would require considerable ad-vances in behavioral synthesis technology. Also, neither of these projects consider constraints modeling as an issue for system-level design. VHDL natively supports concurren-cy and hierarchy, and the object-oriented features improve the support for abstract data modeling, but constraints and performance modeling has not entered the picture yet. This issue will have to be solved in order for a language like OO-VHDL or SUAVE to gain acceptance as a SLDL.

3.2.2. VSpec and Rosetta

The VSpec project takes a wholly different approach to extending the capabilities of VHDL. Instead of focusing on improving data modeling support, VSpec adds func-tional requirement and performance constraint modeling to VHDL. The core observation of the paper is that the top-down system design process requires designers to mod-el many different facets of the system. VHDL alone pro-vides only two facets: behavioral and structural. There are no facets for functional requirements or performance constraints. VSpec adds this functionality by extending VHDL’s syntax to support a declarative semantics for mod-eling requirements. This is done by adding sections other than a port map and a generic map to a VHDL entity dec-laration.

Functional requirements are specified using a state ma-chine model. The keywords sensitive to,requires, and

ensuresare used to declare clauses for sensitivity lists, pre-conditions, and post-conditions in the entity declaration. These clauses specify how the component reacts to its in-puts, what set of inputs are considered valid, and what conditions are guaranteed to be true after the component executes. Together these clauses define the functionality of a component at an abstract level.

The functional requirements have two main uses. First, they provide a set of guidelines that can be used to de-termine if a behavioral or structural implementation of a component is correct. Second, they can be used to verify the control flow of a system of components. VSpec uses the activation conditions specified in thesensitive toclause

(7)

in conjunction with a process algebra based on CSP[13] to accomplish this. The mathematics are somewhat involved, but the main idea is that for any component that is de-scribed as a composition of subcomponents, it is possible to compare the functional requirements of the component to the consolidated requirements of the subcomponents. This makes it possible to test for functional equivalence across two layers of design refinement, which is an important ca-pability of a SLDL. Such a decomposition in VSpec is called anarchitecture.

Performance constraints are specified in VSpec by us-ing aconstrained byclause in the entity declaration. An example given in the paper is:

entity foo is

. . .

constrained by

area≤(3µm×5µm) and power10 mW

and clock frequency≤50MHz; end foo;

Unlike functional requirements it is not easy to relate the performance constraints facet of a design to other facets like the behavioral or structural implementations. VSpec’s authors do not have an answer to this problem.

The Rosetta specification language is based on many of the ideas from VSpec. Rosetta is meant to be a gener-al specification language that can be used in conjunction with any design language. Constraints and requirements are modeled in Rosetta by defining an object called afacet. The meaning of the term facet does not change. It still is used to denote an abstraction of a system. Rosetta merely extends the formalism beyond VHDL’s rudimentary behav-ioral and structural facets with a new syntax that is not VHDL-specific. Rosetta facets may be defined directly or by composition out of other facets. Facet composition is based on a mathematical theory similar to that in VSpec. The decomposition of a system into facets is meant to par-allel the decomposition into behavioral or structural com-ponents. Thus, each component in a system description is represented by a facet.

At the time of this writing, the Rosetta language and the tools to support it are still under development. It is not clear at this point how successful Rosetta’s approach will be. Since the technology of synthesis tools is not sufficient-ly advanced to take advantage of constraints specifications, the role of methodologies such as VSpec and Rosetta is con-strained mainly to the conceptual organization of a complex system. The constraints exist only to help designers make design decisions during the process of system refinement. At this stage, the mathematics behind VSpec and Roset-ta are still quite complex. Perhaps with additional work the semantics of languages like VSpec and Rosetta can be cleaned up enough to make constraints specification efficient and intuitive.

3.2.3. Conclusions

The projects we have examined in this section take two different approaches to extending VHDL for system-level design. The approach of Vista OO-VHDL and SUAVE

is to improve VHDL’s data modeling support with object-oriented language extensions. These extensions are shown to be intuitive to use and satisfy most of the criteria for data and computation modeling described in section 2. Further-more, the proposed extensions do not change the existing language semantics. The object-oriented features can be used alongside standard VHDL without any problem.

The approach of VSpec is different. Instead of propos-ing yet another set of object-oriented language extensions, VSpec attacks the issue of constraints and functional re-quirements modeling. VSpec adds facets, or abstractions, to VHDL with additional clauses in entity declarations for declaring constraints and requirements. The mathematical model for the constraints provides for the decomposition, assignment, and verification of this information. These ex-tensions satisfy the criteria for constraints specification and propagation described in section 2.

So far, there have not been any projects that try to com-bine the features of VSpec with an object-oriented VHDL to create a complete SLDL. The System-Level Design Ini-tiative is in fact moving away from this approach. The Rosetta language is the first part of the philosophy that a single unified design language may not be the best tool for system design. Rosetta is targeted as a general constraints specification language to be used in conjunction with one or more design languages. Whether this mixed-language approach will be successful remains to be seen. Currently, the mathematical model behind Rosetta is fairly complex and nonintuitive. Hopefully this complexity will be hidden by the Rosetta design tools.

The Superlog language from Co-Design Automation In-c. challenges the mixed-language approach. While details on this language are not available yet, the designers claim that it will have support for abstract data and communica-tions modeling as well as constraints specification. Superlog mixes the data modeling features of C++ with the concur-rency of VHDL. The emphasis is on finding the right bal-ance between these languages to make system-level design efficient. The single-language approach is more attractive than the multi-language approach, but we feel that suc-cess will lie in the efficiency of the tools rather than the underlying design philosophy. Whichever package enables designers to create robust complex systems faster and easier will likely succeed.

4. RELATED WORK

Not all system-level description languages use a sequential programming language or a HDL as a foundation. The POLIS[7] framework developed at the University of Califor-nia, Berkeley, provides a system design environment based on the CFSM model. POLIS uses Esterel, a synchronous re-active language, as its native input language. A Statechart-to-CFSM conversion tool[9] developed at the University of Newcastle allows POLIS users to input their designs graph-ically in Statecharts instead of Esterel. The major issue in using FSM-based languages for system design is that they often lack the expressiveness needed to describe application-s that require complex computationapplication-s. The languageapplication-s work well for control-dominated systems, but there are many systems that are either data-dominated or have a mix of

(8)

control-oriented and data-oriented components. A SLDL should be generic enough to design all of them.

The Esterel-C language[16] addresses this issue by com-bining Esterel’s support for concurrency and reactivity with the data modeling features of the C language. A natural extension of this work would be to add object-oriented fea-tures from C++ to improve Esterel’s ability to model data abstractly, much in the way that was done with SUAVE and OO-VHDL. If this can be combined with a mechanism for describing performance constraints and functional require-ments, the language will meet all of the requirements for a SLDL.

An alternative approach is to use the SDL language pro-posed by the International Telecommunications Union[15]. SDL, or Specification and Description Language, is based on concurrent processes and non-blocking communication and is popular in the telecommunications domain. Several design environments for rapid prototyping using SDL have been proposed[11, 20]. These projects address the issues of design at multiple levels of abstraction and real-time con-straints specification. Other work has focused on object-oriented data modeling in SDL[18]. The semantics of SDL are still evolving[12].

The main challenge of these alternative SLDLs is to overcome the resistance towards moving to a new language. The best way to do this is through the quality of the design tools. All of the languages we have analyzed have their pros and cons, but no language in particular stands out as having some inherent advantage over the others. Designers should be willing to move away from languages like C++ or VHDL if alternative design environments can provide greater productivity.

5. CONCLUSIONS

In this paper we have analyzed two opposing approaches for defining a system-level description language. The first approach extends C++ with base classes for concurrency and communications. The second approach extends VHDL with object-oriented features for data modeling and declar-ative syntax constructs for constraints modeling. The goal of both approaches is the same: to produce a language suit-able for system-level design with only minimal changes to existing domain-specific design languages.

C++ and VHDL both have their strengths and weak-nesses in comparison to the SLDL criteria set forth by the System Level Design Initiative. Our analysis has shown the various ways by which the weaknesses have been overcome, with varying levels of success. The criterion that has re-ceived the least attention is that of constraints definition, assignment, and verification. While design constraints and functional requirements are a critical part of system design, they have been frequently overlooked. The mathematical models behind functional verification can be cumbersome, and performance constraints can rarely be used by synthesis tools to affect the implementation of a design. Hence, this aspect of system design is often glossed over in the projects we have analyzed.

While all of the languages presented in this paper do a passable job at improving the features of a domain-specific language, there are always minor flaws in the

implementa-tions that limit the generality of the languages. For exam-ple, the inter-process communication mechanisms in Weiler

et al. and Scenic are tied to their underlying C++ seman-tics. This makes it difficult to describe certain complex re-active systems. The object-oriented features of a language like SUAVE can also interfere with the semantics of VHDL signals. This is especially true for data types that main-tain internal state. As embedded systems become more complex, these issues may become problematic. Eventually designers will have to abandon the semantics of languages like C++ and VHDL and build systems at a more abstract level using a language that generalizes away these inconsis-tencies. However, it is likely that these languages will still be useful for system design in the mean time.

All in all, none of these languages have any inherent advantage over any of the others. Until a more general SLDL can be defined, the quality of the design tools will define the usefulness of these languages. It is our hope that continued research into system-level design tools will reveal solutions to the language issues presented in this paper.

REFERENCES

[1] P. Alexander and P. Baraona. Extending VHDL to the Systems Level. Proc. VHDL International Users Fo-rum, pages 96-104, October 1997.

[2] P. Alexander, R. Kamath and D. Barton. Rosetta Facet Semantics Strawman.The System Level Design Language Initiative, seehttp://www.inmet.com/SLDL, June 1999.

[3] M. A. Ardis and J. A. Chaveset al. A Framework for E-valuating Specification Methods for Reactive Systems - Experience Report. IEEE Transactions on Software Engineering, vol. 22, no. 6, pages 378-389, June 1996. [4] P. J. Ashenden and P. A. Wilsey. Considerations on System-Level Behavioural and Structural Model-ing Extensions to VHDL.Proc. International Verilog HDL Conference and VHDL International Users Fo-rum, pages 42-50, March 1998.

[5] P. J. Ashenden and P. A. Wilsey. A Comparison of Alternative Extensions for Data Modeling in VHDL.

Proc. of the 31st Hawaii International Conference on System Sciences, pages 207-215, January 1998. [6] P. J. Ashenden, P. A. Wilsey and D. E. Martin.

SUAVE: Painless Extension for and Object-Oriented VHDL.Proc. VHDL International Users Forum, pages 60-67, October 1997.

[7] F. Balarinet al.Hardware-Software Co-design of Em-bedded Systems: The POLIS Approach. Kluwer Aca-demic Publihsers, 1997.

[8] D. L. Barton. Systems Level Design Section of the In-dustry Standards Roadmap.The System Level Design Language Initiative, seehttp://www.inmet.com/SLDL, July 1998.

[9] I. D. Bates, E. G. Chester and D. J. Kinnimen-t. A Statechart Based HW/SW Codesign System.

Proc. of the Seventh International Workshop on Hard-ware/Software Codesign, pages 162-166, May 1999.

(9)

[10] G. Berry and G. Gonthier. The ESTEREL Synchron-ous Programming Language: Design, Semantics, Im-plementation.Science of Computer Programming, vol. 19, pages 87-152, 1992.

[11] O. Bringmann and A. Muthet al.Mixed Abstraction Level Hardware Synthesis from SDL for Rapid Proto-typing.Proc. of the Tenth IEEE International Work-shop on Rapid Systems Prototyping, pages 114-119, June 1999.

[12] R. Gotzhein, B. Geppert, F. R¨oßler, P. Schaible. To-wards a New Formal SDL Semantics.Proc. of the 1st Workshop of the SDL Forum Society on SDL and M-SC, volume 1, pages 55-64, June 1998.

[13] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, Englewood Cliffs, 1985.

[14] D. Harel. Statecharts: A Visual Formalism for Com-puter Systems.Science of Computer Programming, vol. 8, no. 3, pages 231-274, 1987.

[15] ITU-T. ITU-T Recommendation Z.100: CCITT Spec-ification and Description Language (SDL). June 1994. [16] L. Lavagno and E. Sentovich. ECL: A Specification Environment for System-Level Design.Proc. of the De-sign Automation Conference, 1999.

[17] S. Liao, S. Tjiang and R. Gupta. An Efficient Imple-mentation of Reactivity for Modeling Hardware in the Scenic Design Environment. Proc. of the Design Au-tomation Conference, 1997.

[18] M. von L¨owis and R. Schr¨oder. Object Oriented Data Concepts for SDL. Proc. of the 1st workshop of the SDL Forum Society on SDL and MSC, June 1998. [19] S. Narayan and D. D. Gajski. Features Supporting

System-Level Specification in HDLs.Proc. of the Eu-ropean Design Automation Conference, pages 540-545, 1993.

[20] S. Petters and A. Muthet al. The REAR Framework for Emulation and Analysis of Embedded Hard Real-Time Systems.Proc. of the Tenth IEEE International Workshop on Rapid System Prototyping, pages 100-107, June 1999.

[21] D. Soderman and Y. Panchul. Implementing C Design-s in Hardware: A Full-Featured ANSI C to RTL Ver-ilog Compiler in Action. Proc. International Verilog HDL Conference and VHDL International Users Fo-rum, pages 22-29, March 1998.

[22] S. Swamy, A. Molin and B. M. Covnot. OO-VHDL. Object Oriented Extensions to VHDL.IEEE Comput-er, vol. 28, no. 10, pages 18-26, October 1995. [23] C. Weiler, U. Kebschull and W. Rosenstiel. C++ Base

Classes for Specification, Simulation and Partitioning of a Hardware/Software System. Proc. of the ASP-DAC 95/CHDL 95/VLSI 95, pages 777-784. August 1995.

References

Related documents

perairan yang tidak terlalu dalam (kedalaman penangkapan berkaitan dengan kemampuan dan pengalaman dari nelayan yang bersangkutan); 3) Jenis lobster yang tertangkap di

Good mental health leads to life satisfaction for the geriatric residents, physical health is more impor - tant for the high subjective well-being of people living in their own

GOOD: Select this option if your wireless adapters DO NOT SUPPORT WPA NONE: Select this option if your do not want to activate any security featur Click Prev button

38 Will the normal (#1 transfer bus) power source be disconnected if the standby switch is placed in the BAT position..

I decided to back She’s On The Case in the Betfair win and place SP markets and, after running a very good race, she was beaten to second place by none other than Mrs Faulty and was

Despite its small sample size, this study has clinical meaning to apply the low-dose chest CT screening to colorectal cancer survivors, and to analyze the clinical outcome with

Today’s Song in Dialogue videoconference between Manhattan School of Music and the University of Michigan School of Music, Theatre, and Dance, featuring Thomas Hampson, uses a

The ordinal regression method was used to evaluate the relationship between ICT performance of the overall production procedures in Greek SMEs (enhancement of