Cadence icfb: integrated circuit front to back. Used for custom schematic entry, layout and simulation.  Cadence also has icms (integrated circuit mixed signal) which doesn't have layout capability as layout tools are expensive. icfb brings up virtuoso tools (virtuoso schematic, virtuoso layout, ADE sim
------------
icfb -ame => list all available versions.
 -5.10.41.500.6.144p1_414 is the default icfb version.

We can invoke icfb either way:
icfb -5.10.41.500.6.144p1_414 => invokes mentioned version which is mapped to cic_ti-5.10.41.500.6.144p1_414
icfb -artisan-2.91 => artisan-2.91 is mapped to cic_ti-5.10.41.500.6.144p1_414, so it invokes same icfb version as above.

when we run icfb in ~/proj/<PROJECT_NAME>/ dir, we get the version of icfb based on various settings in cds files. It also sets other env parameters based on settings.
However, if we start icfb in brand new dir without any files, then icfb starts with default settings, and creates bunch of files for its own use.

to get version of icfb being used, type following in CIW (command interpreter window) of icfb:
getVersion() => displays main version: "@(#)$CDS: icfb.exe version 5.1.0 07/29/2010 22:47 (cicln04) $"
getVersion(t) => displays sub version: "sub-version 5.10.41.500.6.144"

Cadence icfb version 5.1.x was being used at TI, which had older look. It's CDB (Non-OA) based. Support ended in 2010 by cadence. Artisan 2.9 launches this.
Now we use Cadence icfb version 6.1.x which has the newer look. It's OA based. Artisan 3.5 and above launch this.

purge data from icfb memory:
---------------------------
sometimes we have lots of files which will show as locked even though they were never opened for editing. The way to get rid of this is to clear everything from memory. That way if there is any file that is locked, it will show up during the clearing process. Goto CIW window (not lib mgr): File->Close data. Then it will prompt for all files that are in memory, and ask us to save or discard files in memory. We can usually discard all files here, if we are sure, we haven't modified anything.


----------------------------
Cadence Virtuoso Layout:
------------------------
1. Sometimes layout only shows blocks and boundary and not the guts in it.
To view full layout, press "Shift" + "f". To see boundary only, do "ctrl" + "f".
2. To turn on/off certain layer, in LSW window, press middlemouse on that layer name. It turns it off. Pressing middle mouse again, turns it on. To see the effect in layout, either do a fit "f", or refresh "ctrl+r".
3. V2 (or V02), V3, V5, V12, ..., V95 refer to voltage layers of 2V, 3V, 5V, etc. That is why, we see "V" all over the layout, as it shows voltage layer routes. To turn this off, just click on middle mouse while hovering the mouse on these layers in LSW panel.
4. To see layout for a device from the schematic editor, select that device on schematic editor, and goto PDK_utils->PreviewLayout. It shows layout on a new window.
5. To cross match a device on schematic to it's layout in top level layout, open the layout. In layout editor, goto Assura->run_lvs. After lvs finishes, goto Assura->Open run and open lvs report. then we can click on probe to probe any net/cell.
6. To look at cell hierarchy, click on windows->Assistants->Navigator. This will bring Navigator window on top of palette window that we can pull to the side. It will show the schematic cells and hierarchy, so it's easier to navigate on layout. We can unsuppress on "5K further instances" to see all instances and nets (since this is flat layout, so eveything is under 1 hierarchy).

Cadence Virtuoso Schematic:
---------------------------
1. to start new schematic, type icfb, goto Lib mangager. click File->new->cell view.
2. choose lib="hayate_sim" or other sim lib. cell=sim_kail_1, view=schematic, click OK.
3. This opens new schematic window.

to draw schemtic,
1. click i to "add instance".
A. To add digital cells: choose library as "pml30_lbc8_2pin", cell as "BU116", view as "symbol" and then place the cursor on schematic. Once done, press escape. For analog cells, choose library as "50hpa07". When adding transistors, we have multiple pins (B, SUB, BTWO) depending on type of tran (iso or non-iso). These pins even though shows as floating on schematic (they are actually connected to supplies, but we have to zoom in to see that, and sometimes it's hard to read), are actually connected to PBKG, VDD, VSS supplies. Click "q" after selecting tran, and it will show connections on new "properties" window. Make sure these pin names exist in schematic as "I/O PORT" at that hier, and tran pins are connected to expected supplies. Else modify the pin connections by hitting "q".
B1. To add gnd pin,  choose library as "analogLib", cell as "gnd", view as "symbol". The gnd pin has "gnd!" net name attached to it. Wherever we connect that gnd pin, the net gets assigned "gnd!" and all such nets connect automatically. Many times, designers add vdc of 0v to gnd pin and use the output of vdc as GND and connect it to other pins. This keeps it simpler. NOTE: we need gnd pin "gnd!" connected to gnd node of vdc to allow sim to see it as 0V. Else, -ve node of voltage src, don't know what potential they are connected to, and give an error as "isolated nets". So, gnd! net is not just for convenience but is required to assign 0V to nets.
B2. To add vdd pin, we choose library as "analogLib", cell as "vdd", view as "symbol". The vdd pin has "vdd!" net name attached to it, and works similar to gnd! pin.
B3. To add resistors/caps, we can either run sims with ideal components or real components. To add ideal components, choose lib=analogLib, catgory=passives and cell=res/cap. To add real components, choose lib=50hpa07, category=Resistors/Capacitors, then choose appr res/cap. Note that real components are not pure res/cap, but have models underneath them, which model parasitics. Descend into hier of these to see parasitic model. So, if we choose a very large res (eg 100K) with a real component which has very low resistivity (eg a metal M1 resistor), then the length of the res would have to be very large (in cm), resulting in large capacitive parasitics in the model. This can cause very large time to settle and give weird results. So, always start any sim with ideal passive components, and then substitute real ones as design gets closer to maturity.
C. To add dc voltage source, choose library as "analogLib", cell as "vdc", view as "symbol". Put DC voltage as "1.8V" or "1.8 V".
D. To add PWL(Piecewise Linear function), choose library as "analogLib", cell as "vpwl", view as "symbol". Put DC voltage as "0 V", put number of points to "10" or whatever you need, and then start putting time and voltage. time1=0, voltage1=0, time2=2u, voltage2=0, time3=2.001u, voltage3=1.8 and so on. (units are seconds and voltage). We can also add "delay" to delay the start of time1. time1 is very impotant to be 0s, else we get weird waveforms. Note: to make it periodic, tick mark "periodic" in the box.
E. To add pulse, add vpulse. This is easy for periodic waveforms.
F. To add sine wave, add vsin (from analogLib and not from basic library, as one in basic lib doesn't have any param to be set). Instead of vsin, it's recommended to use vsource with sourcetype=vsin as it's a superset of vsin, and is supported by more simulators. parameters to be set for vsin:
  1. AC analysis: AC magnitude (set to 1V or 0.1V or whatever magnitude we desire  for ac analysis to run, this value doesn't matter as it doesn't use the absolute value of this voltage, but just uses it to report gain value. We usually choose 1V as then the Vout magnitude shown on plot would directly equal to gain), AC phase (default is 0, so no need to set), DC voltage (DC voltage sets the DC voltage of sine wave, so this should be the bias voltage), offset and amplitude should be set to 0 V, evrything else can be left blank.
  NOTE: instead of using vsin, we should use vdc when running ac analysis. We just need to provide "DC voltage" as "VDD/2" V and then "AC magnitude" as "1 V". This makes it simpler.
  2. DC analysis: vsin = DC voltage, Offset voltage: these specify dc voltage to be used
  3. TRAN analysis: vsin = Offset voltage, Amplitude, Frequency => offset determines the dc voltage on which sine wave is superimposed. amplitude denotes peak from offset voltage (sp peak to peak would be 2X amplitude). DC voltage is ignored. (NOTE: Amplitude is used here instead of "AC magnitude" to denote sine voltage.

NOTE: Not all properties on an analogLib component (e.g. vsin, vsource, isource, port, etc.) are supported by all simulators. Spectre supports all of these cadence analogLib cells, but others as Pspice, TI-spice may not support all of them, just a subset of these properties.

3. click w to "add wire".  To add name to wire, click L (no shift+L, it's small L), fill in the name and hit on the wire to which you want the name added. To delete, select an instance and hit "delete". To modify name of existing wire, click on wire name (NOt on wire) and then hit q. Then we can change name of wire. click q on wire to make sure name changed.
4. To add Inductor/capacitor, click i. choose Library_name = analogLib, cell_name=ind or cap and view_name=symbol. Add Ind/cap values as 20u H or 20u F, and initial condition as "0 A" or "0 V". NOTE: ideal ind/cap exist in Passives category of analogLib. Ones in Parasitics category are not ideal.
5. To add resistor, do same as in step 4 above, bu choose res, resPoly, resUser etc. However, most of the times, resistances are chosen from pdk library which are poly or diffusion resistances. Here, we define number of links, and link length, and if the links are connected in parallel or series(multi-link) or straight(just 1 link). That decides the overall resistance. Usually 1 link of certain length is the base unit, and then we do parallel connection to get lower resistance, or we do series connection to get higher resistance.
6. To highlight a net, click 9 and then click on that wire. Alt, goto Design->Probe->Add Net (in icfb version 5.10). To un-hihglight, goto Design->Probe->Remove Net (or Remove all to remove all highlights).
7. To search for anything on schematic, goto edit->Find. Select search for (maybe cellname), and put serach term as *pwl* to search for any instance with pwl name. Select zoom to object and click apply. It will start showing all matching instances one by one.

symbol:
-----
1. To create a new symbol from schematic, open schematic. goto Create->Cellview->From_Cellview. On new box, everything should already be filled in. (From_view=schematic, To_view=symbol). Click OK, and symbol is created. Check and save.

SVS:
---
SVS: To find diff b/w 2 schematic, we can do SVS. Open one of the schematic, goto Assura->Run_SVS. Provide both schematic names, and click OK.

probe:
-----
Cross probe: To do a cross probe b/w schematic and layout, they have to be lvs clean. Then goto Assura->run_LVS. Then goto Assura->Probing and it will bring s new window where we can put name of nets to probe. (May need to open Layout_XL instead of Layout_L). Select "net_name" on "Probe_by_name" box, and click on Add Probe. It will show net highlighted.

To copy any lib/cell/view:
-------------------------
ex: copy patgen cell from old design lib to new design lib.
Right click on lib/cell/view you want copy, and select copy. It brings up a window.

If it says copy problems, see what files has copy problem. If its data.dm in dest view that is going to get overwritten with one in src view, click OK to skip this particular data.dm copy. All other files will be copied correctly. If we click "overwrite all" then this data.dm will be overwritten with new data.dm which may not be correct. copy will complete and you can see all new files in dest dir.

For designs under Design sync, we'll get a prompt everytime we want to modify a file, asking us for checkout. Select yes. Also, after modifying when we close the file, we'll be asked if we want o check in. click yes again. "green arrow" in front of any view shows that it's checked in. "red arrow" shows it's not checked in.

Virtuoso ADE (Analog Design envviroment):
----------------------------------------
ADE v5.1 from Cadence Virtuoso. It has inbuilt simulators (spectre, TI-spice, ams etc) and waveform viewer (Wavescan (SST2 format), AWD-analog waveform display (*.tran format)).

Both Wavescan/AWD use cadence proprietary psf format. Wavescan is newer and faster but still slower than other waveform viewers. Cosmoscope from synopsys is also available to view waveforms in many formats (*.fsdb, *.tr, etc depending on what simulator was used to genrate the file). TIspice generates waveforms in punch (*.pun) format, which can be read by cosmoscope.

For AMS sim, we can have top level design as text, where text can be in Verilog, VerilogA, VerilogAMS, VHDL or VHDLAMS format. You cannot use a SPICE-based text design as the top-level design.

ADE-XL: This is advanced version of ADE which can be used to run sims for multiple corners (Temp, process, statistical monte carlo runs). Basically, it calls ADE for each run under the hood. However, setup is different for ADE-XL. New view has to be created. Then, multiple tests can be run. We can setup tests to run self checking tests where SCM (spec compliance matrix) can be built automatically from data generated and pass/fail be reported based on whether parameter of interest is in range specified or not. We'll talk about ADE below, as ADE-XL is comlpicated.

steps for running sims in ADE: (inst are for older version: icfb 5.1):
----------
To run analog sims using TISpiceD or spectre: (NOT mixed signal sims using ams which require configuaration views explained later)
1. do check and save, once schematic is done.
NOTE: In schematic a voltage src has to be added b/w gnd and pwr to supply voltages to these nodes. However, this will still make simulator fail, as it doesn't know the exact voltage to put on gnd node. i.e with voltage src of 2V, gnd might be 1V, and pwr might be 3V, or gnd might be 4V, and pwr node might be 6V. Thus simulator cannot solve as it needs to start with a finite initial value on all nodes and then compute eqn. gnd! is special net name that puts a 0V on that net. So, choose gnd node net on schematic, right click, choose "add name" and put net name as "gnd!". This puts 0V on gnd node, and the simulator can proceed now without errors.
2. click Launch->Virtuoso ADE (or ADE L) (Note: we did our schematic in Virtuoso ADE). Or in icfb 5.1, click on Tools->Analog Environment to launch Virtuoso ADE. A new ADE box appears.
3A. On setup->design, make sure correct design is already chosen
3B. On setup->simulator/dir/host choose "spectre" as simulator, and "sim" dir as project dir.
3C. In simulation->options->analog, goto main and set tolerance options. (this is for spectre, for TIspice4 we see differnt box).
   - Reltol = 1e-5 (default is usually 0.1% or 1e-3)
   - vabstol = 1e-8 (default is usually 1uV or 1e-6)
   - iabstol = 1e-13 (default is usually 1pA or 1e-12)
   convergence criteria is:
    - |V(k)-V(k-1)| < epi
    - |I(k)-I(k-1)| < sigma (spectre uses |I(k)| < sigma equation)
   voltage tolerance error epi   = RELTOL x|Vref| + VABSTOL where Vref is largest voltage ever found on that node or anywhere in ckt
   current tolerance error sigma = RELTOL x|Iref| + IABSTOL where Iref is largest current ever entering on that node

NOTE: floating nodes cause convergence issues, as the voltage node has infinite soln. So, a GMIN of 1 Gohm is added automatically by tool to get finite soln.

3d. On design variables on left side, add any design var that were in schematic. i.e "vm 24" if vm var was used on schematic.
3E. click on "ac/dc/trans" icon on right side of screen (or on analysis window). This brings up analysis window. choose analyses type as "tran" and stop time as 5u. click OK. Then the analyses window shows the analyses type. Make sure, "Enable" is checked. for tran. 5 analysis type:
 A. AC: here we need AC src and frquency. Put ac source as "vsin". Put DC voltage "vdd/2 V" or whatever bias voltage is, put "AC magnitude as "0.1" V, put "offset" and "amplitude" as 0. This causes ac analysis to run with ac src of 0.1V riding on dc voltage of vdd/2 V. choose analysis as "ac", sweep variable as "Frequency", start as "1" Hz, stop as "10000000" Hz (10MHz), sweep type as "logarithmic". Save the sweep and click OK.
 B. DC: here we run DC analysis, which sweeps a parameter from start to stop in step_size and shows behaviour of ckt with this varying parameter. Ex: To vary DC voltage of parameter VDC supplying voltage to a transistor, we click on dc, select design variable as "VDC", put start=0, stop=3 and ste_size=0.01. Click save, then OK. Then Vdc voltage is varied from 0V to 3V in increments of 10mv. We see current/voltage at all nodes as function of VDC (VDC is shown on x axis instead of time being shown on x axis). Here, all voltage/current are calculated assuming infinite time, after everthing is in steady state (cap/ind are removed since they are open/short in final dc steady state).
 C. TRAN: here time simulation is done with time being swept on x axis. Here cap/ind are considered. For convergence issues, we always ramp up the power supply for tran analysis.
 D. OP: here operating point analysis is done. Very helpful for quickly seeing whether transistors are in sat or not. click on "op", turn on "enabled" for options (uually in options, we have output init file to be dumped back"), click "OK". We provide a dc input voltage, and simulations shows V,I, etc for each node. On ADE, goto Results->Annotate->Selected OP point Instance info/Node voltages. This annotates values on the schematic. We can also do  Results->print->Selected OP point Instance info/Node voltages, which will print voltages on a display window for any nodes that we click on schematic.
 E. STB: It's stability analysis. It  provides a way to simulate continuous time loop gain, phase margin and gain margin without breaking the feedback loop. We use it instead of ac analysis to measure ac loop gain. We place a dc voltage src of "0 V" so that it completely breaks the loop. Then in Results->Direct Plot->Main Form, we can see db plot of gain,phase,etc.

4. Hit on the "green arrow"  button on right side of screen, which says "netlist and run".
5. Once sim completes, to see waveforms, see below section.

NOTE: in ADE, you need to have all signals being driven from within the schematic. No external stimuli/source allowed. The schematic is complete in itself. This is in contrast to Hspice simulator, where we could specify signal stimuli from a text file and connect it to schematic ports.

Waveform viewer: To bring up waveform viewer separately, goto tools->waveform, and it will bring up AWD or Wavescan (whichever is chosen in session->options). AWD is the familiar one. Wavescan is kind of same as AWD (In wavesan in order to split signals do Axis->strips). to bring up simvision or other viewer, we can always goto Tools->SimVision Waves which is same as used in digital runs and shows both analog and digital voltages. To bring up cosmoscope, type tiscope on command line and then load *.pun file (click on File->open->Plotfiles). To bring up wavescan standalone, type wavescan (with SKILL or MDL option) on command line and then load SST2 format file. To bring up awd, type awd on command line and then just provide the dir path of psf dir (where the *.tran file is).

To see waveforms: (on AWD waveform viewer): In icfb 5.1, we have AWD (with very few buttons), while In icfb 6.1, we get "virtuoso visualization & Analysis XL" viewer with lots of buttons.  
1. click on results->Direct plot->main form on virtuoso ADE window that we had above. It brings up "virtuoso visualization & Analysis XL"(for icfb 6.1) or AWD waveform viewer(for icfb 5.1). We can also click on results->Direct plot->Transient Signal on virtuoso ADE window to bring up waveform viewer. However on choosing this option, we don't get to plot selected nets on schematic, so always use "main form".
2. click on any net in schematic, and it will show the waveform for that. DO NOT close the "Direct Plot Form" or else clicking nets won't bring up waveform. All waveforms get cluttered on top of each other, so for icfb 6.1, take cursor to "name" on LHS (where signal names are), then right click and goto "split current strip". This splits all waveforms so it's easy to see. There's also an icon (3rd row, 3rd from last), which says "split current strip" on hovering mouse on top of it. clicking this will also split waveforms. In AWD, it has "switch axis mode" icon on LHS (2nd from bottom), which splits waveforms.
3. To see current thru any net, goto outputs->to be plotted->select on schematic. Then, we click on the node of a component(NOT on the net). It will show a circle on the schematic and show current in waveform viewer. We might have to rerun sim or click on plot output (see below). If using Results->Direct_plot->Main_form, we should select function as "current" and not "voltage". Current is shown +ve for current flowing into the component, while it's -ve for current flowing out of the component. So, for a single component, we'll see +ve current on one node, while -ve current on other node.
4. Calculator is different for icfb 5.1 and 6.1:
 A. icfb 5.1: In AWD, we have a calculator under Tools->calculator. On opening this and selecting any net on schematic, we see VT("/I0/I1/net_name") in window. We can click on plot button (on LHS, 3rd from bottom) to see voltage waveform for that net. This is another way to show waveforms. Here we can manipulate signals to add/sub, etc.
 B. icfb 6.1: click ctrl+N on "visualization and analysis" waveform window. It opens a new tab. click on "calculator" button (bottom panel on the top, towards right). Brings up calculator. On it, goto view. select "custom toolbar" and "schematic selection toolbar" if they are not already selected. click on "vt" for plotting transient voltages. Now on the schematic, click on any signal. That signal will show up as "VT("/hier/signal_name")". If we click on more signals, all of these add up on the stack. Now click on "plot" (3rd panel from the top). This will update the signal on waveform viewer. Signals will be on top of each other. On waveform window, click on "split current strip" tab (third panel from top, fourth from right). Signals viewed are all showing as analog.

waveform dump: signals saved in waveform files can have both voltage/current info. In icfb 5.1, goto outputs->save_all. This brings a pop up showing what we want to save, and upto how many levels deep. By default, "save_nets is set to all" and "levels of hier is set to 2). Similarly for currents to save, we can do same thing in "currents" section (currents is not needed for most debug).
Plot Output:  To plot o/p, 3 ways:
A. goto Outputs->To be Plotted -> select on schematic. Then on clicking on any net on schematic, it adds an entry in Outputs box (on bottom right of ADE window). Now, whenever waveform viewer is called, it will display waveform for these signals. We may need to click on "Plot outputs" button on RHS bottom of ADE window (2 button below netlist and run button) to show the waveform on window. Sometimes, we may need to rerun the sims. "Plt outputs" will not show anything when none of the signals in "outputs" has Plot set to "yes".
B. goto Results->Direct_plot->Main_form. It brings a form. Now we can click on any net in schematic and it will show up in waveform window.
C. goto Tools->SimVision_waves. This brings up simvision. On left side, There are 5 icons and a "x >" on top of those icons. Click on > which will extend those 5. Select top one which is design browser. Then it shows top level module name and all signals. Clicking on any signal name shows the waveform on right side. Clicking on top sign of top level module name, shows lower level module and associated signals. Click on < to hide it again

To run sims again, we can click on "green arrow button" on schematic window itself, instead of clicking it on waveform window. This saves the new sch as well as reruns the sims. click "ctrl" + "r" to refresh the waveform.

Saving state: Before we exit, we can save the current state by clicking on session->save state. We provide a state name, and select what all we want to save. Then, next time, we can load this state, and the analysis type, outputs, design variables, connect rule files, will all be loaded for us.

Running sims on verilog-A instead of schematic:
--------------------------------------
Here we stil use spectre to run, but isntead of schematic at transistor level, we can create models of blocks in verilog-A and then run sims. Remember even schematic transistors have spice models that are run. What we do is create similar models at higher level, or make simpler model of transistors, cap, res, etc, so that it runs faster.
1. create new design in verilogA: File->new->cell_view. Type verilogA. It opens with emacs with module name as the cell name you choose. Enter the VerilogA code. On closing, it asks for creating a symbol. After creating symbol, we can edit symbol too.
 IMP: close the verilog file, else the changes are not compiled. This causes sims to be compiled with older file.
2A. create schematic testbench: create new cell view "schematic" for new cell called "tb_cell_name", open it with "schematics L". Launch ADE-L. choose options (simulator would be spectre). Then run ac/tran analysis.save state into the same cell view.
2B. create config view: We can create config view and run ams, if we don't want schematic to be created. This is explained below.

Running AMS:
-----------
see verilog_ams.txt for verilogA details.

steps for running AMS sims from scratch:
1. Create a top level schematic or verilog-ams file which has various block instantiations and testbench stimuli. For ex, we can create top level vams file (verilogams view) using verilogams editor for a vams testbench. We can also do it in schematic format or in verilog-A format for top level or lower levels. save it.
2. create configuration view. File->new->view (in library manager). library_name=atago, cell_name=tb_top, view_name=config (or config1 or any other name). Type=config and open_with=hier editor. click OK. It pops a new window. Put library=atago, cell=tb_top, view=verilogams (shows whatever views are avilable for that cell. mostly it's schematic view for tb_top). Put values for global bindings as follows:
 Library_list=atago (here usually we put digital lib (msl200_hpa07_2pin))
 view_list=verilogams verilog schematic symbol => here order is imp. If there are multiple views for tb_top, then verilogams as chosen if available, else verilog is chosen and so on. we gave verilogams priority since we want the tool to deal with digital code as much as possible, since it runs faster.
 stop_list=symbol => here we say which view to finally stop at. Tool will keep on descending into lower level instances until it sees symbol for an instance and then it stops at that level. Usually we set it to symbol, since before it gets to symbol, it should have found some other view as verilog or schematic. If we set "stop_list" to verilog, then while descending instances, when the tool encounters verilog view of instance, it will stop there. So, basically it will just descend 1 level of hier and stop. That's bad as we want to descend all the way to lowest hier, where there are no more instances referenced.
 click ok. It brings up a hier editor. click save. It creates this new config view called "config".
3. In Hier Editor:
   A1. Here in table view, we will see all the cells and the view found. We should see all lower level cells instantiated in top level and the view the tool used (view found). We can also force tool to use diff view for an instance by right clicking on "view to use" column for that cell, and set cell view to desired view. We can also set view to some other config file for that cell (if config view exists for that sub cell). Most of the views will be schematic, except for stdlib cells, which will be srcVerilogAMS view.
   A2. We can also look at "Tree view" as it's easier to nagivate. It shows top cell, and hier below it.  It also shows the view used for that hier, and by expanding on "+", we can see cells underneath it, and views used for those. We can open the schematic for any hier cell/module here by right clicking on that module, and clicking "Open read only". Then, in the schematic when we click "e" on any instance, it will show the view used, and will descend into that view. This becomes very easy to see which views got used for each instance, as we descend directly in that view. On the other hand, if we opened schematic directly from lib manager, we wouldn't know which views were used for instances, as the schematic is not associated with any view. Only when we open schematic thru "hier ed" by opening config, is when we see correct views for each instance.
   B. click ADE-L. This opens ADE to run sims on. (on clicking "open" in hier-ed, we open that view (verilogA or whatever view was used to build that config. This may be needed if we need to see the code or edit it).
4. In ADE: Here make sure simulator is set to "AMS", design is set to config view.set outputs->save_all (save all nets, all hier and all AHDL var). Run tran analysis and see results. Tran analysis is run within ncsim cmdline but spectre/TIspice is invoked as needed. "irun" is run with args as needed. It adds args "-discipline logic", "-amsconnrules ConnRules_ss_full1 /db/.../connect/verilog.ams (which is a connrule file)", "-amscompilefile "file:/data/.../AN210/verilog.ams (for text only files)" and few additional settings. It reads Netlist which resides in "netlist/cirNetlist.vams" which is a V-AMS file with all instances in it. It then starts compiling as in digital sims. ncvlog and spectre are run from within irun, and results printed for both. On finding $finish or on hitting "tran time", sim stops.
5. Results can be seen in waveform viewer or SimVision(Tools->SimVision_waves)
6. In Simvision: Open File->open database. Choose psf.trn, and then "open & dismiss". This brings up design browser, which shows all nets, signals etc in top level verilogA/verilog-AMS file.
7. Make changes: To make changes, open verilogA/verilogAMS file, save and close and then rerun analysis in ADE to regenerate psf.trn. In simvison click File->Reload_Database.

steps for running patgen sims in ADE: (when running patgen, we have to use analog mixed signal simulator. In our case, we use ams, which requires config view which says what views to use for each cell/block. Then it runs sims using those views).
----------
Depending on icfb 5.1 or 6.1, the steps below might have different panel than mentioned.
Basic steps are these: create a config view for a simulation schematic (which says what view you want to use for each isntance in that schematic), create a state (which stores all variable values that are used in schematic with a name assigned), run ADE.
NOTE: We need patgen when we have a communication i/f (spi, i2c) and we want to control inputs to those as well as read outputs from them. All pins of digital are connected to anlaog blocks which generate signals internally but communication i/f are the only ones that connect to pads which have to be connected to a pattern generator (patgen.v). All other IC pin chips goto analog and NOT to digital directly.
 
Steps:
1A1. Create functional view for patgen: Run icfb. In CIW, goto File->New->Cellview. In the popup box, type library as "gemini_1p0_sim", cell "patgen", view "functional" and select "HDL reader" as application opener. You will see emacs window open with verilog code "module .... endmodule". fill in your required patgen code inside it. This creates a new block named "patgen" with functional view.
NOTE: When we need to dump vcd files, we need to add dump calls inside the module or create a separate functional view named "digdump" and instantiate it in top level schematic. Ex:
module patgen ( );
   //i2c_read, i2c_write, functions, tasks, etc
   initial begin //process for dumping vcd files
    $dumpvars;
    $dumpfile("/sim/SAKURA_OA/kagrawal/sim/sim_hl_VCORE_tran_nopkg_1p1/digdump.vcd");
   end
endmodule

1A2. Modify patgen: We can also modify existing patgen. Open patgen cell. In lib mgr, goto library (gemini_1p0_sim), cell (patgen), view (functional). Click to open in edit mode. vi editor opens for the verilog file (named as verilog.v). Instead of modifying it in vi, we cam also modify it in this dir using emacs:
Dir: ~/proj/MOTGEMINI_DS_Latest/cds/gemini_1p0_sim/patgen/functional_ka/verilog.v
Once the file is modified, close the vi editor, and checkin the changes.
If you want to create any more functional view, just copy existing functional view and name it "functional_1",etc.
To create a symbol for such functional view: remove any existing symbol in that view dir. then open functional view (verilog.v) in edit mode (using right mouse click open), then make any change, save it and then close it. On closing the editor window for verilog.v, it will show any errors/warnings in verilog.v and ask if we want to create a symbol. Click yes to create a symbol.

1B1. Create new Conf: Top level sim cell will have various "config" views that we can choose. In order to create a new config (when we don't have any available), goto lib mgr: File->New->View. On new popup box, choose correct Library, Cell and view (Lib-> ZORRO_SIM, Cell->zorro_toplevel, View->config_new). Leave Module Context empty, and Tool name as Hierarchy-Editor. Click OK. On new popup box, we'll see correct lib, cell. View would be empty at this time. For global bindings, click on "Use Template", choose Template Name as "AMS", click OK. This will populate View with schematic (Note view has to be schematic) and also populate Library list, View list and stop list in global bindings. Sometimes Library list will not have std cell lib, so add it manually. (Library List = basic msl270_lb7_2pin, View List = ams stop udp verilogams veriloga functional srcVerilogAMS schemTIspiceToplvl schemSpectre sch_simple schematic", stop list = udp stop. click OK. Now, it will open virtuoso hier ed in which we'll see Top cell, global bindings and Cell bindings. Make sure Library list in global bindings has both "basic msl270_lb7_2pin" in it. Look under both table view and cell view to see that there are no errors. You might have to click on "recalculate hier" button to the top panel (2nd from right) to see updated views.

1B2. Open existing Conf: Open config that has the sim setup in it. In lib mgr, goto library (gemini_1p0_sim), cell (zorro_top_vel_gk), view (schematic or config_dig_only or config_ams or some other view). We open config view. click "yes" for configuration and "no" for schematic view. If you want to edit, open in edit mode else open in read only mode. In the hier ed that we get, it will show library, cell and view that we want for that config. If we are modifying it, select lib=gemini_1p0_sim, cell=zorro_top_level_gk and view=schematic (since we want to run sim on schematic of zorro_top_level_gk). Make sure global bindings are correct (should be pointing to std cell lib and main project lib: i.e "basic pml48_1533c035_2pin gemini_1p0 tiva". view_list should be set to all possible views for any cells in these lib: i.e "ams stop verilogams srcVerilogAMS veriloga functional schemTIspiceToplvl schemSpectre sch_simple schematic" => tool picks up the first view that if finds for a cell from this list going left to right. So, if srcVerilogAMS view is found for a cell as AN210, then that view is picked up instead of schematic view.

1C. Explained in 1B1 above. On cell bindings, we indicate which view to be used for each cell in that lib. click on cell (to arrange by cell name), scroll to patgen cell, change the view by clicking right mouse on "functional_ka" or whatever view is there. click "set cell view" and set it to "functional" or whatever you want it to set. This makes the simulator pick up functional view for our patgen symbol in schematic. You will see most of the other views (for analog blocks) are set to schematic (and some are set to ams view. For digital blocks, view should be set to srcVerilogAMS (NOT to schematic). click on file->save to save it. click on view->update to see any changes in views. Keep hier ed open or close it.

NOTE: open a config view. When we open any config view (other than schematic view), we get a pop-up box, asking if we want to open configuration (config_dig_only) and/or top cell view(schematic). If we choose configuration, we get the hierrarchy editor, which shows what views are being used for different blocks/gates/etc. If we choose top cell view, we get the normal schematic opened, which has config name written on the top panel (config: ... config_dig_only), so that we know, that it's the schematic for that config. The recommended way to open schematic for a config view is by selecting yes for "config", no for "top cell". Then on the config view window, we can open up the schematic by clicking "open" on next to Library, cell, view. We can also open schematic from ADE window by going to session->Schematic_Window. The schematic should be the same either way, as it's the one for that config view. Now, if we hit e on any block on this schematic, we can see what view it's using for that block. For ex, if we hit e on patgen block, it shows the view as "functional_gk_digital_only". This is what we should see from the hier ed also in patgen cell. Click yes on configuration and no on top cell view to open the hier ed for that config view.
Note that if we just open the raw schematic from the view list, it opens the schematic with no config name written. This is the base schematic that doesn't have proper views for different blocks. (This schematic is not a config view. AMS simulator an't be run on this schematic as it doesn't have any config view) All other views are config views, and we can either see them as schematic or in hier ed. We should open one of the config views, as that has proper views defined for each cell. Diff config views are different schematics with different models for blocks being used (ie clk block may use functional model or schematic depending on the view).
NOTE: We can go from raw schematic (cell "zorro_toplevel_ka", view "schematic") to config view too. Just follow step 2,3 below and change the view to config view in step 3A. Then it will bring up new schematic with config view written on top of the schematic bar.From here, we can open ADE. However, this is not recommended.

2. In hier ed, click open ( After Library, Cell, View boxes in the first row) and it will open up the schematic for that config.In schematic window that opened, click Tools->Analog env. Opens ADE.

3A. Sim Setup: In ADE (icfb 5.1), do setup: click Setup->Design. In new box, choose lib name(gemini_1p0_sim), cell name (zorro_top_level_gk), view name (config_dig_only). Leave open_mode in read. click OK to close the box. Now, in ADE, click Setup->choosing_sim/dir/host. choose simulator as ams. (we choose ams because spectre, TIspice, etc aren't capable of running mixed signal sims). By default, TIspice4 is chosen. change it to ams, else you will see bunch of errors related to udp primitives. Leave proj dir to be whatever it is (/sim/MOTGEMINI_DS/kagrawal/Latest/sim).click ok

3B. Connect Modules (CM):  These are needed whenever signals go from digital(logic) to analog(electrical) or vice-versa. D2A and A2D connect modules are already provided by cadence which are basically verilogAMS code written within them to convert signals. Depending on spec of connectrules file, they are automatically inserted b/w logic and electrical. For multiple supply voltage, we need multiple logic discipline defined in connectrules file. CM rule files are put in "ConnectLib" library. They reference other E2L, L2E, etc std modules which are also in same dir, and have view "module". they have verilog code in them, and are provided by cadence to be modified and used.  There are 2 types of connect modules: Std connect modules (E2L/L2E) & Supply sensitive connect modules (E2L_ss/L2E_ss)

 3B1. Std connect modules: These are std A2D and D2A connect modules written in verilogAMS. D2A converts logic 0/1 to electrical VDD/VSS, while A2D vice-versa. These modules don't have any VDD/VSS supply pins, so VDD/VSS to be driven out is hardcoded in the module. That's why we have CM with different voltages, and we choose one that suits our supply voltage. See pg 132/166 of modeling notes.
In ADE (icfb 5.1), click on Setup->Connect Rules (It only shows up if simulator is ams. choose simulator as ams, if it doesn't show up) => It shows connectLib Library and the rules that exists in the cells of that lib. These rule files figure out the connectivity voltage for E2L (anlaog,E to digital,L), L2E (from digital,L to analog,E). It shows a list of connect Rules in the top window. These are the rules that are used for analog/digital interface. It has built-in and customized rules that we can choose from. On choosing a rule and clicking "add" it shows up the rule in top panel. We need to enable a rule in order to activate it. (on enabling, comment sign "#" in front of the rule goes away). To disable a rule, click "disable". Rules are only for digital logic drivers(L2E) and receivers(E2L). "View" shows connect rules .vams file. If built in rules don't suffice, "Customize" allows us to customize that particular rule file to create a new rule file. Customize brings up a new window, which has connect modules E2L, L2E, etc. E2L shows for a given supply voltage on the (digital receiver) cell, what VH from analog should be treated as 1 (usually 70% of Vsupply) and what VL should be treated as 0 (usually 30% of Vsupply) going into digital block, along with the edge rate. Similarly L2E shows for a given supply voltage on the (digital driver) cell, 1 should be treated as what voltage (usually vsupply), and 0 should be treated as what voltage (usually 0v) when going into analog side, along with the transition rate. (For L2E, there is no option to provide vhi, as it's taken to be equal to vsup). to customize, click on the rule (ie. E2L_O). It will show up parameters below. click on "vsup" parameter, it will show the value below. To change, replace that value with "1.5" for ex. similarly change vthi to 1.2, vthlo to 0.3. Click Apply to apply these changes. Similarly do it for L2E_O (vsup to 1.5, vlo to 0). Usually these will suffice. Click OK. It will create a modified rule with type "Modified built in". Add that Modified rule to the list, and click OK. Now, that custom rule along with other built in rules that we specified in top box are going to be used. We'll need to save list of connect rules in the state, or else state will have default rules. Goto Session->Save_state so that this saved state can be loaded in step 5.
NOTE: we not only need to save state, but also need to copy the new custom rule into "connectLib" Library, so that we can use it for other sims. If you look at custom connectrule file (by clicking view), you'll see that it's saved in that local sim dir. So, we click "copy" and save it in a new library "connectLib_custom" (we create new library "connectLib_custom" beforehand since icfb won't allow us to save any new rules in "connectLib" library as it comes from central database for that tech). Once we save our custom rulefile in that library, it will appear in drop down menu of "Rules Name" so that we can select it and save it in state of other sims.

3B2. Supply sensitive connect modules: Non-std extension provided by cadence that can automatically observe supply voltage, and drive pins accordingly. The only difference is that A2D and D2A CM here have internal supply nodes (no input/output defn) defined using supplySensitivity & groundSensitivity keyword. See pg 138/166 of modeling notes.
 Extra lines in A2D and D2A CM (note these are internal signals)
  electrical (* integer supplySensitivity="cds_globals.\\vdd!";*) vdd; //V(out) <+ f(V(vdd));
  electrical (* integer groundSensitivity="cds_globals.\\vss!";*) vss; //V(out) <+ f(V(vss));

 Now, vdd/vss ports are added on all digital modules, and all I/O pins of these digital modules have supplySensitivity & groundSensitivity  added to them. Now these pins can have correct analog voltages when connected to electrical signals. Appr A2D and D2A get connected b/w analog and digital by looking at supplysensitivity pins.

I. connect rule: basic connect rule specify connect rules for all digital/analog interface logic, and is the same rule for all verilog modules. However, if we have 2 or 3 different digital blocks with different power supply, we need to use "supply sensitivity" connect rule. can turn off connect rule and do supply sensitivity.
Goto setup->Connect rule. Choose Rules_Name "connectLib.ConnRules_ss_mid", click customize, change the mode to split for E2L_ss, L2E_ss, Bidir_ss (by selecting that "connect module declarartion and choosing mode "split" (not merged). Then clicking apply will show "split" mode. do it for all 3). click OK. It will create new connect rule "ConnRules_ss_mid1". click on that rule, hit rename to rename it (new popup box) to something meaningful like "ConnRules_ss_mid_split". Now we enable this rule and disable any other existing rules. If we view on this connect rule file, we see that it doesn't have any vsup info, as it picks up the power supply from the pwr pins in the module. It just has vthi, vtlo which is set as a % of pwr supply voltage. Now save this state by session->save_state.

II. schematic change: Now, for functional blocks which have verilog code, we cp existing cell, functional view into "cell_name_ss" and keep functional view name same. Then, we open functional view for cell_name_ss in edit mode. In the verilog file that opens, change module name to match cell name (i.e if cell=patgen_ss, module name should be patgen_ss), add 2 ports VDD,VSS and provide supply sensitivity (ss) to all input/ouput pins as follows: (Not sure if we can do "electrical VDD" or "electrical VSS" instead of using input)
module clock_ss     ( output reg (* integer supplySensitivity = "VDD";
                                    integer groundSensitivity = "VSS" ; *) osc_clk_o,
                      output reg (* integer supplySensitivity = "VDD";
                                    integer groundSensitivity = "VSS" ; *) nreset_o,
              input VDD,
              input VSS
                      );
#Now on saving it, it will create a new symbol. Now goto top level schematic for mixed signal sims, and replace symbols in schematic with new symbols for digital blocks that have functional code in them. New symbols will have pins VDD,VSS. Hook it up to appr power supply. Note that for digtop, we didn't need to do anything, as it's gate level schematic, and the stdcells in it are using srcVerilogAMS which already have "supply sensitivity", so they don't need any connect Rules file. They were already getting simulated based on power supply flowing to these gates. If digtop was verilog/RTL code, then we would have needed to provide ss on all i/o pins of digtop, so that tool could drive them correctly. Save the schematic and rerun "netlist+run".

4. In ADE, click session->option. choose waveform_tool as WaveScan (easier to see waveforms than in AWD). Wavescan can view files in *.? format, while AWD can view files in *.tran format. click OK.

5. In ADE, click on session->load state. choose lib and cell as whatever you have above. Choose state to load. Each state has design variables, analyses type, outputs, custom connectLib etc stored. So, when we load that state, we get all of those on ADE box. If this is the first time, then we have to create a state. For that, in ADE, we double click on design variables panel, and add variables in the new "edit design var" window. Same way we do for Analyses and Outputs. Then we save this state by going to Session->save_state,and providing a state name. Remember we can also edit any var in ADE by double clicking it.

6. Netlist and Run: In ADE, click on Simulation->Netlist and Run to start running sim. Can also click on traffic light signal on RHS (3rd from bottom). It will take about 15min to run. It shows a progress bar at the bottom for netlisting. Once it's done netlisting, it will show log file window and on completion, it will bring up Waveform viewer Wavescan. To just run, without netlisting, click on 2nd bottom traffic light. To view netlist click simulation->netlist->display

NOTE: to find out if the run succeeded, goto Simulation->Output log->netlister.log,compiler.log,elaborator.log and simulator.log which get generated in this seq. All 4 log files should be w/o any error.

7. Waveform viewing: See info above for viewing waveforms.

8A. Other options: In ADE for icfb 5.1:
A. Simulation->options->Compiler => compile options. add additional arguments (verilog compiler) as +define+TI_functiononly
B. Simulation->options->Elaborator => timescale, sdf, timing, pli, access, msg, other options. add additional arguments as +define+TI_functiononly (at the bottom, need to scroll down)
C. Simulation->options->AMS => pli/vpi, msg, other options. add additional arguments as +define+TI_functiononly
All these options cause ADE to run dig sim in function only mode (no delay)

D. Setup->Environment => can change netlist options (i.e what to add, preserve in netlist) and waveform output file options (PSF is for Wavescan/AWD while Punch is for cosmoscope). These waveforms get stored in simulation dir(specified in setup->simulator/dir/host)/sim_name/TIspiceD/schematic/psf dir. *.pun files are punch files for cosmoscope while *.tran files are for AWD.

8B. Other options: In ADE for icfb 6.1:
Goto simulations->options->AMS Simulator. Here on Main form under other options ( on scrolling down), there are arguments that can be provided for compiler, elaborator and simulator. Add "+define+TI_functiononly" to make digital work in 0 delay mode. There are also other options for SDF, Timing, etc.

Hierarchy Editor: . In schematic window, click on tools->hier editor (or clcik on Hierarchy-Editor button directly). This brings up hier ed box, where we can see what cells and corresponding views are being used. View to use is what decides what view we are going to use if any. For ex, we see patgen under cell, and corresponding view as func_gk_digital.  If we open that view in lib mgr, we'll see the patgen verilog file. For ex, for cell "MUX_4bit", we see view to use as "sch_blank" => blank sch that's in there is being used for this cell.

Sims complete and *.vcd dump file generated in file specified in $dumpfile function (only if patgen or digdump module with dumpvars is there). It can be loaded in nWave and viewed (it's converted into *.vcd.fsdb). NOTE: you'll have to use reload button (shift+L) in nWave to reload new vcd file, as vcd.fsdb is not updated automatically.

Dir in ADE: In step 3 above, we specified sim dir. All results/files are dumped in this dir
----------
sim dir: /sim/MOTGEMINI_DS/kagrawal/Latest/sim
In this, we have the top level cell dir: zorro_toplevel_gk
In this, dir: ams, TIspiceD, spectre (we use ams from cadence, so we'll goto ams dir. TIspiceD is an internal mixed signal simulator, while spectre is cadence analog simulator)
In ams dir, we have all views. For us, we have config_dig_only as the view. goto "config" dir.
In this, we have netlist dir (where netlist and other files kept) and psf dir (all log files kept. Imp dir). We'll have to usually look in psf dir, various nc*.log files to see what options were used for running digital sim. Look at simulation.log to see messages printed while running sim.
 

Cadence locks held:
---------------
to find out if you have any locks for any design, goto virtuoso CIW (NOT library manager) and then click on File->Make Read Only. It pops up a box, that shows all the cell views that have locks on them.

Cadence dir structure:
--------------------------
Library:
-------
Cadence orginizes itself in terms of libraries. There are several system-wide libraries that hold generic parts such as transistors, resistors, and-gates, or-gates, etc. However the name of these libraries varies from process to process. These libraries are listed along side your own personal libraries where you will create schematics, layouts, HDL code, etc...

cell:
--------
Each library contains several "parts" called cell. For instance, you could have a library called "my_digital_parts" and then a cell called "two_to_one_MUX" for a multiplexer.

View:
----
Each cell has atleast one view associated with it. Each view is literaly a view of the part. For instance, you may have a schematic view, which is the physical schematic of the part. You may have a symbol view, which is what you would see if you included that part as a sub-part of another schematic. You could also have a functional view that is a verilog description of the part. When you simulate a design, you can use the heirarchy editor to tell the simulator which views to use when it simulates that perticular cell view.

create new design:
----------------
To create new lib, from lib manger, do File->New->Library.
To create new cell,  from lib manger, do File->New->CellView.
Now start creating new schematics.

Dir structure: NOTE: /db/<PROJECT> and /dtat/<PROJECT> are same dir. Project is in /db/ but all user area is in /data/. sometimes it shows different, not sure why?
--------------
cds dir: has 1 critical file "cds.lib" and several sub-dir. (at TI, cds dir is /data/<PROJECT_NAME>/cds. However, this doesn't contain any cds.lib file. Reason is as follows. when we run setup_user in /data/<PROJECT_NAME>/dotfiles dir, we create a link to /data/<PROJECT_NAME>/users/kagrawal/<PROJECT_NAME> in ~/proj/<PROJECT_NAME>. This "/data/<PROJECT_NAME>/users/<USER_NAME>/<PROJECT_NAME>" dir is the main dir from where each user runs icfb and creates lib, cell, etc. So, this is where all the .lib files reside). so, at TI, dir named cds is not real cds dir. Real cds dir is ~/proj/<PROJECT_NAME> dir. We just have a "cds" dir created in this dir, where all library such as lbc7, msl270_lbc7_2pin, GEMINI_1p0, GEMINI_dig1p0, etc reside.

Libraries in cds dir:
--------------------
ex: ZORRO2_dig1p0 library has these 3 files: cdsinfo.tag (simple ascii file), data.dm and tech.db (binary files). These files are created when we create a new dir and attaching a tech lib (i.e lbc7,etc) to it. data.dm and tech.db contain all info about where to find all the components from. To see what tech file got attached, we can goto CIW in icfb, and click on Tools->Technology file manager. Then we click on dump (on technology tool box). On new pop up box, we choose Technology library for which we want to read contents of. Let's say, we choose ZORRO2_dig1p0, we check "select all", provide ascii technology file name, as /tmp/tech.ascii, and click OK. It brings up tech.ascii in emacs, and shows refTechlibs as lbc7, layer Definitions (poly, PMOAT, METAL1, VIA1, etc), via definition, etc. If we want to make any changes to this tech file, we can edit it, save it and then load this file from "Technology tool box". data.dm,tech.db gets modified accordingly. If we dump tech file for lbc7 library, we see much larger ascii file with tech layers, tech displays, layer rules, via defs (std and custom), minspacing, etc.

Besides the 3 files, ZORRO2_dig1p0 has dir for each cell, which has subdir for each view (symbol, schematic, layout). These view dir have the actual database, such as sch.oa. It also has master.tag and data.dm.

If we look in lbc7 library, we'll see similar dir for each of the cells, which are a link to /data/pdkoa/lbc7/2012.05.07/cdk/* dir. Look in pdk.txt for details.

~/proj/<PROJECT_NAME> dir: This dir in addition to having "cds" dir, also has .lib, .cdsrc and .cdsinit files. cds_artisan.lib files have lowest priority and are set by the admin and settings apply to all projects. project.lib files have next higher priority and are set specifically for this project. finally, cds.lib belonging to the user has highest priority of all the .lib files. This priority happens because cds.lib has SOFTINCLUDE to cds_artisan.lib, cds_project.lib.
Apart from *.lib files, we've artisan.cdsrc, artisan.cdsinit and project.cdsrc and project.cdsinit.

cds.lib files:
-------
This file tells cadence where to find libraries. It usualy has one INCLUDE or SOFTINCLUDE line at the top of the file that tells cadence where to find the system-wide libraries. It can also have SOFTINCLUDE to other .lib files. Following this line there may be several DEFINE lines that define your local libraries. You may edit this file by hand via "vi" .

Many .lib files in the dir:

A. assura_tech.lib: paths to all assura tech libs
B. cds_artisan.lib: has include to companywide cds.lib file. Also has path to all tech lib(lbc8), ref lib(pml30_lbc8_2pin) and assura lib.
C. cds_project.lib: paths to all user lib at project level such as "DEFINE  HAYATE_dig1p0 /data/NOZOMI_NEXT_OA/cds/HAYATE_dig1p0". These defines are the reason that when we delete "HAYATE_dig1p0" lib and create a new "HAYATE_dig1p0" lib, the path to that is set to "/data/NOZOMI_NEXT_OA/cds/HAYATE_dig1p0". If this DEFINE wasn't there, then the path to any new lib would be in the dir where we ran icfb (i.e path would be /data/<PROJECT>/users/kagrawal/<PROJECT>/HAYATE_dig1p0).
D. cds.lib: This has highest priority and has SOFTINCLUDE to cds_artisan.lib, cds_project.lib and then maybe DEFINE for HAYATE_dig1p0 lib. If the DEFINE for HAYATE_dig1p0 is already there in cds_project.lib, there's no need to redefine it here, unless we want to change the path.
NOTE: when we manually move/delete some lib, then cds.lib gets messed up. Best way is to close icfb, and restart it again with everything UNDEFINE in cds.lib (or DEFINE commented out). Then cds.lib gets written with correct DEFINE in cds.lib. There's always an issue with cds.lib, when manual unix changes are done, while icfb is open. So, always close icfb.

other files:
-----
.cdsrc file: env file => Used to set env. for ex artisan.cdsrc has: "setenv ARTISAN_PROJECT /data/NOZOMI_NEXT_OA", etc. artisan.cdsrc also has lib var settings. i.e: path for pdk (/data/pdkoa/lbc7/2012.05.07), digital models for stdcells that should be used when running our digital synthesis/PnR flow.  project.cdsrc is empty.

.cdsinit file: cds function,etc to setup cadence. For ex artisan.cdsinit has: "projSimPath = getShellEnvVar("ARTISAN_SIMDIR")". project.cdsinit is commented out, so kind of empty.

various *.log files to keep logs. verilogIn produces verilogIn.log, defIn produces defin.log.

cds dir structure:
----------------
--------------------------------------

---------------------------------------------
Load final netlist and def files to cadence cds: For top level chip integration
----------------------------------------------

1. goto particular proj dotfiles dir and run setup_user. This creates project link in ~/proj/<project> pointing to /data/<project>/users/kagrawal/....
cd /db/YELLOWSTONE/dotfiles/ > ./setup_user creates link in ~/proj/YELLOWSTONE -> /data/YELLOWSTONE/users/kagrawal/YELLOWSTONE
2. cp ~rraja/.ihdlEnvFile_ys_digital in your home dir. This file will save some typing later. Modify it based on the project. It's called in step 4 below.
3. cd ~/proj/YELLOWSTONE. Run icfb here. (Note: all cds lib links are set in this dir for icfb to run)
VerilogIn:
---------
4. Import verilog:
0). Instead of creating new library this way, we can also do it using defIn process mentioned in DefIn section (bullet 6).
On cadence CIW (cmd interpreter window, NOT the lib mgr), goto File->new->Library. In the new box, enter name as "yellowstone_dig1p0" (or whatever library name you want to have). This library gets added in the dir path specified in the box below "Directory" scroll menu. MAke sure, it's the path that you want (It should be something like "/data/NOZOMI_NEXT_OA/cds", always put designs in cds dir). If not, click on ".." in Directory structure, unless the correct path appears in the box. NOTE: cds.lib file gets automatically modified in ~/proj/<PROJECT_NAME> dir to show new library with it's path. It first "UNDEFINE" that lib when we delete it, and then "DEFINE" when we create new lib.
check that "attach to an existing techfile" box is checked. click apply, It opens new box, with the new design library name and Technology library to choose from. choose appropriate tech lib and click OK. For our case, it's lbc8. this Tech lib has sch/symbol/layout for all basic components (as mosfets, res, cap, diode, metal, via, etc), that are being referenced in other digital and analog lib. (If you forget to do this step, during def file import, you get errors like met1,vias,etc not found, tech file empty, and you don't see any metal/via layers in layout). then close main window (new library window). Do NOT click OK as the library is already at this time.
1). On cadence CIW (cmd/log window, NOT the lib mgr), goto File->import->verilog.
NOTE: Valid for icfb 5.1 version: Here, you can load file (using load button from top) from dir ~/.ihdlEnvFile (cp file from ~/scripts/ihdl_model_file_verilog_import to ~/.ihdlEnvFile and make required changes in file). This will do all steps 2 to 9 below for you. However, this doesn't show up anymore in infb 6.1 version, so do steps 2 to 9 manually.
2). Enter "yellowstone_dig1p0" under Target Library Name => to create new lib with this name
3) "basic" and "msl270_lbc7_2pin" "other hardIP" only under Reference Libraries. => to point to these lib. "basic" lib has gnd/pwr/io pins sch/symbol which are needed in generating schematic, while "msl270_lbc7_2pin" has schematic/layout for all gates,etc. Note that the schematic/layout of these gates have components (mosfets, res, cap, diode, metal, via) that have reference to tech library (i.e lbc8), so we need to define tech library in step 0 above. If we look at size of files, we see that size of layout file for NCH_1 is about 400KB while size for IV110 is 20KB. IV110 layout file is much smaller as it only has refrences for NCH_1, PCH_1, metal, via, wells, etc. NCH_1 layout files are large, as they have actual drawing.
NOTE: Any component that is referenced in verilog file in step 4 is checked for in the cells of these reference lib for a matching name. If any component/module is not found, then the import step complains. So, if we have any other hard macros in verilog, appr lib should be added under Reference Libraries.
4)  Path name to file under Verilog files to import: /db/YELLOWSTONE/design1p1/HDL/FinalFiles/digtop/digtop_final_route.v =>Final verilog files
5) (-f and -v options left untouched)
6) Path to verilog models under -y (/db/pdk/lbc7/rev1/diglib/msl270/r.0.1/verilog/models) => same as ones we use in RTL/gate sims in Testbenches dir under irun options. NOTE: If the imported netlist has vdd/vss for all gates, then leave this option blank, else it gives errors: power ports not found in verilog model. To be safe, always leave this option blank.
6B) check "overwrite existing views". others optional: select all for "overwrite symbol views". check "create symbol only" for Verilog cell modules.
6C) On bottom for "verilog cell modules", select "import" option (default is "create symbol only").
7) Click on "Global net options" tab (valid only in icfb 5.1. In 6.1, it appers on the same form). check that Power Net Name is VDD and Ground Net Name is VSS. Make sure these are Correct pwr/gnd net names by going to schematic of any lib gate, and checking Power/Gnd pins.
NOTE: verilog netlist doesn't have pwr/gnd pins for cells (eg cell INV has pins A and Y, but no VDD/VSS pins). Cell schematic from ref lib (in step 3) has pwr/gnd pins on top of i/o pins. So, we need this step to connect all such pwr/gnd pins to net named VDD/VSS.
8) Click on Schematic Generation Options tab: From the default options, check   Ignore Extra pins on symbol.
   - basically you need "Full place and route", "Generate square schmatics", "Extract schematics" and "Ignore Extra pins on symbol"  checked, and everything else unchecked. "Full place and route" is to generate schematics which have wire connection. To have air connection in schematic (for clarity or when the design is large), we should leave "Full PnR" unchecked. click OK. Then OK on main window (Verilog In)
9) when "VerilogIn import completed" box pops up, we are done with import. clcik Yes to look at log file. Goto bottom, and make sure "checked in symbol digtop" and "checked in schematic digtop" appear at the bottom of logfile. Make sure all schematics are closed, else you may not see "digtop" in cell view.
-----
NOTE: on CDS.log file (goto help->View CDS log file on CIW window), we'll see verilogIn process with values filled in for the form:
CCSverilogIn
hiiSetCurrentForm('impHdlOptionsFormMain)
 impHdlOptionsFormMain->impHdlImportFileTabMain->page1->impHdlTargetLibField->value="ATAGO_S1_20140224" "ATAGO_S1_20140224"
 impHdlOptionsFormMain->impHdlImportFileTabMain->page1->impHdlRefLibField->value="basic" "basic"
 impHdlOptionsFormMain->impHdlImportFileTabMain->page1->impHdlRefLibField->value="basic" "basic "
 impHdlOptionsFormMain->impHdlImportFileTabMain->page1->impHdlVerYCmdFileField->value="/db/pdkoa/1533e035/current/diglib/pml48h/verilog/models/" "/db/pdkoa/1533e035/current/diglib/pml48h/verilog/models/"
 impHdlOptionsFormMain->impHdlImportFileTabMain->page1->impHdlRefLibField->value="basic pml48h_1533c035_2pin" "basic pml48h_1533c035_2pin"
 impHdlOptionsFormMain->impHdlImportFileTabMain->value=2 2
 impHdlOptionsFormMain->impHdlImportFileTabMain->page2->impHdlPowerNetField->value="VDD" "VDD"
 impHdlOptionsFormMain->impHdlImportFileTabMain->page2->impHdlGroundNetField->value="VSS" "VSS"
 impHdlOptionsFormMain->impHdlImportFileTabMain->value=3 3
 impHdlOptionsFormMain->impHdlImportFileTabMain->page3->ihdlOptionsIgnoreExtraPins->value= t t
 impHdlOptionsFormMain->impHdlImportFileTabMain->value=2 2
 impHdlOptionsFormMain->impHdlImportFileTabMain->value=1 1
 impHdlOptionsFormMain->impHdlImportFileTabMain->page1->impHdlVerDesignField->value="/db/ATAGO_OA_DS/sync/users/kagrawal/Latest/verilog/design2p0/Autoroute/S1/vdio/dbs/final_files/S1_final_noPwr.v" "/db/ATAGO_OA_DS/sync/users/kagrawal/Latest/verilog/design2p0/Autoroute/S1/vdio/dbs/final_files/S1_final_noPwr.v"
hiFormDone(impHdlOptionsFormMain)
INFO (VERILOGIN_GUI-13): Verilog Import process has started ...
----

5. Schematic is created at this time, under view for all cells in "yellowstone_dig1p1" library. Check schematic
------------------
1) Open the schematic by selecting "Digital_Top_Level" (digtop) under cell and right clicking shematic under view. Opens up schematic, but Pwr/Gnd are not connected (floating wires are connected to these). To connect these to proper pwr supply, do: (make schematic editable first)
2) Check -> Hierarchy opens up new box. (check the "every schematic" box) . click OK and go back to main schematic window. On doing check and save, we see proper power connections. On modules, we see new dots VDD/VSS (not ports, but seen as dots on schmatic), which make connections to std cell pwr/gnd pins within that module. we also get pwr/gnd connections to all cells at top level or within modules. However, the schematic still doesn't have pwr/gnd ports yet.
3a) icfb 6.1 => goto File -> Netlist@TI -> Verilog@TI(give path to final files: /db/YELLOWSTONE/design1p1/HDL/FinalFiles/digtop/digtop_cadence.v) - this writes out the verilog file that can be used for simulations, sta etc. Keep name as *_cadence.v. NOTE: this netlist doesn't have vdd/vss pins or vdd/vss connections to gates. It's similar to what we get from PnR tool. If we chose some other option for generating netlist, then we would have got netlist with VDD/VSS pins on all cells, which we could not run any sims on (since digital library has cells with no vdd/vss pins). There are netlisting options here: Basically select all (Ignore supply pins, keep view list as "behavioral functional verilog schem_Complex schematic symbol" and stop_list as "verilog". That way, tool will keep on finding schematic for all modules/sub-modules and since no verilog view exists for any of these sub-modules, so it will finally descend into gates in library. Over there it will find verilog view and finally stop there. Same happens with hard IP also, where it finally stops at verilog view of these hard IP. May mistake, if we have verilog view exist for any of sub-module, then we won't descent into sub-module and hence won't be able to get complete netlist).
3b) icfb 5.1 => OBSOLETE: goto Design->Netlist->Verilog@TI to generate netlist.
4) close the schematic now.

6. Import def files now, to create layout. Importing Def (FinalFiles/Digital_Top_Level_FINAL_PC.def)
-------------
DefIn:
----
1) File -> Import -> Def (in CIW)
1a)  Type in the path to the def file (From FinalFiles dir) => /db/MOTGEMINI_DS/design1p0/HDL/FinalFiles/digtop/digtop_final_route.def
2) for target library name, we can enter  "yellowstone_dig1p1" or whatever library name is
3a) only for icfb 5.1: cell name = digtop, view name = layout. check  the "use [] Ref Library Names" box (and provide the 2pin library name) => msl270_lbc7_2pin. If there are more libraries for hardmacros, provide their name too.
3b) only for icfb 6.1: Under ref Tech lib, enter lbc8 or whatever was entered during start. NOTE: this is tech name and NOT ref lib name. target cell name "Digital_Top_Level" (in our case, it's digtop, so enter digtop here). target view name "layout"
4) provide def file name: /db/NIGHTWALKER/design1p0/HDL/FinalFiles/digtop/digtop_final_route.def  
5) When creating new library using DefIn, check "new Library" box. Creating new library using VerilogIn method above (in import verilog section) may not work, as it may not get the proper "tech lib name" attached (when we click on properties of a digital library, we should see lbc7 under "techlibname". If that doesn't showup, that means "techlibname" didn't get attached). In "Tech from library" choose lbc7. Here, we sometimes don't have an option to specify "path of digital library", so do NOT use this method if library path is not what you intend. Use VerilogIn method.
6A) only for icfb 5.1: May need to scroll down: In component master views, type "layout". If you forget this, you won't see any component layouts such as layouts of and, or, etc.
6B) only for icfb 6.1: component view list "layout" => Important to do this, otherwise gate layout will have abstract view (won't show layouts of and, or etc)
7) only for icfb 6.1: master library list => library name, i.e Msl270_lbc7_iso_2pin (add hard IP name if any such as sram, efuse, etc)
8) only for icfb 6.1: check "Create CustomVias only" in the DEFIN window. else we get "OALEFDEF-50159: warnings for matching via rule used since there is no via rule specified".
9) only for icfb 6.1: check "use gui fields".
10) OK => It will take sometime to genrate layout
NOTE: we'll get CORESITE errors for each row like: ROW CORE_ROW_0: The siteDef CORESITE was not found. This row was ignored. Ensure that the site is defined in the technology database. => These are OK.
11A only for icfb 5.1 => Open layout in edit mode, and on the new laypout panel,  tools->layout (to get into layout mode, then it shows the LSW panel and TI Tools, TI utils, buttons). goto: TI Tools->Edit->Add Pin Lables @TI. This puts pin names for all the pins. then Save it.
11B only for icfb 6.1: Open layout in edit mode. Goto File->editable. goto: Create->Pins@TI->Add Pin Labels@TI. This puts pin names for all the pins. then Save it.

IMP: If layout still shows only boundary for std cells, press "shift" + "f" to view guts of cells.
---------
NOTE: In CDS.log file, we'll see exact cmd used for defIn:
defin -def \"/data/.../final_files/DIGCORE.def\" -lib DIGCORE_1P0 -techRefs \"1533c035\" -cell digtop -view layout -viewNameList 'layout' -masterLibs 'pml48_1533c035_2pin ATAGO_BL01536064080 gs40_core'
------

10. this creates all 3 views for digtop cell: layout, schematic and symbol. It also generates 2 views for all other cells: schematic and symbol.

The top level cell for the whole design is called "toplevel_1p0" under some library. Inside this schematic, we'll find instantiation of "digtop" cell called as Idigtop.

NOTE: If after check and save, schematic shows warnings/errors, we can goto Check->Find_Marker on schematic and it will show all errors/warnings. We should look thru this to make sure none of them is real.

----------------------------------
NOTE: when we get an error during def import into icfb, it's usually generated vias in VDD/VSS power rings, , which can't be mapped correctly.
ERROR: (OALEFDEF-50093): NET VSS: The layers of via viadcuM1_0p3x0p3_OA at ( 1323800 488400 ) do not match the route segments. Following route segments for this net might not be created on the correct layer. Ensure that the vias used in this design are specified in the correct order.
ERROR: (OALEFDEF-50096): ROW CORE_ROW_43: The siteDef CORESITE was not found. This row was ignored. Ensure that the site is defined in the technology database.

These errors can be fixed by creating a new lib in these steps:
1. Do a def import first: File->import->def from CIW. check "new library" and select Technology from library as "lbc7". check "create customvias only". Leave everything the same way as it would be normal defin. Click ok. This not only creates a new library, but also crates a layout for digtop. You will see custom vias in "cell list" (VIA12, VIAGEN12_1, etc) along with digtop. Now digtop layout will reference these vias from this cell dir in "ZORRO2_dig1p0" and not from "lbc7" library.
2. Now do Verilogin the same way as would be for normal verilogIn.

This will fix the error - 50093, but not 50096. That's OK. Just open layout and make sure VIAGEN12_1, etc are there. These vias should not get replaced by other vias, nor should they be missing.
-------------------------------------

generate gds from layout:
-------------------------
Goto icfb cwi. Goto File->Export->Stream_out. On new popup box, use library browser to goto appropriate layout.
ex: Library name=NIGHTWALKER_1p0, Topcell_name=digtop, View=layout. For output, select stream DB, Provide output file name as digtop.gds. Click OK, and it generates gds file in the same dir from where icfb was invoked.
To generate layer map file (since this gds file has layer numbers but not layer names), goto icfb ciw. goto PDK_Utils->General_usage->Tool_boxes->Design_info_tool_box. On new box, click  on "create Laff/stream layer map". On new box, specify laibrary for layer mapping, i.e"pml48_lbc7_2pin", map file type "stream", give a new layer mapping file name, leave Run_on_layers as "all", and click OK. This generates the layer mapping file in the same dir from where icfb was invoked.

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

Run LVS/DRC on layout:
---------------------
LVS: open layout of top level design "digtop". In layout window, goto Assura -> Run LVS. Everything should be filled by default. In view Rules Filescheck that "Technology" is checked, choose appropritae Technology (for lbc8: it's lbc8_assura). Then everything below it will get filled in appropriately.
check for these (even though they are filled in automatically)
For Schematic Design Source: Library=HAYATE_dig1p0, Cell=digtop, View=schematic
For Layout    Design Source: Library=HAYATE_dig1p0, Cell=digtop, View=layout

If running Extraction also (after running lvs), run these 3 steps:
1. Click on "Set Switches" and select "BLACKBOX, DSPF_SPEF", click OK. This fills in the switch names with "BLACKBOX DSPF_SPEF".
2. Check "View avParameters", click on "Modify avParameters". On new box, click on "?blackboxCell", check "Use in run", do not select "cells", but select file by putting in the filename "cell_list.bbox" with the fullpath (ex: /data/pdk/lbc5/rev1/diglib/tla950/r1.3.0/doc/cell_list.bbox). do the same step for "?dspfCells". Here check "Use in run", for "which cells?", choose "specified in a text file", and for file "put samefilename "/data/pdk/lbc5/rev1/diglib/tla950/r1.3.0/doc/cell_list.bbox". then repeat this step for "?ignoreCell" if any filler cells exist in design (as we don't want assura to analyze these cells). check the "use in run" box, and then provide list of cells in "Ignore Cells" box (ie SPAREFILL1 SPAREFILL2 etc).
3. click OK once done with this. That removes the pop up box. Make sure that modified av parameters appear in the box below avParameters.

click OK , and then lvs starts running. Progress is shown on anew box. After couple of minutes, new box pops up, that shows LVS results.

click OK on this new box, to see detailed lvs results pop up box. clicking on View->Compare LVS summary shows quick summary. click on other buttons to see detailed results.

cross reference layout and schematic:
-------------------------------------
Once LVS is complete, any net/device on schematic can be refrenced to that on layout.

Run Assura RCX on layout (spef generation)
-----------------------------------------
Once LVS is complete, close lvs window. goback to Layout window and click on Assura->Run QRC (or Run RCX). If LVS was run just before this, then "QRC Parasitic Extraction Run Form" box pops up. If LVS wasn't run immediately preceding this, then a different box pops up, asking for the LVS run dir, from where LVS results should be picked up. Once that LVS dir is provided, we get the "QRC Parasitic Extraction Run Form" box.
0. click on run details tab. This shows the run directory where LVS was run. Make sure it points to the place where LVS ran.
1. In setup tab, set RuleSet to min corner = lbc5_3m_minC_minvia. Set Output to Spef, and name to digtop_min_coupled.spef. This spef file gets written to dir where icfb was invoked (i.e /data/EPSTINGRAY/users/kagrawal/EPSTINGRAY/*), so to change dir,click on ".." box next to name, and choose appr dir.
2. In Extraction tab, set extraction type to RC, Temperature to appr value (for min, T=-40. check in create_rc_corner in create_views.tcl file in Autoroute dir), cap coupling mode to Coupled, and ref node to ground of the ckt (Look in the layout to see what is the gnd node at top level. Sometimes layout folks put a ring around at the digtop wrapper level, which changes the name of pwr/gnd net. Look in the schematic too. For our case, it's GND at wrapper level)
3. In filtering tab, enter power/gnd nets that we want excluded from spef file. QRC won't extract these nets. This is needed as verilog netlist doen't have pwr/gnd, so existence of pwr/gnd in spef file causes errors. Power net name is whatever appears in top level schematic (eg Power nets is "V3P3", and gnd net is "GND" and "PBKG")
3. In netlisting tab, set "sub node character to ":", and Bus Bit to "<>" (<> is needed as schematic/layout has bus with <>. So, setting <> makes the tool write out spef file honoring <> as bus bits [top of spef file says "*BUS_DELIMITER <>" implying bus bits are within <>]. Else, it will treat them as special characters, and precede them with \< or \>, which is incorrect). NOTE: spef file generated from PnR tool has bus bits within [], so that spef file has "*BUS_DELIMITER []" at top.

A QRC Run Progress box appears, and then final box appears showing the run was successful.
Results are in /data/EPSTINGRAY/users/kagrawal/EPSTINGRAY/digtop_min_coupled.spef

close the OK box, and rerun assura QRC for max corner. Choose RuleSet to max corner = lbc5_3m_maxC_maxvia. Set Output to Spef, and name to digtop_max_coupled.spef. Set Temperature to max temp (i.e 190), "sub node character to ":", and Bus Bit to "<>". Final results in /data/EPSTINGRAY/users/kagrawal/EPSTINGRAY/digtop_max_coupled.spef

We get both max and min spef files.

---------------------------------------------------------------
Steps in running netlister and TI-spice simulator in virtuoso ADE:

1. First netlisting is done.
2. Now, TI-spice is invoked with cmd as: /apps/tispice/4.2.3p1/bin/tispice --plugin_path /apps/tispice/4.2.3p1/plugins/suse64 --plugin tispice raw/input -o "shm://../psf/input.shm" .... --digsim irun => starts running simulator in dir: /sim/ATAGO_OA_DS/kagrawal/Latest/sim/sim_AFE1_tran_kailash/TIspice4/schematic/netlist
3. Parse netlist, walk AST and check analysis to make sure the analysis can be carried out (Dc, AC, etc)
4. Circuit is expanded: Many warnings when expanding circuit:
 A. MESSAGE: Usually non-fatal. Messages for compiling VAMS files, or other HDL related messages.
 B. WARNING:
    1. EXPANDER-28: * WARNING * Device xafe0.xamp0.xbias.xdd5.darea is shorted to avdd and will be removed. (EXPANDER-28) => This is when src/drn/gate are shorted together, so that the transistor is just a wire, so is removed.
5. setting up simulation: Here topology checking is done. Typical warnings:
 A. TOPOLOGY-59: WARNING * MOS device xafe0.xamp0.xmmn18.mn9999 has floating source/drain node xafe0.net12 (TOPOLOGY-59) => This is when either of src/drn is floating. This usually happens for spare transistors or when o/p of transistor(src or drn) is not connected to anything.
 B. TOPOLOGY-50: * WARNING * Following dangling devices will be removed: xafe0.xrbias.xrr3.rh2 xafe0.xrbias.xrr3.rb2  (TOPOLOGY-50) => this is when one end of resistor is not connected to anything (as in spare resistor), so it's removed.
 C. TOPOLOGY-2: * WARNING * Node trim[12] was dangling (added GMIN conductance to ground). (TOPOLOGY-2) => this is when the node is floating, so very high resistance added to gnd.
 D. TOPOLOGY-51: * WARNING * Following net will be removed after pruning dangling devices: xafe0.xrbias.net016 (TOPOLOGY-51) => after removing dangling devices, nets associated with those are also removed.

6. Now analysis is run (from start time to stop time in steps) and final job summary is shown. It shows "Simulation: PASS" at end.

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

DEF: design exchange format.
------------------
has logical design data (netlist) and physical design data (routing, placement location,etc).
most of the file syntax same as that for LEF

#def file => comments preceded by #
VERSION 5.7 ;
DIVIDERCHAR "/" ;
BUSBITCHARS "[]" ;
DESIGN digtop ;
UNITS DISTANCE MICRONS 2000 ; => Specifies the convert factor used to convert DEF distance units into LEF distance units. 2000 implies that 1 micron in lef file is equiv to 2000 database units (dbu) in def file. All unnits in def file are in terms of dbu. Allowed values for dbu are 100, 200, 1000, 2000.

PROPERTYDEFINITIONS
    COMPONENTPIN designRuleWidth REAL ;
    DESIGN FE_CORE_BOX_LL_X REAL 25.500 ;
    DESIGN FE_CORE_BOX_UR_X REAL 881.300 ;
    DESIGN FE_CORE_BOX_LL_Y REAL 27.200 ;
    DESIGN FE_CORE_BOX_UR_Y REAL 829.600 ;
END PROPERTYDEFINITIONS

DIEAREA ( 0 0 ) ( 1813000 1713200 ) ; => coord of die in dbu

ROW: shows all rows that are there. Each row has a name.
---
syntax: ROW <row_name> <row_type> <origin_X origin_Y> <orientation> {DO x BY 1 STEP <sp_x 0>  or DO 1 BY y STEP <0 sp_y> } => in x BY y, if x=1, it's vertical row. if y=1, it's horizontal row. Mostly designs have horizontal rows, so y=1. x then denotes the number of repeating columns that create this row. sp_x denotes spacing_b/w_cols_in_horizontal_row, while sp_y denotes spacing_b/w_rows_in_vertical_cols.

ex:
ROW CORE_ROW_0 CORESITE 51000 54400 FS DO 503 BY 1 STEP 3400 0 ; => row "CORE_ROW_0" present in site "CORESITE" with origin (51000,54400) dbu (=51000/2000,54400/2000 = 25.5um,27.2um). orientation is flip south. this row has 503 cols, where each col has 3400 dbu of spacing.  3400 spacing is taken from M2 pitch in tech lef file (M2 pitch=1.7um in tech lef file, which translates to 3400 dbu). So, each row has a width of 503x3400=1710200, add left and right offset of 51000 and we get the x dimension of die to be 1813000.
similarly for next row and so on ...
ROW CORE_ROW_39 CORESITE 51000 1632000 N DO 503 BY 1 STEP 3400 0 ;

TRACKS: tracks defined for each metal layer in both x and y dirn. router can only route on tracks.
------
syntax: TRACKS {X | Y} <start> DO numtracks STEP space [LAYER layerName] ; => X indicates vertical lines, while Y indicates horizontal lines. start is the x or y coord of first line. space indicates spacing b/w tracks, We specify both horizontal and vertical tracks for each metal layer.
TRACKS X 3400 DO 533 STEP 3400 LAYER MET3 ; => vertical lines for met3 starting from 3400dbu, repeat it 533 times with spacing of 3400 dbu.
TRACKS Y 3400 DO 503 STEP 3400 LAYER MET3 ; => similarly horizontal lines for met3.
TRACKS Y 3400 DO 503 STEP 3400 LAYER MET2 ;
TRACKS X 3400 DO 533 STEP 3400 LAYER MET2 ;
TRACKS X 3400 DO 533 STEP 3400 LAYER MET1 ;
TRACKS Y 3400 DO 503 STEP 3400 LAYER MET1 ;

GCELLGRID: Defines the gcell grid for a standard cell-based design.
---------
Each GCELLGRID statement specifies a set of vertical (X) and horizontal (Y) lines, or tracks, that define the gcell grid. You select a gcell grid based on routing resources for the floorplan. Every track segment must belong to a gcell. The gcell grid partitions the routing portion of the design into rectangles, called gcells. A gcell grid in which all gcells are the same size is called a uniform gcell grid, otherwise it's a non-uniform grid.

syntax: GCELLGRID {X <start> DO numColumns+1 STEP space} {Y <start> DO numRows+1 STEP space} ; x=vertical, y=horizontal. space specifies spacing b/w tracks.

ex: There are 3 diff gcells formed below. 1st is gcell of size=800x31800, 2nd is gcell of size=(44x3400)x(121x3400), 3rd is gcell of size=3400x3400. so, everything inside the core is a uniform grid.
NOTE: GCELLGRID stmt keeps on getting modified at different stages of PnR flow by the routing tool, so that it works with optimal grid size. In the ex below, final gcell grid used insixde core was 64000x64000 (i.e 400 times of initial gcell grid size)

GCELLGRID X 1499400 DO 2 STEP 800 ; => starts at (1499400,4117400) and forms 1 gcell grid of size=800x31800
GCELLGRID Y 4117400 DO 2 STEP 31800 ;

GCELLGRID X 3400 DO 45 STEP 34000 ; => starts at (3400,3400) and forms 44x121 gcell grid of size=3400x3400
GCELLGRID Y 3400 DO 122 STEP 34000 ;

GCELLGRID X 0 DO 2 STEP 3400 ; => starts at (0,0) and forms 1 gcell grid of size=3400x3400
GCELLGRID Y 0 DO 2 STEP 3400 ; =>

VIAS: same as in lef file (these vias are defined in def file so that they can be referenced locally from here, wherever they are used. If they are not not defined here, then during import of def file in virtuoso, tool will try to see if these exist in Tech library. If yes, then it will map these vias with those present in tech library, else it will give an error "via not found" and drop the vias from imported layout).
----
- VIAS12 => defines a single via b/w M1 and M2. This via is defined in tech lef file. Since units is 2000 in lef file, all dimensions in lef file are multiplied by 2000. So, VIAS12 M1 rect of (-0.25 -0.35 0.25 0.35) gets translated into (-0.25*2000 -0.35*2000 0.25*2000 0.35*2000) = (-500 -700 500 700)
 + RECT METAL1 ( -500 -700 ) ( 500 700 )
 + RECT METAL2 ( -500 -500 ) ( 500 500 )
 + RECT VIAS1 ( -300 -300 ) ( 300 300 )

- VIAS12A => variation of via12. This via is rotated version of VIAS12, so that's it's longer in X, and shorter in Y.
 + RECT METAL1 ( -700 -500 ) ( 700 500 )
 + RECT METAL2 ( -500 -500 ) ( 500 500 )
 + RECT VIAS1 ( -300 -300 ) ( 300 300 )
 ;

- VIAGEN12_3 => This via was generated in tech lef file using "VIARULE VIAGEN12 GENERATE". This is used for vias in power ring vdd/vss. It has a array of 14 vias spread over M1/M2 and named as VIAGEN12_3. Other shapes of vias that are generated for vdd/vss at the corner is named VIAGEN12_1, etc. These are instantiated in special nets section below.
 + PATTERNNAME VIAGEN12_5.0000_2.0000_I7F
 + RECT METAL1 ( -5000 -2000 ) ( 5000 2000 )
 + RECT METAL2 ( -5000 -2000 ) ( 5000 2000 )
 + RECT VIAS1 ( -4500 -1000 ) ( -3900 -400 )
 + RECT VIAS1 ( -4500 400 ) ( -3900 1000 )
 + ..... => 14 such vias spread on metal1/metal2
 + RECT VIAS1 ( -3100 -1000 ) ( -2500 -400 )
;
END VIAS

-- VIAGEN12_3 can also be defined as viarule instead of specifying 14 vias separately. This makes it more compact, but then these custome vias might not get generated correctly during def import to icfb. See in cadence_virtuoso.txt for more details.
- VIAGEN12_4
 + VIARULE VIAGEN12G => here viarule specified for generating this via "VIAGEN12_4" using viarule VIAGEN12G. This viarule "VIAGEN12G" needs to be defined either here or should exist in virtuose tech library, else we'll get error about "missing via defn" during def import to icfb.
 + CUTSIZE 300 300
 + LAYERS MET1 VIA1 MET2 => layers specified
 + CUTSPACING 550 550 => spacing b/w vias
 + ENCLOSURE 600 600 600 600 => overhang on all sides b/w cut layer and metal layer
 + ROWCOL 1 11
 ;

COMPONENTS: placement info of all stdcells
---------
COMPONENTS 1694 ; => 1694 total components
- spr_0/FE_OFCC104_tie_hi_net0 BU170 + SOURCE TIMING + PLACED ( 1043800 860200 ) N ; => initially all cells are unplaced. PLACED impliesit's placed and  component's location can be moved by automatic tools while FIXED implies component's location cannot be moved by automatic tools. We always provide location co-ordinates and orientation. Co-ordinates are always specified for the lower left corner of cell, irrespective of orientation. N=North, FN=flipped North. N,S,E,W refer to rotation at origin in clockwise dirn, while FN,FS,FE,FW refer to flipping across y axis.
#N=>cell placed normally (crossbar on bottom left, so VDD on top and VSS on bottom)),  
#E=>crossbar on top left. It's N rotated by 90 degrees clockwise so that VSS is on left side while VDD is on right side. Normally this orientation does not apply to stdcells but to routes.
#S=>crossbar on top right, so VSS on top and VDD on bottom, S is N rotated 180 deg clockwise),
#W=>crossbar on bottom right. It's N rotated by 270 degrees clockwise (or 90 degrees anti-clockwise) so that VSS is on left side while VDD is on right side. Normally this orientation does not apply to stdcells but to routes.
- FILLER_2173 FILLER2 + SOURCE DIST + PLACED ( 241400 4097000 ) FS .... ;
- Imtr_b/hs_pos_tmp_dly_clk_reg_0 DTCD2 + FIXED ( 1332800 3199400 ) FS + WEIGHT 1 ;
END COMPONENTS

PINS:
----
PINS 411 ;
- n_puc + NET n_puc + DIRECTION INPUT + USE SIGNAL
  + LAYER MET2 ( -2000 0 ) ( 0 2000 )
  + FIXED ( 0 4138000 ) E ;
- ...
- ana_sel_native + NET ana_sel_native + DIRECTION OUTPUT + USE SIGNAL
  + LAYER MET2 ( 0 0 ) ( 2000 2000 )
  + FIXED ( 590200 0 ) N ;
 ;
END PINS

SPECIALNETS: used for pwr/gnd. These VDD/VSS pins are present for all stdcells in lef file, where PIN VDD has "USE POWER", while PIN VSS has "USE GROUND". So, PnR is able to connect pwr/gnd pins of stdcells correctly to VDD/VSS routes in floorplan.
----------
SPECIALNETS 2 ;
- VSS
  + ROUTED MET1 7600 + SHAPE FOLLOWPIN ( 17000 207400 ) ( 1482400 * )
     NEW MET1 7600 + SHAPE FOLLOWPIN ( 17000 125800 ) ( 1482400 * )
     ...
  + USE GROUND ;
- VDD
   + ROUTED MET1 7600 + SHAPE FOLLOWPIN ( 17000 17000 ) ( 1482400 * )
     NEW MET1 7600 + SHAPE FOLLOWPIN ( 17000 71400 ) ( 1482400 * )
     ...
   + USE POWER ;
END SPECIALNETS

NETS
---
NETS 2941 ; => total no. of nets is 2941
- dcdc_ldo_00/FE_PHN147_N46 => name of the net is dcdc_ldo_00/FE_PHN147_N46
  ( dcdc_ldo_00/FE_PHC147_N46 Y ) ( dcdc_ldo_00/FE_PHC140_N46 A ) => component pin names
#now wiring specified by + COVER | + FIXED | + ROUTED | + NOSHIELD
  + ROUTED MET1 ( 314300 1098300 ) ( 315700 * 0 ) =>  + ROUTED means wiring can be moved by tool. It's routed on MET1 with the rectangular co-ords given. co-ords are for centerline of wire. The wire is 1/2 width on one side and 1/2 width on other side. "*" specifies that the y-coord last specified is used. So, here,* means 1098300. The third value of 0 specifies how far the wire is extended at specified point (default is half the routing width for that layer). so, be default, wire is extended 1/2 width on both the end points of center line. If value was 5, then wire is extended 1/2 routing width + 5 units.
    NEW POLY ( 314300 1098300 ) ( * 1105300 ) CONTSPLY1 => NEW indicates a new wire segment, i.e there's NO wire segment b/w last specified segment and next coord. CONSTPLY1 implies there is a via "CONTSPLY1" at the last specified coord. * means x-coord is 314300.
    NEW MET1 ( 314300 1105300 ) ( 315700 * ) VIAS12
    NEW MET2 ( 315700 1105300 ) ( 317100 * )
    NEW MET2 ( 317100 1085700 ) VIAS12 => if only one co-ord specified, it's just a point in MET2 (it's width * width square since it's extended on all sides). VIAS12 is placed on this MET2 wire.
    NEW MET5 0 + SHAPE BLOCKWIRE ( 557000 748375 ) VIAGEN45_22 => here loc of generated via is specified. so, this via defined above will beplaced here.
    NEW MET5 750 ( 1375 0 ) ( * 749750 )
+ SOURCE TIMING
 ;
- Idigital_mux/n154 ...;
END NETS

--------
ENDDESIGN => ends design digtop def file


LEF : library exchange format - developed by cadence
-----------------------------
An ASCII data format, used to describe a standard cell library. Includes the design rules for routing and the Abstract of the cells, no information about the internal netlist of the cells. Usually kept as 2 files, a tech lef file, and a design lef file.

A LEF file contains the following sections:
1. Technology: layer, design rules, via definitions, metal capacitance
2. Site: Site extension
3. Macros: cell descriptions, cell dimensions, layout of pins and blockages, capacitances.

1. The technology is described by the Layer and Via statements. To each layer the following attributes may be associated:
-type: Layer type can be routing, cut (contact), masterslice (poly, active), overlap.
-width/pitch/spacing rules
-direction
-resistance and capacitance per unit square
-antenna Factor

Manufacturing Grid: Defines the manufacturing grid for the design. The manufacturing grid is used for
geometry alignment. When specified, shapes and cells are placed in locations that
snap to the manufacturing grid.
MANUFACTURINGGRID value ;

I. Layers are defined in process order from bottom to top
poly masterslice
cc cut
metal1 routing
via cut
metal2 routing
via2 cut
metal3 routing

A. Cut Layer definition: Defines contact layer (top layer and bottom layer) for via

LAYER layername
TYPE CUT;
SPACING => Specifies the minimum spacing allowed between via cuts on the same net or different nets. This value can be overridden by the SAMENET SPACING statement (we are going to use this statement later)
END layerName

B. Implant Layer definition: Defines implant layers in the design. Each layer is defined by assigning it a name and simple spacing and width rules. These spacing and width rules only affect the legal cell placements. These rules interact with the library methodology, detailed placement, and filler cell support.

LAYER layerName
TYPE IMPLANT ;
SPACING minSpacing
END layerName

C. Masterslice or Overlap Layer definition: Defines masterslice (nonrouting) or overlap layers in the design.
Masterslice layers are typically polysilicon layers and are only needed if the cell MACROs have pins on the polysilicon layer.
Overlap layer is used for overlap checking for rectilinear blocks (i.e L shaped blocks). Obstruction descriptions in the macro obstruction statements refer to the overlap layer

LAYER layerName
TYPE {MASTERSLICE | OVERLAP} ;
...

D. Routing Layer definition
LAYER layerName
TYPE ROUTING ;
DIRECTION {HORIZONTAL | VERTICAL} ;
PITCH distance;
WIDTH defWidth;
OFFSET distance ;
SPACING minSpacing;
RESISTANCE RPERSQ value ; => Specifies the resistance for a square of wire, in ohms per square. The resistance of a wire can be defined as RPERSQU x wire length/wire width
CAPACITANCE CPERSQDIST value ; => Specifies the capacitance for each square unit, in picofarads per square micron. This is used to model wire-to-ground capacitance.


II. Via: Defines vias for usage by signal routers. Default vias have exactly three layers used: a cut layer, and two layers that touch the cut layer (routing or masterslice). The cut layer rectangle must be between the two routing or masterslice layer rectangles.

VIA viaName DEFAULT TOPOFSTACKONLY
FOREIGN foreignCellName [pt [orient]] ;
RESISTANCE value ;
{LAYER layerName ; => layer1, layer2 and cut layer specified here
{RECT pt pt ;} ...} ...
END viaName

Via Rule Generate: Defines formulas for generating via arrays. Use the VIARULE GENERATE statement to cover special wiring that is not explicitly defined in the VIARULE statement. Rather than specifying a list of vias, we can specify viarule to generate cut layer geometries.

VIARULE viaRuleName GENERATE
LAYER routingLayerName ;        => layer1
{ DIRECTION {HORIZONTAL | VERTICAL} ;
OVERHANG overhang ;
METALOVERHANG metalOverhang ;
| ENCLOSURE overhang1 overhang2 ;}
LAYER routingLayerName ;        => layer2
{ DIRECTION {HORIZONTAL | VERTICAL} ;
OVERHANG overhang ;
METALOVERHANG metalOverhang ;
| ENCLOSURE overhang1 overhang2 ;}
LAYER cutLayerName ;            => cut layer
RECT pt pt ;
SPACING xSpacing BY ySpacing ;
RESISTANCE resistancePerCut ;
END viaRuleName

Same-Net Spacing: Defines the same-net spacing rules. Same-net spacing rules determine minimum spacing between geometries in the same net and are only required if same-net spacing is smaller than different-net spacing, or if vias on different layers have special stacking rules.
These specifications are used for design rule checking by the routing and verification tools.
Spacing is the edge-to-edge separation, both orthogonal and diagonal.

SPACING
SAMENET layerName layerName minSpace [STACK] ; ...
END SPACING

------
2. Site
SITE siteName
CLASS {PAD | CORE} ;
[SYMMETRY {X | Y | R90} ... ;] (will discuss this later in macro definition)
SIZE width BY height ;
END siteName

------
3. Macro
MACRO macroName
[CLASS
{ COVER [BUMP]
| RING
| BLOCK [BLACKBOX]
| PAD [INPUT | OUTPUT |INOUT | POWER | SPACER | AREAIO]
| CORE [FEEDTHRU | TIEHIGH | TIELOW | SPACER | ANTENNACELL]
| ENDCAP {PRE | POST | TOPLEFT | TOPRIGHT | BOTTOMLEFT | BOTTOMRIGHT}
}
;]
[SOURCE {USER | BLOCK} ;]
[FOREIGN foreignCellName [pt [orient]] ;] ...
[ORIGIN pt ;]
[SIZE width BY height ;]
[SYMMETRY {X | Y | R90} ... ;]
[SITE siteName ;]
[PIN statement] ...
[OBS statement] ...

Macro Pin Statement
PIN pinName
FOREIGN foreignPinName [STRUCTURE [pt [orient] ] ] ;
[DIRECTION {INPUT | OUTPUT [TRISTATE] | INOUT | FEEDTHRU} ;]
[USE { SIGNAL | ANALOG | POWER | GROUND | CLOCK } ;]
[SHAPE {ABUTMENT | RING | FEEDTHRU} ;]
[MUSTJOIN pinName ;]
{PORT
[CLASS {NONE | CORE} ;]
{layerGeometries} ...
END} ...
END pinName]

Macro Obstruction Statement
OBS
{ LAYER layerName [SPACING minSpacing | DESIGNRULEWIDTH value] ;
RECT pt pt ;
POLYGON pt pt pt pt ... ;
END


-----------------------
TI tech lef file: pml30_lbc8_tech_3layer.lef
It has general info, then defines layers, vias, viarules, and lastly spacing

VERSION 5.4 ;
NAMESCASESENSITIVE ON ;
BUSBITCHARS "[]" ;
DIVIDERCHAR "/" ;
UNITS
  DATABASE MICRONS 2000 ; => conversion factor from lef to def is 2000. means numbers in lef file should be multiplied by 2000 before being used in def file.
END UNITS

MANUFACTURINGGRID 0.100 ;

--overlap layer --
LAYER OVERLAP
    TYPE OVERLAP ;
END OVERLAP

#poly and cont layers are there only in lbc5 and earlier tech files for 2 metal layer files. Router routes on all layers in the tech lef file that have "TYPE ROUTING", so, router will start from default bottom layer, which may be POLY or MET1, depending on this file.

--poly and CONT layer --
LAYER POLY
  TYPE          ROUTING ;
  ...
END POLY

LAYER CONT
  TYPE  CUT ;
  SPACING       0.7 ; => min spacing b/w vias is 0.7um
END CONT

--metal1 layer --
LAYER MET1
TYPE        ROUTING ;
  ANTENNAAREARATIO 100.0 ; => max legal ant ratio, using area of metal wire that is not connected to diffusion diode
  ANTENNADIFFAREARATIO PWL ( ( 1 1000 ) ( 100 10000 ) ( 500 50000 ) ) ; => Specifies the antenna ratio, using the area of the metal wire connected to the diffusion diode. You can supply an explicit ratio value or specify piece-wise linear format (PWL (diff_area1 ratio1) (diff_area2 ratio2) .. ), in which case the ratio is calculated using linear interpolation of the diffusion area and ratio input values. So in our ex, it means that if diffusion area of 1 is connected to the metal wire, then a ratio of 1000 should be used instead of a ratio of 100. If diffusion area of 100 is connected to the metal wire, then a ratio of 10000 should be used and so on. Note that with diffusion diode connected, antenna ratio is not infinity, as a diff diode can only allow so much current to pass thru it.
  DIRECTION    HORIZONTAL ;
  PITCH        1.7  ;
  OFFSET    0  ;
  WIDTH        0.6 ; => M1 width is 0.6, but M2 and M3 width is 0.8
  SPACING    0.7 ; => min spacing is 0.7um for wires less than 15um wide for M1,M2,M3.
  SPACING    1.5 RANGE 15 9999 ; => min spacing is 1.5 (instead of 0.7) for wires with width b/w 15 to 9999.
  AREA 1.92 ; => min area for M1 is 1.92um^2
  //res/cap/edge cap values below used to be there, but moved to cap table now.
  RESISTANCE  RPERSQ 0.066 ; => res is 0.06ohm/sq (sq=W/L)
  CAPACITANCE CPERSQDIST 0.1 ; => cap is 0.1pf per sq um
  EDGECAPACITANCE 0.1 ;
END MET1

--via1 layer --
LAYER VIA1
  TYPE    CUT ; => It's a cut layer and not routing layer
  SPACING    0.8 ; => min spacing b/w vias is 0.7um
END VIA1

--similarly for MET2, VIA2, MET3 --

--Vias--
-- via defined here is as such:  met1 is rect of (1.2,0.8), via1 is square of (0.6,0.6), met2 is rect of (0.8,1.0). met1 and met2 are not symmetric, since met1 runs horizontal with min width=0.6um while met2 runs vertical with min width=0.8um.
VIA VIAS12 DEFAULT
  LAYER MET1 ;
    RECT -0.600 -0.400 0.600 0.400 ;
  LAYER VIA1 ;
    RECT -0.300 -0.300 0.300 0.300 ;
  LAYER MET2 ;
    RECT -0.400 -0.500 0.400 0.500 ;
END VIAS12
 
--similarly for VIAS12A/B/AB, VIAS23, VIAS12DCN/E/S/W (double cut vias with orientation North,East,South,West), VIAS23DCN/E/S/W --

--top of stack via --
VIA VIAS23T DEFAULT TOPOFSTACKONLY
  LAYER MET2 ;
    RECT -0.700 -0.700 0.700 0.700 ;
  LAYER VIA2 ;
    RECT -0.400 -0.400 0.400 0.400 ;
  LAYER MET3 ;
    RECT -0.600 -0.400 0.600 0.400 ;
END VIAS23T

--viarule --  These specify rules for multiple via generation as in power rings.
#It describes a formula for generating via cuts using DIRECTION. If you specify DIRECTION, the WIDTH range is based on the connecting horizontal or vertical wire, not the layer of the connecting wire. Therefore, a horizontal wire that is between 0.6 and 14.9 units wide and a vertical wire that is between 0.8 and 14.9 units wide will trigger ViaGen12, independent of whether the horizontal wire is M1 or M2. It will create vias of 0.6x0.6 with an overhang of 0.3 on all sides and spacing of 1.4 on all sides b/w adjacent vias
VIARULE VIAGEN12 GENERATE
  LAYER MET1 ;
    DIRECTION HORIZONTAL ;
    WIDTH 0.6 TO 14.9 ;
    OVERHANG 0.3 ;
  LAYER MET2 ;
    DIRECTION VERTICAL ;
    WIDTH 0.8 TO 14.9 ;
    OVERHANG 0.3 ;
  LAYER VIA1 ;
    RECT -0.3 -0.3 0.3 0.3 ;
    SPACING 1.4 BY 1.4 ;
END VIAGEN12

--similarly for viagen23--

--spacing--
SPACING
  SAMENET VIA1  VIA1    0.800 ;
  SAMENET VIA1  VIA2    0 STACK ;
  SAMENET VIA2  VIA2    0.900 ;
END SPACING

END LIBRARY

-----------------------------------------------
TI core lef file: pml30_lbc8_core_2pin.lef
It has PnR info for all stdcells.

--initial info same as that for tech file, i.e version, units,etc--
#SITE => defines smallest size cell (1.7um is the pitch). It has cell height defined for CORESITE. All rows are in CORESITE (in the .def file), so PnR tool understands that it has to route VDD/VSS every 13.6um.
 SITE CORESITE
 SYMMETRY Y ;
 CLASS CORE ;
 SIZE 1.7 BY 13.600 ;
 END CORESITE

#MACRO for all stdcells.
MACRO IV110 => inv x1
  CLASS CORE ;
  FOREIGN IV110 0.000 0.000 ;
  SIZE 5.100 BY 13.600 ; => size 3 pitch wide.
  ORIGIN 0.0 0.0 ;
  SYMMETRY X Y ;
  SITE CORESITE ;
  PIN A => i/p pin A. i/p pins are all in Met1
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT => pin shape in metal1
      LAYER MET1 ;
      RECT 1.300 5.800 3.100 6.800 ;
      RECT 1.300 5.800 2.100 7.400 ;
    END
        ANTENNAGATEAREA 2.580 ; => antenna gate area to use for antenna ratio (AR) calc
  END A
  PIN Y => o/p pin Y. o/p pins are all in Met1, except for few complex cells, where it's in Met2, but internally routing is still all in Met1
    DIRECTION OUTPUT ;
    USE SIGNAL ;
    PORT
      LAYER MET1 ;
      RECT 3.000 8.100 4.700 9.100 ;
      RECT 3.000 7.900 4.600 9.100 ;
      RECT 3.800 2.800 4.600 9.100 ;
      RECT 3.700 2.800 4.700 3.800 ;
    END
    ANTENNADIFFAREA 1 ; => o/p pin is always connected to diffusion area, so specifies diff area to use for AR calc
  END Y
  PIN VSS => gnd pin VSS
    DIRECTION INOUT ;
    USE GROUND ;
    SHAPE ABUTMENT ;
    PORT
      LAYER MET1 ;
      RECT 0.000 -1.900 5.100 1.900 ;
      RECT 0.700 -1.900 1.700 3.500 ;
    END
  END VSS
  PIN VDD  => pwr pin VDD
    DIRECTION INOUT ;
    USE POWER ;
    SHAPE ABUTMENT ;
    PORT
      LAYER MET1 ;
      RECT 0.000 11.700 5.100 15.500 ;
      RECT 0.700 10.200 1.700 15.500 ;
    END
  END VDD
  OBS => metal1 obstruction layer, we only have obs in met1 as stdcells only use Met1 internally to connect.
    LAYER MET1 ;
    RECT 13.400 4.000 14.200 8.300 ;
    RECT 16.000 6.200 16.800 8.300 ;
  END
END IV110

--similarly for all other stdcells--

END LIBRARY

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

UVM: unified verification methodology. UVM created in 2009. It's just a bunch of sv files with lot of tasks, functions, classes, etc already written, so that you don't have to write it. You just have to learn how to call them.
---
NOTE: In sv, classes are created at runtime, as opposed to verilog/vhdl, where all instances are elaborated before runtime.



We can use irun/xrun with -uvm option which then allows us to access cadence uvm library. Top level design units that show while compiling are uvm_pkgs (uvm_pkg.sv cdns_uvm_pkg.sv cdns_uvmapi cdns_assert2uvm_pkg) and tb.sv

uvm library files are usually installed in these paths for Cadence simulator:

ies: /apps/cds/incisiv/14.20.01/tools/methodology/UVM/CDNS-1.1d/additions/sv/ => for uvm 1.1 (all files are system verilog files)

xcelium: /home/.../cadence/xcelium/19.01.v001/tools/methodology/UVM/CDNS-1.2/sv/ => for uvm 2.0

Within this "sv" dir are multiple dir. Source code is in dir = src

src/uvm_pkg.sv => It's a package, with bunch of include files (*.svh) in it

src/uvm_macros.svh => It has bunch of include files for macro defn (*_defines.svh) in it. This is not a package, just a regular file with include files which have various macro defines (i.e `define uvm_delay(TIME) #(TIME);)

There are bunch of more dir in "src" that has all of these include files, and all other files needed by uvm (i.e src/base/uvm_root.svh has run_test task, ..).

sample tb testbench: => no test being called in this
---------------
module tb;

import uvm_pkg::*; // uvm package imported, these 2 lines needed
`include "uvm_macros.svh" //uvm macro included (to get all defn)

initial begin
  `uvm_info("TEST", "Hello!!!", UVM_LOW) //NOTE: no semicolon at end since it's replaced by the macro defn found in uvm_macros.svh
end

endmodule : tb

cmd:
---
irun -uvm tb.sv => -uvm compiles uvm pkgs (uvm_pkg.sv cdns_uvm_pkg.sv). Then module tb is compiled. Then ncsim is run, which causes "initial" block in tb to run. It prints "HELLO!!!" from that block

screen o/p:
-----------
SVSEED default: 1                                                               
ncsim> source /apps/cds/incisiv/14.20.017p1/tools/inca/files/ncsimrc                      
ncsim> source /apps/cds/incisiv/14.20.017p1/tools/methodology/UVM/CDNS-1.1d/additions/sv/files/tcl/uvm_sim.tcl    => This has bunch of tcl proc which parse various uvm cmds for option correctness, before calling the uvm package (i.e uvm_version proc finally calls uvm_pkg::uvm_version)
UVM_INFO tb.sv(12) @ 0: reporter [TEST] Hello!!!
ncsim: *W,RNQUIE: Simulation is complete.       
ncsim> exit    

----------------------------------------------
Now we modify tb above to include a test to run  
----------------------------------------------
sample tb testbench: =>  test being called in this
---------------
module tb;

// uvm package/macro, these 2 lines below needed
import uvm_pkg::*;
`include "uvm_macros.svh"

 wire a, b,..; //nets, reg etc defined which are used here

 digtop u_digtop (.A(wire1), ...); //inst digtop
 pullup(GPIO1); //inst other modules
 i2c_bfm u_i2c_bfm (.SCL(SCL), ...);

 always @(a) begin .. end //for capturing events

 //simple interface for interfacing internal nets => we always connect dut signals to interface, and then interface interacts with our uvc. This is to make it resuable. We use virtual interface (which then needs to be connected to real interface). config database is used to set these virtual i/f.
 gpio_interface gpio_if (.pclk(`TB.u_dig_top.clk_16m),.data(..),...);
 adc_interface adc_if (....);

//ex of interface: (see pg 300 of UVM lecture notes from cadence)
interface (input clk, rst);
 logic [7:0] in_data;
 logic ...;
endinterface

 //configuring interface ..
initial begin
 //components can be configured using uvm_config_db.  uvm_config_db is a class that has set and get function defined in it. We can supply the name of field, and value to be set or get using this uvm_config_db
 uvm_config_db #(virtual gpio_interface)::set(null, "*", "gpio_vif", gpio_if); //gpio_vif is set to value gpio_if
 uvm_config_db #(virtual adc_interface)::set(null, "*", "adc_vif", adc_vif);
end

initial begin
  `uvm_info("TEST", "Hello!!!", UVM_LOW)
   run_test(); // calling test to run. run_test is a task in .../CDNS-1.1d/sv/src/base/uvm_root.svh  [task uvm_root::run_test(string test_name=""); ... endtask] which calls run_phases [fork ... uvm_phase::m_run_phases(); join_none] and finally does $finish, once all done. All uvm tasks are in base dir. i.e base/uvm_phase.svh, etc. So, no explicit $finish needed in our testcase.
end

initial begin
  #10ms;
  $finish; //for sim timeout (there's already a $finish in uvm run_test call)
end

//code below differs for separate testcases. So, we can keep below code in separate files  so that each test has it's own tc.sv file. similar to how we do our regular testcases in non-uvm env. In this ex, testcase is part of same file as tb.

/////////////// testcase start = base_test.sv /////////////
NOTE: classes are same as modules. They have local signals, function, etc
`define testname base_test

class `testname extends uvm_test; //uvm_test is built in uvm class for tests.
  `uvm_component_utils(`testname)

  byte mask[]; //dynamic byte array of undefined length

  function new(string name, uvm_component parent);
    super.new(name, parent);
  endfunction : new

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);        
    `uvm_info("TEST", "Running base Test", UVM_LOW)
  endfunction : build_phase
   
  //more func and task (everything below optional and not included for irun)
  virtual function void end_of_elaboration_phase(uvm_phase phase);
     super.end_of_elaboration_phase(phase);        
    `uvm_info("TEST", "End of elab: Sample Test", UVM_LOW)
  endfunction : end_of_elaboration_phase
   
  function init_test_seq(test_seq_base test_seq);
     test_seq.env = this.env; ...
  endfunction

  //tasks
  task run_phase(uvm_phase phase); //NOTE: we can also use task "main_phase" instead of "run_phase"
    phase.raise_objection(this, "base_test"); //raise obj, uvm keeps track of how many obj raised
    ... // all tests done here
    phase.drop_objection(this, `teststr);      // drop obj, only when all obj dropped, $finish called by uvm
  endtask:

   //more tasks
   task i2c_read(input bit [6:0] addr, input byte reg output byte data[]);
    ...
   endtask

endclass : base_test
/////////////////////// testcase end /////////////
   
endmodule : tb

cmd:
---
irun -uvm tb.sv => calls default test (base_test) to run.
irun -uvm tb.sv +UVM_TESTNAME=base_test => or we can provide test name explicitly if there are many tests. same as above if only 1 test.
If base_test is in separate file (other than tb.sv), then we need to give name of that file too so that irun can compile/elaborate it, i.e
irun -uvm tb.sv base_test.sv +UVM_TESTNAME=base_test

screen o/p:
----------
UVM_INFO tb.sv(12) @ 0: reporter [TEST] Hello!!!
UVM_INFO @ 0: reporter [RNTST] Running test base_test...
UVM_INFO tb.sv(29) @ 0: uvm_test_top [TEST] Running Base Test  => prints "Running Base test" from function above      

--- UVM Report catcher Summary ---
Number of demoted UVM_FATAL reports  :    0
Number of demoted UVM_ERROR reports  :    0
Number of demoted UVM_WARNING reports:    0
Number of caught UVM_FATAL reports   :    0
Number of caught UVM_ERROR reports   :    0
Number of caught UVM_WARNING reports :    0

--- UVM Report Summary ---

** Report counts by severity
UVM_INFO :    3             
UVM_WARNING :    0          
UVM_ERROR :    0            
UVM_FATAL :    0            
** Report counts by id      
[RNTST]     1               
[TEST]     2                
Simulation complete via $finish(1) at time 0 FS + 179 => NOTE: here sim finishes via $finish
/apps/cds/incisiv/14.20.017p1/tools/methodology/UVM/CDNS-1.1d/sv/src/base/uvm_root.svh:457     $finish;
ncsim> exit                           

-----------------------------------
we can create another testcase called sample_test which can extend base_test (in sample_test.sv)
//////////////////////// sample_test.sv => testcase start /////////////

`define testname sample_test
class `testname extends base_test;
  `uvm_component_utils(`testname)

  byte mask[]; //dynamic byte array of undefined length

 //these function defn below may not be needed
 extern function new(string name = `teststr, uvm_component parent = null); //defined as external function, so compiler looks for these function outside the class
 extern function void build_phase(uvm_phase phase);
 extern task run_phase(uvm_phase phase);
 extern task main_phase(uvm_phase phase);

endclass

  function new(string name, uvm_component parent);
    super.new(name, parent);
  endfunction : new

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);        
    `uvm_info("TEST", "Running sample Test", UVM_LOW)
  endfunction : build_phase
   
  //more functions
  function check_val (byte data1, int i);
     ....
  endfunction

  //main task
  task `testname::main_phase(uvm_phase phase);
   int a,b;
   super.main_phase(phase); //super fn always called for phases before doing anything else
   phase.raise_objection(this, "sample_test"); //raise obj
     $display(`testname:: main_phase");
     #10; addr = ... //write like normal task
     #1ms;
   phase.drop_objection(this, `teststr);      // drop obj
  endtask: main_phase
/////////////////////// testcase end /////////////

-------------------------------
see UVM lect from Cadence 5 day workshop:

tb consists of "reusable verification component (UVC)" + DUT. It also has sv i/f to link VC to DUT.
testcases can be put in separate files or within tb.

UVC consists of
 - sequencer = to create high level data (as do_read), either random or under control of test data (has TX transmitter)
 - driver (BFM=Bus functional Model) = to drive i/f signals to DUT (from high level to low level signals)
 - Monitor = to capture activity on i/f for coverage, checking and analysis (has RX receiver)

Top level of UVC is "Env". Env contains one or more agents. Each agent contains inst of Sequencer, driver, monitor and config. config indicates if it'a active agent (i.e TX => all seq, driver, monitor implemented) or passive agent (i.e RX => only monitor implemented)
All above components are created using class.
class sequencer extends base ... endclass
class driver extends base ... endclass
class monitor extends base ... task monitor(bit[3:0] ..) forever begin ... end endtask endclass
interface pds_if(input ...) .. endinterface

//PDS UVC => top level uvc which inst all of the above components
class pds_vc extends base; ... endclass

On top of this, scorboard UVC is also added to tb, so that i/p and o/p to/from DUT can be compared and errors flagged.  
UVM phases: (pg 177 of UVM doc from cadence) These are predefined phases. User defined phases can also be added. Phases start running in the order below when global task run_test() is called.
NOTE: to use phases below, we simply declare *_phase function in your class, and add reqd functionality. We should not call *_phase directly. It's automatically executed by simulator during that phase.
 - build_phase => building testbench. All hier should be built using build_phase rather than constructors. build_phase executes top down, all other phases execute bottom up.
 - connect_phase => making connections. Any connections b/w components should be made using connect_phase rather than constructors
 - end_of_elaboration_phase => for any pre run activity
 - run_phase => simulation of design. run_phase is implemented as a task, as it can consume time. Rest all phases are implemented as functions, as they run in 0 time. run_phase has many subphases and were added in UVM1.0. These sub-phases run in parallel with run_phase.
 - check_phase, report_phase => checking results and generating reports
 
----------------------------
Built in classes (chapter 4 in uvm book)
---------
UVM lib has many inbuilt classes from which we extend to create our classes. Ex:
1. uvm_object: this is the base class for all (data and component) UVM classes. It has built in methods for copy(), compare(), clone(), print(). Most of the time, we derive our data item from uvm_sequence_tem which itself extends from uvm_transaction which extends from uvm_object.
 ex:
class apb_transfer extends uvm_object; //or "extends uvm_sequence_item"  can also be used
      ...
  `uvm_objects_utils_begin(apb_transfer) //uvm automation macros => used to declare common operaations
     `uvm_field_int(addr, UVM_DEFAULT)
  `uvm_objects_utils_end
  function new (string name = "apb xfer"); //uvm construction new() - not mandatory
   super.new(name);
  endfunction
endclass

2. uvm_component: All infrastructure components as testbench comp, UVCs, tests are derived directly or indirectly from uvm_component. Typically we derive our user classes from methodology classes (uvm_agent, uvm_driver, uvm_sequencer, uvm_monitor, uvm_scoreboard, uvm_test and so on), which are themselves extension of uvm_component. Phases and configuration methods are functionality provided by uvm_component base class.
ex:
class testbench_comp extends uvm_component; //testcase
  function new(string name, uvm_component parent)
   super.new(name,parent);
  endfunction
  function void build_phase(uvm_phase phase);
   super.build_phase(phase);
   my_uvc = if_comp::type_id::create("my_uvc", this);
  endfunction
  //similarly other function for end_of_elaboration_phase, etc can be added here
  task run_phase (uvm_phase phase); //this is where the testcase is coded and run
   ...
  endtask
endclass

class if_comp extends uvm_component; //this is some other class that has many uvm_phases
 function new ... endfunction
 function void build_phase ... endfunction
 task run_phase ... endtask
endclass

module test; //testbench to run above testcase
 testbench_comp tb;
 initial begin
  tb = testbench_comp::type_id::create("testbench", null);
  run_test(); //this call starts the uvm phases for all the classes above
 end
endmodule

-----------------
contraints:
-------
In any class, we can have constraints defined for any field.
ex: constraint c_addr {addr[1:0] == 2'b01; }

we can overwrite any constraint in subclass, by redeclaring. Parent class contraint can be removed in subclass by leaving it empty.
ex: constarint c_addr {} => constraint c_addr is removed for this subclass, even though it's present in parent class.

-----------
coverage in uvm: see system verilog notes also:
----------

Metric driven verification
1. functional coverage
2. assertions (static formal verification and sims)
3. directed tests
4. code coverage

Most coverage constructs are placed in monitors.

1. functional coverage of 2 types:
A. assertions for control oriented coverage => cannot be in class
ex:
property req_gnt (cyc);
 @(posedge clk) req |=> ##[cyc] gnt;
endproperty

cover property (req_gnt(3));
cover property (req_gnt(4));

B. covergroups for data-oriented coverage => can be declared as class member
ex:
covergroup cg @(posedge clk);
 len: coverpoint pkt.length { ...}
 addr: cross pkt.addr, len;
endgroup

cg cg1 = new();

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

ARM: It was initially called Advanced Risc Machines Ltd, but later changed the name to ARM Ltd. It licenses CPU cores (cortex lineup), as well as GPU cores (mali lineup). NOTE: ARM primarily licenses processor cores, and NOT microprocessor or microcontroller. However, they also provide licences at system level and software level for companies which want to get the full pkg. It's cores can be used anywhere, although they are mostly used in microcontrollers. It licenses these designs (core license), as well as it allows companies to license it's instruction set (architectural license), so that they can build their own design any way they like. Apple and Qualcomm use architectural license from ARM to design their mobile processors. For Core licenses, companies receive ARM synthesizable core IP in verilog (i.e processor RTL). These IP are called soft IP, as they are in RTL. Synthesis and PnR are carried out by the companies getting these licenses.

ARM was formed in 1990, and introduced ARM6 processor family in 1991. It was based on ARM v4T processor architecture. Then came ARM7, which were still based on v4T, most popular of which was ARM7TDMI. ARMv5E arch was introduced with ARM9E processor families (E stands for enhanced, which added DSP inst for multimedia processing). Then came the ARM11 processor family based on v6 arch. At this time, it was decided to branch processor families into different types, based on their use profile. Also, each processor family would be based on arch most suited for that application type. This resulted in new product portfolio from ARM called cortex family of processors.These were subdivided into 3 profiles based on application usage. The 3 profiles were A, R, M (discussed later). New v7 arch was introduced for the cortex family. Each of these profiles had their own tailored arch, namely v7-A, v7-R and v7-M.

Though ARM had it's classic cores starting from 1990's, it's more popular "cortex" cores started appearing from 2004. These are the cores that you see everywhere in designs, the classic cores (ARM6, ARM7, etc) were used in older devices, and have disappeared from mass market. One reason for success of ARM cortex lineup is that they became very cheap, with some cortex M0 based microcontrollers sold for as low as 25 cents. This allowed these 32 bit cores to replace 8 and 16 bit microcontrollers. Let's talk about ARM ISA before delving into profiles and arch.