Details

Published: Friday, 12 October 2018 04:33

Hits: 594

PDK (Process delivery kit) link: http://pdk.dal.design.ti.com/ (at Ti, we have pdk dir, which is used by our flow. All pdk info is kept in PCD (Process Control doc) for each process. Strawman PCD is built on simulated/extracted data (no Si data), Beta PCD is after the process baseline has been set and Production PCD is after verifying it with Si.

OA (open Access) PDK is now being used everywhere, which has database in OA format. OA format and API is developed by Si2 (Si2.org) and is free and open to everyone.

Mentor (process tech info)  website: https://mentor.itg.ti.com
----------

FreePDK (from NCSU): base kit - http://www.eda.ncsu.edu/wiki/FreePDK
FreePDK (from Nangate): generic open cell lib based on 45nm.

Free CAD tools are here: http://opencircuitdesign.com/index.html

------------------
Scribe Line Structures: Test structures needed to verify the PCD.

-------
manufacturing grid : The manufacturing grid is the grid on which all design-rules are based. No shape may exist in the database that is not aligned to this grid. The manufacturing grid is 2.5 nm for this 45nm process on FreePDK45. Higher the MG, lower the cost of mask tooling.

LBC7: For TI LBC7 process, MG is 0.050 um, even though min coding increment of 0.10um is required. This is to accommodate centerpoint and centerline figures. Sizes that are not on grid, are snapped to nearest grid. final mask size adjust is a combination of the design size adjust, which adjusts sizing relative to the minimum grid size, the selective size adjust, and the process size adjust which compensates for process manufacturing offsets, amd may be different for different layers. A shrink of 0.9 is done from the Drawn CD to the final Reticle (mask) CD for LBC7.

------------------------
CDB PDK Dir: This has all lib data (schematic, layout, etc) in cadence database (cdb) format.
-----------
/db/pdk/<Process_name> (Process_name can be for fab process, packaging, foundry, etc)
lbc*/tsmc*/umc* => all fab process
bicom* => all bicmos info
foundary =>
sample_pdk =>
copper => metal/via rules put seprately here, since metal rules not mainatined by lbc7,etc process platform.
packagaing => all pkg rules here,  since pkg rules not mainatined by lbc7,etc process platform.

--------
Most used Process_name : lbc7, lbc8(shrinking factor of 0.35 applied to drawn design for lbc8), tsmc*, umc*, bicom*

LBC7 dir: /db/pdk/lbc7/rev1/

DIGITAL LIB section
--------------------
digital lib dir: diglib/msl270/r3.0.0/. In this we have following dir:

verilog dir: all verilog models here
------------
verilog/models/*.v: models for all stdcells in terms of verilog primitives (nand, or, not, pullup, etc).  It has also defines for TI_functiononly, TI_openhdl, etc.
For ex: AN210.v has the gate modeled as:
and #0 TI_AND_PRIM0 ( Y , A , B ) ; //Verilog Structure section (in terms of gate prims). and gate has 0 unit delay. we define gate delay as 0 and delay mode as "distributed" and timescale as 1ps in TI_functiononly mode, so that delays are added for each gate in ps. This doesn't affect much as delays are already 0, so total delay is also close to 0ps. However for non function mode, we define module delay as #ns, and set delay mode to "path" delay so that module delays are used directly. In non function mode, we define AN210 gate delay as #0.01 (equals 0.01ns with 1ns timescale directive). However, from ATD page, this gate has delay of about 1ns. So, delay not defined correctly. Doesn't matter as we don not use this delay value. We use the delay that comes directly from the gate delay in sdf file.
For delay cells (as DLY03), we model delay as 3 time unit delay (3ns for 1ns timescale).
For filler cells (as SPAREPOLYCAP32), we don't have anything in module defn.

verilog/verilogsrc(ams)/msl270_lbc7_*pin/*.vams : verilog analog models for all std cells. (4 variations of same cell: 2pin, 3pin, iso_2pin, iso_3pin). Note this wasn't there for normal verilog models as they don't model this variation in structure. 2 pin has VDd/VSS pins. 3pin and iso_2pin has additional PBKG pin. iso_3pin has further additional VSS_ISO pin.
Ex: AN210.vams => has 2 extra pins VDD,VSS as electrical pins (has additional PBKG pin for 3pin variation), and A,B,Y have sensitivity to VDD/VSS. rest of the structure section is same.

synopsys dir: all CORE.lib and CTS.lib here (same for all 4 variations of std cells)
--------------
synopsys/src/MSL270_*.lib: src lib files for various PVT corners for both CORE and CTS
synopsys/bin/MSL270_*.lib: binary .db files for various PVT corners for both CORE and CTS (derived from .lib files)

vdio dir: all lef and cap/res files
---------
vdio/lef/msl270_lbc7_tech*.lef: tech lef file. has metal/via width/spacing/antenna_ratio info. Diff tech files for 2/3/4 layer
vdio/lef/msl270_lbc7_core_*pin.lef: std cell lef files for all 4 variations (2pin, 3pin, iso_2pin, iso_3pin). For each std cell, lef file has physical metal layout info for i/p, o/p pins and VDD/VSS and/or BLKG/VSS_ISO. This doesn't have internal guts of cell, but just the pin and blkg info needed for routing.
vdio/captabl/2lm_maxC_maxvia.capTbl:  use these LUT values for calc timing, instead of doing full extraction using Maxwell's eqn. defined for 2/3/4 metal layers for max/nom/min Cap/Res. has Cap table (which has cap values for diff width/space for diff metal layers), and various metal/via process variations (min Width/Space, height, thickness, resistance, thermal coeff,etc)

variation dir: all cdb data for all stdcells (schematic, symbol, layout, verilog)
--------------
msl270_lbc7_2pin/<std_cell>/layout|schematic|symbol|verilog|srcVerilog|srcVerilogAMS : similarly for iso_2pin, 3pin and iso_3pin. => note: schematic dir has sch.cdb and master.tag(master.tag just has sch.cdb written in it), layout dir has layout.cdb and master.tag((master.tag just has layout.cdb written in it), etc. everything is stored as cdb(cadence data base).

PAL dir: gdsii data for all stdcells kept here
-------
PAL/pml30CorePall/CORE/gdsii/CORE.fram.gdsii => for CORE cells
PAL/pml30CorePall/CTS/gdsii/CTS.fram.gdsii => for CTS cells

ANALOG DIR section
-----------------

drc rules: rules/assura/2010.12.22/
Assura is physical verification tool (both lvs/drc) from cadence. Its integrated with extraction tools.
drc.releaseNotes.txt => find all info related to drc files (drc rules are usually in drc.rul file, which incudes files from "files" dir).
copper rules are in /db/pdk/copper/rev1/rules/assura/*
packaging checks are in /db/pdk/packaging/rev1/rules/assura/*

qrc/ => has qrc tech files (in binary format) for metal/via layers.
QRC is 3D full-chip parasitic extraction and analysis tool from cadence. it includes an integrated field solver and does an RLCK extraction for cells, RF, analog, mixed signal, custom digital, etc.

------------------------
OA PDK Dir: This has all lib data (schematic, layout, etc) in open access database (oa) format.
-----------
/db/pdk/<Process_name>/<rev>/
Let's look at lbc8 dir: /db/pdkoa/lbc8/2011.06.26/

In this, we have following dir:
cdk/          copper/       diglib/       esdlib/        models/       releaseNotes/ rules/

DIGITAL LIB section for diglib dir:
--------------------
digital lib dir: diglib/pml30/. In this we have following dir:

verilog dir: all verilog models here, same as in CDB PDK.
synopsys dir: all CORE.lib and CTS.lib here. same as in CDB PDK.
vdio dir: all lef and cap/res files. same as in CDB PDK.
PAL dir: gdsii data for all stdcells kept here. same as in CDB PDK.
OA db dir: all OA data for all stdcells (schematic, symbol, layout, verilog)
ex: pml30_lbc8_2pin/BU110/ has following subdir:
*.oa contains actual data in oa format, while master.tag is ascii file with just the name of oa file that contains data. NOTE: even .oa files are not large, as they just have references to transistor, vias, metal lines, etc and don't contain the actual drawing.
schematic: sch.oa,    master.tag, data.dm
symbol:    symbol.oa, master.tag
layout:    layout.oa, master.tag
abstract:  layout.oa, master.tag => similar to layout dir, but is slightly smaller in size.
module, srcVerilog, srcVerilogAMS:  all these dir have same content =>  netlist.oa, master.tag, verilog.vams.

-------------------------------------------

Details

Published: Friday, 12 October 2018 04:31

Hits: 1182

ECO Flow:
-----------
Many types of ECO flow supported in Encounter L/XL/FE-L/FE-XL (Enc version 7 and above). GXL and conformal ECO have additional support for ECO. GXL supports ecoRemap, while conformal supports conformalECO.

These ECO flows supported in Enc:

1. Pre-Mask changes from ECO file => note: eco file generates a new verilog netlist, which is used by subsequent steps.
2. Pre-Mask changes from new verilog netlist =>
loadConfig old.conf, set rda_Input(ui_netlist) "newchip.v", ecoDefIn oldchip.def, ecoPlace, ecoRoute, ..
3. Pre-Mask changes from new DEF file => similar as 2 above, as def file contains new logical cells/connections. An ECO file is generated by ecoCompareNetlist, loadECO loads this eco file, and then follow as in 2.
4. Post-Mask changes from new verilog netlist => use -postMask for ecoDefIn to minimize mask changes. Otherwise same as pre-mask.
5. Post-Mask changes using ECO spare cells or GA(gate array) cells. => preferred method at TI

-----------------------------------
2 methods for generating new eco netlist: (we've the new 1p1 rtl with our fixes in)
1. Manual: Here, we look at 1p0 netlist in debussy and figure out where to place gates in 1p1 netlist. Then, we an modify netlist in 2 ways: (In both of these ways, new netlist only has new gates added with appr connections. These new gates are not connected or matched to spare gates as the VDIO tool is supposed to do those connections).
 A. eco directive file: create eco_directive file that has the list of gate changes and connections. What this does is that it adds new gates with appr connections to netlist. We should look at this new netlist generated before we move to VDIO. Then we read in this file in VDIO.
 B. directly modify old ntlist: We directly modify old netlist and then read in the new netlist. This new netlist has new gates added with appr connections. It's similar to above option except that we don't use eco directives.

Then we run VDIO which reads in the old def and the new netlist (either eco directive or new verilog netlist). The tool then matches the changes with spare gates, places them and routes it to create lec clean netlist and def. then we run final checks, timing, etc. We discuss this methos below.

2. Conformal: Here we use conformal lec. We modify rtl for 1p1. Then we run thru Synthesis to create 1p1 netlist. Then we run conformal lec which diffs old 1p0 PnR netlist with newly synthesized 1p1 netlist. It creates a patch, and then generates a new netlist with the changes. This new netlist uses spare cells, so spare cells are already mapped to new logic within netlist (you'll see that spare cells are removed from the spare module). In manual option above, no spare cells were mapped to new logic. Then we go thru regulat PnR flow to accomodate this patch in VDIO. We dsicuss this method in later section marked conformal_eco.

NOTE: Regardless of which method we use for generating netlist, we have to run ecoDesign in VDIO (super cmd which does everything for us). We can also make changes directly to verilog and run ecoDesign.
#ecoDesign cmd is supported in all Enc version, so use ecoDesign. It takes EDI System database and a modified netlist as input and performs ECO operations. It restores the design, examines the changes in the new netlist, and automatically implements the required  changes  with ecoPlace and ecoRoute. deffile is not there in enc.dat database, but it's OK as rout.gz and place.gz has that info.
ecoDesign -postMask -modifyOnlyLayers <MLb>:<MLt> -spareCells <spareCellName> -useGACells <GACoresite> <old_design.enc.dat top_cell new_netlist> => Use -noEcoPlace -noEcoRoute if we don't want to ecoplace and ecoroute with this cmd, but want to do it separately.
 
---------------------------------------
Manual ECO (non conformal):
---------------------------------------
Inreactive ECO: provides manual inc updates to design.
#we can also do an interactive ECO by going to optimize->interactive ECO for PreMask changes. We can add repeater(ecoAddRepeater), upsize/downsize instances(ecoChangeCell), delete buffers(ecoDeleteRepeater), display buffer tree to modify it(displayBufTree)

#For PreMask/PostMask ECO, we can also do file->ECO design. Then goto Place->ECO Place for placement. then do routing by route->Nanoroute (choose ECO route) => instead of doing it on the encounter cmd line

------------------------------------
ECO changes using ECO spare cells (post mask):
------------------------------------
Flow for Making changes from ECO file: (preferred method at TI)
load old config file => load new_change.eco file (modifies old verilog to get new verilog) => ecoDefIn old_def file => specifySpareGate => ecoPlace => ecoRoute =>save design

#0. make new(1p1) dir and cp files from old(1p0) dir & then change mode:
cp -rf /db/YELLOWSTONE/design1p0 /db/YELLOWSTONE/design1p1
chmod 777 -R /db/YELLOWSTONE/design1p1

1. Update RTL in Source dir.
#run debussy in old dir on gate level netlist to look at gates to make changes in gate level netlist
cd /db/EPSTINGRAY/design2p0/HDL/Debussy.
Run create_symbols if *.lib++ dir not present
run_debussy => runs debussy with/without any options. If with options, "-f <gate_netlist>". If w/o options, bring up debussy, click  File->Import design, Put the file name (/db/DRV9401/design1p0/HDL/FinalFiles/digtop_VDIO.v) in bottom box, and then click Add, then OK.

2A. Run ECO flow in VDIO after running encounter (tcl/eco_flow.tcl => this file has all cmds in it for eco flow)
NOTE: to add/delete any pins, use PinEditor in VDIO gui (Edit->PinEditor). Do this before running ecoplace. Else, new pins are added at origin (0,0). To edit/add pin, you can also use "editPin" cmd:
#editPin -pinWidth 0.4 -pinDepth 0.4 -fixOverlap 1 -side Left -layer 3 -assign 0.0 367.85 -pin RX_SEL[4]

1st option: run ecoDesign with no place and route. This super cmd is explained above.
-----------
ecoDesign -postMask -noEcoPlace -noEcoRoute -spareCells spr_*/spr* dbs/filler/filler.enc.dat digtop /db/HAMMER_OA/design1p1/.../digtop_final_route_eco.v

2nd option: do it old way of reading in 1p0 config, 1p0 def and 1p1 directives.
----------
loadConfig dbs/filler/filler.enc.dat/digtop.conf => load previous config file for VDIO. Change dir path (set cwd) to present dir in this file. Config file only has path locations of digtop.v (note that even though this is verilog file for filler, it doesn't have any filler cells in it, as they don't exist in tech .lib file), tech .lib and tech .lef files. It doesn't have def file info, so we have to do DefIn to read def file.

# Read 1p1 eco_directives => This adds new cells, makes new connections etc to 1p0 verilog file to make new 1p1 file.
source tcl/eco_directive_1p1.tcl
# Or other option is to modify old netlist manually to create new netlist, and read that new netlist.
#set rda_Input(ui_netlist) "/db/.../digtop_final_route_1p1.v" => This overwrites the "i/p netlist" in loadConfig above
#commitConfig => This commits the config file so that all parameters spec above are applied


# ECO DEF in the old DEF file. since new verilog design is in memory and we are reading old def file, tool can figure out new changes for 1p1.
#-useGAcells GACoresite => specifies GA Core site to use for gate array eco. In cell lef file, it looks for cells with "SITE = GACoresite name" specified here. Regular stdcells have "SITE CORESITE", while GA cells have "SITE GACORESITE". That's how tool knows which cells are ECO cells that can be built from filler cells. this cmd implies "postmask" mode.
#-suffix _SPARE_DELETED => Appends the specified suffix to cells that appear in the DEF file but have been deleted in the new netlist. Default: _SPARE
#-postMask => When used with -postmask option, tool can only change nets, not cells. tool checks for cells that exist in memory but not in def, and marks them as unplaced. It then maps these to fillers/spares during ecoPlace. Modified nets which are found in both memory and DEF file, but whose connections are different, are processed during ecoRoute. When -postMask option is not used, it implies pre-mask mode, which can change cells too (it can put any new cell in empty space of fillers).

ecoDefIn -postMask -reportFile ecoDefIn.rpt /db/YELLOWSTONE/design1p0/HDL/FinalFiles/digtop/digtop_final_route.def => Restores physical information from an old design and compares this information with the new design (modified verilog using directives bove). It gives report on screen saying what new inst/net were added, etc (also dumps it in report file ecoDefIn.rpt specified above).

# Specify Spare Gate (-inst specifies instance name and NOT module name) This is needed only if we are not using gate array as spares (i.e. GA cells are not specified above).
specifySpareGate -inst spr_*/*spr_* => use any spare cell in spare modules.
specifySpareGate -inst spare_*/spare_inv_* => if you want to use only inverters
specifySpareGate -inst I_scan_iso_out/g1453 => This specs any extra gate (unused) as a spare cell. This is useful when we have some usuned gates in netlist that we want to use for eco purpose.

After running one of the options above, run ecoPlace and ecoRoute.
-------------
ecoPlace -useSpareCells true

#user intervention to change spare cell mapping. Provide instance name and NOT module name
ecoSwapSpareCell i_inst/eco_inst_an2 spr_3/spr_gate65 => gate "spr3/spr_gate65" from spare cell module is mapped to i_inst/eco_inst_an2. Here eco instance an2 was already mapped to some spare cell, but we didn't like the mapping, so we swap this cell with this other spare cell. Now, spr_gate65 becomes eco_inst_an2, and eco_inst_an2 becomes spr65

# ECO Route new netlist. If only certain metal layers, specify them
ecoRoute -modifyOnlyLayers 1:3
setNanoRouteMode -quiet -drouteFixAntenna true => set this if antenna errors still remain
ecoRoute -modifyOnlyLayers 1:3 => rerun eco route if errors are still there

#ecoRoute may not be able to route because it doesn't touch non-eco nets. Rerun ecoRoute until all errors are fixed. If errors still remain, we can run Nanoroute directly in eco mode. However, ecoRoute is still preferred to be run since it does preprocessing which minimizes routing changes. Cmds below do the same job as ecoRoute above, but can move non-eco nets too.
setNanoRouteMode -quiet -drouteFixAntenna false => optional, improves routing.
setNanoRouteMode -quiet -routeWithEco true
setNanoRouteMode -quiet
#setNanoRouteMode -routeEcoOnlyInLayers 1:3 => can use this single cmd or use these 2 cmds:
setNanoRouteMode -quiet -routeBottomRoutingLayer 1 => bottom routing layer has to be the lowest layer on which there are existing nets. Otherwise error says: "conflict with already existing routed wires on layer x-1"
setNanoRouteMode -quiet -routeTopRoutingLayer 3 =>  similarly, top routing layer has to be the highest layer on which there are existing nets.
setNaonoRouteMode -quiet routeSelectdNetOnly false
routeDesign -globalDetail => instead of this, we can also use: globalDetailRoute 100.0 1200.0 350.0 600.0 => specify co-ords if you want to reroute within a certain area. Although globalDetailRoute and "routeDesign -globalDetail" seem to be doing the same thing, they result in different results. "routeDesign -globalDetail" gives better results

#NOTE: keep on rerunning "routeDesign -globalDetail" until it passes all drc. (set antenna fix to false)
#Do not use the globalRoute command in ECO mode (use globalDetailRoute as shown above. globalRoute only performs global routing, while detailRoute only performs detailed routing).
#If more than 10 percent of the nets are new or partially routed, run full global and detailed routing instead of ECO routing (set routeWithEco false so that routing is done from scratch. Most of the times, it fixes all routing issues.)

#to route only a list of nets, which are in selectnets.txt file (one net per line)
set NET_FILE [open "selectnets.txt"]
foreach i [ read $NET_FILE ] {
 selectNet  $i => can only select one net at atime. wildcards are allowed
}
close $NET_FILE
#route these nets
setNanoRouteMode -routeSelectedNetOnly true => routes selected nets only. default is false (routes all nets).
routeDesign -globalDetail

#set_attribute -net <netName> -skip_routing true => to skip routing on selected nets, useful when we don't want to touch nets which are on layers above or below the eco routing layers. Since we can only specify one net_name, we have to use this cmd multiple times for multiple nets. However, this is dangerous to use, as set_attribute ties the attribute with that net, and it is saved with the database. so, next time encounter runs on this database, this attribute is still there, unless we set attribute to false.

# Save design
saveDesign ./dbs/eco_filler_1p1/eco_filler_1p1.enc
checkDesign -noHtml -all -outfile ./dbs/eco_filler_1p1/eco_check_design.rpt => checks design for all issues. Necessary as final_check.tcl later doesn't check for floating nets, etc.

2B. with eco_flow.tcl, we saved the new db into filler.enc. So, we need to run steps beyond filler, to run all checks and get the final netlist.
#Note: we should run timing as extra step since we should make sure design is timing clean, before we run PT.
timeDesign -signoff -reportOnly       -prefix digtop_post_route_signoff
timeDesign -signoff -reportOnly -hold -prefix digtop_post_route_signoff

#run post route opt if timing not met or any other violations
setOptMode -effort high
optDesign -postRoute -hold -prefix digtop_post_route_opt

#now run steps beyond filler
source tcl/final_check.tcl => to verify conn, etc.
source tcl/export_final.tcl => run extractRC to generate spef, get final verilog and defout.

3. run Formality to check RTL against ECO netlist. (For ECO netlist, use verilog generated above)
4. Rerun PT to check if timing is ok
5. Rerun all RTL sims and gate sims
6. Regenerate Tetramax patterns and rerun gatesims
7. Import Netlist and DEF to Cadence for top sims and tapeout

------------------------------------
ECO changes using gate array cells (post mask):
------------------------------------
When we use GA cells, we don't have any GA cells in netlist. For doing ECO change, we modify the original netlist to add ECO cells ending in E (made from GA cells) , and then in the layout, appr filler cells are connected to form these GA cells.
These ECO cells have a prefix E at the end to indicate that they are GA cells (i.e IV110E). These cells are generated from base filler cells (FILLER5, FILLER10, etc) which are present in layout. These filler cells were inserted in layout during the filler step (where these base filler cells are filled first and then any remaining spaces are filled with Dcap fillers). Tool figures which E cells can be replaced with which FILLER cells is by looking at physical of cells. NOTE: filler cells are never removed from design. Tool just picks up appr space where ECO cell can be placed, and makes metal connections to reflect the change. Filler cells are still unmodified under the ECO cell.

1. first make sure that ECO filler cells were put in 1p0 design using these 2 cmds:
addFiller -cell  FILLER5 FILLER10 FILLER15 FILLER20 FILLER25 FILLER30 FILLER40 FILLER50 FILLER55 -prefix FILLER_ECO
addFiller -cell  SPAREFILL1 SPAREFILL2 SPAREFILL4 SPAREMOSCAP3 SPAREMOSCAP4 SPAREMOSCAP8 -prefix FILLER_NORMAL

2. get the i/p netlist from 2p0 and modify it manually to add the new eco cells (ie IV110E, AN210E, etc) that need to be added, connecting them appropriately. name it as dig_top_noPhys_2p1.v
ex:    IV120E eco2_2p1_inv27 (.Y(eco2_2p1_prdata_27_bar), .A(eco2_2p1_prdata_27));

3. Once done with changes, read the old layout db and new netlist
ecoDesign -postMask -noEcoRoute -noEcoPlace dbs/handoff_20121106.enc.dat dig_top /data/PROJECT/.../dig_top_noPhys_2p1.v => we don't do eoPlace and ecoRoute as we do it in separate steps

4. do ecoplace using GA cells
ecoPlace -useGAFillerCells "FILLER55 FILLER50 FILLER40 FILLER30 FILLER25 FILLER20 FILLER15 FILLER10 FILLER5" => these filler cells should not have FIXED attribute in def file, else tool would not pick these for replacement, and will try to move around other std cells (which is incorrect).

5. If placement causes any errors (like overlapping placement etc), fix it by deleting and moving
eg: deleteInst FILLER_pdLogic_18457 (delete and then move/add filler cells manually and place them at correct location)

6, do ecoRoute
ecoRoute

7. If ecoRoute doesn't fix all routing violations even after multiple attempts, do full blown routing. Can be done from GUI also: Route->NanoRoute->Route. Unselect ECO ROute and select "Global Route, Detail Route".  Check "Fix Antenna". If you want to fix net by net, select "selected nets only" and select on those nets on encounter layout gui.
   setNanoRouteMode -quiet -routeWithEco true => may be set to false if we want to do full blown route
   setNanoRouteMode -quiet -drouteFixAntenna true
   setNanoRouteMode -quiet -routeTopRoutingLayer default
   setNanoRouteMode -quiet -routeBottomRoutingLayer default
   setNanoRouteMode -quiet -drouteEndIteration default
   setNanoRouteMode -quiet -routeWithTimingDriven false
   setNanoRouteMode -quiet -routeWithSiDriven false
   routeDesign -globalDetail -viaOpt -wireOpt

8. confirm location of newly added cells and then save new db
 selectInst *_2p1*
 saveDesign ./dbs/handoff_eco_2p1

9. Now run steps 2B and beyond (step 2B, 3-7) as shown in Normal filler cell flow. Run timing, optDesign and then steps beyond filler.
----------------------
ECO directives (old way):
---------------------
to make new connections, we use the 5 cmds listed below in tcl/eco_directive_1p1.tcl.
NOTE: all cmds specify instance name of any module, and NOT the module name itself. However, if we use -moduleBased, then we specify module_name itself. As module_name is unique for each instance in the synthesized netlist (see final synthesized netlist format desc above), it works OK.

addModulePort: To add port or bussed port to a module. Module should not have net with that name. Ex:
addModulePort i1/i2/i3 p1 input => adds i/p port p1 on instance i3(in hier i1/i2).

attachModulePort: Attaches a port in the specified instance (or top level) to a net. Seems like this cmd attaches ports to nets outside the module (i.e the net has to be at a higher level of hier than the port). This cmd doesn't detach anything, so detachModulePort cmd also needed. (this is different than attachTerm which does detach automatically)
attachModulePort i1/i2/i3 p1 i1/i2/n1 => connects port p1 on i1/i2/i3 to the net i1/i2/n1.

detachModulePort: Detaches the net connected to the specified port on the specified instance.
detachModulePort i1/i2/i3 p1 => detach port p1 from module i1/i2/i3

addNet: Adds a net to the design. The net can be logical or physical. Ex:
addNet i1/n1=> adds net i1/n1

addInst: Adds an instance and places it in the design. Ex:
addInst -cell BUF1 -inst i1/i2 -loc 100 200 => adds buffer instance i1/i2 at location 100, 200. (-cell specifies master of instance while -inst is the actual instance)

attachTerm: Attaches a terminal to a net. If the terminal already connects to a different net, the software first detaches the terminal from the current net, then attaches it to the new net. Previously we used to use: detachTerm to detach the existing net, but not needed any more. Ex:
attachTerm i1/i2/i3 in1 i1/i2/net26 => attaches terminal in1 of instance i1/i2/i3 (in1 is a port of i3) to net i1/i2/net26

NOTE: addModulePort and attachModulePort cmd can be avoided by using attachTerm which is more generic cmd.
#For ex, to connect internal gate o/p within one module to internal gate i/p within another module, use this:
attachTerm  spi_regs/eco2_inv A clock_reset_gen/n37 => attaches terminal A of inv in "spi_regs" module to net n37 in "clock_reset_gen" module. Note, this cmd first figures out the port thru which pin A of inv can be accessed, and then connects the net to that port. So, if there are multiple connections to that port, all of them will get conncted. In essence, this cmd connects a port to a net. If the port doesn't exist, it creates a port in the module (spi_regs) with that netname (n37).

#alternative way would be to have ports and then connect them
addModulePort     spi_regs  eco2_spi_inp input
addNet     -moduleBased digtop eco2_rst_connect
attachModulePort  spi_regs  eco2_spi_inp eco2_rst_connect => created port for "spi_regs" module and connected net to it.
addModulePort     clock_reset_gen eco2_clk_reset_out output
attachModulePort  clock_reset_gen eco2_clk_reset_out eco2_rst_connect => created port for "clock_reset_gen" and connected same net to it.
attachModulePort  clock_reset_gen eco2_clk_reset_out clock_reset_gen/n37 => connects the other end of port to net n37

Steps: to do ECO fix, first find the net name to where u want to insert ur logic. Use debussy on gate verilog and find the net on schematic of that module. If o/p net of new logic goes to fewer instances compared to i/p net of new logic, leave i/p net as existing net name and make o/p net as new net. Do vice versa (i.e if o/p goes to more instances, leave o/p net as existing net and make i/p net as new net)
Ex: attach an inverter to input of flop
#-moduleBased <module_defn_name> sets the module defn_name so that hier is not required. Note we specify module_defn_name and NOT module_instance_name. As module_name is unique for each instance in the synthesized netlist (see final synthesized netlist format desc above), it works OK.
addInst    -moduleBased spi_regs_test_1 -cell IV140 -inst eco1_inv_before => add inx instance
addNet     -moduleBased spi_regs_test_1 eco1_reg_input => add new net to connect to o/p of inx
attachTerm -moduleBased spi_regs_test_1 eco1_inv_before A n610 => attach inx i/p to existing net n610 (we chose i/p since n610 might be driving multiple loads)
attachTerm -moduleBased spi_regs_test_1 eco1_inv_before Y eco1_reg_input => attach inx o/p to new net.
attachTerm -moduleBased spi_regs_test_1 vbg2_op_out_reg_2 D eco1_reg_input => attach FF D i/p to new net. This causes exising net n610 to disconnect from D i/p of FF. If n610 wasn't connected to any other o/p, it would become floating.

---------------------
conformal ECO:
-------------------
Here, conformal generates the patch that can be used in VDIO. Run LEC:
lec -12.10-s400 -gui -xl -ecogxl -log ./logs/eco.log -dofile scripts/eco.do => -ecogxl enables post mask eco.

eco.do file:
-----
1. set common settings:
set log file eco.log -replace
usage -auto

2. Read library: (note that .liberty files are read, and NOT verilog models)
read library -both -liberty /db/pdkoa/.../MSL270_N_27_3_CORE.lib
read library -both -liberty /db/pdkoa/.../MSL270_N_27_3_CTS.lib  -append

3. Read design. Read 1p0 final PnR netlist as golden and new synthesized netlist as revised.
#NOTE: spare cell modules are missing from revised netlist since they are added in PnR flow
read design -verilog -golden  -sensitive -root digtop /db/HAMMER_OA/design1p0/HDL/FinalFiles/digtop/digtop_final_route.v
read design -verilog -revised -sensitive -root digtop /db/HAMMER_OA/design1p1/HDL/Syhnthesis/digtop/netlist/digtop_scan.v

4. set eco directives:
A. enable ECO meodeling directive. It's necessary to have this for eco. Other directives are optional.
 1. set flatten model -eco => prevent default flatten modeling from removing important info that is vital to correlate the ECO change back to original netlist. It's a macro that enables a number of related modeling options such as "set flatten model -keep_ignored_po -noremove_real_buffer" etc.
 2. set flatten model -enable_analyze_hier_compare => analyze hier bdry (module bdry) comp of flattened design. Needed to do hier comparison later.

B. other directives:
set flatten model -Latch_fold => if needed
set flatten model -seq_constant => if needed
set flatten model -gated_clock => if needed Gated clock control

#scan shift en turned off since scan chain may be different in new synthesized netlist. scan_mode still allowed both 0/1 values as scan_mode signal is just like any other logic signal.
add pin constraints 0 scan_en_in     -golden =>
add pin constraints 0 scan_en_in     -revised =>

#specify any new pins added/deleted at top level
#ex: new pin new_in2 added at top level digtop which also goes into submodule ctrl. so, we add this eco pin in both modules for golden (since they don't exist in golden. If we don't specify ports for modules/sub-modules, then tool is not able to add it for golden, and so reports them as unmapped points.). -input specifies i/p pin, while -output specifies output pin (default is input).
NOTE: We specify module definition name and NOT instance of module, as pin needs to be added on module defn.
add eco pin scan_out_iso  new_in2 -input -golden => use delete eco pin for deleting pins.
add eco pin scan_out_iso  new_out2 -output -golden => scan_out_iso is a submodule but still referenced as module since conformal flattens the design.
add eco pin clock_reset_gen_test_1 new_out2 -output -revised => clock_reset_gen_test_1 is the module defn name in revised netlist.

set mapping method -unreach

5. analyze hier bdry and do hier comaparison (lec mode). It should show non-eq points. Then create patch based on that.
set system mode lec
#while doing hier comp, hier_analyze.do file is generated which has all cmds for hier comparison. ecopins.do file is also generated which has eco cmd for adding pins to modules which need it in new netlist
analyze hier_compare -dofile hier_analyze.do -replace -constraints -verbose \
                     -threshold 0 -noexact_pin_match -noexact_module_match \
                     -eco_aware -input_output_pin_equivalence -function_pin_mapping -ecopin ecopins.do

add compared points -all
compare => should show non eq points
report statistics => reports

compare eco hierarchy => we break down comparison to sub-module level
report eco hierarchy -noneq -verbose
analyze eco -hierarchical patch.v -replace -ecopin_dofile ecopins.do -preserve_clock => creates a patch file which has only the gate changes needed for 1p1

6. apply patch, then optimize patch based on spare/GA cells, then write final netlist.
set system mode setup
dofile ecopins.do => add pins needed to modules.
#apply patch: -auto Automatically reads in and applies all patches that were created with the ANALYZE ECO cmd in the current session. (-keephierarchy specifies that the ECO changes will be put in a sub-module. Do not use this option, as that will cause problems in VDIO)
apply patch -auto => shows patch file being read and applied.

#### this section optional = to check if patch is good
set system mode lec
add compare point -all
#delete compare point A_REG[0] => To omit certain non-equiv points from eco analysis
compare  // this checks if patch if good before optimization, design should be equiv (1p0 vs patch)
write eco design -replace -newfile digtop_tmp_eco.v => IF we write out netlist, it will have separate eco modules which will have the new instances/connections. Later, after doing optimize patch, we get netlist which has no separate eco mdules, but the changes are within the existing modules. The netlist with no separate eco modules is the one that can be used in VDIO, else it will give an error for having extra modules.

NOTE: we could stop here and use the netlist generated above in VDIO. However, there are 2 problems. First, the netlist has extra modules, and secondly it has cells in eco_modules which may not be present in spare_cell module, so these will need to be substituted by cells which are actually present in spare_cell module. So, optimize patch step needed.

####
set system mode setup
###spare/GA cells added for Post-mask eco only. For pre-mask, ignore this section
add spare cell -freedcell => add any freed up cells to be used as spare cells
add spare cell -deffile  /db/HAMMER_OA/design1p0/HDL/FinalFiles/digtop/digtop_final_route.def -sparecell spr_*/spr* => this adds all spare cells to be used for eco
#add spare cell -deffile  /db/HAMMER_OA/design1p0/HDL/FinalFiles/digtop/digtop_final_route.def -sparecell GAFILL* => this adds all GA cells for eco
#delete spare cell -sparecell spr_*/spr_AN2* => This disables any specific spare cell that we don't want to use
report spare cell => This shows all avilable freed cells as well as spare cells
###

#optimize patch does the actual mapping to get new netlist generated
optimize patch -verbose  -usespare -workdir WORK \ => for postmask using spare/GA cells, use -usespare
-library "/db/pdkoa/.../MSL270_N_27_3_CORE.lib \
          /db/pdkoa/.../MSL270_N_27_3_CTS.lib" \
-netnaming eco_net_%d \ => within each module, new eco nets named as eco_net_1, eco_net_2, etc
-instancenaming eco_instance_%d \ => within each module, new eco instances named as eco_instance_1, eco_instance_2, etc
-rcexec "rc -12.20-s014" \ => version of rc to use
-sdc /db/HAMMER_OA/design1p1/HDL/DesignCompiler/digtop/sdc/hmr_constraints.sdc \
-def /db/HAMMER_OA/design1p0/HDL/FinalFiles/digtop/digtop_final_route.def \
-lef /db/pdkoa/.../vdio/lef/msl270_lbc7_tech_3layer.lef \
     /db/pdkoa/.../vdio/lef/msl270_lbc7_core_iso_2pin.lef  \
-mapscript mapping.tcl => This is optional and creates a mapping file which maps new eco cells with location aware spare/GA cells. this can be used in PnR, so that PnR doesn't have to do tedius process of mapping

#report eco changes -script -file test.script -replace => generates ECO inst set file that can be used directly in verplex(by using -script option) or EDI (by using -encounter option. it generates eco directive file)
report eco changes > eco_changes.rpt => reports eco chamges for each module (as new nets,instances,pins,etc)
write eco design -replace -newfile digtop_final_route_eco.v => new netlist can be tkdiff with old netlist to see differences.

exit

7. Now use the netlist generated above in Encounter to do place and route as in any eco flow. This new netlist above just has new instances added/deleted, but doesn't have the mapped spare cell isntance connection. This will be done in EDI. However, we will still need to modify the above netlist to add scan chain connection for any newly added flops.

---------------
DIFF the layout: After the ECO change, verify the differences to make sure, only desired metal layers got changed.
--------------
A. generate laff files for digital design for both 1p0 db and 1p1 db.

1. On cadence CIW (cmd/log window, NOT the lib mgr), goto TI_Utils->Translators->Physical->LAFF_out@TI. We get new pop up box (CDS2Laff).
2. Provide Form Template File name if you have any(.cds2laff.ctrl). This file has all the info in it, so that we don't need to type anything in boxes below. you need to load this file to save typing. .cds2laff.ctrl lools like this (resides in /proj/DRV9401/users/kagrawal/DRV9401 or anywhere else):
topcells
Hawkeye_digtop_1p1  digtop  layout
end
laffname   /sim/BENDER/pindi/assura/digtop_1p1.laff
nosystemlayers
layermap /data/pdk/lbc8/rev1/cdk446/4.6.a.19/doc/cds2laff.map
logfile /data/BENDER/users/pindi/BENDER/CDS2LAFF.LOG
signal label

If .cds2laff_1p1.ctrl file is not loaded, then run steps 3 to 7, and then save this template as .cds2laff.ctrl.
3. leave run dir as current (.).
4. choose cell type as "cellname" and Provide Library name (Hawkeye_digtop_1p1), cell name(digtop), view name (layout)
5. Provide Laff file name to write to (ex: digtop_1p1.laff).
6. choose layer map table => this comes from the pdk doc dir. Without this layer mappings will not be correct and we may get a "syntax error" on running difflay (for HPA07, it's /data/pdkoa/50hpa07/2012.11.13/cdk/itdb/doc/cds2laff.map)
6. choose signal type as "label". (leave "exclusive layer mapping" as ticked)
7. click "OK", and the digtop_1p1.laff file is generated in the dir mentioned. (choose yes and no for the first 2 options that pop up)

Repeat steps 1 thru 7 for digtop_1p0 design to generate digtop_1p0.laff (by changing .cds2laff_1p0.ctrl file appr)

NOTE: Look at CDS2LAFF.LOG file. At the very bottom, we should see 0 errors and 0 warnings.

B. Diff b/w digtop_1p0.laff and digtop_1p1.laff
Open difflayman tool (by typing difflayman on the unix command window). On the gui, provide the laff path for the 1p0 and 1p1 laff files, cell names as digtop, path to summary out file and log path file, and then click submit. A new window pops up. when it's done, then you can click on "view summary" to see what layers changed.

-------------------------------------

Details

Published: Friday, 12 October 2018 04:25

Hits: 1512

SPEF: this file has Res,Cap and other parasitic info for all nets in design
----

Standard Parasitic Exchange Format (SPEF) is an IEEE standard for representing parasitic data of wires in a chip in ASCII format. Resistance, capacitance and inductance of wires in a chip are known as parasitic data. SPEF is most popular specification for parasitic exchange between different tools of EDA domain during any phase of design.
The specification for SPEF is a part of standard 1481-1999 IEEE Standard for Integrated Circuit (IC) Delay and Power Calculation System.

General Syntax
--------------
A typical SPEF file will have 4 main sections:
¡V a header section,
¡V a name map section,
¡V a top level port section and
¡V the main parasitic description section.

Generally, SPEF keywords are preceded with a *. For example, *R_UNIT, *NAME_MAP and *D_NET.
Comments start anywhere on a line with // and run to the end of the line. Each line in a block of comments must start with //.


A. Header Information
---
The header section is 14 lines containing information about
¡V the design name,
¡V the parasitic extraction tool,
¡V naming styles
¡V and units.

When reading SPEF, it is important to check the header for units as they vary across tools.

ex: digtop.spef file:
--
*SPEF "IEEE 1481-1998"
*DESIGN "digtop" <design name
*DATE "Mon Mar 12 12:11:11 2012"
*VENDOR "Silicon Perspective, A Cadence Company"
*PROGRAM "Encounter"
*VERSION "09.12-s159_1"
*DESIGN_FLOW "COUPLING C" "PIN_CAP NONE" "NAME_SCOPE LOCAL"
*DIVIDER /
*DELIMITER :
*BUS_DELIMITER []
*T_UNIT 1 NS <= time units is ns
*C_UNIT 1 PF <= cap unit is pf
*R_UNIT 1 OHM <= res unit is ohm
*L_UNIT 1 HENRY <= ind unit is H

B. Name Map Section: optional
----
To reduce file size, SPEF allows long names to be mapped to shorter numbers preceded by a *. This mapping is defined in the name map section.
ex:
--
*NAME_MAP

*1 spr_6/FE_OFCN92_tie_hi_net0 <= net name mapped. Later in the file, it can be refrred by *1
*2 spr_6/FE_OFCN93_tie_hi_net0
*2246 trim_dout[52]
*3062 U57 <= instance name mapped

C. Port Section
-----
The port section is simply a list of the top level ports in a design. They are also annotated as input, output or bidirect with an I, O or B.
ex:
--
*PORTS

*1973 I *C 0 2069 => *1973 is n_puc i/p pin.
*1975 I *C 185.9 2073.6

D. Parasitics: this is the main section. It has info about each and every net is design.
----
Each extracted net will have a *D_NET section. This will usually consist of a *D_NET line, a *CONN section, a *CAP section, *RES section and a *END line. Single pin nets will not have a *RES section. Nets connected by abutting pins will not have a *CAP section.
The *D_NET line tells the net name and the net's total capacitance. This capacitance will be the sum of all the capacitances in the *CAP section.

ex:
--
*D_NET *1 0.163578 => net name is *1 and total cap on this net is 0.16pf = 160ff. Each net is subdivided into nodes with node id, which are used in cap and res fields below.

*CONN => lists all the pins connected to the net. A connection to a cell instance starts with a *I. A connection to a top level port starts with a *P. The syntax of the *CONN entries is:
*I <pin name> <direction> *C <xy coordinate> *L <load_pin_cap> *D <load_cell_type>

*I *2453:CLK I *C 493 1783 *L 0.00608 *D DTB20 => net *1 is connected to pin "clk" of instance *2453. clk is located at coord <493,1783>.  clk pin cap is 6ff and it's on cell DTB20.
...
*I *2323:A I *C 368 1943 *L 0.0129 *D BU140

*CAP => provides detailed capacitance information for the net. Entries in the *CAP section come in two forms, one for a capacitor lumped to ground and one for a coupled capacitor.
A capacitor lumped to ground has three fields: an identifying integer, a node name and the capacitance value of this node
A coupling capacitor has four fields: an identifying integer, two node names and the coupling capacitor values between these two nodes

1 *2323:A 9.27572e-05 => This lumped cap is given id 1, it's cap of 0.09ff to pin A of inst *2323
...
115 *2447:A *1707:33 0.000475296 => this coup cap is b/w pin A of *2447 and node id 33 of *1707(o/p buf x4).

*RES => provides the resistance network for the net. The resistance network for a net can be very complex.
Entries in *RES section contain 4 fields: an identifying integer, two node names and the resistance between these two nodes. Out of the 2 nodes, one of the node has to be the node for this net itself. The other node can be end point connection (any load in *conn) or other node on this net itself.

1 *1:19 *1:27 38.7104 => res of 38.7ohm b/w node id 19 and 27 of *1(this net).
...
46 *3565:Y *1:46 8 => res of 8ohm b/w node id 46 of this net and pin Y of *3565

*END => end of NET *1

*D_NET *2 0.0863349 <= repeat same as above for net *2
...
*END

*D_NET *2311 0.0154887 <= repeat same as above for all nets
...
*END

----------------------------------------------------
sample ex of a net:

*D_NET *2311 0.0154887 => net name *2311(wr_strobe_spi_sync). total cap=15.5ff which is the sum of all cap in *CAP. From digtop_route.v, we see that wr_strobe_spi_sync has following connections:
load1: NO210 U4 (.Y(n1), .B(n20), .A(wr_strobe_spi_sync));
driver: DTCD2 wr_strobe_spi_sync_reg (.Q(wr_strobe_spi_sync), .D(N28), .CLRZ(nreset), .CLK(clkosc__L2_N4));
load2: NO211 U161 (.Y(N28), .B(wr_strobe_spi_sync), .A(wr_strobe_spi_meta));
load3: IV110 U162 (.Y(n18), .A(wr_strobe_spi_sync));
load4: AN2D0 U176 (.Y(N145), .B(wr_strobe_spi_sync), .A(n193));

*CONN => there are 4 loads and 1 driver connected to this net.
*I *3556:B I *C 610 1416 *L 0.00265 *D AN2D0 => load4 is pin B of *3556(AN2D0). pin cap=2.6ff.
*I *3549:A I *C 540 1443 *L 0.00638 *D IV110 => load3 is pin A of *3549(IV110). pin cap=6.4ff.
*I *3548:B I *C 591 1416 *L 0.00561 *D NO211 => load2 is pin B of *3548(NO211). pin cap=5.6ff.
*I *3195:A I *C 588 1404 *L 0.00568 *D NO210 => load1 is pin B of *3195(NO210). pin cap=5.7ff.
*I *3220:Q O *C 622 1400 *L 0 *D DTCD2 => driver is pin Q of *3220(DTCD2). pin cap=0ff as it's o/p pin, even though in cap section, cap of 0.8+1.1+1=2.9ff is assigned to this o/p pin Q.

Now, this net (wr_strobe_spi_sync) is subdivided into subnets and node numbers are assigned to end points of these subnets. That forms a tree. Node ID appear in the connection part of cap and res section. If you look in connections of *RES section, you'll see that Node numbers are 5,6,7,8,9,10,11 (7 nodes) while the 11 res connecting these nodes and load/driver have been assigned 11 ids. Similarly in *CAP section, you will see that these 7 nodes are being used to connect coup/lump caps to, along with coup/lump caps attached to load, while 17 caps have been assigned 17 ids.
NOTE: Id of Res or cap have nothing to do with node numbers. Node numbers are the ones that form tree. Id for res and cap just indicate that particular cap/res were assigned some id. Same node numbers will appear in both res and cap section.
Below, a tree is formed as shown starting from driver o/p Q, and ending at 4 loads, ld1 to ld4. Node Ids 5 to 11 are shown.
Q->5->6->     10->     8->9->7->ld1
      6->ld4  10->ld2     9->11->ld3

*CAP => this section contains cap at each node and at some loads. Some loads are missing, not sure why?
top 10 are lumped cap, while 11 to 17 are coupling cap. These coupling cap are treated appr when running timing for setup/hold. In PT/ETS, all coupling cap are grounded to 0. So, it may be optimistic or pessimistic for setup/hold depending on which data or clock path it appears on. Ideally for setup, data path coup cap should be mult by 2, and clk path coup cap mult by 0, while for hold data path coup cap mult by 0, and clk path coup cap mult by 2. In PTSI, it does it that way.

1 *3220:Q 0.000805389 => driver o/p lump cap is 0.8ff. cap placed at o/p Q.
2 *3548:B 0.000700078 => lump cap placed at ld2
3 *3556:B 0.000671207 => lump cap placed at ld4
4 *2311:11 0.00116516 => lump cap placed at nodes 5 to 11
5 *2311:10 0.00159617
6 *2311:9 0.000124281
7 *2311:8 0.000102239
8 *2311:7 0.00367203
9 *2311:6 0.000747997
10 *2311:5 0.000117708
11 *2311:7 *3219:CLK 0.000676197 => coupling cap to clk of *3219 at node 7 of wr_strobe_spi_sync
12 *3220:Q *1929:10 0.00112872 => coupling cap to node 10 of *1929 placed at o/p Q.
13 *2311:7 *1762:7 0.000385412
14 *3556:B *170:8 0.000849882 => coupling cap to node 8 of *170 placed at ld4
15 *3556:B *3246:D 0.00124761 => coupling cap to pin D of *3246 placed at ld4
16 *2311:7 *1964:18 0.000400017
17 *3220:Q *1972:163 0.00109857 => coupling cap to node 163 of *1972 placed at o/p Q.

*RES => this section will contain all load and driver, as there has to be a res to the final end point. So, starting from driver, we can form a tree to all the loads:

1 *2311:8 *2311:10 8.80112
2 *3549:A *2311:7 17.2017
3 *2311:8 *2311:9 0.839437 => res b/w node id 8 and 9
4 *3556:B *2311:6 17.2017
5 *2311:9 *2311:11 11.3902
6 *3195:A *2311:11 8.16737 => res b/w node id 11 and ld3
7 *3548:B *2311:10 9.20169
8 *2311:5 *2311:6 2.04502
9 *2311:7 *2311:9 8.07294
10 *2311:6 *2311:10 11.2614
11 *3220:Q *2311:5 19.0042
*END

-----------------------------

Details

Published: Friday, 12 October 2018 04:23

Hits: 2355

UPF Syntax:

UPF is based on tcl scripting language. UPF commands are defined using syntax that is consistent with Tcl, such that a standard Tcl interpreter can be used to read and process UPF commands. Compliant UPF processors shall use Tcl version 8.4 or above.

UPF supports the specification of attributes, or properties, of objects in a design (eg UPF_clamp_value, etc). Many Liberty attributes are mapped to UPF attributes (i.e lib attr "pg_type" is mapped to UPF attr "UPF_pg_type).

There are 50 or so UPF cmds to specify power intent of design. We will deal with few imp ones. There are many legay or deprecated cmds which should not be used any more.

Power Domains, states and scope:

0. set_scope <inst_name> => This sets current scope of design. Inst name can be scope/design relative hier name.

• slash = / => changes scope to top inst of design
• dot = . => sets scope to current scope
• double dots = ..  => sets scope 1 hier level higher, or parent of current scope.

If design has "top" as top inst, then "mid" and then "bot", then :

• ex: set_scope top => This sets current scope to instance top.
• ex: set_scope top/mid => sets current scope to mid

1. create power domains, port, nets and connect them: These cmds add the pwr signals to design.

A. create_power_domain <PD_NAME> => defines a power domain and the set of instances that are in the extent of the power domain. The scope of this PD is the current scope of design, so scope has to be set beforehand using "set_scope" cmd. options:

• -supply: defines the supply sets (SS) that are used to provide power to instances within the extent of the power domain. The supported supply set handles are primary, default_retention, default_isolation, and extra_supplies_#. Primary is the primary SS for this PD, while extra_supplies_0, extra_supplies_1, etc are the power supplies that are needed for other smaller portions of the PD.
• -elements: If -elements <list> option is used, then only those  inst (and all their descendants) specified in the list are in extent of that PD. option -exclude_elements excludes specified inst from the extent of this PD. By default, everything in scope is in extent of that PD. PD may contain elements from different hier of chip, as A/inst1, B/inst2, C/D/inst3 => so these 3 instances will be in one PD, even though logically they are in 3 different modules.

ex: create_power_domain PD_CHIP -include_scope -supply {primary {SS_VDD1p2}} -supply {extra_supplies {SS_VDDIO}}=> here supply set for primary is set to SS_VDD1p2, and extra_supplies to SS_VDDIO, for this PD. Here, scope is whatever scope was set to.

ex: create_power_domain PD_CHIP -elements {i1 i2 i3} -supply {primary {SS_VDD1p2}} => This includes instances i1, i2 , i3 and all their descendants in the PD_CHIP domain. No other instances from current scope are in this PD.

B. create_supply_port <PORT_NAME> => creates supply port at current scope. If option -domain <PD_NAME> is used, then PORT is created in the scope of speciifed PD.

C. create_supply_net <NET_NAME> => same as above, except that it creates supply net

D. create_supply_set <SET_NAME> => creates supply set. option -function {func_name net_name} defines function (func_name) that a supply net (net_name) provides for this set. Thus it maps each supply net in the set with 1 of 6 functions, These nets comprise the set.

ex: create_supply_set SS_VDD1p2 -function { power VDD1p2 } -function { ground VSS } -function { nwell VDD1p2 } -function { pwell VSS }

We can grab the supply net name from the supply set by using hier with dot as separator, i.e To get net name VDD1p2, we use "SS_VDD1p2.power". Similarly to get net name VSS, we use "SS_VDD1p2.ground".

E. connect_supply_net <NET_NAME> -ports <PORT_NAME> => connects supply net to supply ports

2. power/supply states: specifies various power states possible with various supplies. For ex, VDD supply might have 3 possible voltage values, so we may define 3 power states for it.

- add_power_state <OBJ_NAME> -state <STATE_NAME>  (add_port_state and add_pst_state, along with create_pst are legacy and shouldn't be used) => defines power state of an object which can be a PD, inst, supply net/port/set, etc. Usually power state is defined on supply set. If -supply is specified, the object_name shall be the name of a supply set or a supply set handle. option "-supply_expr {boolean_expr} " specifies a Boolean expression defined in terms of supply ports/nets/set, that evaluates to True when the object is in the state being defined. We can add as many power states as we want to <STATE_NAME> by repeatedly using this cmd.

ex: add_power_state PD_CHIP.primary -state { GO_ST -supply_expr {(power == {FULL_ON 0.8}) && (ground == {FULL_ON 0})} } -state { OFF_ST -supply_expr {power == OFF} } => defines 2 power states = GO_ST and OFF_ST, for PD_CHIP primary supply set which as defined above is SS_VDD1p2

ex: add_power_state SS_VDD1p2 -state V_NOM {-supply_expr {power == `{FULL_ON,0.5,0.6,0.7}}} => creates power state V_NOM for supply set "SS_VDD1p2".

- add_supply-state <OBJ_NAME> -state {<NAME>  <nom_val|off>} => defines a named supply state for a supply object which can be supply port/net/set. If a voltage value is specified, the supply net state is FULL_ON and the voltage value is the specified value; otherwise, if off is specified, the supply net state is OFF.

ex: add_supply_state PD.primary.power -state {active_state 0.90 } -state {off_state off} => defines supply states for condition when active_state is at 0.9V, while off_state is set to "off"

Power management cells: We need Power mgmt cells as power switch, level shifter, isolation, repeater and retention cells. there are set_* cmds to instantiate these in design (except for power switch which has create_* cmd), map_* cmds to map specific lib cells to such cells, and define_* cmds which are basically same as map_* cmds. Not sure why are there map_* and define_* cmds. Power switch, repeater and retention cells have corresponding map_* cmds (there's no map cmd for level shifter and isolation cells), while power switch, level shifter, isolation and retention cells have corresponding define_* cmds (repeater cells don't have a define_* cmd).

3. power switch: create and map/define pwr switch. create cmd used for power switch only (NOT for other cells, as set* cmd is used for those. This is because these are power strategies). Power switch is created just like ports/nets are created.

- create_power_switch <SW_NAME> -domain <PD_NAME> => defines a power switch in the scope of domain specified. This is abstract model of a single switch, impl may use multiple distributed pwr switches. Connections to i/p, o/p, ctl and ack port of switch is done via additional args here or using the map cmd (explained in example below). An on/off state condition is also defined, so that flows can understand how to turn the switch on or off.

ex: create_power_switch sw1 -domain PD_CHIP -control_port {SLEEPN_IN psw1/buf_in/y} -ack_port {SLEEPN_OUT psw1/buf_out/a} -on_state {SW_ON SLEEPN_IN} -off_state {SW_OFF !SLEEPN_IN} -input_supply_port {TVDD VDD_12} -output_supply_port {VDD VVDD_12} => This defines a power switch and connects the ports of power switch to various nets. Here control/ack ports of power switch are named as SLEEPN_IN and SLEEPN_OUT and are connected to some internal net in power switch wrapper. When SLEEPN=1 (i.e SLEEP=0), power switch is on. Vice-versa for when SLEEPN=0. The supply ports are also mapped to i/p supply and switched o/p supply.

- map_power_switch <SW_NAME> -lib_cells {LIB_CELL_LIST} -port_map {port_mappings} => This specifies list of lib cells to which impl of this switch can be mapped to. Lib cells should appear in liberty file with required "power switch" attr or such attr should be added via "define_power_switch_cell" upf cmd.

ex: map_power_switch switch_sw1 -domain test_suite -lib_cells {sw1} -port_map {{inp1 vin1} {inp2 vin2} {outp vout} {c1 ctrl_small} {c2 ctrl_large}}

- define_power_switch_cell -cells {cell_list}  => this cmd identifies the library cells that can be used as power switch in a design. Lots of options available with this cmd. This cmd not needed if "power switch" attr is specified on such cells in liberty files.

4. retention cell: set and map/define retention cells. These reg/flops already exist in RTL design, just that we identify which of these are going to be retention, and what strategy is going to be used.

- set_retention <RET_NAME> -domain <PD_NAME> => specifies retention strategy, and the domain to which it's applied. Other options provide save/restore ports and their active level/edge for save/restore to happen, save/restore condition (logic needed to be connected to generate save/restore condition). option -elements or -exclude_elements can apply this to specific elements instead of applying it to whole PD. -retention_supply provides supply set used to power the retention cells.

- map_retention_cell <RET_NAME> -lib_Cells {LIB_CELL_LIST} -port_map {port_mappings} => This speciifes list of lib cells to which these retention cells can be mapped to. Lib cells should appear in liberty file with required "retention" attr or such attr should be added via "define_retention_cell"

ex: map_retention_cell {my_PDA_ret_strat_1 my_PDA_ret_strat_2} -domain PD_A -elements {foo/U1 foo/U2} -lib_cells {RETFFIMP1 RETFFIMP2}  -port_map { {CP UPF_GENERIC_CLOCK} {D UPF_GENERIC_DATA} {SET UPF_GENERIC_ASYNC_LOAD} {SAVE save_signal} {RESTORE restore_signal} {VDDC primary_supply.power} {VDDRET retention_supply.power} {VSS primary_supply.ground} }

- define_retention_cell -cells {cell_list}  => this cmd identifies the library cells that can be used for retention in a design. Lots of options available with this cmd. This cmd not needed if "retention" attr is specified on such cells in liberty files.

5. repeater cell: set and map repeater cells. map cmd for repeater cells doesn't have an equivalent define_* cmd.

- set_repeater <REP_NAME> -domain <PD_NAME> -applies_to <Inputs|outputs|both> -repeater_supply <SUPPLY_SET> => specifies repeater strategy, and the domain to which it's applied. supply_set that powers this buffer is specified.

- map_repeater_cell <REP_NAME>  -domain <PD_NAME> -lib_cells {LIB_CELL_LIST} => This speciifes list of lib cells to which these repeater cells can be mapped to. NOTE: there is no "repeater" attr needed on lib cells or "define repeater cells" upf cmd, as these are regular buffer cells.

ex: map_repeater_cell my_rep1_pd1 -domain PD1 -elements { clk1 rst1 clkout1 rstout1 } -lib_cells { aon_clk_bufx2 }

6. level shifter cell: set and define level shifter strategy. It's applied at the domain boundary, as required to correct for voltage differences between driving and receiving supplies of a port. There's no map cmd for level shifter in UPF IEEE doc, though it's used as valid UPF cmd everywhere.

- set_level_shifter <LVL_NAME> -domain <PD_NAME> -applies_to <Inputs|outputs|both> -rule <low_to_high|high_to_low|both> -input_supply <IN_SUPPLY_SET> -output_supply <OUT_SUPPLY_SET> => defines level shifting strategy for ports on i/f of specified PD. port_dirn to which this applies can be specified as i/p ports, o/p ports or both (by default, strategy applied to all ports). Rule specifies if level shifter strategy should be applied only to ports needing level shifting in one dirn (default is to apply it to ports needing level shifting in any dir, i.e high to low or low to high). option -no_shift can be used to not apply level shifter on specified ports.

ex: set_level_shifter DFT_input_ls -domain PD_DFT -applies_to inputs -rule both -location parent => defines Level shifter on all i/p ports of PD_DFT power domain.

ex: set_level_shifter DFT_no_ls -domain PD_DFT -no_shift -elements {mux0/out1 {mux2/In[*]} mux3/in3} => This cmd specifies no level shifter on these ports. So, all i/p ports in above cmd will have level shifter, except for ports specified here.

- define_level_shifter_cell -cells {cell_list} -enable <EN_PIN> -direction <low_to_high|high_to_low|both> => this cmd identifies the library cells to use as level-shifter cells. This cmd replaces "map level shifter cells", as all lib cels defined here can be mapped to level shifter strategy defined. 

7. Isolation cell: set and define isolation strategy.Just like level shifters, it's applied to ports at the domain boundary, so that correct electrical and logical functionality is maintained when domains are in different power states. Again, there's no map cmd for isolation cells in UPF IEEE doc, 

- set_isolation <ISO_NAME> -domain <PD_NAME> -applies_to <Inputs|outputs|both> -clamp_value <0|1|Z||latch|value> -isolation_signal {iso_ctl_signal} -isolation_sense <high|low> -isolation_supply <supply_set_list>=> specifies isolation strategy, and the domain to which it's applied. Isolation ctl signal of cell, as well as the active level of ctl signal is specified. We can also specify the Supply set for isolation cell.

ex: set_isolation PD_efuse_in_iso -domain PD_EFUSE -applies_to inputs -clamp_value 0 -isolation_signal pgctl_clamp -isolation_sense high -isolation_supply SS_VDD_1 

- define_isolation_cell -cells {cell_list} -enable <EN_PIN> -clamp_cell <high|low> => this cmd identifies the library cells that can be used for isolation in a design. This cmd replaces "map iso cells", as all lib cels defined here can be mapped to iso strategy defined. Iso cells can be of 2 types => clamp type (clamps o/p to high or low when EN_PIN is active) or non-clamp type (cell function determines cell o/p).

ex: define_isolation_cell -cells iso_cell1 -power VDD -ground GVSS -enable iso_en

8. Port attributes: specifies info associated with ports. These port attributes identifies port's related supplies, and aid in isolation and level shifting insertion.

- set_port_attributes -ports {port list} -clamp_value <0|1|Z|value> -driver_supply {driver supply set} -receiver supply {receiver supply set} => clamp_vale specifies the clamp value to be used if an isolation strategy is applied to the port. Driver_supply is used for an o/p port to specify the driver supply of logic driving the o/p port. Similarly for i/p port, we have receiver supply.

ex: set_port_attributes -ports {port1 port2[*]} -driver_supply SS_VDD12 -receiver supply SS_VDD12 => Here driver and receiver supply for all these ports are set to same supply voltage, implying all ports of current instance.

UPF cmd file Example: (ex in http://rd.springer.com/chapter/10.1007/978-1-4614-4271-4_8/fulltext.html)

In the example above, there are 3 power supplies and 4 power domains defined.

3 pwr supplies => (PVDDdsp=1.1V_0.9V, PVDD1p0=1.0V, PVDD0p9=0.9V), but 4 pwr domains, since PD_COP has a switch to connect to 1.0V spply
4 pwr domains =>

• PD_MYCHIP=1V,
• PD_CPU=0.9v (both always ON)
• PD_COP=1V (from PD_MYCHIP, but can be shutdown using a switch)
• PD_DSP=1.1V or 0.9V

We can define various power modes (basically 4 power modes, where PD_COP may be ON or OFF, and PD_DSP may be 1.1V or 0.9V), and other 2 PD are always ON.

There is a power ctl in PD_MYCHIP domain which controls switch, drives isolation and state retention signals to PD_COP.

mychip.upf:
------
# Set scope to top-level:
set scope

# Declare power domains: (create for all 4 PD)
create_power_domain PD_MYCHIP - include_scope => creates power domains
create_power_domain PD_CPU - elements {U_CPU} => and so on for other 2

# Create power nets at top : (similarly do for other 3 PD => PD_CPU and PD_DSP have only 2 supply nets, one of VDD* and GND, PD_COP has 3 supply nets: VDD1p0, VDD1p0_SW and GND. VDD1p0 is needed since it has retention flops which are always ON)
create_supply_net VDD1p0 - domain PD_MYCHIP - reuse => nets can be any name. supply_net is needed to connect supply ports
create_supply_net VDDdsp - domain PD_MYCHIP - reuse
create_supply_net VDD0p9 - domain PD_MYCHIP - reuse
create_supply_net GND    - domain PD_MYCHIP - reuse

# Create the power ports at top:(similarly do for other 3 PD, all of which have 2 ports). For each PD, supply and gnd port must be specified
create_supply_port PVDD1p0 - domain PD_MYCHIP => port names have to be top level port names
create_supply_port PVDD0p9 - domain PD_MYCHIP
create_supply_port PVDDdsp - domain PD_MYCHIP
create_supply_port PGND - domain PD_MYCHIP

#Connect top power ports and nets: => all ports connected to internal nets
connect_supply_net VDD1p0 - ports PVDD1p0 => this connects the supply ports created
connect_supply_net VDD0p9 - ports PVDD0p9
connect_supply_net VDDdsp - ports PVDDdsp
connect_supply_net GND - ports PGND

#connect top to PD_CPU (connects each lower level module port to these nets) => similarly for other 2 PD
connect_supply_net VDD0p9 - ports {U_CPU/PDCPU_VDD0p9}
connect_supply_net GND - ports {U_CPU/PDCPU_GND}

# Connect inside PD_CPU: => similarly for other 2 PD
connect_supply_net VDD0p9 - ports PDCPU_VDD0p9 - domain PD_CPU
connect_supply_net GND - ports PDCPU_GND - domain PD_CPU

# Specify primary power nets:  It specifies one primary power and ground connection for every power domain.
set_domain_supply_net PD_MYCHIP - primary_power_net VDD1p0 - primary_ground_net GND
set_domain_supply_net PD_CPU - primary_power_net VDD0p9 - primary_ground_net GND
set_domain_supply_net PD_DSP - primary_power_net VDDdsp - primary_ground_net GND
set_domain_supply_net PD_COP - primary_power_net VDD1p0_SW - primary_ground_net GND

#####
#Define isolation strategy and control for PD_COP:
set_isolation PD_COP_ISO \
- domain PD_COP \
- isolation_power_net VDD1p0 \ => supply nets for isolation logic
- isolation_ground_net GND \
- applies_to outputs \ => isolation only applies to output ports of this PD
- clamp_value 0 => specifies value to which iso i/p or o/p are clamped. Here it's iso low

set_isolation_control PD_COP_ISO \ => every set_isolation cmd should have corresponding set_isolation_control
- domain PD_COP \
- isolation_signal U_PC/ISE \ => This can only be a net (no port or pin)
- isolation_sense low \
- location self => self means iso cell is placed within current hier, while "parent" implies it's placed in parent module.

#####
# Define level shifter strategy and control for PD_CPU: (similarly for PD_DSP) => needed only when voltage levels differ
set_level_shifter FROM_PD_CPU_LST \
- domain PD_CPU \
- applies_to outputs \
- rule low_to_high \
- location parent

set_level_shifter TO_PD_CPU_LST \
- domain PD_CPU \
- applies_to inputs \
- rule high_to_low \
- location self

# Declare the switches for PD_COP:
create_power_switch PD_COP_SW \
- domain PD_COP \
- input_supply_port {VDDG VDD1p0} \ => 1st arg is port name, 2nd arg is net name connecting to it.
- output_supply_port {VDD VDD1p0_SW} \
- control_port {SLEEP U_PC/PSE} \
- ack_port {SLEEPOUT U_PC/PSE_ACK} \ => ACK o/p port if present
- ack_delay {SLEEPOUT 10} \ => delay from CTRL i/p port to ACK port
- on_state {SW_on VDDG !SLEEP} \ => SW_on state is defined as when SLEEP port is low
- off_state {SW_off SLEEP} => SW_off state is defined as when SLEEP port is high

# Specify the switch type: This command specifies which cell to use from a technology library for a power switch.
map_power_switch PF_COP_SW \
- domain PD_COP \
- lib_cells HEADBUF_T50

# Specify isolation cell type:
map_isolation_cell PD_COP_ISO \
- domain PD_COP \
- lib_cells {O2ISO_T50 A2ISO_T50}

##########
# Specify retention strategy: (i.e which reg in that PD are to be implemented as ret reg)
set_retention PD_COP_RET \
- domain PD_COP \
- retention_power_net VDD1p0 \ => ret pwr/gnd net are connected to save/restore logic and shadow regs.
- retention_ground_net GND \
- elements {U_COP/reg1 U_COP/pc U_COP/int_state} => All reg here are given ret capability. If no elements specified then element list used to define PD is used.

set_retention_control PD_COP_RET \ => each ret strategy has corresponding ret control.
- domain PD_COP \
- save_signal {U_PC/SRE high} \ => specifies net used to save data in shadow reg, and logic state of save signal that causes this to happen
- restore_signal {U_PC/SRE low} => same signal used for restore signal

map_retention cell MULT_RET \
-domain PD_COP \
-lib_cells RSDFF_X40

#########
# Add port state:
add_port_state PVDD1p0 -state {S1p0 1.0}
add_port_state PVDD0p9 -state {S0p9 0.9}
add_port_state PVDDdsp -state {SH1p1 1.1} -state {SL1p1 0.9}
add_port_state PGND -state {default 0}
add_port_state PD_COP_SW/VDD -state {SW_on 1.0} -state {SW_off off}

# Create power states and state table:
create_pst MYCHIP_pst - supplies \
{VDD1p0 VDD0p9 VDDdsp PD_COP_SW/VDD}

add_pst_state PM1 - pst MYCHIP_pst - state \
{S1p0 S0p9 SH1p1 SW_on}

add_pst_state PM2 - pst MYCHIP_pst - state \
{S1p0 S0p9 SH1p1 SW_off}

add_pst_state PM3 - pst MYCHIP_pst - state \
{S1p0 S0p9 SL1p1 SW_on}

add_pst_state PM4 - pst MYCHIP_pst - state \
{S1p0 S0p9 SL1p1 SW_off}

-------------------------------------