See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/346695407

Study and Analysis of RTL Verification Tool

Conference Paper · July 2020

DOI: 10.1109/SCES50439.2020.9236747

CITATIONS READS
0 1,158

3 authors, including:

Akhilesh Yadav Poonam Jindal

5 PUBLICATIONS   3 CITATIONS   
National Institute of Technology, Kurukshetra
47 PUBLICATIONS   230 CITATIONS   
SEE PROFILE
SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Design and implementation of RS(450,406) Encoder and Decoder for Gigabit Automotive Ethernet View project

security View project

All content following this page was uploaded by Akhilesh Yadav on 23 December 2020.

The user has requested enhancement of the downloaded file.

2020 IEEE Students’ Conference on Engineering & Systems (SCES)
July 10-12, 2020
Prayagraj, India

Study And Analysis of RTL Verification Tool

[1]
Akhilesh Yadav, [2]Poonam Jindal, [3]Devaraju Basappa
[1][2]
ECE Deptt. NIT Kurukshetra, [3]NXP Semiconductor Bangalore
[1]
akhileshecenitkkr@gmail.com, [2]poonamjindal81@nitkkrnitkkr.ac.in, [3]devaraju.basappa@nxp.com

Abstract—According to Moore’s Law, number of transistors on
chip doubles in every next two years, So the complexity of the
circuit increases. So it needs to be careful in designing and
verification. Register Transfer Level (RTL) designing and its
verification is also most important part of circuit design. The
intent behind verification is to check that design meets all system
specification and requirements or not. It is important to verify
RTL before simulation and synthesis the design because It save
clock cycle and time of simulation. This paper is focused on the
RTL verification tool, Such as HAL linting and Spyglass RTL
signoff tool. This type of RTL verification is used to find bugs
and error in design before synthesis. It is easy to debug RTL
design and pinpoint the problem and their solution. It is
important to identify design issues as early as possible before
synthesis RTL design.
RTL verification is one of the most important and
challenging task in digital system design development. If
verification team finds any error, then it needs to be correct
the RTL code. There is several RTL verification tools are
present as:
• HAL Linting Tool
• Spyglass RTL Signoff Tool
• Questa Formal verification Tool
• Questa CDC Verification

Index Terms-- Cadence, Clock Domain Crossing, HAL Linting,

Reset Domain Verification, Spyglass RTL Signoff Tool.

I. INTRODUCTION
During development of Integrated Circuit (IC), digital
design passes through the many number of stages from design
specification to final product. The stage or phase of digital
design [1] flow is shown in Figure 1. Design flow shows the
top – down approach in very simplified way. Reality of an IC
development is more complex, having many stages. So we just
follow the flow of design until final design get and it reaches
to meet specification requirement like area, power, cost and
timing. It is a large scale problem, So single digital designer
can focus only one portion of design flow one at a time.
Design flow starts form the design specification to testing and
packaging. The design specification is the most extremely
important of the investigate phase of the design cycle. It is a
list of requirement that your design ideas must meet plus a list Figure 1. Block diagram of digital system design.
of constraints that you have. Functional engineer designs high
level functional description of digital design, after this II. HAL LINTING TOOL
hardware design group proceeds to RTL design step. In this
phase designer design the data path and control path using Linting tool is a most efficient tool, it checks both static
Hardware Description language (HDL)[2], this stage also and formal analysis in more efficient way. Formal
develop the clocking system of the circuits. Our main focus is verification is a small part in lint verification. HAL [4-6] is a
on the next stage that is RTL verification [3]. RTL verification super linting tool for static verification. Linting tool (or Lint
team provides the confidence that a digital circuit is tool) are used to check potential mismatches in between
functionally correct. They use different type of verification synthesis and simulation. And some linting tools are also
tool to verify the design. undertaken at gate level. The flow of linting verification is
given in Figure 2. We used Cadence HAL linting tool for
static verification in our Reed Solomon[7-9] encoding and

978-1-7281-9339-7/20/$31.00 ©2020 IEEE

Authorized licensed use limited to: Auckland University of Technology. Downloaded on December 20,2020 at 10:09:36 UTC from IEEE Xplore. Restrictions apply.
decoding for Gigabit Automotive Ethernet project. In this tool
we add the RTL code, it support many language like Verilog,
VHDLs etc.. So if there will be error in your design, then it
should be correct before entering in next stage. According to
the flow of linting verification, if any design issues are
present then it need to modify the RTL code, after doing this
it need to pass again RTL code into the linting tool.
Figure 2. Flow of Linting Verification.
Every Linting tools have their own rules and policy for
verification. Lint tool is a more effective tool for pre–
simulation and we can also visualize errors or warnings from
generated Schematic Tracer. It can find bugs without any test
vectors. Lint tool reduces number of simulation cycles. Some
problems addresses by the Lint tool are as:
• Naming
Figure 3. View of HAL Lint Tool.
• Coding style
• Structural checks
• DFT check
• Race around condition
• Unintentional latch
• Unused declaration
• Unsynthesizable constructs
• Undriven and driven signal
• Blocking Assignment related
Authorized licensed use limited to: Auckland University of Technology. Downloaded on December 20,2020 at 10:09:36 UTC from IEEE Xplore. Restrictions apply.
• Non – blocking assignment
• Data overflowing
• Incomplete assignment
• Issues related to Finite State Machine
• Case statement issue
• Not proper Synchronization
• Range indexing etc.
In lint tool no need to add constraints file, for defining
clock and reset signal. It also generates the report for review.
By using generated report, we can analyze which types of
error and bugs can be fixed and waived. Because it contains
so many rules and sometime designer complains that it
generates some false positive. HAL lint tool view is shown in
Figure 3.
HAL lint tool generates Severity Error, Severity Warnings
and Severity notes, inside the .log file as shown in Figure 3.
From the File icon we can generates the reports and view log
files, also we can reload are close the log file as per our
requirement. We added Reed Solomon Encoder RTL Verilog
file of our project. Details of each and every error, warnings
generates in message details option with detailed example.
A. Formal Verification
Formal verification[10] tool combines both Property
Specification Language (PSL) and System Verilog Assertion
(SVA) and gives exhaustive solution. Formal verification
come inside the Lint verification. Combinatorial equivalence
checking and sequential equivalence checking are used for
formal verification. Several challenges in formal verification
are:
• Sometime formal analysis workflow are unfamiliar
with reports.
• Many engineers are opposes to write properties
manually and learning assertion language.
• Formal tool exhibit run times and it need more
capacity.
 III. SPYGLASS RTL SIGNOFF TOOL
During the RTL designing, it is very important to find out
the critical design bugs in RTL code. Inefficient RTL code can
create problem during synthesis. If these bugs are detected at
the starting stage, then simulation cycles and time will reduce.
Synopsys provides depth analysis of RTL code through the
Spyglass tool. Spyglass[11-13] provides integrated solution
for analysis and fixing the bugs at starting phase of circuit
design. Spyglass is capable to set all type of electrical and
structural issue. Spyglass solution economizes and accelerates
IC development by reducing cost, time consumption and
debug iteration. Spyglass RTL signoff tool flow is shown in
the Figure 4. Due to increasing size and complexity of chip, to
achieve predictable result has become a more challenging
task. In a single RTL verification tool Synopsys provides
multiple checking phase like:
• Spyglass Lint verification.
• Spyglass clock domain crossing (CDC) verification.
• Spyglass reset domain crossing (RDC) verification.
• Spyglass power estimation and exploration
verification.
• Spyglass design for test (DFT) verification.
• Spyglass time constraints verification.
Figure 4. Verification flow of Spyglass Tool.
Spyglass is most interesting and challenging verification
tool for RTL verification engineer. We also used Spyglass tool
for verification of RTL code for our project, Reed Solomon
(RS) encoding and decoding for automotive ethernet. Features
and benefits of spyglass is given below.
• It provides complete verification of RTL design.
• Identifies critical RTL design Issues.
Authorized licensed use limited to: Auckland University of Technology. Downloaded on December 20,2020 at 10:09:36 UTC from IEEE Xplore. Restrictions apply.
• It provides both static and dynamic analysis.
• It consider design reuse compliancy check.
• It provides customizable framework to automate and
capture company expertise.
• It supports Verilog, System Verilog, VHDL, and
mixed language design.
• Tcl shell for effectual rule processing and design
query.
A. Spyglass Lint Verification
Lint check is the initial phase of RTL verification of any
design. It checks basic simulation and connectivity issues.
Spyglass lint[6] is just like HAL lining, which checks basic
synthesis issues. Spyglass lint check both functional and
structural verification and also checks design reuse
compliance. Traditional flow and with spyglass flow of design
is shown in Figure 5. Feature of Spyglass lint are :
• Structural Lint :- It checks syntax, synthesis,
simulation, semantics etc. .
• Turbo Structural :- It checks faster debug and
improved root cause analysis.
• Hierarchical flow :- it checks Top – down/Bottom -up
with abstract model.
Figure 5. Comparison of traditional flow and with Spyglass flow.
B. Clock Domain Crossing Verification
Clock Domain Crossing (CDC) verification is the most
important and difficult phase of spyglass verification. CDC
verification[14-15] has the top rank in RTL verification in
difficulty. It is so much difficult to verify the design by using
Static time analysis (STA) or conventional simulation. CDC
problems are generated due to the metastability of data
signal. Metastability causes of setup and hold time violation
of signal. This violation cause functionality failure in design
chip. CDC problems generated when multiple clocks are used
in design, these clocks are asynchronous with each other.
Such type of error can increase time and expense to debug the
design. Spyglass checks all type of CDC problem during RTL
verification and this tool explain the bugs in details through
the Spyglass guide documents. For CDC and Reset Domain
Crossing (RDC), we need to be create a constraints file in results and also generates verification reports, stored in log
which all clock, reset, name of current design should be file and by using Goal setup icon (option), it is easy to select
mentioned in proper format. For removing metastability, one type of verification like:
different – different synchronization techniques are used like.
• Synchronization with 2- FF synchronizers
• Synchronization through MUX synchronizer
• Handshake synchronizer etc.
Spyglass provides effective guide to solve the CDC
problem at the RTL level for avoiding costly resins. The
constraints file Spyglass Design Constraint (SGDC) for our
design is given below :
1. current_design rs_decoder_top_level_rtl
2. clock -name "clk" -domain domain0 -period 8 -edge
{0 4}
3. clock -name "out_clk" -domain domain1 -period 4 -
edge {0 2} Figure 7. Incremental Schematic of RS Encoder.
4. reset -name "rst_n" -value 0
• Lint verification, Lint turbo verification
Constraints file in our design having two clock signal

Figure 6. Modular Schematic of Top level RS Encoder and Decoder.

one is “clk” and second one “out_clk” of period 8 and 4 • Cross Domain Crossing Verification
respectively and one reset signal “rst_n”. The top module of
our design is rs_decoder_top_level_rtl. Spyglass generates • Design for test verification
modular schematic and incremental schematic for analysis of • Reset Domain Verification & Power Verification etc.
design. Modular schematic of top level RS encoder and
decoder is shown in Figure 6. And the Incremental schematic And we can also setup multiple goal or all type
of RS encoder is shown in Figure 7 of our RTL design. n our verification goal one at a time. From the setup icon, we can
RS design there are 7 major module to calculate the final set the parameter like as:
corrected data symbols (crr_data). Spyglass provides Modular
• Enable Synopsys Design Constraint (SDC) to SGDC
and Incremental schematic for better analysis of your design.
file translation.
If there will be synchronization error between the source and
destination flip-flop, then it will show error and tool • Enable clock gating.
generates the incremental schematic for synchronization
analysis of design. Unsynchronization crossing can be due to • Enable memory Handle Memories.
scalar and vector signal as shown in Figure 8. In spyglass we • Enable translation of IO Delay.
can setup goal individually or all at a time for analysis. Every
goal takes some time to generate the result. • Enable System Verilog processing etc.
Spyglass tool view is shown in Figure 9. From the
spyglass tool icon, Analyze results, we can view verification

Authorized licensed use limited to: Auckland University of Technology. Downloaded on December 20,2020 at 10:09:36 UTC from IEEE Xplore. Restrictions apply.

(a)
(b)
Figure 8. (a). Incremental schematic of unsynchronized crossing (b).
Generated results from Spyglass tool.
Figure 9. Spyglass Tool view.
Figure 10. Asynchronous reset between source and destination flop.
C. Reset Domain Crossing Verification
It is known that clock domain crossing is the result of
metastability, but asynchronous reset signal also causes
metastability within the same clock, but different reset signal
in between source and destination flip-flop. Due to RDC [16-
17] RTL verification tool generates more design error. Such
type of error can add much time and expense to debug the
design. RDC verification is as important as CDC verification
and it guaranty that RTL design will work as expected. The
success of RDC verification tool is defined by measuring
Authorized licensed use limited to: Auckland University of Technology. Downloaded on December 20,2020 at 10:09:36 UTC from IEEE Xplore. Restrictions apply.
time taken to signoff RTL and completeness of RDC
verification. Figure 10 shows asynchronous reset in RTL
design that can cause the metastability issues. Spyglass[18]
provides high performance debug capability for any type of
crossing verification. Spyglass provides standard rule set for
RDC verification. Mentor Graphics also provides design
verification tool. Questa Formal Verification[19], Questa
CDC[20] or Questa Signoff CDC are the Mentor Graphics
design verification tool.
IV. SPYGLASS CDC ANALYSIS FOR AN FPGA
As the cost of doing with ASIC (Application Specific
Integrated Circuit) design is increases with quickly to very
high level, FPGA (Field programmable gate arrays)
becoming an attractive alternate design to system on chip
(SOC). As complexity of design increases, it can be done
easily with FPGAs, making RTL verification a major task.
Apart from the usual design issues of width mismatch,
simulation or synthesis mismatch, connectivity, there are
many issue related to multiple asynchronous CDC such as
data re-convergence, metastability, FIFO integrity and other
more.
Figure 11. Spyglass RTL design flow for FPGA.
So CDC verification for FPGA is challenging task. Some
verification flow for ASIC already exists for above problems.
The Spyglass RTL design verification flow for FPGA is
given in Figure 11. Clock Domain Crossing analysis for an
FPGA is so much similar to an ASIC design. However,
FPGA based design may not be work accurately for CDC
analysis if libraries and RTL design are not synthesizable.
Some RTL files have un-synthesizable constructs and could
also be encrypted. And all these un-synthesizable constructs
creates black boxes during CDC and RDC analysis. Due to
this results may have many false violation that impacts on the
accuracy of CDC signoff. Mainly there are three input files to
Spyglass as shown in Figure 11. And these are Design Files,
Constraint Files and Library files.
But the recommended FPGA based design flow is given
in Figure 12. This flowchart should follow for FPGA based
design verification. This flowchart divided into mainly three
parts are Run Design_audit, Run CDC setup, Run CDC verify
struct and SGDC template. In first we analyzed two point are:
• Follow the project file details as outlined in
Application notes
 • Analysis design_audit results.
And in second part we should focus on three points as:
1. Setup black box boxes generates SGDC template for
multi-clocked black boxes.
2. CDC setup for black boxes and complete the
template to use it for subsequent run for accuracy
CDC analysis.
3. You can also check impact of not using SGDC
template by making two separate CDC verify
constructs.
 Run1- Treat all black-box
Asynchronous crossing.
 Run2- Treat all black
synchronous crossing.
These all done by using parameter CDC to reduce
pessimism. And in last we analyze results of CDC verify
struct.
Figure 12. Recommended flowchart for FPGA based design.
V. CONCLUSION
Design verification is most important and its challenging
phase of any design (IC or IP) designing. For RTL
verification many standard tool are available for industry
level. Some for analog design verification and some for
digital design verification. Spyglass is most important and
popular design verification tool and HAL tool is best for
linting verification. We used HAL and Spyglass tool for our
RTL design verification and by using these tool, we verified
our design. They generates Modular and Incremental
schematic for better analysis of Design. For any type of error
or warnings HAL tool explain with example, by
understanding this example verification engineer can easily
correct critical error and warning. Clock Domain Crossing,
Reset Domain Crossing, and Linting verification is most
Authorized licensed use limited to: Auckland University of Technology. Downloaded on December 20,2020 at 10:09:36 UTC from IEEE Xplore. Restrictions apply.
View publication stats
important and challenging verification for front end design
verification team.
REFERENCES
[1] Valeria Bertacco, “Scalable Hardware Verification with Symbolic
Simulation,” 1st ed., Boston: Springer Science + Business Media, Inc.
2006.
[2] Fredrik Wickberg, “HDL Code Analysis for ASICs In Mobile
System,” Master thesis, Dept. Electronic System, Linkoping Univ.
Jan. 2007.
[3] Janick Bergeron, “Writing Testbenches: Functional Verification of
HDL Models,” 2nd ed., Kluwer Academic Publishers, Inc. 2003.
[4] [Cadence 3, 2006] - Incisive HDL analysis (HAL) User Guide, Version
box 5.82, August 2006 Author: Cadence.
[5] [Cadence 3, 2006] - Incisive functional verification User Guide,
Version 5.82, August2006, Author: Cadence.
[6] [Synopsys] – Spyglass Lint Verification Datasheet, Author: Synopsys
[7] A.Yadav, P. Jindal, D. Basappa, M. Prakashaiah, “Forward Error
Correction for Gigabit Automotive Ethernet using RS(450, 406)
Encoder,” International Journal of Innovative Technology and
Exploring Engineering, vol. 9, ISSN. 2278-3075, Dec. 2019.
[8] M. Kaur and V. Sharma, “Study of Forward Error Correction using
Reed-Solomon Codes,” International Journal of Electronics
Engineering, vol. 2, pp. 331 – 333, 2010.
[9] E. R. Berlekamp, Algebraic Coding Theory, New York: McGraw-Hill,
1968. (revised ed.—Laguna Hills, CA: Aegean Park, 1984).
[10] [Mentor, 2017] - Questa Formal Application Datasheet, 20 April 2017,
Author: Mentor.
[11] [Atrenta 1, 2006] - SpyGlass® DC Rules Reference, Version 3.8.0.3,
July 2006, Author: Atrenta, Inc.
[12] [Atrenta 2, 2006] - SpyGlass® Predictive Analyzer User Guide,
Version 3.8.1, August 2006, Author: Atrenta, Inc.
[13] [Atrenta 3, 2006] - SpyGlass® Policy Customization Guide, version
3.8.1, 2006, Author: Atrenta, Inc.
[14] [Cadence 1, 2006] - Clock Domain Crossings, Technical Paper, Author:
Cadence
[15] [Synopsys] –Spyglass Clock Domain Crossing Verification Datasheet,
Author: Synopsys
[16] [Synopsys] –Spyglass for FPGA Design Datasheet, Author: Synopsys.
[17] [Synopsys] –Spyglass Reset Domain Crossing Verification Datasheet,
Author: Synopsys.
[18] [Synopsys] – Ictools Spyglass User Guide, Author: Synopsys.
[19] [Mentor, 2006] -Design Checker User Guide, Version 2006.1, 10 May
2006, Author: Mentor.
[20] [Mentor, 2017]- Questa Clock Domain Crossing Datasheet, 20 April
2017, Author: Mentor.