Specification of Reactive Hardware/Software Systems - Electronic ...

1.1 Objectives 5
Informal and Formal Approaches
Specification methods that are introduced and accepted by industry are all, at least
partially, informal. This has the advantage of making descriptions readable for a broad
audience. A disadvantage is that informality makes specifications imprecise. Methods
that are industrially accepted may seem to be mature in some way. From our point of
view, however, industrially accepted methods are not yet mature at all. They will never
be able to close the gap to lower level automated design tools, because their informality
severely complicates automation. Future tools must offer:
functional simulation;
formal verification;
behaviour-preserving structure transformation.
Specifications must be readable, precise, unambiguous and robust system descriptions.
A method should therefore be built upon a language with formal mathematical semantics.
As many requirements as possible must be unified into in a formal system
description. A formal representation of the system to be developed should be verified
against various properties. Design tools should offer procedures for restructuring a
model according to architectural and implementation constraints. Formal semantics
offer a solid base for further development of various tools such as compilers, design
entry tools, structure transformations tools, and compilation tools.
Besides the world of informal methods there is a world of formal specification techniques.
Research that has the objective to develop a new specification language, must
take into account results achieved in this area. The state of the art in formal specification
is not yet mature in the sense of being widely accepted. Current formal specification
languages are in general difficult to understand. They tempt to avoid overspecification
and imperative descriptions. Formal approaches do in general not fit the designer’s
experience and intuition. Designers are in general familiar with one or more imperative
programming languages. The imperative way of thinking also matches the controller
approach that is often used by hardware designers. Local behaviour is described as
sequences of commands. An imperative specification language will therefore have a
greater chance of acceptance.
Method Design
The design of a specification language for complex reactive information processing
systems that is able to describe (physical or logical) structure is not trivial. History has
shown that even the design of a simple language is a difficult task. Coalescing concepts
into a language often leads to unexpected counterintuitive effects. The development of
a formal semantics can prevent a lot of problems.
The design of a complex reactive system is as complex as the real world is. There are
a lot of aspects that play a role, but that cannot be formally specified. Furthermore,
a formal description is not suitable as a communication medium for everybody in the