HDL code analysis for ASICs in mobile systems

Master thesis performed in electronic systems

by

Fredrik Wickberg
LiTH-ISY-EX--07/3924--SE

Linköping 2007
 HDL code analysis of ASICs in mobile systems
Master thesis performed in electronic systems at
Linköpings tekniska högskola
by

Fredrik Wickberg

LiTH-ISY-EX--07/3924--SE

Supervisors: Björn Fjellborg, Ericsson AB

Joakim Eriksson, Ericsson AB

Examiner: Mark Vesterbacka, ISY, Linköpings Universistet

Linköping, 27th of February 2007

Abstract
The complex work of designing new ASICs today and the increasing costs of
time to market (TTM) delays are putting high responsibility on the research
and development teams to make fault free designs. The main purpose of
implementing a static rule checking tool in the design flow today is to find
errors and bugs in the hardware definition language (HDL) code as fast and
soon as possible. The sooner you find a bug in the design, the shorter the
turnaround time becomes, and thereby both time and money will be saved.

There are a couple of tools in the market that performs static HDL analysis
and they vary in both price and functionality. In this project mainly Atrenta
Spyglass was evaluated but similar tools were also evaluated for comparison
purpose.

The purpose of this master thesis was to evaluate the need of implementing a
rule checking tool in the design flow at the Digital ASIC department PDU Base
Station development in Kista, who also was the commissioner for this project.
Based on the findings in this project it is recommended that a static rule
checking tool is introduced in the design flow at the ASIC department.
However, in order to determine which of the different tools the following
pointers should be regarded:

• If the tool is only going to be used as for lint checks (elementary structure
and code checks) on RTL, then the implementation of Mentors Design
Checker is advised.

• If the tool is going to be used for more sophisticated structural checks,

clock tree/reset tree propagation, code checks, basic constraints checks,
basic Clock Domain Crossings (CDC) checks, then Synopsys LEDA is
advised.

• If the tool is going to be used as for advanced structural checks, extensive

clock tree/reset tree propagation, code checks, constraints checks,
functional Design For Test (DFT) checks (as testmode signal propagation)
and functional CDC checks on RTL as well as on netlist level, then Atrenta
Spyglass is advised.

The areas regarding checks that could be of interest for Ericsson is believed
to be regular lint checks for RTL (naming, code and basic structure),
clock/reset tree propagation (netlist and RTL), constraints and functional DFT
checks (netlist and RTL).
Acknowledgements

I am very grateful towards Ericsson AB for the opportunity of accomplishing

this master thesis at the Digital ASIC department, PDU Base Station
development, Kista. I would like to give a special “Thank you” to the following
people.

Björn Fjellborg (Ericsson) - for great guidance during the entire project which
helped me a lot in many areas and kept me from slipping out of focus.

Joakim Eriksson (Ericsson) – for guidance and teaching of project

procedures, design structures/methodologies, important issues, discussions
regarding results, possible improvements and so on.

Mark Vesterbacka (Linköpings Universitet) – examiner of this thesis.

Hans-Olov Eriksson (Ericsson) – as the section manager making this thesis

possible.

Jens Andersson (Ericsson) – for UNIX related issues and information

regarding test procedures, constraints usage, improvements etc.

Tume Römer (Ericsson) – for information regarding synthesis procedures and

improvements.

Jakob Brundin (Ericsson) – regarding Phoenix related information and design

structures/methodologies.

Andreas Magnusson (Ericsson) – for information regarding SystemVerilog.

Victor Folkebrant (Ericsson) – for information regarding design issues.

The ASIC department (Ericsson, Kista) – everybody at the department for

being very helpful and making this thesis possible.

Ericsson Mobile Platform in Lund (EMP) – everybody I have had contact with
for being very helpful.

Tom-Carlstedt Duke (Atrenta) – for Spyglass workshop.

Shawn Honess (Synopsys) – for Leda workshop.

Jonas Norlander (Mentor) – for HDL-Designer workshop.

Magnus Jansson (Cadence) – for HAL workshop.

 Table of Figures

Figure 1 Design Flow Diagram 2

Figure 2 The policy template relation. 5
Figure 3 Spyglass GUI. 6
Figure 4 Example of how the usage of Spyglass in the design flow could be. 7
Figure 5 Visualisation of a typical netlist flow between Ericsson and the chip manufacturer. The black
clouds represent the time cost of correcting an error. In the evaluation immediate related
netlists were evaluated and compared in order to determine what could have caused the
undesired iteration. 9
Figure 6 A visualisation of the selection process. An example of the count report copied into an excel
spreadsheet is shown. 10
Figure 7 Example of black box detection. 12
Figure 8 A correct design emerge from implementing the functionality described in the Design
specification and keep it within specified limits and boundaries. 17
Figure 9 An Example of the MCP problem. 18
Figure 10 If the output delay constraint from block B plus the input delay constraint from block C is
longer than the clock period it could lead to a severe error. This error would then cause
unwanted iterations late in the design phase costing time and resources. 19
Figure 11 Block diagram of the Anna design. 21
Figure 12 A visualisation of the meta stability problem. The use of two synchronisation FF:s (in b)
reduces the probability of incorrect sampled data several times. 22
Figure 13 Screenshot of LEDA. 28
Figure 14 Screen dump of HAL. 31
Figure 15 Snapshot of Design Checker. 32
Figure 16 Test code used when evaluating SV support in Spyglass. 39
Figure 17 Test codes used for evaluate LEDA SystemVerilog support. 41
Figure 18 Spyglass reports that CP and Q are different clocks. 44
Figure 19 The propagation of the 156 MHz clock into the EIO jitterbuffer. Notice the absence of a
system clock / test clock multiplexer. The probable reason is that this selection is done in the
Test Mode Controller (see Figure 11). 54
Figure 20 The reset selection structure that was flagged by rule Async_07. The X in the zoom in
symbolises the unknown value of the reset input. The ddr2_rst_n input signal is connected
to the rst_n. 55
Figure 21 A de-asserter is a mechanism that synchronizes the release of a signal, while the hold is still
asynchronous. 56
Figure 22 Schematic of the de-asserter structure used in Anna. 56
Figure 23 The Waveform Spyglass generates to aid in the debugging procedure. However, Spyglass
did not point directly to where the suspicious behaviour appeared (the ellipse marking was
added manually in clarification purpose). 57

Table of Tables
Table 2 Explanation to the commands and switches used in the evaluation. 8
Table 3 Number of licenses needed, based on spyglass runtime, calculated for design teams
containing 10, 15, 20 and 25 designers. 14
Table 4 Spreadsheet over differences between the evaluated tools. 35
 Table of Equations

Equation 1 Spyglass savings vs. Spyglass cost 11

Equation 2 The number of licenses that would be needed based on the assumptions made above. The
value 0.25 corresponds to the 15 minutes the cmc block takes to process with the template
in question. A designer is estimated to run Spyglass 4 times a day 13
 Table of Contents
1 INTRODUCTION ........................................................................................................................................................................1
1.1 BACKGROUND .........................................................................................................................................................................1
1.2 METHOD ..................................................................................................................................................................................2
1.3 PROJECT GOALS .......................................................................................................................................................................3
1.4 INTRODUCTION TO SPYGLASS .................................................................................................................................................4
2 PART I – SPYGLASS USED ON NETLIST LEVEL............................................................................................................9
2.1 METHOD ..................................................................................................................................................................................9
2.2 SETTING UP AND STARTING THE ENVIRONMENT ..................................................................................................................11
2.3 SPYGLASS IN THE ASIC VENDOR’ S FLOW ............................................................................................................................12
2.4 ESTIMATED NUMBER OF LICENSES REQUIRED BASED ON SPYGLASS RUN TIME..................................................................13
2.5 RULES ....................................................................................................................................................................................14
2.5.1 Important rules in RTL-Signoff ....................................................................................................................................14
2.6 THE NETLIST EVALUATION ....................................................................................................................................................15
3 PART II – SPYGLASS USED ON RTL.................................................................................................................................17
3.1 CONSTRAINTS CHECKS ..........................................................................................................................................................17
3.1.1 Method ...........................................................................................................................................................................18
3.2 DFT CHECKS .........................................................................................................................................................................20
3.2.1 Method ...........................................................................................................................................................................20
3.3 CDC CHECKS .........................................................................................................................................................................22
3.3.1 Method ...........................................................................................................................................................................23
3.4 CHECKING DESIGN FOR SYNTHESIS READINESS ...................................................................................................................23
3.4.1 Method ...........................................................................................................................................................................24
3.5 THE RTL EVALUATION .........................................................................................................................................................24
3.6 ASPECTS THAT HAS NOT BEEN EVALUATED .........................................................................................................................26
4 PART III - SPYGLASS COMPARED WITH OTHER TOOLS .......................................................................................27
4.1 SYNOPSYS LEDA, VERSION 2006.06 ...................................................................................................................................27
4.1.1 LEDA in the design flow...............................................................................................................................................27
4.1.2 Running LEDA ..............................................................................................................................................................27
4.1.3 Reports...........................................................................................................................................................................28
4.1.4 Concerning rules...........................................................................................................................................................29
4.1.5 LEDA compared to Spyglass........................................................................................................................................30
4.2 CADENCE INCISIVE HDL ANALYSIS (HAL), VERSION 5.82 ...............................................................................................30
4.2.1 HAL in the design flow .................................................................................................................................................30
4.2.2 Running HAL.................................................................................................................................................................30
4.2.3 Reports...........................................................................................................................................................................31
4.2.4 Concerning rules...........................................................................................................................................................31
4.2.5 HAL compared to Spyglass ..........................................................................................................................................31
4.3 MENTOR HDL DESIGNER/DESIGN CHECKER, VERSION 2006.1 BETA ................................................................................32
4.3.1 Design Checker in the design flow ..............................................................................................................................32
4.3.2 Running Design Checker..............................................................................................................................................33
4.3.3 Reports...........................................................................................................................................................................33
4.3.4 Concerning rules...........................................................................................................................................................33
4.3.5 Design Checker compared to Spyglass .......................................................................................................................33
4.4 TOOL COMPARISON OVERVIEW .............................................................................................................................................35
4.5 SYSTEMV ERILOG SUPPORT FOR RULE CUSTOMISATION ......................................................................................................36
4.5.1 Spyglass .........................................................................................................................................................................36
4.5.1.1 Case 1.......................................................................................................................................................................................... 37
4.5.1.2 Case 2.......................................................................................................................................................................................... 37
4.5.1.3 Case 3.......................................................................................................................................................................................... 37
 4.5.1.4 Case 4.......................................................................................................................................................................................... 37
4.5.1.5 Summary..................................................................................................................................................................................... 37
4.5.2 Leda ...............................................................................................................................................................................39
4.5.2.1 Case 1.......................................................................................................................................................................................... 39
4.5.2.2 Case 2.......................................................................................................................................................................................... 39
4.5.2.3 Case 3.......................................................................................................................................................................................... 40
4.5.2.4 Case 4.......................................................................................................................................................................................... 40
4.5.2.5 Case 5.......................................................................................................................................................................................... 40
4.5.2.6 Case 6.......................................................................................................................................................................................... 40
4.5.2.7 Summary..................................................................................................................................................................................... 40
5 RESULTS ....................................................................................................................................................................................43
5.1 PART I ....................................................................................................................................................................................43
5.1.1 Phoenix netlist version 8 compared to version 9 ........................................................................................................43
5.1.2 Hwacc netlist comparison ............................................................................................................................................45
5.1.2.1 Hwacc, v.2 versus v.3 ................................................................................................................................................................ 45
5.1.2.2 Hwacc, v.3 versus v.4 ................................................................................................................................................................ 46
5.1.3 Anna ...............................................................................................................................................................................47
5.2 PART II ...................................................................................................................................................................................48
5.2.1 Constraints ....................................................................................................................................................................48
5.2.1.1 Results from the CMC ............................................................................................................................................................... 48
5.2.1.2 Results from the Bubble Sort block .......................................................................................................................................... 52
5.2.2 DFT ................................................................................................................................................................................53
5.2.3 CDC ...............................................................................................................................................................................55
5.2.4 Synthesis readiness .......................................................................................................................................................58
6 CONCLUSIONS.........................................................................................................................................................................61
7 REFERENCES ...........................................................................................................................................................................65
Abbreviations

BIST Built In Self Test, logic only used for testing.

CDC Clock Domain Crossings, a signal crossing

between two blocks that does not trigger on
the same clock.

CPU Central Processing Unit

DDR Double Data Rate, a design mechanism that

operates on both edges of a clock signal.

DFT Design For Test, a design technique used to

get a good test and fault coverage.

EMP Ericsson Mobile Platform

FF Flip Flop.

FIFO First In First Out, a queuing technique.

FSM Finite State Machine, a construct very

commonly used in HW designs to control
events.

GUI Graphical User Interface

HW Hardware

HDL Hardware Description Language

IP Intellectual Property

KI/UMB An acronym for the ASIC department section

where this evaluation took place.

LSSD Level Sensitive Scan Design, an alternative

DFT technique to Scan Chain.

Lint Originally a tool that flags suspicious

behaviour in C source code. These days
often referring to a tool that performs static
analysis of source code.

MUX Multiplexer.
Policy A policy is a collection of similar rules. E.g.
the Constraints policy consists of rules that
check the SDC file for correctness and
coverage.

RTL Register Transfer Level,

SDC Synopsys Design Constraints. The name of a

format that specifies the constraints
environment for a design. Also an extension
for the constraints files.

SGDC SpyGlass Design Constraints. A file were

clock, reset and other signals are defined.

Anna The pseudonym for the design used to test

Spyglass on (the actual name is classified).
Developed at the ASIC department at
Ericsson.

Template A template is a set of rules in Spyglass. A

template can consist of rules from many
different policies.

TTM Time To Market

Table 1 Abbreviations.
1 Introduction

1.1 Background

Design complexity increases with the shrinking of the transistor geometry.

Now when technology reaches 65 nm and below, the error correction and
debugging of the complex designs can result in great loss in both time and
money. The time it takes for completing a design project is also a great issue.
One way of preventing code errors and speeding up the process is to use a
static HDL analysis tool that statically checks source code for suspicious
behaviour. Static code analysis tools have been on the market for
programming languages like C and C++ for decades but during the past few
years a number of tools in this area has been introduced for HDL languages
like VHDL and Verilog. One of these tools is Spyglass from Atrenta. This tool
was the main objective for evaluation in this project performed at the Digital
ASIC department, PDU Base Station development, in Kista (from now on
referred to as the ASIC department) but other similar tools were evaluated for
comparison purpose.

The netlist delivery process between the design teams at Ericsson and the
chip vendor is iterative. The process consists of a number of scheduled
deliveries. In each of these deliveries the netlist must have reached an agreed
maturity degree in terms of implemented functionality and structure, this
scheduled delivery is referred to as a drop. The problem is that the number of
undesired iterations has increased. These iterations (revisions of a drop) are
caused by errors that prevent the netlist to reach the agreed maturity degree.
A consequence is that the engineers have to put more work and time into
correcting errors than before. In these days, when time to market and design
cost have to be shortened, the extra work generated from these extra
iterations is greatly undesired. One of the main objectives for the evaluation
was therefore to check whether the use of Spyglass on gate-level netlists, can
reduce or eliminate the number of undesired iterations between Ericsson and
the chip vendor. An illustration of this is shown in Figure 1 (the dotted arrows
on the left symbolise the undesired iterations and would preferably be
replaced by the dotted arrows on the right).

1
 Ericsson Specification

RTL-coding
VHDL
(Sys. Verilog)
RTL-code Testbenches

Verification Rule check

Simulation

Verilog Synthesis

Cell library Gate-level netlist

Rule check
Equivalence check
Verification STA

Floorplanning Netlist Hand-off

Chip Vendor
Place & route

Timing closure Prototype man.

Figure 1 Design Flow Diagram

Other objectives were to see if the errors found at gate level could have been
prevented if Spyglass had been used on RTL and hence cut off the iterations
completely. The type of rules that could be of interest in an eventual future
purchase of the tool was also investigated.

1.2 Method

Anna was the design used as test platform on which the evaluated tools was
applied upon (Anna is a pseudonym, since the actual name is classified).
Anna was a design in 65 nm technology and contains several cores
(Phoenix), a Common Memory Controller (CMC), several hardware
accelerators (Hwacc), a block containing test/clock/reset/timer interfaces
(MISC), external IO interfaces (eIO) among others. The project was divided
into three parts.

In part I an evaluation of the use of Spyglass on netlists has been performed.

Complementary information regarding the used method is described in
chapter 2.1. In part II an evaluation of different packages of Spyglass
(containing different sets of rules) with the purpose of use on RTL code has
been performed. Complementary information regarding the used method is
described in the beginning of each chapter in part II. In part III a comparison
between Spyglass and similar tools has been performed. The results from the
evaluations in part I and part II are presented in chapter 5.

The cost and savings calculations are found in [Wickberg, 2007].

2
1.3 Project goals

In this thesis an evaluation of static HDL-code analysis tools has been

performed. The primary goal was to produce such an extensive amount of
information that the decision makers would be able to base their choice of tool
upon. Problem aspects both on gate level as well as on RTL have been
considered. The primary goal was formulated into the seven questions listed
below. The questions are discussed and answered in chapter 6.

1. Should Ericsson introduce a static HDL-code analysis tool in the design

flow? What resources and quality gains are to be expected from usage on
RTL? What resources and quality gains are to be expected from usage on
gate level?

2. Which rule packages are the most interesting for the ASIC department at
Ericsson?

3. How well would a static HDL-code analysis tool fit into the current design
flow?

4. How user-friendly is such a tool in terms of debugging and navigation?

How well is the result presented?

5. How easy is it to create your own rules?

6. How many licenses are expected to be required for a typical ASIC

project?

7. What gain are there to be seen for the use of the static rule checking tool
on design in 65 nm technology?

3
1.4 Introduction to Spyglass

Spyglass is a tool that performs a static and/or dynamic analysis of RTL code
or gate level netlists in the purpose to find structural, coding, consistency
and/or functional problems with the help of rules. A common
misunderstanding is that Spyglass is a regular static lint checking tool. Even
though this is one of the tools main fields of application, much more can be
performed than just checking that e.g. a “_n” has been used after the name of
an active low reset signal can be performed. One of the more advanced
checks Spyglass can perform is analysing whether the data signal in a clock
domain crossing protocol is stable during request. Spyglass has a number of
rules in different areas and below is a short summary.

• Naming conventions – For example, if the name of an active low signal

followed by _n etc.

• Code structure – For example, if flip flops have reset, reset is used both
synchronously and asynchronously, shift overflow etc.

• Structural checks – For example, if flip flop has the specified reset,
combinational loops, long logic path, redundant logic e.g.
y <= not (not X) etc.

• Constraints – For example, consistency, complete cover etc.

• CDC – For example, properly synchronized signals/busses etc.

• DFT – For example, flip flops replaceable by scan-flops, unblocked test

mode signals, transparent latches, observability/controllability etc.

• FIFO – For example, underflow, overflow etc.

• Handshakes – For example, acknowledge responds in a certain time

span after request etc.

• Functional checks – For example, dead/unreachable states in co-

working FSM:s etc.

The rules in the first two points above are often referred to as lint rules. To
analyse these types of rules Spyglass only investigates the source code and
no synthesis is needed. This is also the case for checking if a flip flop has a
reset. But if a rule that checks whether this reset is the one specified in the
Spyglass Design Constraints (SGDC) file (explained later), then Spyglass
must synthesise the design. The rules that are run depend on the templates
that are selected. A template in Spyglass is a set of rules. The user can use
the templates that are shipped with the tool or put together a new one
containing already existing or custom made rules. Putting together a custom
template is done by browsing and selecting rules in the policies. A policy is a
set of similar rules and distinguishes from a template in the way that a
template can contain rules from many different policies. A visualisation of this
is shown in Figure 2.

4
Figure 2 The policy template relation.

Spyglass can either run in batch mode or interactively using the GUI (shown
in Figure 3). A typical run is done in batch mode. The reports Spyglass
generates are then used to correct the errors. If there are problems that
require more information than the reports can offer, the GUI is brought up. In
the GUI the user can open the schematic view (the “AND” gate symbol
button) or the incremental schematic (the IS button). The difference between
these two is that the incremental schematic shows the user structures
correlated to the selected violation, while the schematic view shows the entire
block. When structural and functional rules are run Spyglass must be supplied
with an SGDC (SpyGlass Design Constraints) file. This file contains
information regarding clocks, resets, test mode signals, additional Synopsys
Design Constraints (SDC) files etc. An example is the specification of the
master clock. In order to check clock tree propagation Spyglass needs
information regarding where to start the checking. Below is a typical clock
specification in the SGDC file:

clock –name I_REF_CLK –domain domain1 –value

rtz -sysclock

The line provides Spyglass with information regarding clock source, domain (if
there are several clock domains), if the clock returns to zero or one and if the
specified clock is a system clock or a test clock. The information the SGDC
file must contain depends on the types of checks that are to be run, but
typically clock and reset information are mandatory for most checks. For more
information regarding Spyglass in general or how to define signals in the
SGDC file, the reader is refered to [Atrenta 2, 2006].

5
Figure 3 Spyglass GUI.

Even though Spyglass’ main contribution is when run at RTL the tool has
functionality to check netlists as well. Different types of rules are often run at
different stages in the design flow. Many of the DFT checks are meant to be
run at gate level, namely because typically the implementation of the scan
chain is done after synthesis. Therefore is there no point in checking all the
DFT rules at an early RTL stage, but instead use a subset containing checks
for clock and reset propagation. There is also no point in checking rules
regarding internal company naming conventions and code structure at the
gate level. Here it is more useful to check naming conventions desired by the
chip vendor to check that the synthesis tool has not named IPs and similar
according to a forbidden style. An example of how Spyglass can be used in
the design flow is shown in Figure 4. The versions of Spyglass that have been
evaluated are 3.8.0.3 for the netlist level checks in part I and 3.8.1 for the rest
of the evaluation.

6
 Fast RTL
Naming checks RTL block code
Sensitivity lists
FSM structures
Block integration

Fast RTL
RTL block signoff CDC checks
Light DFT checks
Pre synthesis checks
Chip integration

Fast RTL
CDC chip checks RTL chip signoff
DFT Ready checks
Pre synthesis checks
Synthesis

Chip Low Power

Chip netlist signoff Chip DFT Ready

Figure 4 Example of how the usage of Spyglass in the design flow could be.

Starting Spyglass is done with the spyglass command. There are a number
of switches to be used depending on the type of evaluation the user desires.
Table 2 shows the switches and commands that were used during this
evaluation. Below is a typical start up command.

spyglass –verilog –policy=stdc –template stdc/RTL-Signoff

–f <PATH>sglib_list <PATH>phoenix.v –sgdc
constraints.sgdc

Spyglass command/switch name Description

Spyglass Invokes Spyglass.

-verilog, -vhdl or –mixed Specifies the language the design is

written in.

-f <file name> Includes a file. Could be a file with

library pointers or design files.

-sgdc <SGDC file path> Includes a SpyGlass Design

Constraints file.

-64bit Specifies that the use of a 64-bits

processor.

-batch Specifying that the run shall be in

batch mode.

-stop Instructs Spyglass not to synthesize

<file/entity/module name> a particular file, module or entity.

7
 -policy=<policy name> Specifies the desired policy to be
run.

-template <default template Specifies which template to be run.

name>

Or

-f <custom template path>

-mtresh <number> Sets the maximum number of

messages shown in the GUI.
Increases overview.

-lvpr <number> Sets the maximum number of

violations a rule can produce.
Increases overview and improves
run time.

-ignorerule <rule name> Ignores a specific rule during the run.

Table 2 Explanation to the commands and switches used in the evaluation.

8
 2 Part I – Spyglass used on netlist level
In this chapter the method and summary from the netlist evaluation is
presented. The results from the evaluation is found in chapter 5.1.

2.1 Method

The method of analysing possible causes to undesired netlist iterations (from

now on referred to as undesired iterations) is explained in the following
section. The designs used for this part of the evaluation were Hwacc, Phoenix
and Anna. It was not possible to run Spyglass on all netlist versions and then
examine all the violations from all the rules. Therefore a heuristic evalutaion
method was formed.

A set of desired rules were defined. As previously mentioned a set of rules in

the Spyglass world is called a template. The template used during this part of
the evaluation originated from the ASIC vendors add-on for Spyglass. The
violations found during the evaluation had to reflect the errors the ASIC
vendor found when they ran Spyglass or a similar tool in their flow. This made
it possible to estimate the engineering hours saved if a violation/violations
were recognised as the cause to the undesired iteration. Spyglass was used
on different revisions of the netlist in a common drop. A typical netlist flow
between Ericsson and the chip vendor is shown in Figure 5. How an
undesired iteration was recognised and selected to be evaluated is described
in Appendix A.

1st drop, 1st revision 2nd drop, 1st revision

Engineering hours lost

Engineering hours lost
Ericsson

Netlist versions

Time
TTM loss

1st drop, 2nd revision 2nd drop, 2nd revision

Chip vendor

Undesired iter. Undesired iter.

Project starts

Figure 5 Visualisation of a typical netlist flow between Ericsson and the chip
manufacturer. The black clouds represent the time cost of correcting an
error. In the evaluation immediate related netlists were evaluated and
compared in order to determine what could have caused the undesired
iteration.
9
The method used to identify causes to the undesired iterations was more or
less a heuristic model in the sense that it did not guarantee an optimal result.
The problem was that there were too many violations to examine from a run
and the work of exhaustively going through them all would have been
impossible. The method model that was developed and used in this part of
the evaluation is described in the following section.

When running checks, Spyglass generates a couple of reports. What reports

that are generated vary depending on what rules that were selected for that
particular run. In order to make the violation comparison, the default report
named “Count” was viewed and considered. This report lists all the rules that
generated errors, warnings and information during the run. For each listed
rule the report also presents the number of violations it had. The two reports
from the consecutive runs were copied together into an excel spreadsheet
and compared. If the number of violations a rule had generated differed, it
was taken into account for further examination. Exceptions to this procedure
were made to rules considered to be extra important. They were examined
even if they had generated the same number of violations. If this was the case
the violations were traced further trough the netlist versions. Figure 6 shows a
visualisation of the selection process.

Figure 6 A visualisation of the selection process. An example of the count report

copied into an excel spreadsheet is shown.

The Spyglass GUI was used to examine the selected violations. Violations
obviously not being the cause to the undesired iteration were disregarded.
The remaining violations were taken into further account and discussed with a
designer. If a violation, in consent with a designer, had a high probability of
being the cause of an undesired iteration, unnecessary design time had been
found. The time was then added to the final equation, used to compare cost
against earnings of the tool (explained more later). The procedure described
was applied to a selected set of different drops on both block and chip level.

10
 When all the selected drops had been evaluated (see Appendix A for the drop
selection procedure), the cost of the extra work the undesired iterations
produced were then calculated by multiplying the estimated time it took to
correct the identified bug (Eh), with the cost of one engineering hour (Ec).
This was then added with the lead time delay (Ch) multiplied with the lead
time cost (Cc). The Ch x Cc factor was very hard to estimate and varies a lot
between projects. The result from the addition makes the left side of Equation
1. On the right side the cost of introducing Spyglass in the design flow was
calculated. The number of required licenses (Li) was multiplied by the yearly
cost of a license (Lc). The initial cost of introducing Spyglass in the design
flow was then added (Ic), which will contain factors like estimated cost of
changing the flow, time costs for educating R&D people in the use of
Spyglass. The sum was divided by the number of projects during a year (P).

The use of Spyglass in the flow will also consume extra engineering hours.
But with respect to that one of the main reasons for using Spyglass in the flow
is to save rather than causing longer developing time (finding errors quicker,
easier debugging etc.), these two factors is assumed in this part to take each
other out.

## & # & & # Li ) Lc + Ic &

%%% " Eh (( ) Ec + %% " Ch (( ) Cc ( > % ( )
(
% ( $ P '
$1$ drops ' $ drops ' ' 1 4442 4443
444442444443 R
L

Equation 1 Spyglass savings vs. Spyglass cost

2.2 ! Setting up and starting the environment

During the environment set up procedure, Spyglass can be a valuable asset

in terms of identifying black boxes. The template Audit/Audit-RTL provides
rules that check the design for correct linking, syntax errors and black boxes.
The set of rules runs fast even on large designs that have not been checked
before. In the message view – spyglass tab, the rule “DetectBlackBoxes”
reports violations if there were any black boxes. This rule was used to identify
libraries that have not yet been provided. Even though Spyglass was able to
run without these missing libraries/code the checking performance increased
if they were included. Functionality and rules that depended on clock, reset
and test mode propagation would not be optimal if there were black boxes in
their paths. Spyglass could use both .db and .lib library files but the .lib files
were preferred.

When the rule InferredBlackBoxes was violated and flagged a black box it
provided both the instance name as well as the expected module/cell name.
An example of black box detection is shown in Figure 7.

11
 Figure 7 Example of black box detection.

The libraries are usually compiled into a common directory in the working
area. For this evaluation a directory called “sglibs/” was created, into which all
the necessary libraries were compiled. The compilation was performed by the
command spyglass_lc –gateslib <library file path>. When
Spyglass was run, pointers to the libraries that were compiled had to be
provided in the start up command. The switch –sglib <spyglass
library path>, did this. Typically when there were a lot of libraries all the
pointers could be collected in a file. The -f command was then used to
include the file at start up.

When correcting errors using the Spyglass GUI, the user browses through the
violations in the “Msg Tree” tab. By default, the messages were sorted by the
severity levels “INFO”, “WARNING”, “ERROR” and “FATAL”. A more
preferred order was to sort by policy. This was done by selecting “Window” ->
“Preferences” -> “Misc” and then selecting “Group by policy” under “Tree
Selection”. The user is also able to specify a preferred editor. This was done
in the same tab as for the sort order mentioned above but under “Specify
Editor program”. To bring up the editor when correcting and analysing the
results, the user only highlights a row in the “code window” and presses the
“e” button. This started the editor and a cross reference makes the editor
automatically to show the part with the selected row.

2.3 Spyglass in the ASIC vendor’s flow

The aim of part I in this evaluation was to simulate the typical procedure the
ASIC vendor follows when they receive a new netlist version from Ericsson.
Later it was learned from the ASIC vendor that they had not used Spyglass on
Annas netlist, but an internal hand-off kit instead. The ASIC vendor gave the
explanation that Spyglass was not able to substitute their current hand-off kit
for implementation. This meant a set back in precision regarding recognising
the causes to the undesired iterations.

Even though Spyglass was not used on Anna, they confirmed that they
usually use the RTL-Signoff template, which can be used for both RTL and
netlist checks. The ASIC vendor’s add-on consists of the following two
policies.

• Set one, various rules for poorly implemented design (contains the RTL-
Signoff template).

• Set two, rules to check constraints coverage and correctness.

12
2.4 Estimated number of licenses required based on Spyglass run
time

Calculating the number of licenses is very hard and the results given in this
chapter is only giving a ruff pointer to how many licenses that would be
necessary to satisfy the need. In order to make this calculation the following
assumptions were made.

• The greatest need for a large quantity of licenses will be when RTL block
delivery takes place before a scheduled netlist delivery. Ericsson Mobile
Platform (EMP) made the same assumption.

• A CMC (common memory controller) block was used to evaluate run

times and is assumed to reflect an average block in size (~350 000
instances).

• At this point of usage the template Block-signoff should be a good

representative for the “worst case” scenario, in terms of what kind of rules
that will be run. This set of rules contains over 800 RTL orientated rules
and took 15 min to run on the CMC.

• The estimated checking procedure was that a designer run Spyglass,

correct the errors and then run again to see if a good job had been
performed. This procedure is assumed to be performed twice a day and
results in that Spyglass is run four times a day / person.

Equation 2 was used to calculate the number of licenses required. The

number of licenses required was calculated for design teams composed by 10,
15, 20 and 25 designers and one designer was assumed to run Spyglass four
times / day. The results from the calculations are presented in Table 3

(" designers )! runs designer ! 0.25

8h
Equation 2 The number of licenses that would be needed based on the
assumptions made above. The value 0.25 corresponds to the 15
minutes the CMC block takes to process with the template in question.
A designer is estimated to run Spyglass 4 times a day.

Number of designers / design Number of licenses required

team

10 1.25

15 1.875

20 2.5

25 3.125

13
 Table 3 Number of licenses needed, based on spyglass runtime,
calculated for design teams containing 10, 15, 20 and 25 designers.

2.5 Rules

As mentioned in chapter 2.1 the template provided from the ASIC vendor was
selected to be used in this part of the evaluation. This template contains all
the rules in the stdc-policy. These are naming conventions, RTL coding rules
and design rules. The motive behind the decision to use the RTL-Signoff
template is explained in the last section of chapter 2.3.

2.5.1 Important rules in RTL-Signoff

Before the RTL-Signoff template was applied on any of the blocks, the
selected rules were surveyed to determine if there was anyone considered to
be of extra importance. The reason for this was to render the evaluation to be
more efficient. Experiences gained after a test run with default Spyglass rules,
were that there would be a lot of violations from a large number of rules.
Deeper knowledge and understanding about the checking functionality of
certain rules were therefore of great asset. The chosen rules were considered
even if there were no deviation between two netlist versions. The character of
these rules were such that if they occurred, the source to the violations had to
be traced further. Below is a list of the names of these selected rules along
with an explanation to why they were given extra attention.

• BB_DES040 – All flip-flops must be initialized from external resets.

This is a very important rule. The value of a reset that is not externally
controlled would be almost impossible to predict or controlled. This is
especially true for flip flops that lack a reset signal all together.

• BB_DES042 – Avoid constant values on the data input pin on flip flops.
There is no point in setting a data pin of a D-flip flop to a constant value.
The only thing this will result in is extra silicon and power consumption.
The possibility of an unintended construct is high.

• BB_DES052 – Do not use combinational feedback loops.

Combinational loops are bad design practice and synthesis tools will
eventually break them in an uncontrolled way. The problem is that this
might alter the designer’s intention and cause the design to misbehave. It
is better if they are broken in a controlled way (by inserting a flip flop
manually), or to remove them entirely if they are unintended. This is
probably not a problem on gate level since a synthesis tool would have
had removed the loops. But if the netlist is patched manually after an error
it could potentially occur.

• BB_DES063 – Preferably use clock signals active on the rising edge only.
The most common practice is to have the entire design to trigger on active
edge of the clock signal. This makes both the verification task easier as
well as meeting the timing constraints. High risk of unintended construct.
There are design exceptions, such as a Double Data Rate (DDR)
mechanism.

14
 • BB_DES070 – Do not use D flip flops nor latches with connected set and
reset pins.
A D-flip flop has either reset or set, not both like an Set/Reset (SR) flip
flop. If they are both set and reset, different tools in the flow might have
different priority levels on the signals and hence make the design work in
an unintended way.

• BB_DES211 – A net driving several outputs is not allowed.

Having a net driving several outputs is often unnecessary and can result
in redundant area and silicon. There are cases though when this
behaviour could be desirable.

• BB_DES746 –.Preferably register1 all top level outputs.

It should be a practice to register all top level outputs although there are
exceptions when this could be overseen.

2.6 The netlist evaluation

The direct savings earned if Spyglass would have been used in the Anna
project (i.e. cost of “unnecessary” engineering hours spent when not using
Spyglass), would have been far from covering the cost of the tool. There was
another matter, however if the lead and calendar time delay were to be taken
into account. The cost of these delays could be immense and the risk of
delays should be considered, as shown with the example in [Wickberg, 2007].

The run times were a big problem. Applying a large number of rules on a
design containing over three million gates is not recommended. Some rules
hit the roof at 999 999 violations (not correctly parameterised naming rules),
and with nearly 400 rules enabled the run times were incredibly long. The run
times had a strong relation to the number of rules that were enabled and the
number of violations these rules generated. Later it was found out how to
reduce the maximum number of violations each rule could generate. There
was no actual reason to be informed of tens of thousands violations. It was
impossible to examine them all one by one. The designer must ask
herself/himself if the rule in question is of any value to her/him, or take drastic
correction measures to reduce the numbers. The max value was set with the
switch –lvpr X. X stands for the number of violations a rule can generate.
When this roof is hit, Spyglass moves on to check the following rule. Using
this switch helped a lot when evaluating Phoenix, where the run times were
cut to almost a third. In Anna’s case no actual gain were recognised by this
method simply because Spyglass never finished a run with the regular
template. Therefore the set of rules had to be minimized and it all came down
to only run one single rule that turned out to have found errors in the Hwacc
block. This was a great setback but nevertheless necessary.

The run times can be apprehended as unacceptably long for a static rule
checking tool. But there are a few things to remember and consider before
forming an opinion.

1
By inserting a flip flop before output.
15
• Spyglass has not been used in the way it should be. The optimal way of
use is through the entire design flow with a set of rules that was defined in
advanced. In this way faults and errors will not be allowed to propagate
through the design. Otherwise a single error at a low level might generate
thousands in a higher level. A simple example is a signal naming rule. If
this rule is not applied until chip signoff and is violated, all the signals will
be reported and the work of renaming all these would be massive. If it had
been applied from the beginning only a few violations would have been
reported and the work correcting these would be effortless.

• Spyglass functionality is more extent and advanced than many of the

competitors. Spyglass has rules that demand synthesis and sometimes
flattening. These rules will therefore take more time to run than rules that
uses templates. It is therefore important to choose the rules to use at
different levels with care. If time is a big issue on some levels then rules
that do not demand a synthesis should be selected for the evaluations.
There are pre-defined templates for these types of runs and their run
times are a lot shorter. These templates are on the other hand mainly for
RTL.

The memory usage was an issue as well, and the reason for this behaviour
was strongly connected to the reasons why Spyglass had such long run
times. At some points the memory on a regular 32-bit processor was not
enough and the run crashed with the message:

“ERROR [100] Memory Allocation Failed. Exiting ...”

It was mainly Anna that suffered from the large memory usage and was run
on a 64-bit CPU. A strange behavior was that a 32-bit CPU could be used
when running the actual evaluation of the Phoenix block in batch mode but
when bringing up the GUI for violation navigation and examination the 64-bit
core had to be used. As mentioned above the reasons for the immense
memory usage were the same as for the reasons with the large run times.
The number of violations and type of rules selected for the run had a great
impact on how large the spyglass.vdb file (the database file) became. But
even though only one rule was selected for the evaluation on Anna, which
only generated 320 violations, the 64-bit CPU had to be used. It was therefore
legitimate to assume that Spyglass demands more than 2^32 = 4.29 GB of
memory for a synthesis of a 3 million gate design. This might sound alarming
but one must keep in mind that most of the runs are to be executed on block
level RTL code (RTL code checks runs faster). When checking the netlist,
theoretically only one evaluation at the time will be run.

16
3 Part II – Spyglass used on RTL
In part II the Spyglass packages Constraints, DFT and CDC was evaluated.
The objective was to compose such a comprehensive information base
regarding each package and making it possible for Ericsson to decide
whether the package is of interest at an eventual purchase of the tool. There
is a presentation of the method used for evaluating each of the packages.
There is also a section regarding regular checks (also known as Lint), in the
end of the chapter there is a summary. The results from the evaluations is
found in chapter 5.2.

3.1 Constraints checks

Constraints are essential when developing a new design. The constraints set
up are the environmental, clock, test and power boundaries the designers
must keep themselves within when designing an ASIC. The constraints set up
is often captured and written in a Synopsys Design Constraints file (SDC). For
more information regarding SDC, the reader is referred to [Synopsys 2, 2006].
Without constraints the design can go haywire and when implemented on a
chip it will not have the desired functionality nor behave as expected. In order
to implement the functionality when a new ASIC is under development, the
designers review the design specification. In order to develop a design that
will make sense in reality, it is at least as important to have a complete
constraints set up and to verify the design against it during the development
phase. This process is shown in Figure 8.

Design
Specification
Design constraints

New
Design

Figure 8 A correct design emerge from implementing the functionality described in

the Design specification and keep it within specified limits and boundaries.

17
 The work of specifying constraints for a design is an ongoing and complex
task. If there are new ports added in the design, parameters constraining
these port must be added in the constraint set up. The risk of missing a
constraint is obvious when there are many people working with different
blocks. If adding a constraint is omitted, the result could be fatal and thus cost
vast amounts of money. Therefore Spyglass functionality regarding verifying
the constraint set up coverage, correctness and consistency were evaluated.

It was also desired to check Spyglass functionality regarding verification of

Multicycle Paths (MCP).

The following is an example of a multi cycle path problem. The path between
A* and B* in Figure 9 has been declared as a multicycle path of two cycles. In
other words the value at A* will not be read at B* until after two clock cycles.
What happens if there is a similar path between A* and C* which is not
declared as a MCP? The synthesis tool will meet the requirement of the
“worst” path between A* and C*, which will then be unnecessary fast due to
that the value at A* only will be allowed to change every second pulse. The
structure is therefore wrongly constrained resulting in unnecessary use of
logic gates and similar. It would be desirable to check for these kind of
constraints defects.

Figure 9 An Example of the MCP problem.

The evaluation of the MCP verification functionality could not be performed

because it will not be available until Spyglass version 3.8.3 or 3.9.

3.1.1 Method

Spyglass ability in terms of checking constraints cover and whether the

constraints are followed in the design were evaluated. The evaluation was
done on the RTL code of the CMC block. The reason for this choice was that
the block in question had a large number of associated constraints in the
Anna SDC file. The constraints belonging to the CMC block was extracted
from the original AnnaChip.ref.sdc and interpreted to map RTL instead of
netlist. The path to the new SDC file was added in the SGDC file with the
following command:

mapped_pin_map –clock CP –enable EN E –data D –out Q QN

sdcschema –file cmc_tmp3.sdc –level rtl –mode fn1

18
When running Spyglass the two default templates Constraints/sanitycheck
and Constraints/synthesis were used to evaluate the constraints set up. The
template mentioned first was used mainly to check whether signals defined in
the SDC file had equivalences in the code. The other template contains rules
for RTL pre synthesis runs and this was the one that was used for the actual
SDC evaluation.

Another interesting evaluated Spyglass functionality was the SDC consistency

checks. If blocks with adherent SDC files are put together, Spyglass has the
means of checking the consistency between them. Take for example Figure
10. Spyglass checks whether the combination of the SDC files for block B and
block C makes sense.

B_o C_i
FF FF

Block B Block C
clk

Block A
output delay overdue violation

Clk (period 3.2)

B_o

output delay + input delay

C_i

Figure 10 If the output delay constraint from block B plus the input delay constraint
from block C is longer than the clock period it could lead to a severe error.
This error would then cause unwanted iterations late in the design phase
costing time and resources.

In order to check this functionality a smaller example design was used. The
design is a bubble sort accelerator.

The Bubble sort design was constructed of three blocks. There were an SDC
file written for each of the blocks and these were linked together in the SGDC
file with the following commands.
current_design ARRAY_BB_SORT_STRUCTURAL
mapped_pin_map –clock CLK –enable EN E –data D –out Q QN
sdcschema –file bb_sort_structural.sdc –level rtl –mode fn1
block –name REG_STD_LOGIC_VECTOR FSM

19
 current_design REG_STD_LOGIC_VECTOR
mapped_pin_map –clock CLK –enable EN E –data D –out Q QN
sdcschema –file bb_sort_reg.sdc –level rtl –mode

current_design FSM
mapped_pin_map –clock CLK –enable EN E –data D –out Q QN
sdcschema –file bb_sort_fsm.sdc –level rtl –mode fn1

The templates used when running Spyglass were the same as for the CMC
block evaluation.

3.2 DFT checks

Size and complexity of new architectures are growing fast which in turn
makes the testing procedures harder. It is therefore important for the
designers to follow the Design For Test (DFT) technique. DFT can be
described in short as making the validation process easier and simpler by
taking testing in consideration from the beginning of the design process. To
achieve a design that is easy to test, the two terms controllability and
observability are used. The meanings of them are shortly explained below.

• Controllability – measures how easy it is to bring a node into a sought

state, only stimulating input pins.

• Observability – measures how easy it is to read the value on a certain

node at the output pins.

One of the approaches under the DFT technique is Scan-Based testing. This
means that flip flops are directly connected with each other in a long chain,
from chip input to output. The testing personnel are then able to scan desired
values into the design using predefined test vectors. The vectors put the
design into desired states which are excited whereupon the new states are
scanned out and read at the outputs. The work of implementing an effective
scan chain puts great demands on the design regarding the observability and
controllability properties previously mentioned. Spyglass capability of
checking these properties early in the design phase was interesting and
therefore evaluated. For more information regarding DFT the reader is
referenced to [Rabaey, Chandrakasan and Nikolic´, 2003] page 721.

3.2.1 Method

The Anna Core was chosen for the DFT evaluation. See Figure 11 for a
hierarchy overview. The reason for not including the entire design was that
the ASIC vendor had not implemented parts of the test logic in the Anna Chip.
Therefore were some test signals connected to ground at the Anna Chip level
awaiting further implementation. The following signals were, referring to the
Anna test documentation [Test, 2006], defined in the SGDC file in order to
satisfy the scan ready checks.

• tst_scanenable and ScTest were set to 1, which puts the design in scan
mode.

• I_POW_ON_RESET_N was set to 1, which deactivates reset during scan.

• ddr2_rst_n was set to 1, which deactivates ddr2 reset during scan.

20
• I_TRST_DEBUG_N was set to 1, which disables testing the test reset.

• dll_test_act was set to 0, which disables dll test mode.

In order to check the observability and controllability of the BIST logic the
following signals were also stimulated:

• BIST_IN [0] (RST_N) was set to 0. Deactivates reset.

• BIST_IN [1] (RBACT) and BIST_IN [5] (BYPASS) were set to 1. This
enables ram bypass and test mode.

• BIST_IN [7] (TST_GATED_CLOCK) was set to 1. Activates clk for bist

logic.

• BIST_IN [10] (CLK_BMP) defined a test clock to verify that the BITMAP
logic had a controllable clock as input.

• BIST_IN [11] (BMP_RST_N) defined a test reset to verify that the

BITMAP logic had a controllable clock as input.

The template “Scan_ready” was used, which contains rules to check for how
well prepared the design was for Scan chain insertion. The three properties
Spyglass checks for are given below.

• All registers should be controlled by a test clock. The Scan_ready

template uses the rule Clock_11 – Internally generated clocks must be
test clock controlled in scan mode.

• All resets and sets should be disabled in test mode. To check this property
the Scan_ready template uses the rule Async_07 – All internally
generated asynchronous sources should be inactive in scan mode.

• All registers should be scannable. Atrenta presumes that if there are no

violation generated from Clock_11 and Async_07 then all registers should
be scannable.

PseudoChip
PseudoCore
BIST_IN

tmc

Figure 11 Block diagram of the Anna design.

21
3.3 CDC checks

As new hardware designs are getting larger, clock path length becomes
critical. In order to shorten the clock path, and thus avoid clock skews that are
too large to be handled, a common design method used is Globally
Asynchronous Locally Synchronous (GALS). The main idea with this method
is to design small blocks with individual clocks. The blocks are then
connected with each other through an asynchronous handshaking
mechanism or a FIFO (among others). On each of the communication paths
between the individual synchronous blocks there will be one or more Clock
Domain Crossings (CDC). The CDC can be a bit tricky to handle and the
consequences of a badly constructed CDC can be severe. For more
information about GALS the reader is referenced to [Myers, 2001]. An
alternative reason for the use of several clock domains is different demands
of clock frequency from CPU subsystem and varieties of I/Os (as there are in
Anna).

The structures used for synchronising data at a CDC are many and varies a
lot in complexity. A simple example of a poorly implemented data
synchronisation structure is the absent of one or several Meta stability flip
flops. The structural idea of using meta stability flip flops can be viewed in
Figure 12. The meta stable behaviour is a question of probability. The
probability of sampling meta stable data once is very small but significant,
while the probability of sampling meta stable data twice in a row is several
times smaller and hence considered to be insignificant. More about CDC
problems can be found in [Cadence 1, 2006].

a b
Domain 1 Domain 2 Domain 1 Domain 2
D12 D2’ D2
D1 D12 D2 D1

clk_1 clk_1

clk_2 clk_2

clk_1
clk_1 D12
D12

clk_2
clk_2 D2’
D2
D2

Figure 12 A visualisation of the meta stability problem. The use of two

synchronisation FF:s (in b) reduces the probability of incorrect sampled
data several times.

22
 Spyglass possesses functionality of checking CDC. In the basic CDC
package there are rules for checking the meta stability problem mentioned
above, reset is correctly de-asserted, the presence of a CDC, rules to check
for a custom CDC structure etc. In the advanced CDC package there are
rules checking over/underflow of FIFO, if data is stable during the entire
period of the require signal, reconverging synchronised signals, the correct
implementation of busses crossing domains, the existence and structures of a
fast to slow clock domain etc. Even thought not many CDC exist in the
present designs, it was decided that some of Spyglass CDC checking
functionality were to be tested due to the severity of a CDC error.

3.3.1 Method

The Anna Core was used with the template Clock-reset/Sync_checks. The
template contains rules from the basic CDC package mentioned in the
previous section. The following clocks and their relation were defined in the
SGDC file.

• I_REF_CLK, domain1

• I_TCK, domain1

• I_EIO0_FP_156_CLK, domain2

• I_EIO1_FP_156_CLK, domain3

• I_EIO2_FP_156_CLK, domain4

• O_DDR_CLK_P, domain5

• O_DDR_CLK_N, domain5

And the following resets:

• I_POW_ON_RESET_N

• ddr2_rst_n

The reason why the FIFO rules were not evaluated was problems with the
Design Ware (DW) component in the FIFO implementation. This problem is
more intensely discussed in chapter 3.5.

3.4 Checking design for synthesis readiness

A synthesis run of a typical design can take days. If warnings or errors occur
during the synthesis due to design failure, there will be wasted time and the
synthesis must be rerun after the correction of the error. If a majority of these
errors or warnings could be prevented from reaching the synthesis phase, the
time gain would be considerable. In this chapter the investigation of Spyglass
capabilities regarding prevention of unnecessary synthesis failures is
presented.

23
3.4.1 Method

Warnings from a synthesis log was extracted and counted. The warnings
were then discussed with an experienced designer regarding severity and
their need to be checked. After this, the warnings were compared with the
result from a Spyglass run on Anna to see if they could have been caught. A
dilemma was that the synthesis log file origins from a different design than the
one used for the Spyglass test run. This can be a problem in means of
evaluation accuracy, but it should reflect the reality sufficiently. If time could
be saved, the cost of this time was added to the calculations in [Wickberg,
2007]. The cost of the saved time was calculated through engineering hours
saved multiplied with 850 SEK (cost of one engineering hour).

3.5 The RTL evaluation

Conclusions drawn from the Constraints evaluation was that Spyglass has
good functionality regarding to check constraints cover in terms of clock
definitions, input/output constraints, load, capacitance, transition etc. A
negative result was that rule clk_Gen01 flagged signals that were input to
latch enables as unconstrained clocks. The rule therefore generated
thousands of ”unnecessary” violations. This behaviour would make the
correction work harder in terms of identifying real unconstrained clocks.
Spyglass could not map the rules checking input/output delays regarding how
much logic there were between the input and the first flip flop. A suggestion
would be that a threshold parameter is used to set a default value on
combinatorial gate in the path. As it was, a combination of the Inp_delay rules
along with rule Topology_10 had to be used. The Topology_10 rule is shipped
in a different package, which could be a problem. Spyglass could however
check the delay against a customisable percentage of the clock period.

In terms of checking RTL code for scan readiness Spyglass functioned well.
According to Atrenta it should be enough by removing all violations to rule
Async_07 and Clock_11. It was easy to understand the violations generated
by these two rules. In order to satisfy LSSD instead of Scan insertion the rule
Async_07 LSSD should be used. One must then also configure the SGDC file
with the scantype –lssd constraint. This results in that Spyglass only
checks whether set and reset are inactive in test mode because the test clock
is not inserted until the actual LSSD insertion.

24
If the test implementation procedure in future projects will be performed as it
was in Anna more information sharing is desired in order to gain as much as
possible from the use of tools like Spyglass. As it was with the Anna project,
implementation of test signals in the AnnaCore were requested by the ASIC
vendor which then was cleared in the AnnaChip, during RTL, awaiting
connection work from the ASIC vendor at gate level. There was no
information regarding the use of these signals because the test document
developed by the ASIC vendor was written for the chip interface. The
connection between the signals into the chip and the signals into the core was
therefore partly unknown until the ASIC vendor connected them. If future
vendors request implementation of signals in blocks it would be preferred if a
specification of them is shipped with the request, describing purpose and
stimuli for the different modes. However this test implementation procedure is
not how Ericsson intends to work in the future. Either test is implemented fully
from the beginning or not implemented at all until later. This would certainly
increase the ease of using Spyglass in DFT purpose.

Another problem encountered during the DFT evaluation was the use of a
DesignWare component. Even though this has little to do with DFT it is worth
mention. DesignWare is Synopsys customizable IP libraries. Spyglass is
supposed to have functionality to handle and parse DW components but this
was not managed to work. Contact was taken with Atrenta regarding this.
They referred the problem to that the DW component used was new and that
there were no wrappers to handle it at the time. The support at Atrenta made
new wrappers which were received within a day. But the parsing problem
persisted and after a few days of troubleshooting and debugging without
progress the rest of the evaluation had to move on. The problem was
temporarily solved by black boxing the DW instance. Possible causes to the
problem could be the environment linking to Design Compiler (which Spyglass
invokes to compile the DesignWare libraries) or that the Spyglass version
used did not work with the new DW wrappers. Atrenta was however very
forthcoming and eager to help, as they were during the entire evaluation.

The main problem seen in the CDC package was Spyglass’ lack of
functionality regarding propagation of the reset signal. The tool was unable to
detect the de-assertion structure used in the Anna project. Because of this a
large number of unwanted violations were generated which in turn
complicated the correction work. The reset signal had to be manually defined
as synchronously de-asserted in the SGDC file. Due to the simple structure of
the reset de-asserter used in Anna it is quite surprising that Spyglass was
unable to detect it. Contact was taken with Atrenta regarding this problem and
they promised to look into it. CDC checks are however not a big issue at the
ASIC department. There are not that many crossings in the designs and the
basic CDC package would therefore suit their purpose.

25
 In the question regarding whether Spyglass can reduce resources costs by
preventing faults that would otherwise appear during synthesis the answer is
yes. Spyglass has functionality to check for all the three warnings with
importance degree “high” and half of the warnings with importance degree
“medium”. After discussion with a designer it was concluded that the
estimated saving in time could be a week to several month, if Spyglass were
to be introduced. This estimation is based on the assumption that the
synthesis engineers’ saves a week if the warnings with “high” importance
degree were to be confirmed as “intentional” directly. The overhead of going
through them all would be redundant if the person writing the code had
already confirmed them with Spyglass. If one of the warnings slips through,
the correction work could be massive and take up to a month and involve
many engineers. The result is that the savings could be very considerable on
this level of use. For the calculations the reader is referred to [Wickberg,
2007].

3.6 Aspects that has not been evaluated

In this chapter a short discussion regarding interesting aspects regarding

functionality that has not been tested is brought up.

An interesting aspect that has not been evaluated in this thesis was the Auto-
Verify policy in Spyglass. This policy contained functionality to verify false
paths and later on (in Spyglass version 3.8.3) multi cycle paths. Another
interesting aspect was the SOC rules in the DFT policy. These rules were
supposed to be able to verify that signals specified in the SGDC file were
correct with different input stimuli. A more extent evaluation regarding case
analysis on a design containing full implementation of test logic would also
have been interesting to perform.

26
4 Part III - Spyglass compared with other tools
This chapter contains a comparison between Spyglass and three other static
rule check tools. For each tool the overall impression and capabilities is
outlined and discussed. The tools are also compared in a spreadsheet to get
a good overview of the differences in interesting aspects. The spreadsheet
can be found in chapter 4.4. There is also a comparison between Spyglass
and Synopsys LEDA regarding the ability to customise rules for
SystemVerilog code.

4.1 Synopsys LEDA, version 2006.06

Leda is probably, after Spyglass, the most advanced tool in the area. The
results gained from one week of testing the tool are outlined in this chapter.
For information regarding how to use LEDA the reader is referred to
[Synopsys 3, 2006].

4.1.1 LEDA in the design flow

The way LEDA is supposed to be used is before the functional verification

RTL-code. The developer run Leda on the finished block and delivers the
RTL-code along with leda.log and leda.inf. The leda.log file should be empty
and for all the deselected rules in the leda.inf file there should be an
explanation to why that rule has been deselected, if any. LEDA can also be
used on a netlist but has then limited functionality in terms of suitable rules.

4.1.2 Running LEDA

Setting the environment took a lot of time and LEDA did not elaborate in the
beginning. The main reason for this behaviour was that there were instances
in the design lacking functionality in libraries. The compilations of the libraries
were difficult and the impression was that Synopsys have to work with this.

The application was uncomplicated to handle once the environment had been
set up, in terms of finding and compiling all the libraries etc, the checks run
quite fast and the explanations to the violated rules were decent however
more details were desirable. It was easy to dig deeper into the code from
where the violation occurred which could be done by either tracing the error
with a schematic view or directly in the code with the built in editor. The
schematic view visualised only the logic involved in with the chosen violation,
however the user could navigate further in the design if that was required. The
LEDA main window with the schematic view is visualised below in Figure 13.
There were cross-reference capabilities between the schematic view and the
editor. This made it possible to select a desired structure in the schematic to
be viewed in the editor.

27
 Figure 13 Screenshot of LEDA.

When browsing through the violations after a run it was hard to get a good
overview of the violations. It would have been nice with filter capabilities like
not showing violations that went over a thousand in number, or was decided
to be of little importance during that particular run, without to have to turn that
rule of before the run. Filter functions like “show only violations regarding
clocks and resets” or “show FSM correlated violations” in the design could be
of help. Another nice but absent functionality would have been the ability to
filter a particular violation of a rule in the design.

4.1.3 Reports

A very nice feature was the ability to save an HTML document that further
explained the rules that had failed. In this document the violations were
described in more details than in the GUI and it also presented the number of
gates and latches that the design contained etc. This feature would make it
possible to correct uncomplicated bugs and errors without running the
application and thus not occupy a licence someone else needs. Below is an
example of one of the reports.

-- DESIGN REPORT --

Name of the top: top

Library containing the top unit: /home/efrewic/leda/demo/demo-

libs/LEDA_WORK

Number of design pins: 35

Number of hierarchy levels in the design: 4

28
 Number of flipflops and latches that LEDA tools has inferred
Number of flipflops: 176
Number of latches: 16

Number of clock origins: 1

Number of reset origins: 1
List of clock origins:
top.clk

List of reset origins:

top.rst

List of source paths:

$0 = /app/synopsys/leda/2006.06/test/mixed/src/topunit.v
$1 = /app/synopsys/leda/2006.06/test/mixed/src/stage2.v
$2 = /app/synopsys/leda/2006.06/test/mixed/src/shift_reg.v
$3 = /app/synopsys/leda/2006.06/test/mixed/src/reg.v
$4 = /app/synopsys/leda/2006.06/test/mixed/src/misc_logic.vhd
Ð Ôà

There were a lot of different angles to approach the report. This was done
through, as mentioned, a HTML document, a text document, or the GUI
depending on the desired way of procedure.

4.1.4 Concerning rules

There were a lot of different rules in different categories, about 1500. When
choosing the desired rules you can either sort them by topic (e.g. CLOCKS,
FSM, DFT etc.) or by policy (e.g. IEEE, DC, LEDA etc.). There were rules for
e.g. how a state machine should be constructed, if the outputs from a block
are registered, is there a reset for all the flip flops etc. There were also rules
concerning the RTL code’s power efficiency. The desired checks concerning
identification and verification of multi-cycle path was however not available.
LEDA was capable of checking whether a signal was synchronised with a
double flip flop when crossing clock domains, but for now, not capable of
checking the synchronisation of busses.

It was relatively hard to configure your own set of rules in terms of selecting
and identifying desired rules. At this point the application was not as user
friendly as the HTML report. When putting together a set there were a lot of
different rules to choose from and it was hard to get a good overview. A
feature desired was a search function where you can search for e.g.
“Asynchronous loop” and then get a list of rules concerning that subject.
Instead you had to search with the UNIX functions find and grep in a
terminal.

29
4.1.5 LEDA compared to Spyglass

The main impression of LEDA was that it was acceptable with remarks.
Compared to Spyglass the schematic view could be more sophisticated, the
explanations to the rule violations more extensive and the navigation through
rules and violations easier. Filter abilities that exists in Spyglass was also
highly desirable. Regarding to functionality LEDA was somewhere between
Spyglass and Cadence HAL. It can check double flip flop synchronisation of a
signal as mentioned before but not the synchronisations of a bus. On the
other hand had LEDA some advantage in relation to Spyglass. Especially the
extensive HTML report over the violations was good. With this, the user could
make the error corrections without holding to any licence.

4.2 Cadence Incisive HDL Analysis (HAL), version 5.82

4.2.1 HAL in the design flow

HAL is supposed to be used early in design flow on the RTL block and chip
design. As Cadence describes in [Cadence 2, 2004]:

“HAL supports Verilog, VHDL, and Mixed language designs. For Verilog
designs, HAL supports both file-based analysis as well as the snapshot-based
analysis (This snapshot is the simulation snapshot created after elaboration).
For VHDL and Mixed language designs, HAL supports snapshot-based
analysis. In the snapshotbased mode, HAL performs the complete set of
checks including checks, which span across multiple modules. In the file-
based mode (for Verilog only), HAL performs only lint checks.”

This snapshot could in other terms be described as a light synthesis. Even

though the main use was on early RTL code there were also a number of
rules for netlist post synthesis as well. The easiest way to use HAL was in
batch mode and then the user was supposed to navigate through the
violations with the GUI named “NcBrowse”. Text reports could also be
generated which made it possible to correct errors without occupying a
license.

4.2.2 Running HAL

Navigating through the violations was easy in HAL and the explanations to the
violations were good. The schematic view was also quite nice and easy to
use. Using HAL Definition File Editor the user could either decide which
predefined set of rules to be used or configure new customized sets. All the
rules could be parameterized. The overview of the rules in the HAL Definition
File Editor was poor and the user have to use a combination of the grep
command in a terminal and the GUI to be able to define a set of rules. The
main reason to the low grade given was that there were no explanations to
the rules in the GUI, but instead a six letter long name that did not tell you
anything about the rules purpose. The switching between the GUI and the
terminal made it so complicated that simply editing the .def with a text editor
was easier.

30
 Figure 14 Screen dump of HAL.

4.2.3 Reports

The report HAL generates fulfilled its purpose in terms of making it possible to
correct errors without occupying a license. The report was short, descriptive
and concise, though at some occasions more explanations to the violations
was desired.

4.2.4 Concerning rules

HAL’s main use was for regular lint checks and simpler CDC and DFT
checks. More advanced rule checking as complex CDC checks, constraints
checks and power were not supported.

4.2.5 HAL compared to Spyglass

That HAL only supported file-based mode lint checks for verilog files, this was
a disadvantage compared with Spyglass in the sense that for some rules the
tool needed to do a synthesis.

The schematic tracer in HAL was not as sophisticated as the one in Spyglass
even though it was acceptable. There was also no support for signal
stimulation and propagation in HAL, and no such functionality as a waveform
diagram was present, as in Spyglass. Configuration of the set of rule to be
used was a major disadvantage in HAL compared to Spyglass where this
activity was easy. Spyglass had first class violation explanation although the
explanations in HAL were not bad at all.

31
4.3 Mentor HDL Designer/Design Checker, version 2006.1 beta

4.3.1 Design Checker in the design flow

Design Checker is a tool for pure lint checking and it is supposed to be run at
an early stage in the design flow. The application is hardly integrated in
Mentors HDL Designer which is a tool for helping engineering teams create,
manage and analyze large complex designs. More information regarding
Design Checker can be found in [Mentor, 2006].

Figure 15 Snapshot of Design Checker.

32
4.3.2 Running Design Checker

The environmental setting for Design Checker was done in Designer Manager
(the main GUI of HDL Designer) and was very easy, but then the purpose of
HDL Designer is to manage designs so that was somewhat expected.

The cross references between HDL Designers main window and Design
Checker were also very good. When the user had run the desired checks
other features of HDL Designer was used to navigate and correct errors and
warnings found in the design during the run. Another nice feature in the tool
was the filter function, which provided an excellent overview and made the
correction work easy. There were many ways of filtering the violation
messages and it was easily done. Waiving capabilities were not supported
and should be implemented in the upcoming version of the tool.

Design Checker was shipped with a couple of hundred rules, which almost all
could be parameterised. The tool was also shipped with a number of pre
defined sets of rules, but the idea was that the company puts together their
own. The work of specifying a new set of rules was easy and there were
excellent explanations to the rules. What you cannot do in Design Checker
was to define your own rules, which were a great minus. New rules could be
ordered from Mentor from a charge or contract.

When correcting your design there was a feature in HDL Designer that gave
the user a spreadsheet view over the design. This view was excellent to use
when debugging block connectivity problems or just errors that propagated
over the entire chip.

4.3.3 Reports

The report features in Design Checker has not been tested and therefore a
grade has not been set. But referring to the “Design Checker tutorial” the tool
is capable of generating CSV, TSV and HTML document. The CSV (comma
separated value) is written into a .csv extended file, the TSV (tab separated
value) into a .txt file and HTML (HyperText Markup Language) into a .htm
extended file.

4.3.4 Concerning rules

Design Checkers purpose, as mentioned earlier is pure lint checking. This

makes an impact to the number of rules the tool provides. There are rules for
typical lint checking like; naming conventions, FSM structures, registered
outputs, flip flogs has reset etc. But there are no rules for DFT, CDC,
constraints, timing or power.

4.3.5 Design Checker compared to Spyglass

Spyglass and Design Checker concerning functionality are each others

opposites. While Design Checker is purely meant to be used for ordinary lint
checking, Spyglass is meant to be used for more. Therefore the question,
regarding selecting one of tools before the other, must be asked.

33
- Are the tool meant for plain lint checking or shall the tool be used to debug
clock/reset tree propagation, constraint files, DFT problems (test signal
propagation observability/controllability), power use etc.?

If the answer is that the tool chosen solitarily will be used for lint checking
then Design Checker is the preferred choice, otherwise Spyglass or LEDA
should be selected.

Both tools give a very solid impression and it feels like there are a lot of
thoughts behind the development in either case. The filter function in Design
Checker was somewhat more sophisticated than its counterpart in Spyglass,
even though the Spyglass equivalent was good.

34
 4.4 Tool comparison overview
S y nopsy s LED A C a de nc e H A L A tre nta S py gla ss M e ntor H D L-D e signe r
Ge ne ra l
Ove ra ll s ta b ility 2 3 4 3
K n o w le d g e a b o u t d e s ig n
fu n c tio n a lity to a c e rta in d e g re e no y es no
S e ttin g u p th e e n viro n m e n t 2 2 4 5
lim ite d , fu ll in
S y s te m ve rilo g s u p p o rt lim ite d lim ite d ~fe b ru a ry 2 0 0 7 no
E la b o ra tio n e rro r E la b o ra tio n e rro r Give s a w a rn in g o f
B la c k b o x h a n d lin g m es s age m es s age B B d e te c tio n H ig h lig h te n s B B
1 0 m in - >2 4 h ,
R u n tim e 1 0 m in - 1 h 1 0 m in - 1 h d e p e n d in g o f ru le s 1 0 m in - 1 h

R ule se le c tion
N o (D o n e w ith g re p N o (D o n e w ith g re p
R u le s e a rc h e n g in e in te rm .) in te rm .) 4 4
P a ra m e te riz e d ru le s y es y es 3 4

y e s , in C P I y e s , u s in g p re -
y e s , u s in g V e R S L , (C a d e n c e S p e c ific d e fin e d ru le p rim itive s n o , n e w ru le s c a n b e
V R S L , C /C ++ o r A P I fo r c o d in g in P E R L e n v. o r C o rd e re d a fte r
C re a tio n o f n e w ru le s TC L s tru c tu ra l c h e c k s ) w ith a n A P I. c h a rg e /c o n tra c t.

R e port
H TM L d o c u m e n t g e n e ra tio n 4 no no y es
.tx t d o c u m e n t g e n e ra tio n 4 y es 4 y es

R ule v iola tion brow sing

2 w h e n d e fin in g a
V io la tio n d e s c rip tio n , ru le s e t. 5 w h e n
e x p la n a tio n 3 b ro w s in g vio la tio n s 5 4
E d ito r b u ilt-in b u ilt-in u s e r d e fin e d b u ilt-in
S c h e m a tic vie w 3 3 5 4
5 , n ic e fe a tu re w h e re
b lo c k c o n n e c tivity is
B lo c k c o n n e c tio n s p re a d s h e e t no no no s hown.
N a vig a tin g th ro u g h d e s ig n 3 3 5 4

R ule obse rv a bility

s o o n w ith
W a ive a b ility no no y es p ra g m a s /e x c lu s io n s
Filte r fu n c tio n no 3 3 5
D is a b le fu n c tio n y es y es y es y es

S upporte d R ule s
te m p la te b a s e d /lig h t
D e te c tio n o f c lo c k s /re s e t lig h t s y n te s is s y n th e s is lig h t s y n te s is te m p la te b a s e d
L in t ru le s y es y es y es y es
C o n s tra in ts c h e c k in g y es no y es n o , d o n e in P re c is io n
Tim in g p a rtly no y es no
P o w e r (le ve l s h ifte rs , d o u b le
in p u t ...) y es no y es no
D e te c tio n o f m u ltic y c le p a th s no no 0 7 -m a r n o , d o n e in C D C 0 -In
V e rific a tio n o f m u ltic y c le p a th s no no 0 7 -m a r n o , d o n e in C D C 0 -In
D o u b le flo p s y n c h ro n iz a tio n fo r
s ig n a ls y es y es y es n o , d o n e in C D C 0 -In
P ro p e r s y n c h ro n iz a tio n o f
bus s es no no y es n o , d o n e in C D C 0 -In
FS M s tru c tu re s y es y e s , ~1 0 ru le s y es y es
D e te c tio n u n re g is te re d
o u tp u ts /in p u ts y es y es y es y es
D FT y es y e s , ~ 4 0 ru le s y es no

Table 4 Spreadsheet over differences between the evaluated tools.

35
4.5 SystemVerilog support for rule customisation

To be able to determine the support for customising and creating new rules in
Spyglass and Leda, six test cases have been defined. The test cases was
chosen and defined in a way so they would be syntactically representative
and reflect the SystemVerilog language rather than design behaviour. The
test cases are listed below:

1. Port declarations for objects that are packed arrays of unpacked array
objects, must not use the type ‘logic’ for the packed dimension.
Example:

input logic [15:0] datain [0:143];

2. Type cast must not be made on expressions. Example:

a = unsigned’(b + c);

3. Signal aliasing must not be used. Example:

alias a_slice = an_array[7:4];

4. Assignment operators (‘+=’, ‘-=’, ‘++’ etc.) must not be used. Example:

a += 2;

5. Array assignment to unpacked arrays must not be used. Example:

int an_array [1:3];

...
an_array = {4, 6, 9};

6. Type definitions must not be forward referenced. Example:

typedef e_type; // empty typedef to define name

e_type e;
...
e = 1; // used before type is defined (forward
reference)
...
typedef int e_type; // type definition

4.5.1 Spyglass

The chapter will start with a short result presentation for the different test
cases and end with a summary of the work procedure and conclusions.

36
4.5.1.1 Case 1

Possible rules to take as template for customization is: STX_287,

STX_296.
Solution: No rules were written.
Test code runs through Spyglass parser: YES

4.5.1.2 Case 2

Possible rule to take as template for customization is: SYNTH_137 and

SYNTH_5335.
Solution: No rules were written.
Test code runs through Spyglass parser: YES

4.5.1.3 Case 3

Possible rules to take as template for customization is: SYNTH_5399.

Solution: No rules were written.
Test code runs through Spyglass parser: YES, Spyglass reported
unsynthesizable block, unsupported SystemVerilog construct and pointed to
the alias statement.

4.5.1.4 Case 4

Possible rules to take as template for customization is: DisallowMult-ML,

STX_1199.
Solution: No rules written.
Test code runs through Spyglass parser: YES, Spyglass reported
unsynthesizable block, unsupported SystemVerilog construct if the double
operator (e.g. ‘++’) was used.

Spyglass was able to parse the code in Case 5 and Case 6 but there was no
functionality present for writing new rules.

4.5.1.5 Summary

Referring to the [Atrenta 3, 2006] there are four ways of customizing rules.
These are listed below in order of increasing complexity.

• The easiest way is to identify a similar existing rule and check whether it
has some parameters that can be changed to fit your need.

• If there are no rules to parameterise the user can see if the Built-In
Checks can be used. This method does not actually end up with new
check functionality, but more messages to existing built-in rules.

37
• The third way is to use Spyglass pre-defined rule-primitives to write new
rules. The rule primitives are C-functions which extracts information from
the design database in different ways depending on the object they are
run at and the arguments given. A good procedure of finding the right rule-
primitive is to use the spydocviewer and browse the Standard Rule-
Primitives section or do a grep in
$SPYGLASS_HOME/doc/c_primitives or
$SPYGLASS_HOME/policies/<policy-name>/c-primitives.

• If there are no c-primitives matching the desired functionality the user can
define new.

After some browsing and searching among the existing rules it was
established that there were none which could be parameterized to have the
desired abilities. This was expected from the beginning. The next way of
course, described above, was of no interest because it was new checking
functionality rather than only new messages desired. Using rule-primitives
could be profitable because it would make the development of new rules
much easier. Spyglass’ set of rules templates were searched for rules with
similar behaviour to the cases previously defined. As an example for case 1,
the rule STX_287 (improper assignment to a mixed array) was found. If the
functionality concerning identifying a mixed array along with the functionality
to identify logic declaration could have been united, it could have been the
solution. The problem was that this rule (STX_287) and other similar rules
used a primitive called “veParser”. This primitive could not be found in the c-
primitive directories. After contact with Atrenta they confirmed that this
primitive was not documented and could not be used by external users. They
also eventually confirmed what was already suspected, that there are no
primitives to handle the sought behaviour. This left it into the creation of new
rule-primitives which in turn could have been used to make the rules for the
test cases. This method was, compared to the other three, quite more
complicated and required a lot of knowledge of how the Spyglass database
was constructed. According to Atrenta it would be difficult for customers to
write the new rules themselves. Being able to create new rule-primitives was
also only possible if the user possessed a Spyglass Rule Builder license,
which gave full access to the database.

An interesting point of view was that the test code went through the Spyglass
parser without complaints or errors. This indicated that the tool could handle
SystemVerilog code, which also was a question mark. The test code used is
shown in Figure 16

It was decided to round up the investigation here and leave the further
rule-primitive definition to an external part, if the company decided to go
further in this area.

38
 // Simple testcase for the custom defined rules for SV built
// with sv_test_rules.sl file
module testmod(
input logic clk, rst_n,
input wire [7:0] alia,
output wire [3:0] al, ia,
output logic [3:0] inc_in [3:0]); //Should fail.

alias alia[7:0] = al; //Should fail.

alias alia[31:24] = ia; //Should fail.

int signed b,c,x,y,z,w;

int unsigned i,a,d;
int an_array [0:2];

always_comb
begin
for (i=0;i<4;i=i+1) begin
inc_in[i] += 2; //Should fail.
end
end

initial
begin
a = unsigned'(b + c); //Should fail.
d = unsigned'(b); //Should pass.
w = x + y * z; //Should pass.
an_array = {4, 6, 9}; //Should fail.
end

endmodule

Figure 16 Test code used when evaluating SV support in Spyglass.

4.5.2 Leda

The chapter will start with a short result presentation for the different test
cases and end with a summary of the work procedure and conclusions. For

4.5.2.1 Case 1

Solution: A new custom rule was not written. The current build of Leda was
not able to catch this structure. It will however work with the next build
according to Synopsys.
Test code runs through Leda parser: YES

4.5.2.2 Case 2

Solution: A rule to catch cast violations in Systemverilog already existed in

Leda and worked with the test case in Figure 17.
Test code runs through Leda parser: YES

39
4.5.2.3 Case 3

Solution: A new custom rule was not written. Alias assignments in

Systemverilog were not recognised in VeRSL.
Test code runs through Leda parser: NO, the code regarding the alias test
was taken from [Accellera, 2006] with some modification, but were
commented out because of build failure.

4.5.2.4 Case 4

Solution: A new custom rule was written. For this occasion a new rule were
created which prohibited all assignment operators. The function used was not
documented in [Synopsys 4,2006] but came directly from Synopsys R&D
division.
Test code runs through Leda parser: YES

4.5.2.5 Case 5

Solution: A new custom rule was not written. Problems with identifying both
the array structure { .., .. , .. } and the use of unpacked arrays in the
assignment were encountered.
Test code runs through Leda parser: YES

4.5.2.6 Case 6

Solution: According to Synopsys there was no way of writing a rule to catch

this syntax.
Test code runs through Leda parser: Not tried.

4.5.2.7 Summary

The language used when creating new rules was called VeRSL (Verilog Rule
Specification Language) or VRSL (for VHDL). For more information regarding
this area the reader is referred to [Synopsys 1, 2006] and [Synopsys 4, 2006].
This language was macro-based and was constructed of a number of
templates and adherent attributes on which a set of commands were used
upon. Example: The definition of a rule checking that only addition and
subtraction were used in the design looked like this:

Only_add_n_sub:
limit operator_symbol in binary_operation to “+”, “-“
message “Only + and – operators are allowed in the
design”
severity WARNING

limit is the command, operator_symbol the attribute and

binary_operation the template.

40
In Case 2 there were already a rule checking the use of “cast”, but that rule
prevented all use of “casts”. It was later also confirmed by Synopsys that it
would not be possible to customise the rule. The absence of documentation
regarding the cast attribute used in the existing rule made it impossible to
know how it should be used. In all other cases Leda lacked the functionality of
identifying the SystemVerilog syntax. However all the test cases passed the
parser except Case 3, where the use of the alias statement caused build
failure.

Apart from using VeRSL, rules could also be made using C or TCL, however
rules checking RTL code could not be made in this way. The C and TCL
languages were only meant to be used for rules catching design behaviour.
Therefore, if there were no templates and attributes available that could catch
the undesired language syntax, no rules could be made.

// Simple testcase for the rules in the Verilog policy built

with
// sv_test_rules.sl file
module testmod(
input logic clk, rst_n,
//input wire [7:0] alia,
//output wire [3:0] al, ia,
output logic [3:0] inc_in [3:0]);

//alias alia[7:0] = al;

//alias alia[31:24] = ia;

int signed b,c;

int unsigned i,a;
int an_array [0:2];

always_comb
begin
for (i=0;i<4;i++) begin
inc_in[i] += 2;
end
end

initial
begin
a = unsigned'(b + c);
an_array = {4, 6, 9};
end

endmodule

Figure 17 Test codes used for evaluate LEDA SystemVerilog support.

41
42
5 Results

5.1 Part I

In this chapter the results from the evaluations of Phoenix, Hwacc and Anna
are presented. For each block the deviating rules are presented along with an
explanation to why they were or were not considered to be the cause to the
undesired iteration. Rules that did not cause a deviating number of violations
between two versions, but were considered to be important nevertheless are
also presented. Rules that were violated in more than one comparison but not
considered to be the cause to the undesired iteration is not presented
extensively more than once, but only mentioned.

Rule violation concerning naming and DFT was not considered in this part of
the evaluation. The reasons were that a naming violation would not have
caused an undesired iteration and the chip vendor inserted most of the test
functionality. The setup functionality was to a great part therefore unknown. In
part II of this evaluation on the other hand, where checks on RTL was studied,
an entire chapter is spent on Spyglass capacity of making RTL code DFT
ready. The reason to why these rules were run was to simulate the run time, if
such rules were to be used in the future.

5.1.1 Phoenix netlist version 8 compared to version 9

The Phoenix netlist versions 8 and 9 were evaluated. Between these two
versions the following rules gave a deviating number of violations. An
explanation to why the violations were or were not considered to be the cause
to the undesired iteration is given. Appendix A describes how the netlist
version selection process was performed and the results from it.

Rules with a deviating number of violations

BB_DES013 – Do not tie inputs to logic 0,logic 1,VDD,GND.

51 violations in v.8, 50 violations in v.9.
This is usually bad coding practice but it can be necessary in some cases. For
example in this case some flip flops was not fully connected until after
synthesis. The designer wanted to make sure that the synthesis tool did not
replace an intended gate with another, as it might do if the pins are
unconnected. None of the violations were considered to be the reason to an
undesired iteration.

BB_DES014 – Net driving several inputs is not allowed.

734 violations in v.8, 741 violations in v.9.
Probable design choice. Not considered to be the reason to an undesired
iteration.

43
 BB_DES050 – Do not use feedthrough signals.
17 violations in v.8, 16 violations in v.9.
Feedthrough signals is not design practice and should be avoided. Spyglass
reported feedtrough paths inside the ASIC vendor library cells. They were
therefore not considered to be a reason to the undesired iteration. The
problem was that the BB_DES050, according to [Atrenta 1, 2006], is only
used on RTL while the BB_DES250 checks the equivalence for netlists.

BB_DES125 – Do not instantiate library cells in the design.

77871 violations in v.8, 77444 violations in v.9.
On a netlist level, breaking this rule is unavoidable.

BB_DES135b – All flip-flops must use asynchronous reset in the design.

685 violations in v.8, 682 violations in v.9.
The most common way of implementing the reset signal is to have a de-
asserter mechanism immediately after input. The reset will then be
synchronously released. In this case the de-asserter was implemented higher
up in the hierarchy and before it entered the Phoenix block. Therefore these
violations were not considered to be the reasons to the undesired iteration.2

BB_DES720 – Logic inferred at top level design.

143 violations in v.8, 157 violations in v.9.
Phoenix was only a block within the Anna design and hence not the top level.
This rule was therefore not considered to be a reason to the undesired
iteration.

BB_DES751 – Internal clocks must be controllable from external pins.

7879 violations in v.8, 7875 violations in v.9.
Before further explanation see Figure 18. Here Spyglass could not recognise
that the gated clock out from Q was the same as the CP, when controlled
externally from E or TE, which was strange. All the 7875 clock pins reported
was verified to be caused by this behaviour, but several hundred were
investigated. These violations were not considered to be the cause to an
undesired iteration.

Figure 18 Spyglass reports that CP and Q are different clocks.

Important rules without a deviating number of violations

2
This was later defined in the SGDC file.
44
 BB_DES040a – All flip-flops must be initialized from external resets.
3 violations in v.8 and v.9.
The violations turned out to be a design choice and were hence not
considered to be a cause to the undesired iteration.

From the results presented this far no cause to the undesired iteration had
been found. The reason for this could be one of the following.

• The error was of such a kind that Spyglass was unable to find it.
Remember that the ASIC vendor did not evaluate Anna using Spyglass.

• It might not have been an error that generated the iteration. New
functionality might have been added.

• Spyglass did recognise the error but it slipped past in the filtering before
the violation examination. As mentioned, in chapter 2.1, the method used
for the evaluation is not flawless and fault proof but only a heuristic model.

5.1.2 Hwacc netlist comparison

The Hwacc netlist versions 2, 3 and 4 were evaluated. An explanation to why

the violations were or were not considered to be the cause to the undesired
iteration is given.

5.1.2.1 Hwacc, v.2 versus v.3

In this section is the rules that deviated in number between runs on version 2
and version 3 of hwacc.v presented.

Rules with a deviating number of violations

BB_DES125 – Do not instantiate library cells in the design.

184183 violations in v.2, 183860 violations in v.3.
On a netlist level, breaking this rule is unavoidable.

BB_DES151 – Combinatorial paths crossing multiple units are disallowed.

512371 violations in v.2, 531289 violations in v.3.
It is unlikely that a combinational path stretching over multiple units is the
reason for an undesired iteration.

BB_DES250 – Do not use feedthrough signals.

542 violations in v.2, 541 violations in v.3.
The difference between the two runs were a signal called “tbypass” which
were not reported as feedtrough in version 3. The rest of the 541 violations
were a signal called dgr[0:64] to dgrs[0:64]. After consultation with a designer
none of the violations were considered to be the cause of an undesired
iteration.

45
 BB_DES746 – Some outputs from a top module are not registered.
96 violations in v.2, 97 violations in v.3.
These violations could be important and they were all examined but it turned
out to be only the bist vector which was not registered. In this early stage the
bist logic were not ready and due to this these violations were not considered
to be the cause of the undesired iteration.

The rules BB_DES013, BB_DES014, BB_DES720 were violated between

these to versions as well. The reason to why these were not considered to be
the cause to the undesired iteration is given in section 5.1.1.

Important rules without a deviating number of violations

BB_DES040 – All flip-flops must be initialized from external resets.

16 violations in v.2 and v.3.
The rule was violated and reported six types of gates that were instantiated at
a number of places.

BB_DES042 – Avoid constant values on the data input pin of flip flops.
120 violations in v.2 and v.3.
As with rule BB_DES013 the tied input signals are for test logic as scan chain,
bist etc. The reason for that this rule has so much fewer violations than
BB_DES013 is because this rule reports a great number of flip flops in each
violation. Only having this rule enabled would probably be sufficient and do
the job, but whether to disable BB_DES013 would depend on the way the
corrections were to be made.

The result from the examined violations was that no cause to the examined
undesired iteration was found. The reason to this is discussed in section 5.1.1.
But two of the rules that were considered to be extra important had violated
and had to be traced further. These rules will be discussed in section 5.1.2.2
with the presentation of the results from the comparison of version 3 versus
version 4.

5.1.2.2 Hwacc, v.3 versus v.4

In this section the rule that deviated in number between runs on version 3 and
version 4 of hwacc.v is presented. Rules having the same explanation to why
they were, or were not, considered to be cause to the undesired iteration as in
the comparison of version 2 and 3 are referenced to section 5.1.2.1 for this
explanation.

Rules with a deviating number of violations

BB_DES057 – Re-entrant outputs should be avoided.

23327 violations in v.3, 23417 violations in v.4.
In this case Spyglass reports flip flops which has the TQ (scan out) signal
directly connected to the TI (scan in) signal. This is a design decision and the
reason is that a great part of the test functionality is not implemented in these
early versions. This design behaviour is to prevent the synthesis tool from
replacing the flip flop with a flip flop without TE and TQ pins.

46
 The rules BB_DES013, BB_DES014, BB_DES042, BB_DES125,
BB_DES151, BB_DES250, BB_DES720, BB_DES746 were violated between
these to versions as well. The reason to why these were not considered to be
the cause to the undesired iteration is given in section 5.1.1 and 5.1.2.1.

Important rules without a deviating number of violations

BB_DES040 – All flip-flops must be initialized from external resets.

16 violations in v.2 and v.3.
Explanation: see ditto in comparison of v.2 versus v.3.

From the explanations to the rule violations given above no direct cause were
found to the undesired netlist iteration. The reason for this is discussed in
section 5.1.1. There were however still the rules that were considered to be of
extra importance which were violated in the comparison between hwacc v.2
and v.3. Rule BB_DES042 deviated in the present comparison and were after
an examination not considered to cause to the undesired iteration. That left
rule BB_DES040 which still had the same 16 violations. A trace, with only the
BB_DES040 rule enabled, was performed to see if these violations persisted
through the versions. The trace was performed according to the following
procedure.

• Only the BB_DES040 rule was used.

• The netlist versions were checked in increasing order starting from the
current.

• The violations were examined on every version even if the number of

violation did not deviate with the previous version.

The trace stopped when a version with less number of violations from rule
BB_DES040 occurred and an explanation to all violations were found.

The result from the trace was the following. In version 5 only 8 violations
occurred. Therefore a possible cause to the undesired iteration was found
between version 4 and version 5. After consultation with a designer the
conclusion that an actual error had been found were made. The remaining 8
violations turned out to be flip flops that should not have resets according to
their functionality. The errors found were added to Equation 1.

5.1.3 Anna

The evaluation of the Anna block suffered from incredibly long run times (this
issue will be discussed further in chapter 2.6) and after a few tryouts with
different sets of rules only rule BB_DES040 was selected and run on version
3 and 5.

47
 BB_DES040 – All flip-flops must be initialized from external resets.
There were a number of violations to the rule, most of them were to be found
in the pad logic the ASIC vendor provided and was therefore not considered
to be a cause to the undesired iteration. After a trace there were interesting
differences between versions 6 and 7 and versions 8 and 9. Between
versions 6 and 7 two flip flops cells had been corrected with reset. Between
versions 8 and 9 four flip flops cells had been corrected with reset. After
consultation with a designer the conclusion that an actual error had been
found were made and the result was added to Equation 1.

5.2 Part II

5.2.1 Constraints

In this section the results from the evaluation regarding Constraints cover and
correctness are presented. The rules that were evaluated were chosen
regarding to the SDC commands used in the Anna project and rules that were
especially desired by the designers in the project. Besides the chosen rules
associated parts of the SDC file is presented.

Most of the constraints rules were not violated in the unmodified version of the
CMC. In order to check the functionality of the rules some changes were done
in SDC file in order to force a violation.

5.2.1.1 Results from the CMC

General clock rules

• Clk_Gen01, Clock not driven by a clock constraint.

If the clk was not defined in the SDC file using the create_clock
command this rule was violated. When the command line below was left
out from the SDC file a violation occurred. The rule also generated a large
number of violations concerning signals that were inputs to the enable
signal on latches. Spyglass recognises these signals as unconstrained
clocks. The rule was therefore considered to work with remark. It would be
preferable if the rule could be customised in order to choose whether the
enable signal is to be regarded as a clock or not.

create_clock –name clk –period 3.2 –waveform { 0 1.6 }

[get_ports {clk}]

• Clk_Gen02, Constrained clock not used as a clock.

The rule was violated if there was a signal defined with the
create_clock command but was not used as a clock. When the
command line below was defined in the SDC file a violation occurred.

create_clock –name iReset_n –period 3.2 –waveform { 0

1.6 } [get_ports {clk}]

48
• Clk_Gen12, Virtual clock has no corresponding real clock with same
period and waveform.
The rule generated a violation if there was no physical clock correlated
with a defined virtual clock. When the command line below concerning clk
was left out in the SDC file a violation occurred.

create_clock –name clk –period 3.2 –waveform { 0 1.6 }

[get_ports {clk}]
create_clock –name clkVirtual –period 3.2 –waveform {
0 1.6 }

• Clk_Gen22, The set_input_delay/set_output_delay is specified on clock

ports.
The rule generated a violation if a clock was constrained with
set_input_delay command in the SDC file. A clock should not be
constrained with input delay.

set_input_delay 1.6 –clock [get_clocks {clk}] –max

[get_ports {tck}]
set_input_delay -1.6 –clock [get_clocks {clk}] –min
[get_ports {tck}]

• Clk_Lat01, Clock_latency constraint set on an object which is not a clock.

The rule generated a violation if a non clock signal was constrained by the
set_clock_latency command. When the command lines below were
used in the SDC file a violation occurred. Only clocks should be
constrained by clock latency restrictions.

set_clock_latency –max 2 [get_clocks {iReset_n}]

set_clock_latency –min 2 [get_clocks {iReset_n}]

• Clk_Lat04a, Network latency using set_clock_latency constraint not

defined or equal to zero for create clocks.
The rule generated a violation if a real clock had no
set_clock_latency command constraining it. When the command
lines below were left out in the SDC file a violation occurred.

set_clock_latency –min 2 [get_clocks {clk}]

set_clock_latency –max 2 [get_clocks {clk}]

• Clk_Uncert02, Clock_uncertainty constraint not defined or equal to zero.

The rule was violated if there was no set_clock_uncertainty
command constraining the clk. When the command line below was left out
in the SDC file a violation occurred.

set_clock_uncertainty 0.79 [get_clocks {clk}]

49
• Clk_Trans02, clock_transition constraint not defined.
The rule was violated if there was no set_clock_transition
command constraining the clock. When the command lines below were
left out a violation occurred.

set_clock_transition –rise –max 0.15 [get_clocks

{clk}]
set_clock_transition –fall –max 0.15 [get_clocks
{clk}]
set_clock_transition –rise –min 0.15 [get_clocks
{clk}]
set_clock_transition –fall –min 0.15 [get_clocks
{clk}]

• Clk_Trans09, set_clock_transition should not be specified with only one

of –rise/-fall and –max/-min option.
The rule generated a violation if a clock was not completely constrained
by the –rise/-fall –max/-min attributes. When only the two command lines
below were used in the SDC file to constrain the clock a violation occurred
(the clock should have two -fall constraints).

set_clock_transition –rise –max 0.15 [get_clocks

{clk}]
set_clock_transition –rise –min 0.15 [get_clocks
{clk}]

• Clk_Trans12, clock transition specified with inconsistent option values.

The rule generated a violation if the –max value was less than the –min
value.

set_clock_transition –rise –max 0.14 [get_clocks

{clk}]
set_clock_transition –rise –min 0.15 [get_clocks
{clk}]

• Clk_Trans16, set_clock_transition set on virtual clocks.

The rule generated a violation if a virtual clock was constrained by the
set_clock_transition command.

set_clock_transition –rise –max 0.15 [get_clocks

{clkVirtual}]
set_clock_transition –fall –max 0.15 [get_clocks
{clkVirtual}]
set_clock_transition –rise –min 0.15 [get_clocks
{clkVirtual}]
set_clock_transition –fall –min 0.15 [get_clocks
{clkVirtual}]

50
Input delay rules

• Inp_Del01b, Input does not have a set_input_delay constraint.

The rule generated a violation if there was no set_input_delay command
constraining an input port. When the command lines below were left out
from the SDC file a violation occurred.

set_input_delay 1.6 –clock [get_clocks {clkVirtual}]

–max [get_ports {iReset_n}]
set_input_delay -1.6 –clock [get_clocks {clkVirtual}]
–min [get_ports {iReset_n}]

• Inp_Del02, Input constraint min/max delay inconsistent with associated

clock period.
The rule was violated if the one or both of the –min/-max values was
greater than the clock period. When the command lines below were used
in the SDC file a violation occurred due to the mismatch between clock
period and input delay.

create_clock –name clk –period 3.2 –waveform { 0 1.6 }

[get_ports {clk}]
create_clock –name clkVirtual –period 3.2 –waveform {
0 1.6 }

set_input_delay 3.3 –clock [get_clocks {clkVirtual}]

–max [get_ports {iReset_n}]
set_input_delay -1.6 –clock [get_clocks {clkVirtual}]
–min [get_ports {iReset_n}]

• Inp_Del03, Input constraint associated with wrong clock.

The rule generated a violation if an input port was constrained with a
different clock than the one actually used in the design. When the rule
was violated an indication to which clock the port should be associated
with, was reported. Below is the SDC declaration that generated a
violation (the bistInVec[769] is actually clocking some bist logic, but it is
not associated with iReset_n in the design).

create_clock –name bist_clk –period 1.6 –waveform { 0

0.8 } [get_ports \ {bistInVec[769]}]

set_input_delay 1.6 –clock [get_clocks {bist_clk}] –

max [get_ports {iReset_n}]
set_input_delay -1.6 –clock [get_clocks {bist_clk}] –
min [get_ports {iReset_n}]

• Inp_Del04, Input delay constraint has been incompletely defined.

The rule was violated if an input was constrained by only one of
the -max/-min or –rise/-fall options. When only the line below was
used to define a port in the SDC file a violation occurred.

set_input_delay 3.3 –clock [get_clocks {clkVirtual}]

–max [get_ports {iReset_n}]
51
 • Inp_Del06, set_max_capacitance constraints must be present on
input/inout ports of blocks.
The rule was violated if an input was not constrained using the
set_max_capacitance command. If the line below was not used in the
SDC file a violation occurred.

set_max_capacitance 4 [get_ports {iReset_n}]

• Inp_Del09, Not all pins on the same bus have the same input delay.
The rule was violated if the ports on a bus were constrained by deviating
values of the set_input_delay command. If the rows below were
defined in the SDC file a violation occurred due to input delay constraint
mismatch.

set_input_delay 1.6 –clock [get_clocks {clkVirtual}]

–max [get_ports eIO_0_RxIrq[0]]]
set_input_delay -1.6 –clock [get_clocks {clkVirtual}]
–min [get_ports {eIO_0_RxIrq[0]}]
set_input_delay 1.6 –clock [get_clocks {clkVirtual}]
–max [get_ports {eIO_0_RxIrq[1]}]
set_input_delay -1.6 –clock [get_clocks {clkVirtual}]
–min [get_ports {eIO_0_RxIrq[1]}]
set_input_delay 1.6 –clock [get_clocks {clkVirtual}]
–max [get_ports {eIO_0_RxIrq[2]}]
set_input_delay -1.6 –clock [get_clocks {clkVirtual}]
–min [get_ports {eIO_0_RxIrq[2]}]
set_input_delay 1.3 –clock [get_clocks {clkVirtual}]
–max [get_ports {eIO_0_RxIrq[3]}]
set_input_delay -1.3 –clock [get_clocks {clkVirtual}]
–min [get_ports {eIO_0_RxIrq[3]}]

• Load04, Load on output or inout ports not set or zero.

The rule was violated if there was no set_max_load command
constraining an input. When the line below was not defined in the SDC file
for input port iCmDataAck_ a violation occurred.

set_load –pin_load 4 [get_ports {iCmDataAck_*}]

Remark: Only rules for checking input constraints such as set_input_delay

and set_max_capacitance are presented. There are similar checks for
outputs as well, which also were evaluated. These will not be presented
simply because they all worked as expected and did not deviate in result
compared to the input rules.

5.2.1.2 Results from the Bubble Sort block

• Clk_Gen03, A generated clock is not in the fanout of its source clock.

The rule generated a violation if there was a black box between the
original clock and the generated clock or if there was no path at all.

52
 • IO_Consis04, Sum of input delay and output delay should not exceed
(clock period * parameter).
The rule generated a violation if the sum of the output delay from one
block and the input delay from a connected block was more than the
specified clock period multiplied with a customizable factor. When the
lines below were used the rule was violated. The factor used was 1.1,
3.2x1.1 < 2.5+1.6.

From the bb_sort_structural.sdc

create_clock –name CLK –period 3.2 –waveform { 0 1.6 }
[get_ports {CLK}]

From the bb_sort_fsm.sdc

set_output_delay 2.5 –clock [get_clocks {CLKVirtual}]
–max [get_ports {REG_ENB_0}]

From the bb_sort_reg.sdc

set_input_delay 1.6 –clock [get_clocks {CLKVirtual}]
–max [get_ports {ENB}]

• IO_Consis05, Input delay at top-level exceeds input delay at block level.

The rule was violated if a port low in the hierarchy (which was
combinatorial connected to a port higher in hierarchy) was less or equally
constrained than it was in the higher level. In the case below 1.7 > 1.6.

From the bb_sort_structural.sdc

set_input_delay 1.7 –clock [get_clocks {CLKVirtual}]
–max [get_ports {X0_s*}]

From the bb_sort_reg.sdc

set_input_delay 1.6 –clock [get_clocks {CLKVirtual}]
–max [get_ports {DIN*}]

5.2.2 DFT

Clock_11 – Internally generated clocks must be test clock controlled in shift

mode.
There were a large number of violations to this rule before the BIST signals
were defined in the SGDC file. The BIST[7] (TST_GATED_CLOCK) had a
great impact on the number of violations, which was very reasonable because
of the purpose and functionality of the signal. There were however 25
violations left, which altogether affected around 2000 flip flops, after the
definition of the BIST signals. Most of these violations had to do with the
ddr2TstPadlogicIn bus. The bus contains both a clock signal as well as a
select signal for propagation of the clock before an internally generated one.
The reason to why the bus was not defined in the SGDC file was that it was
not found in the test documentation. When tracing the signal further outside
the Anna core the following line was found in AnnaChip.vhdl:

ddr2TstPadlogicIn <= (others => ‘0’);

The assumption was made that the bus was cleared awaiting further test logic
implementation by the ASIC vendor (as the case with the BIST signals).
53
Three violations were caused by the absence of test clock definition for each
of the clocks into the EIO. As one can see in Figure 19 there was no select
logic between the clock input and the first flip flop. A reasonable assumption
was that the system clock/test clock selection was done in the AnnaChip
higher in the hierarchy. The last violations concerned the clock propagation of
the ddr2_fifo_test_in bus and the tst_pll_bypass signal. Which are
both cleared in the AnnaChip.vhdl. These signals were assumed to be
awaiting further test logic implementation by the ASIC vendor regarding to
their functionality and naming.

Figure 19 The propagation of the 156 MHz clock into the EIO jitterbuffer. Notice the
absence of a system clock / test clock multiplexer. The probable reason is
that this selection is done in the Test Mode Controller (see Figure 11).

Async_07 – All internally generated asynchronous sources should be inactive

in shift mode.
As well as with the previous rule there were also a large number of violations
generated before the BIST signals were defined in the SGDC file. The BIST[1]
(RBACT) had a great impact on the number of violations. With current set up
there remained two violations to the rule. These violations were caused by the
absence definition of the ddr2_fifo_test_in[0] signal in the SGDC file.
The signal in question was used as select signal to a multiplexer deciding
whether an internally generated signal or the ddr2_reset_n signal should
have been used as reset (18 FF are affected). The structure can be viewed in
Figure 20. The reason to why this signal was not included in the SGDC file
was that it was not found in the test documentation. But a reasonable
assumption would be that, due to how the signal was implemented and
named, the signal was controlled by other test logic higher up in the hierarchy
and was set during test mode. When the ddr2_fifo_test_in[0] was
defined and set in the SGDC file no violations to the rule were generated.
Notice also how Spyglass reports the violation by highlighting the unknown
input.

54
Figure 20 The reset selection structure that was flagged by rule Async_07. The X in the zoom in
symbolises the unknown value of the reset input. The ddr2_rst_n input signal is connected to the rst_n.

5.2.3 CDC

Clock_sync01 – Signals crossing clock domains must be correctly

synchronized in destination domain.
The rule generated nine violations correlated to the EIO jitter buffer3 crossing.
The structure used was verified to be working and was therefore not
considered being a problem.

Clock_sync05 – Primary inputs should not be multi-sampled.

The rule generated two violations that concerned Reset and ScTest
(controlling test mode) going into the EIO jitter buffer. The reason not to multi
sample a signal is that a transition might be shifted one clock pulse between
the two domains. The functionality of Reset and ScTest was however not one
pulse dependant.

3
The Jitter Buffer is a synchronisation scheme developed by Ericsson in Kista.
55
Reset_sync01 – Asynchronous reset should be synchronously de-asserted.
All violations generated by this rule correlated to the fact that Spyglass did not
recognise the de-asserter mechanism (see Figure 21 for a de-asserter
explanation) used in Anna. This was somewhat surprising due to the
simplicity of the de-asserter structure used (see Figure 22 for the structure
used in Anna).

Asynchronous signal De-asserter De-asserted signal

Clk

Clk

Asynchronous signal

De-asserted signal

Figure 21 A de-asserter is a mechanism that synchronizes the release of a signal,

while the hold is still asynchronous.

Figure 22 Schematic of the de-asserter structure used in Anna.

The following rules were only tested on demo-code provided by Atrenta.

However this is not evaluation praxis the FIFO in Anna could not be used
because of the DW problem. The code of the request generator in the demo
can be seen in Appendix B along with a modified variant whose purpose was
to see if the violations disappeared.

56
PsFifo01 – Detects FIFO:s and looks for underflow and overflow situations.
The rule checks for underflow and overflow of FIFO queues. The code in the
demo looked standard. But that information does not provide much in terms of
how well the rule suits Ericsson. The interesting part was however that the
tool generated a waveform diagram in order to aid in the debugging
procedure. It was impressing that the tool can generate and point to
suspicious structures automatically. The Waveform diagram (see Figure 23
for example) could though have been a little bit more specific in terms of
pointing out where the suspected behaviour appeared. In the demo example
used it was easy to find, but with more complex structures it might get a lot
trickier.

Figure 23 The Waveform Spyglass generates to aid in the debugging procedure.

However, Spyglass did not point directly to where the suspicious behaviour
appeared (the ellipse marking was added manually in clarification
purpose).

PsHandshake01 – Data value is not held constant in handshake protocol.

The rule checks that data was stable and not changing during the request
period. The rule worked well on the provided code. In Appendix B the original
version of the demo code is found along with the modified version that
eliminated the violation. The interesting part was however the violation
presentation in the Waveform viewer, as with the previous rule.

PsHandshake02 – Aknowledgement does not transistion to active within

specified cycles after request.
This rule was somewhat confusing. The rule was supposed to check whether
acknowledge transitions to active within a specified number of cycles after
request. By investigating the source code it was concluded that acknowledge
only was delayed two clock pulses after the receiving of request, but if the
delay parameter was set to 1000 the rule was still violated. It was therefore
believed that the rule was checking whether a complete handshake had been
performed before a new was generated. This assumption was also supported
by the fact that the violation disappeared after the changes done in Appendix
D. The issue was brought up with Atrenta and they backed up this theory.
Even though the rule failed its supposed purpose it has a great deal of
checking value.

57
5.2.4 Synthesis readiness

The warnings extracted from the synthesis log are presented. For each of
these warnings, the number of occasions it had in the synthesis log is
presented. An importance grading is also given to each warning. The degree
given was decided in consent with a designer. Rules with low importance
degree were not considered in the evaluation. The rule that could have
prevented the warning from reaching the synthesis phase is also presented. A
comment is also given regarding severity and if the rule was tested in reality.

Warning: Signal assignment delays are not supported for synthesis. They are
ignored.
Number of occasions: 705
Importance: low
Rule: W257 Lint, Synthesis tools ignores delays.
Comment: The rule generated violations on Anna.

Warning: Potential simulation-synthesis mismatch if index exceeds size of

array <name>.
Number of occasions: 227
Importance: High
Rule: SYNTH_5130 Spyglass. For proper synchronization between
simulation and synthesis index and array size should match.
Comment: If it could be assured that all the warnings of this kind was
intended it would be very valuable and a lot of resources could be saved. The
synthesis engineer would then not have to consider ever one of these
warnings to decide whether it is an actual error or not. The rule generated
violations on Anna. A large resource saving potential expected.

Warning: Symbol ‘<name>’, declared as an enum, may be assigned non-

enum values.
Number of occasions: 24
Importance: Medium
Rule: SYNTH_1028 Spyglass, ArrayEnumIndex Lint, Array defined using
enumeration type as index is not supported (in synthesis).
Comment: The rule has not been confirmed to work on Anna.

Warning: DEFAULT branch of CASE statement cannot be reached.

Number of occasions: 22
Importance: Medium
Rule: LPFSM18 lowpower, Unreachable states exist in FSMs.
Comment: Not been tested.

Warning: Floating pin ‘<name> of cell <name>’ connected to ground.

Number of occasions: 67
Importance: Medium
Rule: W287a LINT, Some inputs to instance is not driven or unconnected
Comment: If the pin is unconnected by mistake and the synthesis tool
connects the pin to ground the design might malfunction. The rule generated
violations on Anna.

58
Warning: Comparison against ‘unknown’ value is always false; may cause
simulation/synthesis mismatch.
Number of occasions: 1
Importance: Medium
Rule: STARC-2.10.1.4, Signals must not be compared with X or Z,
STARC02-2.10.1.5 Do not use X or Z values (Verilog), STARC02-2.10.1.5a
Do not use values including ‘X’,’Z’,’U’,’-‘,’W’,’H’,’L’. (VHDL),
Comment: For synthesis comparison with X or Z is not valid. If it appears it
might be remains from simulation. It is therefore important to remove these.
The rule STARC02-2.10.1.5 reports all occurrences of X, Z, U, - , W, H, L and
the rule STARC-2.10.1.4 reports where such values are used for
comparisons. Both rules generated violations in Anna after modification (a
comparison of a ‘1’ was changed to an X).

Warning: <name> is being read, but does not appear in the sensitivity list of
the block.
Number of occasions: 4
Importance: High
Rule: STARC02-2.2.2.1, Signals read inside a combinational process block
must be present in the sensitivity list.
Comment: The rule reports a signal which is outside a “elsif Clk’event
and Clk = ‘1’ then” construct and is read. What happens then is that
the signal is latched and the design intention might be lost. The rule
generated violations on Anna after modification. A signal was added outside a
sequential block of a process and was read.

Warning: Suppressing LINT-30 messages – they can be found afterwards in

../reports/${BLOCK_NAME}_post_compile.rep.
Number of occasions: 2
Importance: Low
Rule: NONE
Comment: Warning is not important.

Warning: In design ‘<name>’, input port ‘<name>’ drives wired logic.

Number of occasions: 36
Importance: Medium
Rule: W415 Lint, Net which is not tri-stated has multiple simultaneous drivers.
Comment: The rule has not been confirmed to work on Anna.

Warning: Multiple drivers for net ‘<name>’

Number of occasions: 18
Importance: Medium
Rule: W415 Lint, Net which is not tri-stated has multiple simultaneous
drivers.
Comment: The rule has not been confirmed to work on Anna.

Warning: design ‘<name>’ has 294 out of 310 cells marked size-only which
may limit optimization.
Number of occasions: 1
Importance: Low
Rule: NONE
Comment: Warning is not important.

59
Warning: Pad ‘<name>’ connected to port ‘<name>’ is don’t-touch. No
optimization done.
Number of occasions: 2
Importance: Low
Rule: NONE
Comment: Warning is not important.

Warning: Implicit truncation caused by range overflow.

Number of occasions: 2
Importance: High
Rule: W164a LINT, LHS width is less than RHS width of assignment
(Truncation).
Comment: The warning is important. There is a big potential of malfunction if
the designer does not have total control regarding how the synthesis tool
manages the truncation (truncates from LSB or MSB). In order to catch this
behaviour in simulation a test case matching the error exactly must be
created. The rule generated violations on Anna.

60
 6 Conclusions
This chapter aims to discuss and answer the questions in chapter 1.3 based
on the results gained from the evaluation of Spyglass, LEDA, HAL and Design
Checker.

It is advised to implement a static rule checking tool in the design flow. The
tool to be selected for this depends of the usage demand. Spyglass is the
most advanced and considered to be the most stable tool tested during this
project, but it has issues; as with rules generating “false” violations, unable to
detect certain structures, limited SystemVerilog support, a number of rules
that aught to be customizable regarding design choices. One of the strongest
arguments to choose Spyglass is probably the extensive use of the tool by the
chip manufacturers. It is believed that there is a lot to be gained in the means
of netlist deliveries if there is a good collaboration in the terms of using
Spyglass between both parties. Another reason to choose Spyglass is
Atrenta’s helpfulness and co-operate when issues regarding the tools
functionality occur.

One reason for not choosing Spyglass is the packaging of the tool. There are
a number of licenses for different packaging set ups that can be purchased
compared to the other tools where only one is license is required, which
covers all their functionality4. The packaging can be an issue when cost
savings are measured againts performance and efficiency.

The implementation and use of Spyglass is in the range of 700 kSEK to 1 500
kSEK per project (depending on the number of licenses required and number
of project starts per year) including educational costs and support. This
corresponds to 20 - 40 weeks of work in costs, or 15 engineers that waits for
a delay two to three weeks.

The gain of using Spyglass is mainly on RTL. This is based on the fact that
the errors found in the netlist during part I also were found in the RTL code
during part II. The cost versus saving calculation for Part I in [Wickberg, 2006]
applies therefore also in Part II. The objective is to find errors as soon as
possible in the design and thus save time. There are also gains regarding less
synthesis runs. Spyglass can catch a number of errors that appears during
synthesis. Even though not all of the extra synthesis runs may be possible to
prevent with the use of Spyglass, it is expected that a significant number will
be prevented. As mentioned in chapter 3.5 the saving potential could be one
week to months. This corresponds to delay costs in the range of tens of
thousands to a million SEK.

4
Exception is Synopsys LEDA builder which require an additional license.
61
On netlist level the direct savings, if Spyglass would have been used in the
Anna project, was far from covering the tool cost. But then it should be
remembered that the ASIC vendor did not use the tool in their verification
process and that the lead time has not been taken in account (for which the
costs could be very large). It is believed that the gain seen during this
evaluation would have been much greater if Spyglass had been used from
project start and that the set of rules used on both RTL and netlist would have
reflected the rules the chip vendor used.

A scenario could also be that the delayed project’s purpose was to reduce
cost by replacing an expensive card with a new cheaper one. The new ASIC
would only have been a part among many other circuits on that cheaper card.
A delay of the ASIC would hence have caused the new and cheaper card to
be delayed and the old one would have had to be manufactured in the
meantime. If the manufacturing cost would have been reduced with 1000
SEK/card with the new card, 10 000 cards per month were produced and the
delay is one month, the cost of the delay would be 10 MSEK.

The scenario given above along with what has been previously discussed in
this chapter regarding RTL and netlist level of use concludes that the saving
potential of the tool is large compared to the implementation costs.

After discussion with designers and specialists at the ASIC department, it is

concluded that the greatest value is gained on RTL with rule checking:
Naming conventions and basic structure, Clock/Reset tree propagation,
Constraint cover and consistency, DFT for scan readiness and basic CDC to
detect crossings. But also sets of rules for netlist checks regarding structure,
Constraints and DFT in collaboration with the chip manufacturer of choice, are
advised to be purchased. The package that comes to mind is the Design
Analysis package.

The changes to the design flow are not expected to be extensive but
nevertheless considerable. Spyglass is meant to be used during the entire
process, from starting of the RTL coding until netlist delivery. This means that
the designers might have to run the tool up to four times a day during intense
periods which might cause some inconvenience at start. In the constraints
area there might also be a bit of change in terms of how large the constraints
set to use, this to gain as much as possible from the tool. At each project start
there should also be a person who is assigned as a collaborator with the chip
manufacturer. The reason is to make the rules that are to be used to mirror
the chip vendors hand off procedure from the beginning, and thus save
resources.

The error correction work is very sophisticated in Spyglass in terms of using

the GUI. The violation explanations are comprehensive and the schematic
views are state of the art. The reports are acceptable and give enough
information to enable correction of regular violations.

Attempting to create entirely new rules for Spyglass is not advised. But if C-
primitives that suit the purpose exist it is manageable. Creating new rules to
Synopsys LEDA (using VeRSL or VRSL) is considered to be easier, but
perhaps not as powerful, than the use of C-primitives.

62
From the calculations in chapter 2.4, three to four licenses is a good
estimation.

Neither Spyglass nor any other tool makes any difference regarding what
geometrical technology that is used. But the reason to why the need of
implementing a static rule checking tool has been seen, could be the possible
complexity increase the new technology brings. What before was a minor fault
can now cause large damage to the complex designs in terms of correction
work. The need of having complete constraints set ups might also be an issue
due to that more and more focus is put on timing. At 65 nm technology the
wires might have reached a critical level in terms of resistance and signal
propagation time. It is therefore important to have a full timing constraints
setup on all paths from the project start. A signal that worked before without a
flip flop prior an output port does not work any longer.

63
64
7 References
[Atrenta 1, 2006] - SpyGlass® DC Rules Reference, Version 3.8.0.3, July 2006,
Author: Atrenta, Inc.

[Atrenta 2, 2006] - SpyGlass® Predictive Analyzer User Guide, Version 3.8.1, August
2006, Author: Atrenta, Inc.

[Atrenta 3, 2006] - SpyGlass® Policy Customization Guide, version 3.8.1, 2006,

Author: Atrent, Inc.

[Rabaey, Chandrakasan and Nikolic´, 2003] - Digital Integrated Circuits, second

edition, 2003, Authors: Jan M. Rabaey, Anantha Chandrakasan, Borivoje Nikolic.

[Test, 2006] - Test Architecture Specification

[Cadence 1, 2006] - Clock Domain Crossings, Technical Paper, Author: Cadence.

URL: http://www.cadence.com/whitepapers/

[Cadence 2, 2004] - The Cadence Newsletter, July 2004, Author: Cadence.

[Cadence 3, 2006] - Incisive HDL analysis (HAL) User Guide, Version 5.82, August
2006, Author: Cadence.

[Myers, 2001] - Asynchronous Circuit Design, 2001, Author: Chris J. Myers.

[Accellera, 2001] - SystemVerilog 3.1a Language Reference Manual Accellera’s

Extensions to Verilog, Author: Accellera.

[Synopsys 1, 2006] - Leda Rule Specifier Tutorial, Author: Synopsys.

[Synopsys 2, 2006] - Synopsys hompage, URL:

http://www.synopsys.com/partners/tapin/sdc.html

[Synopsys 3, 2006] - Leda User Guide, Version 2006.06, June 2006, Author:
Synopsys

[Synopsys 4, 2006] - Leda VeRSL Reference Guide, Version 2006.06, June 2006,
Author: Synopsys

[Mentor, 2006] - DesignChecker User Guide, Version 2006.1, 10 May 2006, Author:
Mentor.

[Wickberg, 2007] - HDL code analysis of ASIC:s in mobile systems, Complementary

report, version 1.0, January 2007, Author: Fredrik Wickberg

65
66
Appendix A – Netlist drops
As described in Chapter 2.1, Spyglass was used on different revisions and
drops of the netlist. Therefore the drops had to be identified before the actual
evaluation could be performed. In order to do this all the versions of the three
blocks AnnaChip.v, phoenix.v and hwacc.v were listed using clear case (a
version handling program). The outputted list was then copied to an excel
spreadsheet. The versions that were compared against each other are listed
below. The reason why the listed versions were chosen was the timestamp. If
the difference between the “check in” timestamp for two consecutive versions
was more than a week, there was a high probability that only new functionality
were added between them. In other words they would not have been in the
same drop. A visualisation of this is shown in Figure 5. If the timestamp was
less than a day the chances that the chip vendor found out an error in the
netlist was very small. An iteration could not have happened within 24 hours.
In the case of identifying versions to run for the Hwacc block, there were no
definite versions that could have been selected based on the parameters
described above. Therefore a compromise was made and three versions
were to be compared. The following versions were chosen to be evaluated
with Spyglass.

Anna

PseudoChip.v@@/main/3 18-May.12:55
PseudoChip.v@@/main/5 22-May.09:33

Phoenix

phoenix.v@@/main/8 29-May.14:21
phoenix.v@@/main/9 02-Jun.10:39

Hwacc

hw acc.v@@/main/2 10-Apr.17:55
hw acc.v@@/main/3 12-Apr.07:39
hw acc.v@@/main/4 20-Apr.17:49

67
68
 Appendix B
The code below was used to evaluate the handshake rules. The original
version is taken from a demo made by Atrenta. The modified version was
made by the author of this thesis. The modification was used to check
whether the violations from the original version disappeared and thus validate
the correctness of the handshake rules.

In the modified version data is applied one state in advance to the activation
of the request signal, which will ensure data signal stability. The other change
is that a new state has been added (WAIT_ACK2). The new state waits for a
completion of acknowledge. This functionality will make sure that a full
handshake has taken place before a new can be initiated.

Original version of the request generator Modified version of the request generator
always @(posedge reqclk or posedge reset) begin always @(posedge reqclk or posedge reset)
begin

if ( reset ) begin if ( reset ) begin

state1 <= IDLE; state1 <= IDLE;
req <= 1'b0; req <= 1'b0;
end end
else else
case (state1) case (state1)
IDLE: begin IDLE: begin
req <= 1'b0; //req <= 1'b0;
if (in1 ) state1 <= SEND_REQ; if (in1 ) begin
end state1 <= SEND_REQ;
SEND_REQ: begin bus_data <= in2;
bus_data <= in2; //violation end
req <= 1'b1; //violation end
state1 <= WAIT_ACK; SEND_REQ: begin
end //bus_data <= in2;
req <= 1'b1;
WAIT_ACK: begin state1 <= WAIT_ACK1;
if ( core_ack_sync ) state1 <= IDLE; end
end
endcase WAIT_ACK1: begin
end if ( core_ack_sync ) begin
req <= 1'b0;
state1 <= WAIT_ACK2;
end
end
WAIT_ACK2: begin
if ( !core_ack_sync ) state1 <= IDLE;
end
endcase
end

69
70
På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga extra-
ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning
av dokumentet kräver upphovsmannens medgivande. För att garantera
äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och
administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som
upphovsman i den omfattning som god sed kräver vid användning av
dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras
eller presenteras i sådan form eller i sådant sammanhang som är kränkande
för upphovsmannens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.

The online availability of the document implies a permanent permission

for anyone to read, to download, to print out single copies for your own use
and to use it unchanged for any non-commercial research and educational
purpose. Subsequent transfers of copyright cannot revoke this permission. All
other uses of the document are conditional on the consent of the copyright
owner. The publisher has taken technical and administrative measures to
assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be

mentioned when his/her work is accessed as described above and to be
protected against infringement.

For additional information about the Linköping University Electronic Press

and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page: http://www.ep.liu.se/

© Fredrik Wickberg