LANGUAGES FOR SYSTEM LEVEL

SPECIFICATION AND DESIGN

PROF B ABDUL RAHIM AITS RAJAMPET 1

 Introduction
• Selecting a language is generally a trade off between several criteria:
– The expressive power of the language
– The automation capabilities provided by the model underlying the language
– The availability of tools and methods supporting the language
• Intermediate forms are used by the system design tools for the
refinement of the specification into an architecture
Two major types:
1. Language oriented – use graph representation
-- data flow graph
-- control flow graph
-- control data flow graph
2. Architecture oriented – use FSM/Datapath representation
-- closer to the final realization
• The intermediate forms may be based on simple or multiple threads

PROF B ABDUL RAHIM AITS RAJAMPET 2

• The use of languages-oriented intermediate
forms makes it easier to apply system level
transformations
• The use of architectures-oriented models
allows one to handle more sophisticated
architectures with features such as
synchronization and specific communication
buses.

PROF B ABDUL RAHIM AITS RAJAMPET 3

 SYSTEM-LEVEL SPECIFICATION
• The system level specification of a mixed
hardware/software application may follow one
of two schemes:
1. Homogeneous: A single languages is used for the
specification of the overall system including
hardware parts & software parts.
2. Heterogeneous: Different languages are used for
hardware parts and software parts
Ex: mixed C-VHDL model

PROF B ABDUL RAHIM AITS RAJAMPET 4

 Homogeneous specification
• A generic co-design environment based on homogeneous specification
shown below:
• Co-design starts with a global specification given in a single language
specification
– Independent of future implementation and partitioning of the system into HW
parts & SW parts
• The outcome is an architecture made of HW processors & SW processors
• This is generally called a virtual prototype
– May be given in a single language or different languages (C for SW, VHDL for HW)
• The co-design environment provides correspondence between initial
specification & target model – virtual prototype
• In order to reduce the gap between the specification model and the virtual
prototype, these tools start with a low level specification model

PROF B ABDUL RAHIM AITS RAJAMPET 5

PROF B ABDUL RAHIM AITS RAJAMPET 6
• Cosyma starts with C-like model called Cx
• Vulcan starts with another C-like language called
HardwareC
• Lycos & Castle starts with C
• Several co-design tools start with VHDL
• Only few tools tried to start from a high level
specifications
– Polis starts with Esterel specifications
– Specsyn starts from SpecCharts
– Cosmos starts from SDL

PROF B ABDUL RAHIM AITS RAJAMPET 7

 Heterogeneous specification
• Allows specific languages for the hardware & software parts
• Co-design starts with a virtual prototype when the hardware/software
partitioning is already made
• Co-design is a simple mapping of the software parts & the hardware parts on
dedicated processors
• Key issues are validation and interfacing
• The use of multi-language specification requires new validation techniques able
to handle multi paradigm specification
• Instead of simulation – needs co-simulation
• Instead of verification – needs co-verification
• Additionally, multi language specification brings the issue of interfacing
subsystems which are described in different languages
• These interfaces need to be refined when the initial specification is mapped onto
a prototype

PROF B ABDUL RAHIM AITS RAJAMPET 8

PROF B ABDUL RAHIM AITS RAJAMPET 9
• Coware and seamless are typical environments
supporting such co-design scheme
• They start from mixed description given in VHDL
or Verilog for hardware and C for software
• All of them allow for co-simulation
• However, only few of these systems allows for
interface synthesis

PROF B ABDUL RAHIM AITS RAJAMPET 10

 Design representation for system level
synthesis
• The design specifications used in co-design
• The goal is to focus on the computational models underlying specification
languages and architectures
Synthesis intermediate forms:
• Most co-design tools use internal representation for refinement of the
input specification into architecture
• Input specification – human readable format
– Textual language (C, VHDL, SDL, Java, etc.)
– Graphical representation (Statechart, specChart etc.)
• The architecture is generally made of a set of processors
• Refinement of input specification into architecture performed using an
internal representation also called intermediate form or internal data
structure

PROF B ABDUL RAHIM AITS RAJAMPET 11

• Two main kinds of intermediate forms:
1. Language oriented
2. Architecture oriented
both maybe used for system representation and transformations
• Figure below shows generic co-design model that combines both
models
– Language oriented intermediate forms are generally based on graph
representation
models concepts handled in specification languages
– Architecture oriented intermediate forms are generally based on FSM
models
closed to concepts needed to represent architectures
This general model is difficult to implement in practice but most tools make
use of a unique intermediate form

PROF B ABDUL RAHIM AITS RAJAMPET 12

PROF B ABDUL RAHIM AITS RAJAMPET 13
• Language oriented intermediate form make easier the handling of high level
concepts ( Eg. Abstract communication, abstract data types) and high level
transformations
• but, it makes difficult the architecture generation step and specification of
partial architectures and physical constraints
• Architecture oriented intermediate form makes difficult the translation of high
level concepts
• But makes it easier specification of architecture related concepts such as
specific communication and synchronization
• This kind of intermediate form generally produces more efficient design
• The computational model of a given specification can be seen as the
combination of two orthogonal concepts
1. The synchronization model
2. The control model
• four computational models may be defined according to concurrency and
synchronization as illustrated in figure:

PROF B ABDUL RAHIM AITS RAJAMPET 14

PROF B ABDUL RAHIM AITS RAJAMPET 15
 Language oriented intermediate forms
• Data, control and control-dataflow representation are main kind
Data flow graph(DFG):
– Most popular representation of a program in high level synthesis
– Nodes represent the operators of the program
– Edges represent values
– The function of node is to generate a new value on its output depending on
its inputs
– At system level a node may hide complex computations or a aprocessor
In synchronous dataflow model, edges hold at most one value, all operators
consume their inputs before new values are produced on their input edges.
In asynchronous dataflow model, edges may hold infinite set of values stored
in queue. The input arrivals & computations are performed at different &
independent throughputs

PROF B ABDUL RAHIM AITS RAJAMPET 16

PROF B ABDUL RAHIM AITS RAJAMPET 17
Control flow graph:
– Most suited to model control design
– These may contain (possibly nested) loops, global exceptions,
synchronization and procedure calls
In other words, features that reflect the inherent properties of
controllers
– Nodes represent operations
– Edges represent sequencing relations
Control-dataflow graph:
– Model extends DFG with control nodes(if, case, loop)
– Suited for representation of dataflow oriented applications

PROF B ABDUL RAHIM AITS RAJAMPET 18

 Architecture oriented intermediate forms
• Closer to architecture of the realization than to the initial input description
• The data path and the controller may be represented explicitly when using
this model
• The controller is generally abstracted as an FSM
• The data path is modeled as a set of assignments and expressions including
operation on data
FSMD representation:
– FSM extended with operations on data
– Classic FSM is extended with variables
– FSMD may have internal variables and a transition may include arithmetic and logic
operation on these variables
– FSMD adds a data path including variables, operators on communication to the classic
FSM
– FSMD computes new values for variables stored in the data path and produces
outputs
PROF B ABDUL RAHIM AITS RAJAMPET 19
The FSM with Co-processor model (FSMC):
– FSMD with operations executed on co-processors
– Expressions may include complex operations executed on specific
calculation units called co-processors
FSMD + set of N co-processors C = FSMC
– Co-processors may have their local controller, inputs and outputs
– They are used by the top-level controllers to execute specific
operations
– Several co-design tools produce a FSMC based architecture
cosyma, vulcan & lycos system
– In these co-design tools, the top controller is made of a SW
processor and co-processor are HW accelerators

PROF B ABDUL RAHIM AITS RAJAMPET 20

PROF B ABDUL RAHIM AITS RAJAMPET 21
 Distributed intermediate forms
• In order to handle concurrent processes several co-design tools make use of
intermediate forms that support multi-threading
• They may be language oriented or architecture oriented
• Distributed language oriented intermediate form is generally made of
communicating graphs
Most popular format of this type is the task graph
• In this model, each node represents a simple CFG, DFG or CDFG and the edges
represent execution order that may be control oriented or data oriented
• Inter-task communication may follow any of the schemes listed above
• Most co-design tools that make use of task graphs assume that all the tasks are
periodic
• The execution time of each task is bounded and allows for all kind of rate analysis
needed for task scheduling and performance estimation
• Distributed architecture oriented forms generally made of communicating FSMs
• Only few co-design tools support communicating FSMs
• specSyn and polis make use of interconnected FSMs
PROF B ABDUL RAHIM AITS RAJAMPET 22
 System level specification languages
• Specification languages were first introduced in software
engineering in order to support the early steps of the
software development
• The high cost of the software development and maintenance
raised the need for concentrating on the specification and
the requirement analysis steps
• The software quality and productivity is expected to be
improved due to formal verification and gradual refinement
of software starting from higher level specification
• Early hardware description languages were aimed to
specification of instruction set computers

PROF B ABDUL RAHIM AITS RAJAMPET 23

the most productive areas are:
1. VLSI system design:
– Hardware description languages: ISPS, CONLAN, HardwareC, SpecCharts and VHDL
– These languages try to deal with specific characteristics of hardware design such
as abstraction levels, timing and data flow computation
2. Protocol specification:
– Several languages have been created for protocol specification
– In order to allow for protocol verification these languages are based on formal
description techniques (FDT)
SDL, LOTOS & ESTELLE are main languages in this area
LOTOS (Logical Temporal Ordering Specification)
formal specification language for protocol and distributed systems
it is an ISO standard
specification composed of two parts:
1. Behavioral part based on the theory of process algebra
2. A definition part for data definition based on abstract data types
the specification approach consists of producing exhaustible specification, then
validate it and derive an implementation

PROF B ABDUL RAHIM AITS RAJAMPET 24

SDL: Designed in order to specify telecommunication systems standardized
by the ITU as 2.100
suitable for systems represent in behavior by extended FSMs
offers two forms of representation:
SDL-GR ; SDL Graphical Representation
SDL-PR ; SDL Phrase Representation (textual representation)
ESTELLE ; ISO Standardized
specifications are procedural having pascal like construction
it is programming language rather than specification language
adopts an non blocking model for the communication based on message
passing
Several limitations in specifications of parallelism between concurrent
processes

PROF B ABDUL RAHIM AITS RAJAMPET 25

3. Reactive system design:
real time application with fast reaction to the environment
Esterel, LUSTRE & Signal , also petrinets
ESTEREL: Imperative & parallel language which has well defined formal
basis and a complete implementation
the basic concept is event
an event corresponds to the sending & receiving of signals that convey data
Based on synchronous model of computation
this synchronization simplifies reasoning about time & ensures
determinism
LUSTER: Particularly suits to the specification of programmable automata
some real time aspects have been added to the language in order to
manage the temporal constraints between internal events
SIGNAL: Uses different clocks in the same program
clocks can be combined through temporal operators allowing flexible
specification

PROF B ABDUL RAHIM AITS RAJAMPET 26

statecharts: it is visual formalization for the specification of complex
reactive systems
describes the behavior of systems using a state based model
it extends the classical FSM model with hierarchy, parallelism and
communication
the behavior is described in hierarchical states and transitions in
between
transitions are triggered by events and conditions
the communication model is based on broadcasting
The execution model is synchronous
petrinets: tools that enable to represent discrete event systems
describing the structure of the data, the control aspects and the behavior
of the system
the specification is composed of a set of transitions and places
transitions corresponds to events
places corresponds to activities and waiting states

PROF B ABDUL RAHIM AITS RAJAMPET 27

4. Programming languages:
including FORTRAN, C Pascal, C++ and Java
these languages provide nice facilities for
specifications for hardware systems but lack features
like timing or concurrency specification
5. Parallel programming languages:
Very close to hardware specification because of concurrency
specification
-but they lack timing concepts
provide dynamic aspects-difficult to implement hardware

PROF B ABDUL RAHIM AITS RAJAMPET 28

6. Functional programming and algebraic notation:
Ex: VDM, Z and B
• VDM: Vienna Development Method
– Based on set theory and predicate logic
– ISO Standard
– Weakness-non support concurrency & its verbosity
• Z – predicative language, based on set theory
– Enables to divide the specification in little modules named schemes
– These modules describe at the same time static and dynamic aspects of a system
• B- composed of a method and an environment
– Is completely formalized
– Its semantic is complete
– Integrates the two tasks of specification and design

PROF B ABDUL RAHIM AITS RAJAMPET 29

Comparing specification languages
• There is not a unique universal specification language to support all kinds
of applications
(controller, heavy computation, DSP,…)
• A specification language is generally selected according to the application
at hand and to the designer culture
• Three criteria’s for selection of specification languages
Expressiveness: - Determined by the computational model
Expressive power of a language fixes the difficulty
The ease when describing a given behavior
Analytical power: Related to the analysis, the transformation and the verification of
the format
It is mainly related to tool building
Usability: Is composed of several debatable aspects such as clarity of the model,
related existing tools, standardization efforts, et,.

PROF B ABDUL RAHIM AITS RAJAMPET 30

• The main components of the expressive power of a given language are:
concurrency, communication, synchronization, data description and timing
models.
• The analytical power is strongly related to the formal definition of the language
– Some languages have a formal semantics
– Mathematical reasoning can be applied to transform, analyze or prove properties of the
system specification.
• The usability power include aspects such as standardization, readability and
tool support.
– Readability plays an important role in the efficiency of its exploitation
• A graphical specification may be quoted more readable and reviewable than
textual specification by some designers
• The availability of tools support around a given specification language is
important in order to take best benefit from expressiveness of this language
• Support tools include editors, simulation tools, provers, debuggers, prototypers
etc,.

PROF B ABDUL RAHIM AITS RAJAMPET 31

PROF B ABDUL RAHIM AITS RAJAMPET 32
PROF B ABDUL RAHIM AITS RAJAMPET 33
PROF B ABDUL RAHIM AITS RAJAMPET 34
PROF B ABDUL RAHIM AITS RAJAMPET 35
PROF B ABDUL RAHIM AITS RAJAMPET 36
PROF B ABDUL RAHIM AITS RAJAMPET 37
PROF B ABDUL RAHIM AITS RAJAMPET 38