Erez Manor 08/02/2010 Ben Gurion University

Page | 1
1 | 8
P a g e
FORMAL DESIGN CYCLE

INTRODUCTION

Our objective with the following proposal is to simplify the development of assertion
based verification (ABV) for formal verification, splitting the process into stages (Fig
1).

Fig 1: Design Cycle
A formal definition for a FSM denoted in this work by is a sextuple:
(1) ( )
0
, , , , , M I O S S o =
(2) : S x I S o is the State Transition function
(3) : S x I O is the Output function
Erez Manor 08/02/2010 Ben Gurion University

Page | 2
2 | 8
P a g e
Where I, O, and S are a finite and nonempty sets of input symbols, output symbols,
and states, respectively. When the machine is in the current state s S e and receives
an input a from I, it goes to the next state specified by ( , ) s a o and produces an
output given by ( , ) s a , where
0
S is the set of initial states. An FSM can be divided
into sub-system and denoted as { }
1 2
, ,... M M . An SSRPG design also define a set of
retention states
1 2
{ , , ... , }
r
l l l l = such that l S e .


Erez Manor 08/02/2010 Ben Gurion University

Page | 3
3 | 8
P a g e
STAGE REVIEW

1. Stage of Specification
Requirements Specification (or informal problem description). It defines a set of
general characteristics { }
1 2
, , ...
n
= for the design. Each requirement must
capture only a particular behavior of the FSMs. Each behavior will be expressed by a
property.
Semi-Formal Specification. Making a refinement of the original requirements
jointly with the architecture document, a semi-formal specification is obtained
{ }
1 2
, , ... ,
m
= . A semi-formal specification is a form to express a requirement
using keywords that represent the functionality of logical, temporal operators and
specific statements associated to the design. From the semi-formal specification it is
possible:
- To obtain a set of assertions { }
1 2
, , ... ,
m
= .
- To implement the code in the verification tool.
This way can ensure that each requirement { }
1 2
, , ...
n
= is described by its
semi-formal specification.

2. Stage of Implementation
From the semi-formal specification, the hardware description language (HDL)
implementation
HDL
of the FSM and a set of hardware description verification
language (HDVL) assertions { }
1 2
, , ... ,
m
=

are obtained.

Erez Manor 08/02/2010 Ben Gurion University

Page | 4
4 | 8
P a g e
3. Stage of Verification
Then, the implementation is verified using the model checking tool Incisive Formal
Verifier (IFV). It allows to assure that its implementation in verilog, satisfies the
initial requirements of the specification,
(4)
g verilo


If some error is found, a counterexample is generated and it is used to correct the
design. This is the error correction process. Also to validate the design, a functional
verification is executed to assure the global correctness of the implementation. The
functional verification is necessary to detect errors in generated during the
refinement of .

4. Stage of Results
In this stage are generated reports containing statistics about formal and functional
verification. Therefore, conclusions about verification process will be given.
At the end of this stage and getting a pass result we need to evaluate whether
g verilo

, we need to validate the result according to (2.2.5) for error in an
assertions

itself, or a case of vacuity error caused from incorrect defining . After
checking that the design is indeed error proof we can finish the verification process.

Erez Manor 08/02/2010 Ben Gurion University

Page | 5
5 | 8
P a g e
SSRPG IMPLEMENTATION

1. Stage of Specification
Requirements Specification. We need to define a set of general characteristics
{ }
1 2
, , ...
n
= for the SSRPG design.
- Write before Read for an SSRPG design found in low power mode at time
unit
0
t and in retention state l , if a flop was decided as unneeded for
retention, verify it is invoked a write command at time unit
1 1 0
| t t t > , before a
write command at time unit
2 2 1
| t t t > will be issue for all his successors.
- State Reachability
a. Given a finite set of retention states l , verify that the system can reach at
least one state
i
l within the set from any random other state.
b. Use of state decomposition for support of Spec Write before Read to
prevent state explosion problem and allow shorter verification time.
Both Write before Read is classified as Safety class. State Reachability is
classified as Existential class. Write before Read is likely to FAIL for some cases
due to logic between the flops that weakens the criterion, and give more possible
cases, consequently this property will need refinement. The Semi-Formal
Specification,

{ }
1 2
, , ... ,
m
= , which is making a refinement of the original
requirements

well, this issue will be address in later stages of the project.

Erez Manor 08/02/2010 Ben Gurion University

Page | 6
6 | 8
P a g e
2. Device Under Test
The project is a collaboration with CEVA Inc. and Freescale Semiconductor, and we
will examine our formal verification environment over a few of their designs. We will
choose a design modules that are categorized as higher prioritized design group
according to [1].
The alpha test subject is the On-Chip Emulation Module (OCEM), a sub-module of
the CEVA-XCxx1 Memory Subsystem (MSS). The OCEM supports various
debugging capabilities, and provides the interface between a host computer and the
DSP. The OCEM offers a glueless approach using a scan chain methodology,
eliminating the usage of a mailbox and a monitor program. All communications with
the host are carried out via a standard JTAG port.
The OCEM is comprised of the following main modules (Fig. 2):
- Jtag module Supports the interface of the OCEM and the host (JTAG
protocol)
- Break module Generates the breakpoint request signals
- Control module Controls the core during emulation mode

Fig 2: OCEM Block Diagram
The SSRPG is intended for a design that is FSM controlled. The JTAG module
supports the interface of the OCEM and the debugger. The communication is
OBREAK
OCONTROL
data registers
status registers
core
inputs
jtag state
OSCAN_CHAINS
OJTAG
ODVM_BREAK
breakpoint
requests
control signals
core
inputs
tck_set_en
tck_rst_en
tdi_sync_r
tms_sync_r
ocm_tdo_r
Erez Manor 08/02/2010 Ben Gurion University

Page | 7
7 | 8
P a g e
performed by means of the JTAG serial interface. The debugger can access the scan
chains and internal OCEM registers for both read and write operations. The standard
Test Access Port (TAP) controller state machine (Fig. 3) is implemented in the JTAG
module of the OCEM.

Fig 3: TAP Controller State Diagram
The two states EXIT1_DR and EXIT1-IR are set as retention states, and according to
this we manually define which FFs will be retained and which will not. The Semi
Formal Specification is expressed according to this architecture. Later in the project
we will test other modules by CEVA and Freescale according to the insights we will
gain here.
At present, the project is moving from theory state to the practical state, this is noted
as 1
st
Generation, at this generation we verify the write before read and FSM
reachability at their most basic form, according to the proposed design cycle, we still
have to conclude the stage of specification by define the Semi Formal Specification
{ }
1 2
, , ... ,
m
= for the OCEM, after that, at the stage of implementation we need
to write the SVA assertions { }
1 2
, , ... ,
m
= to be verified using for the next stage,

Erez Manor 08/02/2010 Ben Gurion University

Page | 8
8 | 8
P a g e
stage of verification the IFV to see if indeed
g verilo


or not. At the stage of
result we will assess our results and see whether we need to move back to the stage
of implementation or we can move to the next generation and begin a new design
cycle adding more features and capabilities, logic enhancement, vacuity checks,
process automation, etc. in order to make it to a more generic process suited for every
design.
3. Work Report
At present, the project is moving from theory state to the practical state, this is noted
as 1
st
Generation, at this generation we verify the write before read and FSM
reachability at their most basic form, according to the proposed design cycle, we still
have to conclude the stage of specification by define the Semi Formal Specification
{ }
1 2
, , ... ,
m
= for the OCEM, after that, at the stage of implementation we need
to write the SVA assertions { }
1 2
, , ... ,
m
= to be verified using for the next stage,
stage of verification the IFV to see if indeed
g verilo


or not.