UNIX

Some Classifications Of Commands

1.Directory navigation commands
2.Process management commands
3.Text Editor Commands
4.File Archive and Compression Commands
5.Miscellanous commands

I.Directory Navigation Commands

a.PWD:-Present working directory
b.CD:-Change directory
c.LS:-lists directories or files
ls-a :- lists all files including those begin with a dot
ls-d:-lists only names of directory
ls-f:-indicates types of entry with a trailing symbol
ls-g:-displays unix group assigned to the file requires the -l option
ls-L:-if the files a symoblic link lists the info for the file or directory
ls-l:-long listing;list mode,link information,owner size,last modified
Ex:-ls-l <file name>
d.MKDIR:-make directory
e.RMDIR:-Remove directory
f.PS:-Reports the process status(Current running)
g.CD Enter:-Opens home directory
h.CD~:-Opens home directory
i.CD/:-Opens root directory
j.CD.:-Opens current directory
k.CD..:-Opens parent directory of current working directory
l.CD-:-Opens the root directory

II.File maintanace commands

1.chgrp [777] groupfile:-change the group of file
2.chmod [options] filename:-change file or directory acess permissions
3.chown [options] owner file :-change the ownership of a file(can only be done by
superuser)
4.cp [options] file1 file2:-copies the contents of one file to another
[options] file1 file2:-moves the content from one file to another
6.rm [options] file name or directory name:-removes fileor directory

III.Display commands
1.cat [options] file :- concatenation(prints the comtent file on the console
itself)
cat-n:-proceed each line with anumber
cat-v:-displays nonprinting chars
cat -e:-displays non printing chars
2.echo[text string]:-echo the string to stdout
3.head -[number] filename:- displays the lines in file and their content
4.tail [options] [filename] :- displays the last few lines files

IV.System Resources

1.Date:-displays date and time

2.df[options] [resource]:-report file system diskspace usage
3.du [options] [filename]:-report amount of space of disk blocks
4.kill :- terminate a process
5.passwd:-change password
6.su:-(Set root password)
7.Hostname:-Shows the hostname
8.STTY:-change and print terminal line settings
9.Whereis [options]:-report the binary,source,manualpage files for a command
10.Which:-shows the full path of(shell) commands
11.Who:-shows who is logged on
12.Who am i:-who are accessing on the cpu

V.Vi/vim/gvim Editor commands & configuration

Open File: vi <filename/s> � {vi *.c means open all .c files in the current
directory}
Save/Quit: :w
Quit without saving file: :q
Save and quit: :wq
Forcefully Save: :w! {used to save a Read Only File like /etc/shadow}
Forcefully Quit: :q! {it will ignore all changes after last save}
Forcefully Save & Quit: :wq!
Editing Commands:
Insert ch ar/s i
Insert at start of line I
Insert line after o
Insert line before O
Append after cursor a
Append at the EOL A
Delete char x �{delete n char nx}
Delete word dw �{delete n words ndw}
Delete line dd �{delete n lines ndd}
Delete lines n1 to n2 :n1,n2 d
Delete rest of the line D
Change word cw �{change n words ncw}
Change entire line cc
Change rest of the line C
Replace char r �{replace n chars nr}
Replace till <ESC> R
Swap char postion xp
Undo last edit u
Cursor movement:
Go to line no. n : n
Go top of file :1
Go bottom of file :$
Go end of line $
Go start of line 0 or ^
Go up k or � {Go n lines up nk}
Go down j or � {Go n lines down nj}
Go left h or � {Go to left by n col nh}
Go right l or� {Go to right by n col nl}
Go one screen back ^b or Pg Up
Go one page down ^f or Pg Dn
Go to next file :n � {if you opened more than one file}
Go to Previous file :N � {if you opened more than one file}
Search & Substitution:
Search /<string> �(use n for going to next occurrence of <string>)
Substitution :n1,n2 s/X/Y/options � Substitute 'Y' for first occurrence of �X'
between lines n1 & n2
Options: g � Global Change c - Confirm each change
Copy, Cut& Paste:
Yank (Copy) yy �{yank n lines nyy}
Cut can be of chars nx , words ndw or lines ndd or :n1,n2 d
{After deletion or yank, position the cursor properly and use p to paste the
deleted chars, words or lines}
Put p � { Equivalent to Paste}
Search Patterns (Regular Expression)
Beginning of line ^ �{Hat}
End of line $
Any character . �{Dot/Point}
Zero or more of previous character * �{Star}
Matches any character from A to Z [A-Z]
Matches any character from a to z [a-z]
Matches any character from 0 to 9 [0-9]
Matches a, b, or c [abc]
Matches any character BUT a, b or c [^abc]
escape character for literal: \ / $ . ^ [ ' & * | ~ \
General Commands:
Transfer lines :n1,n2 t n3 � {transfer lines between n1 & n2 after line n3}
Write to other file :n1,n2 w <filename> �{write lines n1 to n2 to file filename}
Append to a file :n1,n2 w>> <file name> �{Append from lines n1 to n2 to file
filename}
Read from file :r <filename>
Know about file detail ^g
Refresh Screen ^l
Set Options:
Prints all option settings :set all
Enables option 'option' :set option
Disables option 'option' :set nooption
Prints current value of 'option' :set option?
Prints modified options :set
Show Line Numbers :set nu
Hide Line Numbers :set nonu
Set Auto Indent :set ai
Complex Examples:
Remove first 5 char from all the lines :1,$s/^�..// �{There are 5 dots}
Remove last 5 char from all the lines :1,$s/�..$// �{There are 5 dots}
User can use .exrc or_vimrc file as a default vi/vim configuration.In Unix/Linux it
is called
vi/vim. In Windows it is called vi/gvim.
Sample common_vimrc
set nocompatible
source $VIMRUNTIME/vimrc_example.vim
source $VIMRUNTIME/mswin.vim
behave mswin
set nu
set nobackup
set ts=5
set ai
Sample common .exrc
set nu redraw showmatch beautify autoindent
set tabstop=3

Some Extra Useful commands

Grep:-Prints line matching the pattren
The grep command searchs fies or standard input globally

grep pattern <filename.txt>

1.grep-n ravi <filename.txt> :- prints the word ravi along with line numbers
2.grep-x ravi <filename.txt> :- select only those matches that exactly match the
whole time
3.grep-o ravi <filename.txt> :- prints only the matched part of the line
4.grep-i ravi <filename.txt> :-prints it ignores case distinctions
5.grep-v ravi <filename.txt :- Invert the sense of matching to select the non
matching lines
6.grep-w ravi <filename.txt> :- matching lines
7.grep-f ravi <filename.txt> :- obtains pattrens from file
8.grep-h [pattren] [filename]:-print the filename for each match

jio apn new links

https://www.youtube.com/watch?v=N-uyt8E5TgU

https://www.earticleblog.com/jio-apn-setting-jionet.html

https://tricksgang.com/increase-jio-speed/

https://www.komparify.com/speedtest/provider/reliance-jio

http://electronics-course.com/d-flip-flop

https://www.electronicsforu.com/technology-trends/learn-electronics/flip-flop-rs-
jk-t-d

https://learnabout-electronics.org/Digital/dig53.php

https://www.javatpoint.com/d-flip-flop-in-digital-electronics

https://circuitdigest.com/electronic-circuits/d-flip-flops

https://ecetutorials.com/digital-electronics/d-flip-flop-circuit-operation-and-
truth-table/

https://www.electricaltechnology.org/2018/05/digital-flip-flops.html

https://www.digitalelectronicsdeeds.com/ipsd/enipsd_c5.html

https://www.gatevidyalay.com/flip-flops-in-electronics/

https://www.daenotes.com/electronics/digital-electronics/flip-flops-types-
applications-woking

https://learn.sparkfun.com/tutorials/digital-logic/sequential-logic

https://digitalbyte.weebly.com/delay-and-toggle-flip-flop.html

https://www.realdigital.org/doc/1d4a229dba3de76c709b63ca1dbabe02

http://www.onmyphd.com/?p=flip.flop
https://components101.com/tags/d-flip-flop

How we can move from. Sop or pos to kmap technique

https://www.allaboutcircuits.com/technical-articles/karnaugh-map-boolean-algebraic-
simplification-technique/

https://www.google.com/amp/s/www.geeksforgeeks.org/introduction-of-k-map-karnaugh-
map/amp/

https://www.electronicshub.org/boolean-logic-sop-form-pos-form/

https://www.ques10.com/p/6106/write-a-short-note-on-i-k-map-1/

https://www.elprocus.com/sum-of-products-and-product-of-sums/

https://www.google.com/amp/s/www.electricaltechnology.org/2018/05/karnaugh-map-k-
map.html/amp

https://www.google.com/amp/s/pediaa.com/what-is-the-difference-between-sop-and-
pos/amp/

https://www.zeepedia.com/read.php?converting_between_pos_and_sop_using_the_k-
map_digital_logic_design&b=9&c=11

Implement full adder using 4*1 mux

https://www.iitg.ac.in/cseweb/vlab/Digital-System-Lab/fa_mux.php?id=10#:~:text=Full
%20Adder%20using%204%20to%201%20Multiplexer%3A&text=A%204%20to%201%20line,S%2CCout
%20are%20the%20outputs.

https://www.ques10.com/p/30280/implement-a-full-adder-circuit-using-two-41-multip/

https://www.electronicshub.org/multiplexerandmultiplexing/

https://www.electronics-tutorials.ws/combination/comb_2.html

https://www.circuitstoday.com/half-adder-and-full-adder

main

https://www.electronicshub.org/sequential-circuits-basics/

https://www.circuitstoday.com/half-adder-and-full-adder

https://www.electrical4u.com/electrical-engineering-articles/digital-electronics/

Flooplan : (@ FloorplanningChecks_Barts[1].pptx)
Halo for all macros is taken as 0.5um
Any Standard cell height = 1.26um
Cell Widths:
BUFFD16 = 4.06um FILL4BWP = 0.56
BUFFD12 = 3.08um FILL3BWP = 0.42
BUFFD8���= 2.24um TAPCELLBWP = 0.56

FILL3BWP cell is used as FILL cell isolation at vertical edges in Cedar

TSMC 45nm Requirement

No standard cells may be placed where they don�t have another standard cell
or filler surrounding them
If not followed, this will make their timing unreliable

All tiles have half-row (0.63um) at top and bottom i.e. every tile start and end on
half-row
To meet the above TSMC requirement, we add FILL cells on the first and last row of
each tile.
To meet timing on top-level paths there should also be a vertical channel for
buffering between memories every 200um.

All Macros should have orientation of either �R90� or �MX90� only. ROS macro�s
orientation should be �R0�

Check For IO Pins :

Make sure all the IO pins are on the Routing Track.
Run �checkFPlan� cmd at your encounter terminal

CHK2:Top and Bottom of Tile Should have 0.63 Micron offset from boundary :

CHK3:Shield Ring Around Tile and Should Connect to GND stripes

CHK4:
FeedThru Allignment

CHK5:Near IO ports Reserve Sufficient Space for FCT buffering

CHK6: Left and Right edges must have isolation FILL3

CHK7: Ram to Horizontal edge with stdcell row spacing

Min = 5.1um Recommended >= 6.5um

CHK8: Ram to Horizontal edge with NO stdcell row spacing

Min = 1.76um Recommended = 1.76um

CHK9: Ram to edge vert. with stdcell row.

Spacing Min = 7.08um Recommended >= 7.08um

CHK10: Ram to edge vert. with NO stdcell row - NOT an option

Row must have isolation FILL3 spacing; Min = 3.6um

CHK11:Ram to ram spacing (horizontal spacing) with stdcell rows

Min = 7.3um

CHK11:Ram to Ram spacing (vertical spacing) with stdcell row spacing

Min = 6.3um

CHK12:Ram to Ram with NO stdcell row. Spacing

Min = 0.5

CHK13:Ram to Large Clock Buffer Spacing

Min = 0.5 Recommended >= 3.18 um

CHK14:Halo spacing
min. = 0.5um

CHK15:All tiles must block M8-M9 over entire tile area

CHK16:Rectilinear tiles must block M1-M9 over the tile cut

CHK17: Clock buffer must be within 28.8um of PDLY output

CHK18: All stdcell rows must touch a TAP cell

CHK19: All Stdcell rows minimum TAPCELL pitch � 29.68um

CHK20: All stdcell rows must be supplied with VDD/GND

CHK21: Power stripes on M7 pitch is 5.04um and width is 0.51um

CHK22 : RAM power is connected to M7 stripes, no M6 P/G stripes exist over rams

CHK23: P/G pins align with P/G stripes on all edges

CHK24: PDLY to First clock gator distance is 28.86

CHK25: CKBD96 hookups

CHK26: Htree �pin creations

CHK27: Blockages around clock buffers (CKBD96) [Every CKBD96 clock buffer will
have 1um blockage around it.]

CHK28: TAPCELL (LUP violations)

CHK31: Real Power Hole violations

CHK32: Macro orientation E W FE FW [Macros should be placed in Vertical

Orientations]

N7 Base issues

NW
PO
OD
MP
MD
FB
CCP
NP
PP
VT* (VTUL_N , VTUL_P , VTL_N , VTL_P , VTS_P , VTS_N ) min VT width is 0.228 (4CPP)
VD
VG
CMD
CPO

Violation Type : G4.PP/G4.NP

When Two Tap cells got abutted vertically which are of 2 different ref name then
you will get this violation.
Fix is need to change both Tap cells to HDBLVT08_TAPDS.
VIOLATION TYPE � H240.OD.S.1.10 /H240.OD.S.29
.Tap cells and power gaters are separated by 1X space which is not allowed (need to
maintain min of 3X b/w two FINTAP cells / SYNC Flop to TAP cells )

Violation Type � NW.A.2

When level shifter region is extended till the boundary cells(tile edge ) need to
maintain 7X filler spacing to meet NWELL area with a spacer cell b/w them

VIOLATION TYPE : PP.S.11.3 , PP.EN.5.1 , PP.EN.4 , NP.S.11.3 , NP.S.6 , NP.EN.5.1

When Tap are ending near power gater/macro boundary corner cell which is causing
the PP,NP enclosure by OD violations .FIX:Need to place the TAP cell by 3CPP away
from the Power gater edge.

VIOLATION TYPE : PO.R.15 (odd poly issue)

PERFRO placement need to change which is creating the odd poly issue with the core
region. #From the tile edge to PERFRO edge the length is 7.5810 (if you divide with
the even multiple of� i.e. 0.114 == 66.5 ).#�#So try to reduce the spacing by 0.057
using the placement blockage b/w PERFRO and tile boundary edge 7.5240 (then you
will get even multiple i.e. 66) .

VIOLATION TYPE : PO.R.15.2 ( vertical slice set of 10 poly�s are required)

Need to maintain >=10cpp (>=0.57um) in vertical direction from macro edge to edge.

When RAM�s got abutted to each other PO spacing violations (need to maintain 0.57
spacing b/w them)

Violations around TMAC :

Violations around TMAC related to M0,M1,M2,M3 and DM0 �DM9 .

By reducing the Routing blockage around TMAC (M0-M9) by 0.7um will fix this issue.
Violation type: M*.R.15 and M*.R.14 (* ? M0,M1,M2,M3).

SNIFFER CELL :

Sniffer cell in MV tiles can be R0 or MY . But make sure all the M0,M1 and M2
should align to the respective Color tracks.

Eco main points (@shanghai_Training_ECO-1)

WHAT IS ECO FLOW

ECO Flow makes small changes to a routed design by
using encounter tcl commands , updated verilog
netlist or both
Functional change
Tile Timing closure
Chip Timing Closure
Eco flow will apply eco, place&route, verify design, extraction, timing and
generate new eco files.

Final timing goals:

All clock transition met
All data transition/max cap met
Setup to 0ps
Hold to the specified margin base on the project and technology node
SI setup/SI hold closed as much as possible
All SI noise violations cleaned
All double switching needs to be fixed
All datapulse violations need to get fixed

Automated ECO/Targeted Fixing

This flow allows users to perform significant optimizations in a relatively time

efficient manner during the ECO process and can be enabled by setting
CHOSEN_OPTECOROUTER = Sp and ECO_USE_ECO_COMMAND_FILE to 0.
With the default settings the overall structure of the script is:
read library, design, constraints
dump initial reports
perform optimization for setup, transition and max cap
perform optimization for hold
perform optimization for setup, transition and max cap
dump final reports

Setup Fixes : upsizing and buffer insertion

data/SpGenSetupFixEco.eco
Hold Fixes : Add delay or buf cells, setup and MMMC aware
data/SpGenHoldFixEco.eco
Clock Transition Fixes : upsizing, driver cloning
data/SpGenClkTranFixEco.eco
Data Transition Fixes : upsizing and buffer insertion
data/SpGenTranFixEco.eco
Data Cap Fixes : upsizing and buffer insertion
data/SpGenDataCapFixEco.eco
Data Pulse Fixes : upsizing or inserts a BUFFD1 at the D pin
data/SpGenDatapulseFixEco.eco
Noise Fixes : upsizing and buffer insertion
data/SpGenSiNoiseFixEco_routes.eco
data/SpGenSiNoiseFixEco.eco

Manual Timing ECO methods (1)

Many possible methods for manual timing closure

Upsize
Buffer insert
Buffer delete
Buffer bypass
Buffer non-critical loads
Buffer swap to inverter
Skew clock

Manual Timing ECO Methods (2)

Upsize
Reduces cell delay
Most ECOs will be upsizes
Most combinational D0 cells should be upsized with a delay of ~80ps � D1 cells are
the same footprint!
Flops can be upsized
Should be done carefully
Clock pin cap can change
Flop movement due to legalization can hurt clock routes
Flops can also be upsized to reduce setup time

Manual Timing ECO Methods (3)

Buffer insert
Reduces driver and net delay
Good idea if the cap is large (~100fF)
Also good idea if the net RC delay is large (~100ps)
Can also split fanout
Buffer delete
Saves a buffer delay
Useful if a buffer is driving a small cap
Can also be useful if the cell driving the buffer can be upsized

Manual Timing ECO Methods (4)

Buffer bypass
Saves buffer delay
Tools tend to insert buffers so that all endpoints on a net end up at the outputs
of a buffer tree
Some cells can be reattached to the root of the tree
Cell in red could be attached the output of cell in orange

Manual Timing ECO Methods (5)

Buffer non-critical loads
Speeds up the root of a net by reducing cap
Add a buffer to drive non critical loads
Useful when a net has a high fanout, but few terminals are timing critical
Buffer swap to inverter � May hurt slew
Can save cell propagation delay
Swap back to back buffers to inverters
Increased pin cap on inverters can hurt results
Inverters also are not good at cleaning up bad slew

Manual Timing ECO Methods (6)

Clock skew � ONLY FOR NON-FIXABLE PATH
Improve setup/hold be changing clock insertions
Should be done very carefully
Need to ensure that all new clock nets have correct layout
+ USE CLOCK in def
Correct nondefault rule
Correct routing layers
All timing implications must be considered
Slack always gets worse somewhere

Manual eco scripts (1)

ecoChangeCell used to resize cells to higher/lower drive strengths.

ecoChangeCell �inst <inst name> �cell <cell type>
addInst used to add new cells to the design, and optionally specify their
location.
addInst �inst <inst name> �cell <cell type> [-loc <x> <y> [-ori <orient>]]

deleteInst used to delete instances from the design.

deleteInst <inst name>
addNet used to create new nets in the design. The hierarchy of the net name
controls the module that the net will be added to.
addNet <net name>
attachTerm used to connect pins of a cell to a net. If the cell is already attached
to another net, encounter will disconnect it from the old net. If the cell is
connected to a net in a different hierarchy, encounter will automatically create
ports to wire the signal up.
attachTerm <inst name> <term name> <net name>
detachTerm is used to detach pins on a cell.
detachTerm <inst name> <term name>
ecoAddRepeater is used to add buffers.
ecoAddRepeater { -net <net name>| -term <inst1/term inst2/ ...>} -cell <cell
name>
ecoDeleteRepeater is used to delete unwanted buffers. If two instances are
specified, it will delete both, which is useful for collapsing paired inverters.
This command will also merge the wires from before buffer deletion onto the new
net.
ecoDeleteRepeater �inst <inst name> [<inst name>]

placeInstance is used to place cells in encounter. If the -placed option is used,

the cell locations might be changed during legalization.
placeInstance <inst name> <x in microns> <y in microns> [<orient>] [-fixed|-
placed]

Requirements for entering ECO mode

Release P&R flow def, verilog, sdc. (startpoint for eco)

NICKNAME follows naming convention.

Collect eco scripts

FindFloatingWaste
NonDefaultRuleCheck
NonDefLength
InsertSpareflop
LVT swap
SpMixedVt
LpFF swap
extra metal fill for tiles around chip boundary

Step 3; Run TB with personality eco

TileBuilderStart �params override.params
Run parallel safe and risky ecos
If you have functional Eco, please have 3 parallel runs to reduce risk
- Timing Eco only
- Functional Eco only
- Timing + Functional Eco
Step 4; Release post eco data.
tile_release eco
Release data becomes input for next ECOSET
Tile_release eco_noilms for dft, ct, rep tiles

Functional Eco Flow

Upsize cells if frontend use D0 cells. Open FE and make sure the new cells are
placed in correct location. Check clock pin connection if the new cell is Flop.
Q: PD owner give route.v to frontend to start logic eco, it takes 1 or 2 days to
get the logic eco file back. PD already makes a few iterations of timing ECOs. How
to apply functional ECO without losing timing ECOs?
A1: (with updated verilog flow) go back to the original route.v, apply the updated
verilog and apply all the timing ecos on the original route.v, fix the timing ecos
if they conflict with updated verilog. TB will apply updated verilog first and then
timing ecos. Remember to give locations for new added cells.
A2: (generate eco file from updated verilog flow) Apply the new functional eco file

func.eco to most current def.

#Need to dump eco file with encounter. remember to load timing library
Old netlist : old.v
Old def���� : old.def.gz
New netlist : func.v
Flow:
Dumping ECO:
run_fe
setImportMode -useLefDef56 1
loadConfig old.conf��������������� ## set rda_Input(ui_netlist) "old.v"
defIn ����� old.def.gz
ecoCompareNetlist �logical �verilog func.v �outFile func.eco
exit

Metal eco flow

Overall Review:
During Metal eco flow, we swap existing MECC*_DCAP* cells with various
MECC*_ logic cells to fix timing and perform functional ecos
MECC* logic cells have similar base layers. Only by changing M1 layers to
MECC*_DACP* cells , MECC* logic cells are formed.
Following procedure is adopted to do functional/timing ecos during metal ecos by
using encounter.
a) All non MECC* logic cells and FILL cells are fixed during the process
b) Remove all MECC*_DCAP* cells.
c) Add MECC* logic cells
d) Place them with correct orientation(All dcap cells should have
orientation R0 or MX!)
e) Fill MECC*_DCAP* cells
Check for any FILL cells addition in FeApplyEco log file.
If FeApplyEco adds new FILL cells, TileBuilderCheckLogs will throw an error.

Important things:
a) CbTilePreEcoRouteXOR and CbTileXOR targets in metal eco are as important
as LEC targets. These targets should pass at any given time. Do not proceed to
next eco until *XOR targets run successfully without any errors.
b) Do Not use any regular cells for timing fixes or for functional eco
c) Don not modify any existing 0nm/+2nm lib cells. Upsizing and deleting
cells will modify base layers.
d) If you get a functional eco from front end , Please take look at it and
modify to higher strengths based on MECC cells availability to avoid slownodes

Things to check After ECO

The layout may be loaded easily by using TileBuilderViewDef

Viewing the layout can also save time in the future by catching bad ECOs early
Typically a good idea to check for heavily layout dependant ECOs - Clock skew,
buffer bypass, function ECO
Also check the layout when making ECOs in odd locations
Narrow channels, congested areas

Try not to leave dangling nets and floating gates. Be careful when deleting an
output pin from a net. It may create a floating input.
It�s bad to add more than one CLKBUFs to a particular branch of a clock net. In
this case, you'll need to trace the clock tree back a few levels and create a new
branch.
Frontend should generate ECO file based on PD-released route.v.
 Use primetime or FE timing debugger to simulate the effect of ECO.
Net connected to the tile port should have the same name as port.
Clock buffers can be changed but make sure that they are fixed.

All New clock nets should have non-default spacing tag.

setAttribute -net NET_NAME -non_default_rule Track2X_Wide1X_Metal
Flops and Marker cells should all be fixed.
dbSetIsInstPreplaced INST_NAME 1
Be careful when touching the output of a flop, you may break scan.
Do parallel runs with heavy/light ecos.
If you have D0/D1 cells in functional ECO, swap them to D2 before apply the eco.
Run reportWire after FeRoute, check for bad scenic routes. Reroute these scenic
routes with no detour attribute before enter OptRoute.

Timing Analysis Flow Overview

In addition to basic setup and hold timing, there are many other timing-related
checks that take place in the timing flow
Timing checks - things like unclocked flops, unconstrained endpoints, timing loops
Min period - for a library cell like a RAM, tells the max frequency it can run at
Min pulse width violations (for example, if a clock pulse is too small)
Datapulse violations (when setup and hold time meet timing, but it still will not
latch properly since the total time spent at logic 0 or logic 1 is too small to
latch)
Data transition violations (data signal takes too long to switch)
Clock transition violations (clock signal takes too long to switch - burns power!)
Max capacitance violations (trying to drive too much of a load)
Signal Integrity (SI/noise) related violations
Clock SI (too mush crosstalk on clock nets)
Noise area/height (aggressor signals causing noise interference that is too large)
Double switching (aggressor signals causing a signal to toggle repeatedly in one
cycle)
Miscellaneous reports like clock frequencies, total negative slack, constraint
errors, analysis coverage (percent of design timed), illegal cell types, etc

Timing Analysis Tools

The main timing analysis tool used historically for graphics chips is Synopsys
Primetime. This is for both normal timing and noise timing.

Timing corners and modes

For each process node (like TSMC 45nm), the signoff guidelines team comes up with a
set of PVTs that need to be timed. This stands for:
P = Process (slow, typical, fast)
V = Voltage (0.72v, 0.88v)
T = Temperature (0c, 100c)
In addition to the process characteristics, there are extraction corners that need
to be timed in certain combinations with those PVTs. Usually there are 4 of these
(typical rc with high/low temp, best rc with low temp, worst rc with high temp).
These represent variations in wire delay due to process and temperature.
The cell libraries are characterized at each PVT and timed with extraction corners
that make sense.
For each chip family, the logic design and DFT (design for test) teams provide a
list of modes which need to be timed in combination with the PVTs and extraction
corners. Modes are distinct because they have different clocks and also test
different portions of the logic by setting constant values on muxes which control
the function of the chip.
Typical modes include normal functional mode, display mode, and scan. The common
scan modes are multi-shift, single-shift, capture, and lockup.

On the right are the library PVTs used for the Evergreen line of chips
The cell libraries have to be characterized for each PVT corner, also called
library corners
Libraries come in various flavors
NLDM - Non-linear delay model - are the normal libraries we use. They use a
voltage source for driver modeling.
CCS - Composite current source - are libs that use a current source for driver
modeling. They are supposed to be more accurate than NLDM, but not so much in
45nm+.
Graphics chips so far have chosen to useNLDM for timing analysis and CCS for noise
analysis. Do not be confused by the CCS file extension on libraries in 45nm and
32nm. The timing tables are still NLDM in those CCS library files.

Here are the extraction corners used for the Evergreen line of chips:
StarRC is the normal extraction tool. Extraction files can be text (SPEF) or
binary (SBPF). Standard Parasitic Extraction Format (SPEF) files are larger, but
can be examined using text editors. Synopsys Binary Parasitic Format (SBPF) files
are 4 times smaller and faster to read in timing tools, but are limited in use to
Synopsys tools

Timing Corners and Modes

When lib/extraction/mode are combined, there are 29 unique corners

Some timing corners have a far greater impact than others

These tend to be at the process or voltage extremes - for example, the lowest
voltage timed with the FF process may have a large number of violations
The sortTimingPaths script will report the relative importance of timing corners
Scaling factors between timing corners can be used to normalize them. For
example, adding a BUFD2 in a FF corner may add 30ps of delay. Adding the same cell
in a SS corner may add 60ps of delay. In that case, a scaling factor of 2 would be
used to normalize the delays. This is important when finding critical timing
corners. It really comes down to the ease of fixing violations per corner.

Timing in TileBuilder

There are 4 target groups for timing in TileBuilder tile flows:# ilm -
generates interface logic views of tile for full chip flows# pretiming - runs
non-extracted timing on floorplan data route_timing - most timing runs show up
here, including SI# noise_timing - for SI timing when separated from normal
timing

Direct inputs to timing targets include:

Various csh and cmd files (GenericPtRouteTiming.csh and .cmd)
Routed verilog (ReRoute.v.gz)
Design constraints (sdc)
Parasitics (sbpf)
Various tune files (presdc, postsdc, preanalysis, postanaysis, etc)
Timing scripts (histogram.pl, ptslacks.pl, etc)
The entire cell library in the technology dir

Timing in the tile flow can happen at many different flow stages
Pretiming with no wireload - good early indicator before placement
Pretiming with wireload - usually has bad timing and is ignored
 Route timing - first stage usable for full chip flows, after placement and routing
but before optimization
ReRoute timing - after SpOptRoute and FeReRoute (optimization and re-routing) -
used for tile releases for most of the project
EcoRoute timing - after ReRoute and ECOs are applied
There are more combinations, like MvtRoute (after mixed Vt swap), and DfmEcoRoute
(after ECO and DFM steps like redundant via insertion and dummy metal fill). Do
not be surprised to see others.
The timing targets will have the stages above somewhere in the target name, like
PtTimFuncTT0p85vcbest0cff0p935v0cReRouteSxHld

Direct outputs from sort targets include:

Consolidated min_pulse_width report (merged corners)
Uniquified, sorted paths that come from or go to tile ports (EXTERNAL)
Uniquified, sorted paths that do not touch outside logic (INTERNAL)
Summary report of WNS, TNS, violation counts, etc
Multiple timing corners can be processed in one sort target. This is handled when
configuring timing corners. Simply give the same sort name for multiple timing
runs, and they will get sorted together.

interpreting timing results

Messy design constraints will cause timing results to be very bad. The first thing
to check when timing results are suspicious is the constraints log. Each PtTim
report directory will have a file called constraints.log.gz. Look for failed
constraints (such as a clock that did not get created correctly) by finding any
line that begins with �0�.
All constraints that were processed correctly will be following by a line with �1�
on it.
It�s a good idea to periodically check for errors in the other log files, such as
update_timing.log and the main log file which is kept at logs/PtTim*.log
If clock frequencies are incorrect for clocks which have cross-logic, there may be
clock period expansion warnings in the update_timing log.
Missing false paths or case values on clock gating muxes can cause false
violations to show up.
Too many unconstrained endpoints or unclocked flops points to missing or broken
clocks
Many false violations will appear for high fanout nets that have not yet been
optimized

Many failed constraints can be ignored. Generally a �missed� constraint

results in pessimism, which is safe. Dangerous constraints to mismatch include
clock creation, clock uncertainty, set_min_delay, set_max_delay, or anything else
that increases coverage or pessimism. Safe constraints to miss are ones like
set_false_path, set_case, set_multicycle, etc, since those decrease coverage and
pessimism.
Sometimes constraints get hacked into the SDC for special purposes. These are
prone to errors since they do not get validated in integration flows (which is the
norm).
An example would be a top level constraint applied at the tile level. The tile
hierarchy (like core/bf_t/) should not be present in bf_t tile constraints. The
reverse often happens in full chip timing.
Fastpath tile releases are prone to SDC errors. The fast path constraints do not
have to meet the same level of quality as the constraints from the integration
team.
CCD (Conformal Constraint Designer) is starting to be used more to identify
constraint issues further upstream. It can catch problems very early, which saves
PD engineers from having to spend a lot of time debugging constraint issues.
 OCV stands for on-chip variation. It adds uncertainty into timing calculations to
account for random differences in timing around the chip. For example, an INVD1
somewhere on the chip might have 10% more or less delay than an identical INVD1
somewhere else, even with identical input slew and driving load.
OCV is also called derating, and shows up in timing reports near the top
Startpoint: core/tcpt7/tcp0/tc_L1_rdreqfreemux/d1TCC0_TCP_rdreq_free_reg
(rising edge-triggered flip-flop clocked by SCLK)
Endpoint: core/tcpt5/tcp0/tc_L1_rdreqfreemux/RC_CG_HIER_INST330_RC_CGIC_INST
(rising clock gating-check end-point clocked by SCLK)
Path Group: **clock_gating_default**
Path Type: max
Max Data Paths Derating Factor : 1.02500
Min Clock Paths Derating Factor : 0.97500
Max Clock Paths Derating Factor : 1.02500
Max Timing Check Derating Factor : 1.02500
OCV values are typically higher for hold than for setup, and highest for slow-
device hold corners. The OCV values are determined by the signoff guidelines
working group based on spice analysis of variation caused by many different
factors.

AOCV stands for advanced on chip variation. It�s similar to OCV, except it takes
logic depth into account to reduce pessimism when long chains of logic are
statistically unlikely to randomly vary in the same direction. It also adds
pessimism in the case of short levels of logic since OCV may have been too
optimistic in that case.
AOCV was not used for previous 45nm chips but is starting to be used for smaller
process nodes.
AOCV is a step in the direction of statistical timing analysis (see this PDF for
more info)

CRPR stands for clock reconvergence pessimism removal/reduction

It shows up in the slack calculation at the bottom of timing reports
The general idea is that timing derate (OCV) applied to the clock networks should
not be included for the portion of the launch and capture clock that is common.
After all, how could the delay through those clock cells be different at the same
instant in time?
When CRPR is enabled, Primetime �recovers� the clock skew caused by derating on
the common portion of the clock path.
In SI mode, there is also crosstalk delta delay on the clock network. Since
crosstalk can vary from one clock cycle to the next on the same clock network (due
to aggressors switching differently), clock skew caused by crosstalk delta delay on
the common portion of the clock network can not be recovered in SI setup timing.
This also applies to half cycle hold SI timing, or any other timing path with a
different launch edge and capture edge.
Older versions of Primetime had a bug which sometimes set the CRPR recovery value
to �-0.00000� in slack calculations. If that number is seen, then it�s probably
incorrect.

What are the OCV numbers used for setup and hold?
What are timing margins for setup and hold for various timing corners?

Signal integrity

Signal integrity is the ability of an electrical signal to carry information

reliably and resist the effects of high-frequency electromagnetic interference
from nearby signals.

The term Signal Integrity (SI) addresses two concerns in the electrical design
aspects � the timing and the quality of the signal.
The goal of signal integrity analysis is to ensure reliable high-speed data
transmission.

Since many SI problems are directly related to dV/dt or dI/dt, faster rise time
significantly worsens some of the noise phenomena such as ringing, crosstalk, and
power/ground switching noise.

Systems with faster clock frequency usually have shorter rise time, therefore they
will be facing more SI challenges.

Issues in SI
X-Talk Noise
Delay
IR ( Voltage ) Drop in power lines
Ground bounce
EM / Electron migration

Crosstalk is the undesirable electrical interaction between two or more physically

adjacent nets due to capacitive cross-coupling.

The one creating X-talk is called Aggressor & the one receiving it is called
Victim.

As integrated circuit technologies advance toward smaller geometries, crosstalk

effects become increasingly important compared to cell delays and net delays.

Problems caused by X-Talk

X-talk noise between neighboring signal wires can cause two major problems that
affects the operational integrity of IC designs:

1. X-talk Delay.

2. X-talk Noise.

The timing impact of an aggressor net on a victim net depends on several factors:

amount of cross-coupled capacitance

Relative times and slew rates of the signal transitions

Switching directions (rising ,falling)

Combination of effects from multiple aggressor nets on a single net.

X-Talk Delay

X-talk delay changes the signal propagation on some of the nets, reducing
achievable clock speed.

Crosstalk Induced Delay Change�Setup Failure

Congestion
Too many neighbours

Optimization creates nets with low noise immunity

Downsize drivers in non-critical paths
Place far apart
Route with long routes

Crosstalk Repair Techniques for Glitch and Delay

Victim driver sizing, buffer insertion, aggressor downsizing

Rip-up aggressors and victim spacing

Soft spacing, victim rerouting

Shielding

Fixing Strategies

Buffer insertion may fix crosstalk noise and other problems, but may not have space
at the right spot for extra buffer and wires.
Gate sizing may fix crosstalk and other problems, but may introduce new
aggressor/victim nets
Spacing is usually very effective in the initial few P&R�fixes iterations but takes
routing resources and detouring
Shielding (hard spacing) can be too expensive if applied globally
Rip-up & reroute with spacing is usually very effective for glitch noise victims
that are not timing critical
Rerouting aggressors is usually very effective for both crosstalk glitch and delay

SI Prevention techniques in PnR stage:

Placement-based prevention
Placement stage: congestion optimization (congOpt)

Routing-based prevention
Routing stage: coupling cap reduction in NanoRoute
(routeWithSiDriven, routeWithTimingDriven)

Note: Setting reasonable slew limits during physical synthesis has been shown to be
very effective in reducing crosstalk.

Placement-Based Prevention

Congestion Optimization for Crosstalk Reduction (congOpt)

Move cells/placement
to reduce wire congestion
and coupling

Routing-Based Prevention

Increase spacing to reduce

coupling capacitance

Soft spacing to reduce

parallel wire lengths

Net reordering to
reduce coupling

Layer switching to reduce

coupling capacitance
Double Switching

Double-switching crosstalk effects can be introduced if the victim is transitioning

very slowly.
This can happen if the aggressor produces such a bump on the victim that we have a
double switching: the waveform crosses the delay threshold twice.
This may not be flagged by update_noise, as the victim is not static. Also, users
want to be warned because if this happens in the clock tree, for example, it can be
really destructive for the data.
You may have false clocking if this happens on the inactive edge of the clock or
double clocking if this happens on the active edge of the clock.