Lint Quick Start

Setup Instructions:
1. cd <scripts directory of your design block>
2. get_fpv overwrite
3. Customize fpv/do_fpv.cfg as needed.
4. For HAL: blackbox lower level TSBs, LWCs, and external IPs that are not in your control or not of interest to you
with respect to linting.
All dependent IP components and CAD IP are now automatically blackboxed in HAL by default.
Specify additional blocks to blackbox in fpv/my_hal_design_info.txt.
5. For RC & Conformal: customize fpv/user_info.rctcl as needed. See comments embedded in the file for instruction.
Usage:
Run lint in batch. Return exit code of 0 if there is no NEW violations to indicate a clean run.
fpv/run_lint.cmd
Bring up GUI to analyze after a prior lint run.
fpv/do_fpv.cmd analyze
Run lint and then launch gui with a single command
fpv/run_lint.cmd gui
Typical Use Model:
In GUI, review NEW violations and move all of them to FIX/DEFER/WAIVE.
Fix RTL for the violations in FIX, and make other incremental RTL change.
Run lint again, and make sure the violations in FIX disappear. Review any violations in NEW, introduced by the
incremental RTL change, and move all of them to FIX/DEFER/WAIVE.
Use run_lint.cmd as RTL release QA script:
To make a RTL release with run_lint.cmd as QA script:
pmc_ws tag --all_files --perm --notefile note.txt --qa_script fpv/run_lint.cmd (Do not bsub this command)

PMC-Sierra, Inc. Proprietary and Confidential 1

Linting Goals

The goal of linting is to increase RTL quality by reducing

the chance of errors in the design flow.
A linting tool highlights potential problems in your RTL.
It is up to the designer to evaluate and act accordingly.
It is important that linting is done early and often during
RTL development.
You must lint your code before handing-off your RTL (at minimum!)
However, please do not wait until it is time to make an IP release before
running lint!
Designers are responsible for linting their own code.

PMC-Sierra, Inc. Proprietary and Confidential 2

Definition of Lint Checks
In this slide deck, Lint Checks encompass:
Checks output by the Cadence tool HAL
Checks output by the Cadence tool RTL Compiler (RC)
This is the tool used by implementation engineers
Checks output by the Cadence tool Conformal

Many checks from the combination of these tools are

complimentary, and increase the probability of flagging
issues in RTL
Some checks are unique to each tool
DFT quality checks in RTL Compiler are robust as scan insertion is one
of its core capabilities

PMC-Sierra, Inc. Proprietary and Confidential 3

Problem Statement
HAL Checks
HAL tends to be noisy
Its time consuming to analyze all violations from HAL and waive all the
bogus/dont_care violations.
The waivers (ncbrowse filters) can not be preserved with
even minor RTL change (e.g. adding a comment line)
User often has to go over the same violation that has been waived in the
past, over and over again with any RTL change
Huge waste of time
Need more buckets than just Waived and Not_waived to
classify violations into.

PMC-Sierra, Inc. Proprietary and Confidential 4

Problem Statement
RTL Compiler (Synthesis & DFT Quality) Checks
Going through full synthesis and ATPG requires a long
loop to find out synthesis or DFT issues
Full synthesis to mapped technology gates can take significant run time
Scan insertion and ATPG can also take significant run time
Potentially multiple, lengthy iterations between RTL developers and
implementation engineers are required to address test issues
Iterations are challenging if teams are geographically dispersed

PMC-Sierra, Inc. Proprietary and Confidential 5

 Solution
Lint flow extends the Cadence HAL, RC, and Conformal
tools to enhance its usability.
Allow focusing on a subset of serious checks.
Violations are classified as NEW, FIX, DEFER or WAIVE.
Classifications are remembered from run to run even with RTL change
Enables RTL Designers to view Synthesis & DFT design
rule violations during RTL development
Uses the synthesis tool for consistency of rule checking (the same tool
used by implementation engineers)
No mapping to technology is required (greatly shortens run time)
Can be done at any level of design hierarchy, big or small (not just at the
DFT Region level)
Not meant as a replacement for trial synthesis
No feedback on the quality of timing, area, or power
Provides facility to understand FGCG misses
PMC-Sierra, Inc. Proprietary and Confidential 6
Recommended Use Model

TSB Level Usage

Level 1 checks are a hand-off criteria, and must be run prior to any IP
release.
The IP release note should confirm that lint has been run to properly set
expectations.
Classify lint messages early to reduce effort on subsequent lint
iterations.

Device/MTSB Level Usage

Blackbox TSBs that have already been linted
The lint flow automatically blackboxes dependent IP by default; this
can be overridden.

PMC-Sierra, Inc. Proprietary and Confidential 7

Recommended Use Model

Start linting early in the design cycle of your module or

block, as soon as some partial RTL is available.
Do not need full RTL to start linting!
Less costly to fix bugs early
Can run without RC to reduce runtime costs
Lessons (i.e. recommended coding styles, etc.) are learned early, before
the same mistakes are repeated in many places.
HAL level 1 compliant code (more on levels later) ensure that all
important checks from coding style (Verilog, VHDL, mixed language),
synthesis, race conditions, FSM, DFT, clock domains, scan chains,
palladium compatibility, low power, and RAM are checked in the design
Rest of higher levels (2-4) contain less critical checks, so are not
required.
Run FGCG checks as sensible
FGCG checks should be run less frequently since runtime is longer and
results analysis is not directly coupled to main lint flow
PMC-Sierra, Inc. Proprietary and Confidential 8
 Detecting DFT Issues at RTL:
How RTL DFT Lint Shortens Debug Loop
After: a short loop is
enabled to detect
DFT quality issues,
and is done before
hand-off to IG

Before: a long loop

is required to detect
DFT quality issues,
and involves hand-
off

PMC-Sierra, Inc. Proprietary and Confidential 9

Universe of Lint Checks
Analysis space: collection of lint checks you care to analyze
Outer space: rest of lint checks

LEVEL0
Individual checks
subtracted from
analysis space
DESIGN

LEVEL1 Individual checks

added to analysis
RTL_SIMSYNTH space

set CATEGORIES_TO_ANALYZE = DESIGN LEVEL:1 RTL_SIMSYNTH

PMC-Sierra, Inc. Proprietary and Confidential 10
Universe of Lint Checks
A given check can belong to one or more categories.
i.e. DESIGN and RTL_SIMSYNTH are not mutually excusive sets.

A given check has a specific level associated with it.

i.e. LEVEL0 and LEVEL1 are mutually exclusive sets.

CATEGORIES_TO_ANALYZE = DESIGN LEVEL:1 RTL_SIMSYNTH

This means that the analysis space consists of the following checks:
All DESIGN category checks (regardless of its level)
All RTL_SIMSYNTH category checks (regardless of its level)
All checks that are level 0 (regardless of its category)
All checks that are level 1 (regardless of its category)
Also, if a category to analyze includes other categories, those checks
are recursively included as well.
PMC-Sierra, Inc. Proprietary and Confidential 11
Severity of Lint Checks
All lint checks also have an associated severity:
Error
Anything that has a high chance of causing RTL iteration (simulation,
synthesis, DFT)
Warning
Anything that has a chance of causing RTL iteration.
Note
Informational messages only.

A fatal error is one that causes the lint run to abort.

They cannot be waived and therefore are not even
presented in the GUI for analysis.
HAL fatal errors cause the HAL run to not complete.
RC fatal errors cause RC to not complete. This usually results from RTL that
cannot be synthesized.
Conformal fatal errors cause Conformal to not complete

Note: Severity is not necessarily correlated with level.

PMC-Sierra, Inc. Proprietary and Confidential 12
 Classification of Lint Violations
A classification is also referred to as a bucket
NEW
Violation not yet analyzed. All violations start as NEW, and remain NEW
until re-classified.
FIX
RTL being fixed now to specifically target this violation, which is expected
to disappear after lint is re-run.
WAIVE
Violation is not of concern, and is waived.
DEFER
Not ready to or not sure how to deal with the violation. Defer to later time
the decision to re-classify as FIX or WAIVE, if the violation still exists.
Some of the situations that could make you decide to defer a violation:
Not sure about the usefulness or significance of the violation at the time.
Design is partially implemented. When new functionality gets implemented later,
the violation is expected to disappear as a by-product.
Leave it as DEFER with expectation that the violation will disappear from the classification
later.
Re-classify as FIX if and when making a RTL fix specifically targeting this violation.
PMC-Sierra, Inc. Proprietary and Confidential 13
 Why Classify Violations
Allows you to be organized in analyzing the violations,
just like folders in Outlook allow you to be organized in
dealing with large volumes of emails.
Violations stay in the same classification on next run, or
simply disappear if dont occur any more.
Why classify as FIX:
Violations in the FIX classification are supposed to go away after RTL is
fixed and lint is re-run.
If thats the case, ncbrowse makes the FIX.log folder disappear from
GUI, confirming that the fixes are good.
If the violations are still there, you can easily find them under the fix
folder.
Without the FIX classification, it would be a challenge to determine if the
violations indeed went away, or stayed among all other violations,
especially if only a few instances of the same check are supposed to be
fixed.
PMC-Sierra, Inc. Proprietary and Confidential 14
 Setup: add categories to analysis space
Add categories of checks to analysis space.
Any category defined in the rule definition file tree is
allowed.
Overlap among categories are allowed.
LEVEL:N
Special categories generated on the fly for LEVEL 0, , LEVEL N
N between 0 and 4
Level 0 checks are most severe, Level 4 checks are least severe.
LEVEL:N includes all Level n checks, where n=(0N)
fpv/do_fpv.cfg default:
set CATEGORIES_TO_ANALYZE = DESIGN LEVEL:1 RTL_SIMSYNTH
This includes the DESIGN, LEVEL 0, LEVEL 1, and RTL_SIMSYNTH
categories.

PMC-Sierra, Inc. Proprietary and Confidential 15

Setup: individual checks to add to or
subtract from analysis space
Local rule file fpv/local_lint_rule:
category LOCAL_ADD Checks locally added to analysis space" default_on {
// ABCDEF
}
category LOCAL_SUB Checks locally subtracted from analysis space" default_on {
// give justification for subtracting the following check
// UVWXYZ
}
Environment variable GLOBAL_LINT_RULE, if defined, point to a
global rule file defining categories GLOBAL_ADD and
GLOBAL_SUB with similar syntax as above
setenv GLOBAL_LINT_RULE /proj/digi120/devel/global_lint_rule
Project lead can control the env variable in a project-wide setup_tools file
LOCAL_ADD/GLOBAL_ADD automatically added to analysis space
No need to explicitly add to CATEGORIES_TO_ANALYZE
Checks in LOCAL_SUB/GLOBAL_SUB automatically subtracted
from analysis space

PMC-Sierra, Inc. Proprietary and Confidential 16

 Rule Definition File Tree
Rule files in the rule definition file tree, in descending
order of precedence:
1. fpv/local_lint_rule (users local rule file)
2. $GLOBAL_LINT_RULE (users global rule file)
3. /tools/lib/configs/cadence/ies/conformal/conformal_common_rulefile.def (CAD
Conformal rule file)
4. /tools/lib/configs/cadence/ies/conformal/lec.14.20-s220.lnx86/conformal.def
(CAD Conformal rule file)
5. /tools/lib/configs/cadence/ies/rc/rc_common_rulefile.def (CAD RC rule file)
6. /tools/lib/configs/cadence/ies/rc/v12.20-s014_1.lnx86/rc.def (CAD RC rule file)
7. /tools/lib/configs/cadence/ies/hal/pmc.def (CAD HAL rule file)
8. /tools/lib/configs/cadence/ies/hal/hal_common_rulefile.def (CAD HAL rule file)
9. $IFV_INST_DIR/tools/ifv/files/formalverifier_pmc.def (Cadence IFV rule file)
10. $CDS_INST_DIR/tools/hal/files/hal.def (Cadence HAL rule file)

All available categories are defined in the rule files.

PMC-Sierra, Inc. Proprietary and Confidential 17

CAD Customizations to Rules
CAD maintains and customizes lint rules for HAL, RC,
and Conformal
Enable/disable checks
Upgrade/downgrade severity of a check
Upgrade/downgrade level of a check
Change the category of a check
Change the name of a check
Change other parameters
Modify CAD IP blackboxes for HAL

ICDC KB 1527 lists the history and rationale of CAD

customizations.

Refer to ICDC KB 1527 for more information.

PMC-Sierra, Inc. Proprietary and Confidential 18
 Setup: select appropriate top level
Set TOP in fpv/do_fpv.cfg
For design with Verilog top, specify top module name:
set TOP = pm12_34_56
For design with VHDL top, specify top configuration name:
set TOP = pm12_34_56_rtl
For TSB with a DFT wrapper, set the TSB core as TOP, to
avoid noise from generated DFT wrapper code
set TOP = pm12_34_56_core (pm12_34_56_core_rtl for VHDL)
If only interested in linting a sub-block of a TSB, make the
sub-block the TOP.
This improves run time and allow focus on sub-block of interest.
Multiple runs with different TOP output in separate
directories.
PMC-Sierra, Inc. Proprietary and Confidential 19
 Setup: blackbox (HAL only)
Blackbox lower level blocks that are not of your interest or in your control
Improve HAL run time, sometimes very significantly.
Reduce noise from HAL. Allow focus on more interesting HAL violations.
In general, blackbox lower level TSBs, LW components and external IPs.
By default, all dependent IP components are automatically blackboxed, starting
with do_fpv.cmd version v2.0.
The blackbox list of all dependent IPs is created at fpv/generated_dependent_ip.bbox.
To disable this feature, use -no_dependent_ip_bb switch with do_fpv.cmd.
If a designer owns TSB A and B (A is a dependency of B) and would like to lint both A
and B, the recommendation is to work bottom-up, i.e. run lint on A first, release A, and
then run lint on B.
CAD IPs are automatically blackboxed in PMC HAL wrapper.
Blackboxes are hierarchical.
Specify additional blocks to blackbox in fpv/my_hal_design_info.txt:
# To add a list of modules to blackbox in HAL:
# Uncomment following section, and replace module_x/module_y with the actual module names.
# Make sure to end the last module with a semicolon.
# bb_list {
# designunit =
# module_x
# module_y;
#}
PMC-Sierra, Inc. Proprietary and Confidential 20
 Running Lint
Invoking the lint run
fpv/run_lint.cmd [ -gui ] OR fpv/do_fpv.cmd run lint [ -batch | -gui ]
Run fpv/do_fpv.cmd without switches to get a listing of valid switches

Output log files

Output can be found in fpv/lint/<top_level>/latest_run/
(more on this later)
All checks are run and output to fpv/lint/<top_level>/latest_run/hal.log,
fpv/lint/<top_level>/latest_run/rc.log, and
fpv/lint<top_level/latest_run/conformal.log
Redundant violations are ignored and the rest are split into 4 mutually
exclusive log files, one per classification:
fpv/lint/<top_level>/latest_run/1_NEW.log
fpv/lint/<top_level>/latest_run/2_FIX.log
fpv/lint/<top_level>/latest_run/3_DEFER.log
fpv/lint/<top_level>/latest_run/4_WAIVE.log
PMC-Sierra, Inc. Proprietary and Confidential 21
 Running Lint
Current violations that are pre-existing remain in the
same classification as before

Other current violations that are not pre-existing are put

in 1_NEW.log

By keeping pre-existing violations in the same

classification as before (if they still exist in the current
run):
User can remain organized across lint runs, and avoid wasting time re-
analyzing violations that have been analyzed and classified in the past.
Significant boost of user efficiency.

PMC-Sierra, Inc. Proprietary and Confidential 22

Intelligent Lint Violation Reporting
Each violation in the log file is identified with a tag, source file
path, source file line number and affected design objects.
hal: *W,UNCONN (../rtl/lw55_60_123.sv,785|0): Output port 'TRIGGER_O'
defined in design-unit 'LW20_60_373:RTL' is not connected in its instance
'scbs3_inst'.
With even just a minor change in the RTL to add a comment
line, the source file line number reported by lint gets shifted
when lint is re-run on the updated RTL.
When deciding whether a current violation is pre-existing, the
source file line number is ignored.
The signature of the above violation is:
hal: *W,UNCONN (../rtl/lw55_60_123.sv|0): Output port 'TRIGGER_O' defined in
design-unit 'LW20_60_373:RTL' is not connected in its instance 'scbs3_inst'.
A violation is considered pre-existing, if its signature matches
the signature of a violation from the previous run.

PMC-Sierra, Inc. Proprietary and Confidential 23

 Lint GUI (ncbrowse)
Always use do_fpv.cmd or run_lint.cmd to launch ncbrowse
GUI and analyze lint violations, instead of viewing raw
HAL/RC log files.

ncbrowse GUI launched by either one of the following:

fpv/run_lint.cmd gui (GUI launched when lint finishes)
fpv/do_fpv.cmd run lint gui (GUI launched when lint finishes)
fpv/do_fpv.cmd analyze (GUI launched without a rerun)

Allow change of categories (level,

CATEGORIES_TO_ANALYZE, LOCAL_ADD, GLOBAL_ADD,
LOCAL_SUB, GLOBAL_SUB) without rerun.
Just close the GUI and do fpv/do_fpv.cmd analyze again to have the updated
rule definition files taking effect.

PMC-Sierra, Inc. Proprietary and Confidential 24

 Analysis Space
First sort by
log file, i.e.
classification

Then sort
by tool

Then sort
by category

Then sort
by tag

2_FIX.log &
GLOBAL_ADD not
displayed because
they have no violation

PMC-Sierra, Inc. Proprietary and Confidential 25

Analysis Space

< indicate
violation belong to
multiple categories.

Put mouse over the

violation to see
which categories it
belongs to.

PMC-Sierra, Inc. Proprietary and Confidential 26

Analysis Space

Each RC violation
can be expanded by
clicking the +
sign.

PMC-Sierra, Inc. Proprietary and Confidential 27

Analysis Space

Select rc.log line of

an expanded RC
violation

RC log file (instead

of RTL) displayed,
highlighting the
violation

PMC-Sierra, Inc. Proprietary and Confidential 28

 Classify Lint Violations in GUI
Classify violations as you work through them in the GUI.
Tip: Classify messages right away as you see them.
Many messages are shared between categories. When you classify a
shared message, all shared instances get classified simultaneously. If
you dont classify it right away, you may see it again in a different
category (replicated work).
If you are unsure which bucket to classify to, use the DEFER bucket.
To classify violations:
Select specific instances of violations to be classified.
Hit one of the new, fix, waive or defer button.
Selected violations and violations having the same signature as one of
the selected violations are moved to the log file for the classification,
and all the log files reloaded to reflect the classification.
Dont use the ncbrowse filtering capability to waive
violations. Use the WAIVE button instead.
PMC-Sierra, Inc. Proprietary and Confidential 29
 Classify Lint Violations in GUI

Hit FIX
Button

Select
Specific
Violations

PMC-Sierra, Inc. Proprietary and Confidential 30

 Classify Lint Violations in GUI

Violations
moved to
2_FIX.log

PMC-Sierra, Inc. Proprietary and Confidential 31

 Batch Mode Behavior
If run_lint.cmd is done in batch mode, which is the default:
Return exit code ($status) of 0 if there is no NEW violations in analysis
space, to indicate a clean run
Return exit code ($status) of 1 otherwise
If run superlint is done in batch (default) or TCL mode:
Continue to run IFV automatic checks after lint
Return exit code ($status) of 0 if there is no NEW violations in analysis
space, and IFV returns exit code of 0
Return exit code ($status) of 1 otherwise

PMC-Sierra, Inc. Proprietary and Confidential 32

Use run_lint.cmd as RTL Release QA script
Its recommended to
Resolve all NEW and FIX violations in analysis space (have them deferred,
waived or fixed) before the next IP release
Use run_lint.cmd as RTL release QA script, unless you are in a rush to
make a IP release without resolving all NEW violations
Files and directories necessary to preserve the lint setup and the
classification of violations for RTL release QA are automatically SVN
added when a lint run completes
To make a RTL release with run_lint.cmd as QA script:
% pmc_ws tag --all_files --perm --notefile note.txt --qa_script fpv/run_lint.cmd

PMC-Sierra, Inc. Proprietary and Confidential 33

Use run_lint.cmd as RTL Release QA script
If the QA script fails, the p_ release is not created and the qa
workspace is left in /nobackup for you to review

Running QA Script
=================

QA failed for qa_p_a_release_448_27066.

Output:
Running command: bsub I fpv/do_fpv.cmd -run lint

CURRENT_PMC_COMPILE is not set. Using p_release_22; see ICDC KB 786

Batch Lint Summary:
Logfile: fpv/lint/pm88_60_166/latest_run/1_NEW.log (4518)

Batch Lint Result: NOT CLEAN

CLEAN = NO violation found under NEW bucket in analysis space
NOT CLEAN = violation found under NEW bucket in analysis space

Your release will not be created.

p_a_release_448 could not be created

PMC-Sierra, Inc. Proprietary and Confidential 34

Use run_lint.cmd as RTL Release QA script
And if the QA script succeeds?

Running QA Script
=================

QA completed successfully.

Creating Tag p_a_release_448

============================

p_a_release_448 created.

Creating Release Notes

======================

Comparing this release against previous release p_a_release_051

Creating release note for domain PMC
Tagging completed at Sun Sep 16 12:59:15 2012

PMC-Sierra, Inc. Proprietary and Confidential 35

 End Goal

Resolve all DEFER violations in analysis space (have

them fixed or waived) before tape-in

There should be no NEW, FIX or DEFER violations in

analysis space at tape-in

PMC-Sierra, Inc. Proprietary and Confidential 36

 Outer Space
Outer space = (universe of all lint checks) (analysis space)
fpv/do_fpv.cmd analyze -outer_space
Display checks in the outer space, instead of the analysis space
Display grouped by
LOCAL_SUB
GLOBAL_SUB
CATEGORY_SUB (carved out of each category in analysis space by LOCAL_SUB/GLOBAL_SUB)
REST_OF_OUTER_SPACE

To move a check from outer space to analysis space

Remove the check from LOCAL_SUB and GLOBAL_SUB if its there
Add the check to LOCAL_ADD or GLOBAL_ADD

PMC-Sierra, Inc. Proprietary and Confidential 37

 Outer Space
One per
category in
analysis
space

GLOBAL_SUB
as defined

LOCAL_SUB as
defined

Outer_space
minus
(LOCAL_SUB
and
GLOBAL_SUB)
PMC-Sierra, Inc. Proprietary and Confidential 38
 DCP Audit Procedure
Create workspace
Review setups:
SCRIPT_VERSION should be at least v4.0 in fpv/do_fpv.cmd
TOP and CATEGORIES_TO_ANALYZE in fpv/do_fpv.cfg
LOCAL_SUB in fpv/local_lint_rule
GLOBAL_SUB in file environment variable $GLOBAL_LINT_RULE points to
User defined blackboxes in fpv/my_hal_design_info.txt
User defined synthesis and DFT setup in fpv/user_info.rctcl
fpv/rc.elist: any difference from template
/tools/lib/configs/start_common/fpv/rc.elist
fpv/dft_view.elist: any difference from template
/tools/lib/configs/start_common/fpv/dft_view.elist
Run fpv/run_lint.cmd to ensure the lint result is up-to-date.
Run fpv/do_fpv.cmd analyze. Check that all buckets other
than WAIVE are empty. Review all WAIVE violations.

PMC-Sierra, Inc. Proprietary and Confidential 39

 Additional Audit Tips
Run fpv/do_fpv.cmd analyze outer_space. Review all NEW, FIX,
DEFER and WAIVE violations.

PMC-Sierra, Inc. Proprietary and Confidential 40

 Directory Structure
The output of each run is dumped under a directory like
fpv/lint/<top_level>/2012.07.27.14.48.20/
hal.log
rc.log
conformal.log
1_NEW.log
2_FIX.log
3_DEFER.log
4_WAIVE.log

Symbolic link fpv/lint/<top_level>/latest_run

created/updated to point to directory of the latest run

PMC-Sierra, Inc. Proprietary and Confidential 41

 Classification History
When deciding if a violation is pre-existing, the
classification history by default is taken from the directory
for the last run with the same TOP

-history 2012.07.26.10.34.49
History taken from run 2012.07.26.10.34.49 with the same TOP
Get history from an older run, if the last run was a bad run resulting in
loss of classification history (e.g. you accidentally blackboxed too many
sub-blocks)

-history TOP_2/2012.07.25.18.54.24
History taken from run 2012.07.25.18.54.24 with TOP_2 as TOP
Maybe useful if TOP changed

PMC-Sierra, Inc. Proprietary and Confidential 42

 Hierarchy Information
FPV now outputs information about a designs instance
and TSB hierarchy. Files are in both CSV and JSON
format.
Instance hierarchy files are fpv/<top_level>_hier_inst.*
TSB hierarchy files are fpv/<top_level>_hier_tsb.*

PMC-Sierra, Inc. Proprietary and Confidential 43

 Fine-Grained Clock Gating Check
FGCG is a strategy for reducing power in a device.
FGCG insertion is performed during synthesis.
FPV can report the flops in the design for which FGCG
could not be applied, and the reason(s) why.
Designers can then modify their RTL to ensure that
FGCG is applied to those flops.
Common reasons for ungated flops:
The flop has no enable signal defined.
The flops enable is constant or has a timing exception defined.
The signal does not meet minimum register bank width specification.
The flop is explicitly excluded from clock gating or is user-preserved.
The clock gating library cell is not usable or the logic cannot map to the
clock-gated flop.

PMC-Sierra, Inc. Proprietary and Confidential 44

 Running the FGCG Check
Invoking the check
fpv/run_fgcg.cmd OR fpv/do_fpv.cmd run fgcg_check
Run fpv/do_fpv.cmd without switches to get a listing of valid switches
Output reports
Output can be found in fpv/fgcg/<top_level>
FGCG report is fpv/fgcg/<top_level>/fgcg.rpt
The previous report is saved to fpv/fgcg/<top_level>/fgcg.rpt.bak each
time the check is invoked to enable diffing.

PMC-Sierra, Inc. Proprietary and Confidential 45

 FPV Import
FPV Import allows the IG teams to leverage the FPV GUI
and classification system in their work
Import logfiles generated outside of the FPV lint flow into ncbrowse GUI
Import waivers from PD
Mark specific messages for audit
Currently works for RC and Conformal logfiles and
waivers
Goals:
To allow IG the use of the ncbrowse GUI. RC and Conformal logfiles can
be imported and their messages classified
To reduce duplication of effort between PD and IG teams. PD waivers
can be imported, automatically classifying identical messages in IG
logfiles
To improve communication between IG/PD. The new AUDIT bucket
offers a mechanism to mark messages for review
PMC-Sierra, Inc. Proprietary and Confidential 46
 FPV Import For Use By IG
Import Logfiles
fpv/run_import.cmd -rc_log <RC logfile> -conformal_log <LEC logfile>
Noted logfiles will be parsed, then messages can be viewed/classified
through ncbrowse GUI
Import Waivers
fpv/run_import.cmd -import_waivers <lint directory>
Lint directory must exist in dependent ip directory:
../../../tsbs/<tsb>/scripts/fpv/lint/<top>/latest_run
FIX/DEFER/WAIVE messages will be imported and override local
classifications
AUDIT bucket
New 5th bucket, only available when importing waivers
Contents will never be overwritten by imported waivers
IG should use this bucket for reclassifying waivers that must be reviewed
by PD

PMC-Sierra, Inc. Proprietary and Confidential 47

 References
FPV flow
ICDC component cad_dd_00942
HAL
ICDC component cad_dd_00902
RTL DFT Lint with RTL Compiler (RC)
ICDC component cad_dd_00984
KB 1670: FPV Lint Flow FAQ
Subscribe to ICDC component cad_dd_00942 to get update notifications
KB 1527: CAD customizations to rule files
Subscribe to ICDC component cad_dd_00942 to get update notifications
KB 1536: FAQ on common synthesis and DFT messages
Subscribe to ICDC component cad_dd_00984 to get update notifications

PMC-Sierra, Inc. Proprietary and Confidential 48

 Notes for Training
1) Slide 2 Goals, motivation
2) Slide 6 Advantages of FPV flow, tie in coding guidelines
3) Slide 8 Differences between lint flow and FGCG flow
4) Slides 12-15 Severity, buckets, level
5) Slide 16 Brief pointer that local rules can be defined
6) Slide 18 CADs role in customizations, KB 1527
7) Slide 1 Demo
8) Slides 25-31 Show analysis that was just demonstrated
9) Slide 43 Hierarchy output, show CSV and JSON viewer
10) Slides 44-45 Introduce FGCG and demo

PMC-Sierra, Inc. Proprietary and Confidential 49