DESIGN SPECIFICATION AND

VERIFICATION

PROF B ABDUL RAHIM AITS RAJAMPET 1

 INTRODUCTION
Describes high level design techniques for developing hardware or software
and combinations of the two
In large design project it is necessary to keep track of a large amount of
details
Ex: circuit diagram : ignore physical placements of components & wires ;
focus on combining components – functionality
Design of software and hardware has become more complex - common
difficulty
• Static description of computations [found in high level models]
• Dynamic behaviour [found in executions evolving in the realization]
Models that support the designer in reducing both these difficulties
 Reduce the differences between the static description and the dynamic
behavior – structured programming
 Allow the designer to do exhaustive checking covering the entire space of
possible behaviors – formal methods

PROF B ABDUL RAHIM AITS RAJAMPET 2

 Design
• Computations realized in software or hardware &
combinations of the two
• There is an increasing similarity between software and
hardware development
• Neither hardware nor software are unique easily
identifiable areas, they both cover a whole range of
technologies for realizing (executing) computations such as
– Interpreted code
– Compiled code
– Hardwired code
– Programmable hardware
– Micro code &
– ASICs

PROF B ABDUL RAHIM AITS RAJAMPET 3

An abstract model cover both hardware &
software components

What should be realized as software

What should become hardware

PROF B ABDUL RAHIM AITS RAJAMPET 4

 Co-design
• Co-design has applications in a wide variety of
specialized electronic products
Ex: communications equipment, controllers & instruments
Telephone switch – embedded systems
 Establishing a connection and transmitting data in
digital form
 Switch has an arbiter that reserves the buffers needed
for communication and resolves conflicts like two
phones calling the same receiver
 Finally, the memory contains the buffers needed for
exchanging the data
PROF B ABDUL RAHIM AITS RAJAMPET 5
PROF B ABDUL RAHIM AITS RAJAMPET 6
 The co-design computational model
• Focus on concurrency, modules and communication
• The choice of a model for co-design is a delicate balance between
abstract and concrete
– Model is too concrete – the designer is constrained by low level
decisions even in the phases of design
– Model is too abstract – it may later become difficult to make an
efficient realization
• when doing co-design, model should not favor a particular kind of
realization ex: S/W realization
• There is a close relationship between the model and the
notation/language/tools used for describing the design
• For co-design one needs a model and a corresponding
language(VHDL, C Java, Verilog) that is abstract enough to allow
descriptions of computations in a range of technologies

PROF B ABDUL RAHIM AITS RAJAMPET 7

• All existing models and languages aim at either describing software
(programming languages) or circuits (hardware description
language)
• Both kinds of languages aim at describing a computation
• All programming languages are based on the Von Neumann model
– Computation described by sequence of instructions operating on data
stored in a memory
– Instruction counter keeps track of which instruction to execute next
• Hardware description languages emphasize structural description,
where the physical organization of parts is explicitly specified
• Computations modeled with fine grain parallelism used to develop
both software and to synthesize circuits

PROF B ABDUL RAHIM AITS RAJAMPET 8

 Concurrency
• Concurrent computation contains parts that are not sequenced
• Concurrency is also an important concept for conceiving and
describing computations
Ex: an embedded controller
a communication device &
a piece of medical equipment
• Computations described in languages like FORTRAN, C and Pascal
are sequential
• This suits in predominant computer architectures
• Not adequate for embedded computations where the order of
external events and computational steps cannot be prescribed prior
to the computation
• Concurrent model is a more appropriate model
• S1;s2;……..sn; s1||s2||…….sn
Sequence parallel

PROF B ABDUL RAHIM AITS RAJAMPET 9

• The concurrency abstraction covers a number of different situations
Ex: non determinacy:
the order of the steps of a computation are not known a priori
ex: arrival time of external events is not known
simultaneity:
steps of a computation happen simultaneously
ex: external events must happen at the same time
multiprocessing:
steps of a computation are done in parallel on multiple distinct
physical processors to speed up a computation
structuring:
steps of a computation are separated into different components
ex: handling of different external devices

PROF B ABDUL RAHIM AITS RAJAMPET 10

 Components
• An independent part of a computation done concurrently
with other parts is often called a process
[term used in programming languages & operating systems –
VHDL, OCCAM & UNIX]
Thread (java) , Lightweight process & stream is also used
• In co-design computational mode - named component
Ex: notation COMPONENT name
declaration
computation
Telephone switch ex: COMPONENT unit
p: phone_connector
…. (*computation*)
END unit
A unit can set up and breakdown connections

PROF B ABDUL RAHIM AITS RAJAMPET 11

COMPONENT connect
handles connection when receiver is free
COMPONENT transfer
handles transmission of data
Non-determinism
• The precise ordering of events is often left unspecified in a high level
design
• Therefore a high level design is often non-deterministic
• It may take many forms:
– External non-determinism: the order of external events cannot be specified
– Internal non-determinism: the order of events should not be specified
– Randomization: the order of events must be unpredictable
• Non deterministic events do happen in some order; but which one is not
prescribed
s1|s2|……sn
• This specifies a computation where one of the n alternative action is done

PROF B ABDUL RAHIM AITS RAJAMPET 12

• The general principle in high level specifications when several
alternatives are acceptable, a specification should avoid stating
which one is chosen
• Otherwise over specification can prevent choosing a better (eg:
simpler, faster or cheaper) implementation later in the design
process
• Often the detail ordering of the computational steps can be left
unspecified
• An arbiter in telephone switch is used to resolve a conflict where
several clients such as the telephone units compete for a set of
limited resources
• In telephone switch there is a limited number of buffers
(communication channels) for transmitting data
• The arbiter reserves buffers when a connection is established
• In situations where the number of requests exceed the available
resources the arbiter must make a choice to honor the requests in
some order
• This order is not fixed or predetermined, so non-determinism is a
good high level abstraction of the arbiter
PROF B ABDUL RAHIM AITS RAJAMPET 13
Concurrency in standard languages
Languages enable the designer to describe a computation as a collection of
concurrent components, there are significant differences that influence
the design style and ease of use.
Concurrency in programming languages:
• Programming languages such as FORTRAN, Pascal, Lisp, C, C++ doesn’t
have explicit constructs for handling concurrency.
• Concurrent computations are based on non-standardized extensions such
as real-time kernels and dialects such as concurrentC.
• Concurrent components in Java are called threads
Aspect called multithreading
• Concurrency in hardware description languages :
– Fundamental concept in VHDL & Verilog
.name: process (parameters)
declarations
BEGIN
computations
END PROCESS name

PROF B ABDUL RAHIM AITS RAJAMPET 14

 Synchronous and asynchronous
computations
• Synchronous & asynchronous models of concurrent computations
differ in how steps from different components are combined:
Synchronous: consists of a sequence of macro steps, where each
macro step has a (micro) step from each of the participating
components
Asynchronous: consists of number of independent sequences
consisting of steps from all the participating components
Classification of high-level languages:
Synchronous languages: ESTEREL, LUSTRE & SIGNAL
VHDL-Possibly design with asynchrony
Asynchronous languages: JAVA
CSP/OCCAM – Possibly design to do synchronous apps such as
systolic arrays

PROF B ABDUL RAHIM AITS RAJAMPET 15

PROF B ABDUL RAHIM AITS RAJAMPET 16
PROF B ABDUL RAHIM AITS RAJAMPET 17
Coordinating concurrent computations
• Although the components are largely independent they must occasionally
interact
Ex: to communicate or to synchronize their access to a common resource
• Coordination is used to encompass mechanisms that allows concurrent
components to synchronize, communicate or compete
Also known – synchronization primitives
communication mechanisms
process interaction
• The purpose of the arbiter is to administer the use of memory buffers
which are common and limited resource.
• Before using a memory buffer, permission is requested from the arbiter
and after use of the buffer, it is explicitly released
pattern is ………..
request
use buffer
release
……………….
PROF B ABDUL RAHIM AITS RAJAMPET 18
• The steps request and release involve the arbiter and provides the
needed coordination with other units to ensure that memory
buffers are used correctly
• Furthermore, the arbiter must control the scheduling of competing
components i.e, the order in which they get to use the buffers
• It is the designer who should control the order in which buffers are
allocated to waiting units, this is called medium term scheduling
• First mechanism introduced – semaphores
– A semaphore, S has two atomic operations P(S) and V(S)
– The atomicity ensures that if several processes attempt to operate on
the semaphore concurrently, these operations are done in some
sequences, one at a time
– The algorithm determining the order is called short term scheduling
– This algorithm is fixed in the implementation of the semaphore

PROF B ABDUL RAHIM AITS RAJAMPET 19

PROF B ABDUL RAHIM AITS RAJAMPET 20
• No of processes A,B,C,D,E……. Make requests very close to
each other
• A is allocated the buffer first and before releasing it, both
B,C,D & E also make requests
• At the point where A release the buffer, it is short term
scheduling algorithm that determines to which unit the
buffer is allocated next
• Since this algorithm is a fixed part of the semaphore
implementation it is not possible for the designer to
provide an alternative algorithm, hence it is not possible to
control the medium term scheduling
• All the arbiters make it possible for the designer to decide
which medium-term scheduling should be used

PROF B ABDUL RAHIM AITS RAJAMPET 21

 Classification
• Three orthogonal dimensions for classifying coordination
mechanisms
• The classification is used for analyzing and describing some
principal characteristics of the many existing coordination
mechanisms while avoiding syntactical issues of less
importance
– Shared state Verses messages
– Open Verses closed operations and
– Blocking Verses non-blocking
• almost all of the coordination paradigms found in systems,
programming and hardware description languages can be
classified along these three dimensions
Ex: Verilog has shared state, non blocking & open operations
where as LOTOS uses messages & fixed blocking operations

PROF B ABDUL RAHIM AITS RAJAMPET 22

 Shared state verses messages
• Concurrent processes may coordinate their computations by
sharing part of their state space
Ex: one or more shared variables that they can all read & write.
Alternatively they could coordinate their activities by exchanging
message(values)
Ex: P & Q - two concurrent processes sharing a variable called data
PROCESS P: PROCESS Q:
data:=F(….)
….. Ldots
v:=data
Process P produces some data, illustrated by the function F, and
assigns it to the shared variable data
the other process Q reads the data and copies it to v for further
processing

PROF B ABDUL RAHIM AITS RAJAMPET 23

PROF B ABDUL RAHIM AITS RAJAMPET 24
• The same is easily achieved by message passing
PROCESS P: PROCESS Q:
send_message(F(….))
…….. ……
receiving_message(v)
• the data is again produced with the function F and then
communicated as a message that is received by the process Q
If the sending process sends the message before the receiver is ready
to accept it, the message is placed in a buffer and the sender
proceeds
Conversely, if the receiving process does a receive_message before it
has been sent, the reciever waits until this happens
- called non blocking message passing

PROF B ABDUL RAHIM AITS RAJAMPET 25

• Arbitration is performed by a process that accepts request/release
message from client process using the buffers in the common
memory
• The arbiter must always be able to accept both request and release
message
• If the resources is in use the arbiter stores requests in a local queue
• Ordering of this queue determines the medium-term scheduling
• The following operations are available on the queue:
– Insert a new element in the queue
– Remove the first element of the queue and
– Empty which is true if there are no elements in the queue
• There are no. of different scheduling algorithms, based on many
parameters such as waiting times, priorities and resource utilization

PROF B ABDUL RAHIM AITS RAJAMPET 26

 Open verses closed operations
• The coordination mechanism is embedded in the notation for
specifying the computation
• A monitor is defined by the designer, and it provides a number of
operations (procedure calls) for coordination the concurrent
processes.
• A monitor consists of a data structure (set of variables ) and a
number of operations (procedures). In Java these are called
methods
• The data structures can only be accessed through the procedures,
so direct access is not possible
• Keyword “ synchronized” is used
• The data structure of the arbiter consists of a Boolean indicating
whether the resource is free and a queue of waiting process in case
the resource is not free
• The arbiter gives a grant to a client by returning from the request
procedure

PROF B ABDUL RAHIM AITS RAJAMPET 27

 BLOCKING VERSES NON-BLOCKING
OPERATIONS
• Blocking means the coordination steps in all the involved processes
is viewed as a common step – it takes place at the same time
• Non-blocking – processes not takes coordination steps commonly
ex: sending/receiving process wait for each other, until both are
ready to exchange the message
This is done in a common step after which the processes are again
independent – BLOCKING
sending process delivers the message when it is ready, independent
of receiving process chooses to accept the message;
requires buffering mechanism to hold messages sent, but not yet
received – NON-BLOCKING
• CSP and LOTOS are based on blocking message passing
• Non-blocking message passing is used in many commercial
multiprogramming kernels

PROF B ABDUL RAHIM AITS RAJAMPET 28

 INTERFACING COMPONENTS
• The interface determines the coordination of the
components including their data transfer and
synchronization
• The interface model does not describe a particular
coordination mechanism favoring a particular technology
• The interface model allows components to share one or
more state variables
• Such a shared state variable may contain a simple boolean,
a composite value like an integer, a buffer or any other data
types.
• Undisciplined use of shared variables can easily lead to
time dependent design errors which can be difficult to
locate.

PROF B ABDUL RAHIM AITS RAJAMPET 29

PROF B ABDUL RAHIM AITS RAJAMPET 30
PROF B ABDUL RAHIM AITS RAJAMPET 31
 VERIFICATION
• Verification is an important part of non-trivial design
project
– Exhaustive check
– Behavior exercised
– Simulate
• Recent advances in algorithm, Data structures and
design languages provided exhaustive verification
techniques
– Intended & actual behavior must be expressed in formal
notations
• Program in a programming language or as a logic formula
• Formality is a possibility, not mandatory

PROF B ABDUL RAHIM AITS RAJAMPET 32

1. Interface verification
– Separate components of a design interact through an interface
2. Design verification
– Verifying selected key requirements of incomplete models
– One device has access to a common resource(mutual
exclusion)
3. Implementation verification
– Demonstrates a concrete realization is a correct
implementation of an abstract specification
• The high level description of a design is an abstraction of
its physical behavior
• Formal verification deals with the abstraction and not
with the physical realization
• Verification ensures consistency between two descriptions
1. Modeling the behavior of a design
2. Modeling a requirement
PROF B ABDUL RAHIM AITS RAJAMPET 33
 Design verification
• Design verification establishes consistency
between a precisely described model, the design
and a rigorous formulation of selected key
requirements
• Requirements of a design are formalized as
predicates constraining the computation
• There are many CAD tools available to help
designers master the complexity of larger designs
• Most of these tools focus on later stages of
design process
Ex: layout, code generators and synthesis

PROF B ABDUL RAHIM AITS RAJAMPET 34

 Implementation verification
• In order to construct an efficient product, it is usually necessary to
refine the initial (abstract) design into a concrete realization
• The refinement typically includes a number of restrictions enforced
by physical limitations and other practical constraints
• An abstract design describes the computation with as few
constraints as possible
• The abstract design allows widest possible choice
like selecting scheduling algorithms
• In concrete design one of the possible realizations is chosen
• Therefore, a concrete design may not exhibit all the behaviors of
the abstract design
• Informally, the behavior of a design is the computations that are
extremely visible which means that changes to local (internal) state
variable are not directly reflected in the behavior of a component

PROF B ABDUL RAHIM AITS RAJAMPET 35

 a concrete design is a refinement of an
abstract design if the set of computations of
the concrete design is a subset of the
computations of the abstract design
• To be a refinement, the concrete design must
resemble the abstract one, yet there must be
significant differences between the two

PROF B ABDUL RAHIM AITS RAJAMPET 36

 Verification tools
• No. of powerful formal verification tools evolved
• Majority focus on implementation verification
• Formal verification corresponds to an exhaustive check of
the state space
• Explicit representation leads to combinational explosion of
no. of states generated, resulting in poor performance
• Implicit representation of states sets with clever data
structures can overcome this problem
• One of the most implicit representation is the Reduced
Ordered Binary Decision Diagrams ROBDDs
– They provide compact representations of boolean functions
– All the standard boolean operations are reflected by ROBDD

PROF B ABDUL RAHIM AITS RAJAMPET 37

• Using ROBDDs, the initial states, the set of
transitions and the reachable states are all
represented as boolean functions
• After computing the set of reachable states, the
verification tasks is reduced to checking that
boolean function
• This approach is usually called model checking
ROBDD not guarantee to avoid combinational explosion
• General purpose tools have been used to verify
designs with unbounded state spaces where the
ROBDD – based tools are often not applicable
PROF B ABDUL RAHIM AITS RAJAMPET 38
 Interface verification
• Common source of errors and delays in design and
development of projects is inconsistent views on common
interfaces
• It is important to allow common interfaces to have different
views as long as these are not in conflict
– Consider a packet in communication protocol
– One component may treat this is an uninterpreted collection on
bits to be transmitted whereas another component may impose
a structure on the packet with different fields indicating
addresses, control and checksum.
• In the codesign computational model, the interface of a
component consists of
– A set of state variable
– A protocol

PROF B ABDUL RAHIM AITS RAJAMPET 39

• The state variables are shared with other components
• The protocol describes constraints on the use of the
state variables
• To ensure interface consistency, the protocols do not
contradict each other
• Two implications must be shown for each instance of a
component
1. Demonstrate that the environment meets all the
expectations of the component
2. Ensure components satisfy all requirements set by the
environment

PROF B ABDUL RAHIM AITS RAJAMPET 40

• There are three levels of importance of interface consistency and
verification can be identified:
STATIC: Many languages, type check separately compiled components
in VHDL – Entity declaration – specify procedure headings
no dynamic information is provided
therefore only static consistency check is possible
SAFETY: the approach used previously allows one to specify constraints
on the use of an interface (a protocol)
these constraints express dynamic properties
cannot be checked statically at compile time
instead a verification tool is required
- called functional verification
TIMING: An interface contains timing assumptions
ex: timing diagrams found on most data sheets of hardware
components
these are several approaches to specify such timing constraints in a
symbolic manner that allows a formal consistency check

PROF B ABDUL RAHIM AITS RAJAMPET 41