2.IJAEST-Vol-No-6-Issue-No-2-AN-IMPROVED-METHODOLOGY-TO-ACHIEVE-EARLY-DESIGN-CLOSURE-OF-SoC-USING-AN

AN IMPROVED METHODOLOGY TO

ACHIEVE EARLY DESIGN CLOSURE OF SoC

USING ANALYSIS TOOL

Nanda Kumar A* Dept of Electronics

BMSCE Bangalore, Karnataka, India [email protected]

Vasundara Patel K S Dept of Electronics

BMSCE Bangalore, Karnataka, India

[email protected]

Kalpana S WTBU Group

Texas Instruments Bangalore, Karnataka, India

[email protected]

Abstract -- Mixed Signal System on Chip (SoC) is becoming a

critical bottleneck for most wireless applications in terms of

performance, power, area and design time. A SoC design starts

with a Register Transfer Level (RTL) description to capture

user intent and a set of design constraints to drive

implementation. Once the design goes to synthesis, to a large

extent the design intent is freezed, and there is limited flexibility

for correcting design-quality issues innate in RTL. Quality

measures at the RTL stage of design go a long way toward

determining successful design closure and working silicon by

reducing design debug iterations. In our project essentially

Atrenta Spyglass is used for early design analysis with the most

in-depth analysis at RTL design phase. RTL analysis, debug and

fixing with a comprehensive set of rules for structural,

functional, clocking and Design for Test (DFT) issues were

performed using integrated platform of Spyglass. This paper

brings out improved methodology of using RTL analysis tool to achieve design closure earlier and faster.

Keywords -- SoC, design analysis, Spyglass, Lint, Clock domain crossings, DFT

I. INTRODUCTION The complex work of designing new SoC for wireless

applications and the increasing costs of time to market delays are putting high responsibility on the research and development teams to make fault free designs.

The design of mixed signal SoCs for emerging wireless applications share not only highly integrated devices such as third party processors, Global positioning system (GPS) digital signal processing blocks, memory, peripherals such as uart, i2c but also analog and RF blocks which resulted in increased number of asynchronous clock domains on a chip. The schematic of mixed signal SoC is as shown in Fig 1. There are about 20 clock domains in the design. This poses challenge for design team to ensure that clocks and resets are properly designed.

Inefficiencies during RTL design usually surface as critical design bugs during late stages of design implementation. If detected later in the flow, these bugs will often lead to iterations and left undetected will lead to silicon re-spin. The sooner a bug is found in the design, the shorter

the turnaround time becomes, and thereby both time and money will be saved.

Fig 1: A schematic of Mixed signal SoC

For these reasons, it is must to ensure the quality of the RTL going into backend. Traditionally, design teams often focus on functional correctness using simulation and formal verification, but spending some effort on implementation feasibility and the overall quality of RTL can go a long way toward accelerating design closure.

Hence in our project we the design team achieve such quality through a set of analysis on the RTL using Spyglass.

II. AN IMPROVED METHODOLOGY USING ANALYSIS TOOL

Using Spyglass static and/or dynamic analysis of RTL code or gate level netlists is performed in the purpose to find structural, coding, consistency and/or functional problems with the help of rules. More advanced RTL checks to analyze whether the data signal in a clock domain crossing protocol is stable during request is also performed.

RTL that is being delivered to the back end would be used by both Application Specific Integrated Circuit (ASIC) and Field Programmable Gate Array (FPGA) teams for further validation and verification. Thus in our design, RTL analysis has to be performed both in ASIC mode and FPGA

P

I

N

M

U

X

A

N

A

L

O

G

DIGITAL

GPS

DSP

M

E

M

O

R

Y

CPU

PERIPHERALS

IJAEST

Nanda Kumar A*et al/ (IJAEST) INTERNATIONAL JOURNAL OF ADVANCED ENGINEERING SCIENCES AND TECHNOLOGIES Vol No. 6, Issue No. 2, 168 - 175

ISSN: 2230-7818 @ 2011 http://www.ijaest.iserp.org. All rights Reserved. Page 168

[email protected]

[email protected]

[email protected]

mode. Compared to ASIC, FPGA design errors are still difficult to find, since it just crashes out without any clue if there are errors. Also, clock and reset tree would be different for ASIC and FPGA modes, hence spyglass analysis had to be done separately for each.

Even though Spyglass main contribution is when run at RTL the tool has functionality to check netlists as well and in our project spyglass is run at netlist level also. Different types of rules are checked at different stages in the design flow.

Fig 2: Usage of Spyglass in the SoC design flow

The rules that are run depend on the templates that are selected. A template in Spyglass is a set of rules. 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. In our project, Lint, clock reset and DFT policies are used.

Fig 3: Policy Template Relation

Structural and functional rules must be provided 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.

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.

The rules from the spyglass template were chosen effectively and efficiently in our design, so as to reduce the redundant errors and warnings which would make the run time very high, but the rule set were chosen to catch the relevant design errors early in the cycle.

Spyglass reports three classes of errors namely Error, Warning and Info. The order of debugging the errors is important since without debugging the high severity errors, debugging of low severity errors would make the debug time very high. In our project debugging was based on the severity of errors that were presented from the spyglass report. Black box errors being the high severity error class were cleaned up by creating spyglass library files (sglib) from the Synopsys library files. Then spyglass reported warnings were cleaned up. Using the info class of errors, created SGDC constraints were made still effective to give complete and correct information about the clocks, resets and select signals for the multiplexers in the design, so as to catch more errors.

Spyglass can either run in batch mode or interactively using the Graphical User Interface (GUI). We use the reports that Spyglass generates 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 we 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.

Desired rules

LINT

POLICY

DFT

POLICY

CLOCK RESET

POLICY

TEMPLATE

IJAEST



Fig 4. Spyglass GUI showing incremental schematic

In the subsequent sections we describe the different RTL quality checks with examples that we perform using spyglass.

III. LINT CHECK In RTL lint check, we will weed out syntax and

semantic issues and ensure compliance with coding standards. We will also address more serious structural and connectivity issues at this early stage. If left undetected, they may later lead to more serious design-closure issues.

Examples of these issues include:

Combinational loops Unintentional latches Excessive levels of logic between flip-flops are

potential timing-closure problems Blocking assignment in sequential blocks Variables or non constants in the terminating

condition of a loop Missing asynchronous resets from a sensitivity list Multiple driven nets without a tristate, undriven nets

and ports Mismatch between the left- and the right-hand sides

of an assignment

Although we may be able to detect and fix some or all of these issues during synthesis or later stages of implementation, it is more efficient to fix them before any fixing effort is put into implementation.

We use Lint policy in Spyglass that contains rules to

check coding style, language construct usage, simulation performance, and synthesizability.

Example of Lint rule in spyglass: Rule: W259 - Signal has multiple drivers Rule description: The W259 rule flags signals that have multiple drivers but no associated resolution function. A signal is to be said to be driven by multiple drivers if more than one concurrent statement (process, instance, conditional and selected signal assignment statements etc.) contains signal transform for the same signal. Signals with multiple drivers but no resolution function are driven to tristate or to value x.

IV. CLOCK RESET CHECK As already stated, we have 20 or more clock domains in

the design. We must ensure that clocks and resets are properly designed. When data signals cross between asynchronous clock domains, we must synchronize them to prevent metastability.

Fig 5. A visualization of the Metastability problem. The use of two

synchronization FF’s (in b) reduces the probability of incorrect sampled data several times

Clock synchronizers can range from multiple-flip-flop synchronizers to more exotic schemes, such as FIFO buffers with handshaking. It is important to prevent the data loss and reconvergence of synchronized signals to ensure reliable behavior. We must synchronize deasserted resets, even if they are asynchronous, with the clock domain using Reset synchronizers.

Functional simulation may not detect clock-domain-

crossing bugs unless verification engineers create dedicated test bench scenarios for each crossing, a daunting task for designs that have thousands of such crossings.

IJAEST



We will quickly eliminate Clock Domain crossing (CDC) errors up front at the RTL level, using enhanced CDC analysis in spyglass.

For CDC, run time for performing the analysis using spyglass will be very high for a typical SoC. Having known the design modes of our SoC, suitable SGDC constraints were created so as to reduce the run time of the clock reset check.

Example of Clock reset rule in spyglass: Rule: Ac_resetcross01 - Flags reset crossings Rule description: The Ac_resetcross01 rule flags if there are paths between two sequential elements that are clocked by the same clock domain but have different asynchronous resets/sets, as shown in the following figure:

Fig 6: Example of Ac_resetcross01 rule

In the above figure, there is always a possibility of reset

of the first flop while the second flop is active. Since both the resets are asynchronous, when the reset on the first sequential element is asserted, it may cause setup violation on the second sequential element.

V. DFT CHECK Size and complexity of new architectures are growing

fast which in turn makes the testing procedures harder. It is therefore important for us to follow the 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.

One of the approaches under the DFT technique is

Scan-Based testing. In this technique, flip flops are directly connected with each other in a long chain, from chip input to output. The DFT Team will then 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.

We use Spyglass capability of checking these properties early in the design phase which is very much essential before the RTL code is release to the DFT Team.

We use the three properties of DFT policy in Spyglass:

• All registers should be controlled by a test clock. Internally generated clocks must be test clock controlled in scan mode.

• All resets and sets should be disabled in test mode. All internally generated asynchronous sources should be inactive in scan mode.

• All registers should be scannable. Spyglass presumes that if there are no violation generated from above two then all registers should be scannable.

Example of DFT check in spyglass: Rule: Clock_04 - Do not use clock signals as data signals Rule description: The Clock_04 rule flags clock signals that are used as data signals to flip-flops or latches. Fanout from one signal source to both the clock and data pins of the same register can reduce fault coverage since ATPG tools assume that signals required for a test can be realized whereas clock signals may be under rigorous constraints. In such cases, fault coverage will be compromised. The clock path to each flip-flop is a chain of serially connected nodes that a clock edge traverses from a user specified pin to a flip-flop clock pin. Any other inputs to multi-input elements on the clock path are clock enables. Enable signals are allowed to fanout to data pins but clock path signals are not.

VI. CONCLUSION Using Spyglass, digital design blocks were

scrupulously analyzed to find and debug lint, clock and reset and also DFT errors early in the SOC design flow, thus achieving early closure of legitimate quality RTL before being handed off to downstream teams for verification, synthesis and DFT in both ASIC and FPGA modes. Thus we accelerated and economized SOC development by minimizing costly, time-consuming design-and-debug iterations using Spyglass.

ACKNOWLEDGMENT The satisfaction that accompanies the successful

completion of any task would be incomplete without the mention of people who made it possible and whose constant guidance and encouragement crowned our efforts with success. We would like to express our gratitude to all the colleagues of Texas Instruments for their constant co-operation, support, and invaluable suggestions.

IJAEST



REFERENCES [1] Dino Caporossi, “Rule Checking at the RTL Level”, 0018 9235/96/$5

0001996 IEEE, IEEE Spectrum June 1996 [2] Yongyi Lian, Lan Chen, Yajuan Su, “A Novel IP Quality Evaluation

Method Based on IP Function”, 978-1-4244-2186-2/08/, IEEE 2008 [3] Michael Keating, “The IP Quality Revolution”, 0-7695-2093-6/04,

IEEE Computer Society 2004 [4] Jan M. Rabaey, Anantha Chandrakasan, Borivoje Nikolic, “Digital

Integrated Circuits”, second edition, 2003 [5] Tom Dewey, “A Good Methodology Helps Design Teams Check RTL

Code”, Electronic design article, October 27, 2005 [6] Ramesh Dewangan, Ravi Varadarajan, Jitendra Kumar Gupta, Navneet

Mohindru, Satish Soman, White paper, , Atrenta Inc. “SoC Physical Closure Begins at RTL”, 2010

[7] Spyglass Rules Reference Version 4.3.5 Atrenta, January 2010

IJAEST



Date post:	11-Mar-2016
Category:	Documents
Upload:	iserp-iserp
View:	214 times
Download:	1 times

2.IJAEST-Vol-No-6-Issue-No-2-AN-IMPROVED-METHODOLOGY-TO-ACHIEVE-EARLY-DESIGN-CLOSURE-OF-SoC-USING-AN

Documents