├── Bibliography and Acknowledgements.md
├── DAY 5.md
├── DAY 2.md
├── README.md
├── DAY 3.md
├── DAY 1.md
└── DAY 4.md
/Bibliography and Acknowledgements.md:
--------------------------------------------------------------------------------
1 | # Bibliography and Acknowledgements
2 |
3 | ## Acknowledgements
4 |
5 | Firstly, I would like to express my heartfelt gratitude to Kunal Sir and Anagha Ma'am along with the entire VSDIAT team who has worked for this course to be accessible to me.
6 | I would like to thank the course instructors and the teachers for teaching with such clarity in the videos.
7 | I would also like to thank Kunal sir for making OpenLANE and Virtual Box accessible to us for the lectures.
8 |
9 | Secondly, I would wish to thank the entire IIITB team who conducted the various lectures throughout Level 2 and Madhav Sir. It was a truly great experience, and I really am grateful for the oppurtunity.
10 |
11 | Thirdly, Sudarshan Sir, who devoted about 27 classes to our group, and who guided us through all the stages. It really was a great experience, and thank you so much sir for your guidance, mentorship and advice.
12 | Without you, this course designed for college students, probably wouldn't have been attemptable to me, a eighth grader. I really appreciate all your efforts and advice. Thank you for connecting me and the group to VSDIAT, the IIITB team and this entire opportunity on it's own.
13 | Also, thank you for bringing the group together, I made many new friends and this definitely was an unforgettable opportunity.
14 |
15 | ## Bibliography
16 |
17 | 1. [VSDIAT platform](vsdiat.com)
18 | 2. The various sessions conducted by [Sudarshan Sir](https://www.linkedin.com/in/linkedin2sudarshan/?originalSubdomain=in)
19 | 3. Another [Repository By Deepthy Santhakumar](https://github.com/dsanthak/NASSCOM-VSD-SoC-Design)
20 |
--------------------------------------------------------------------------------
/DAY 5.md:
--------------------------------------------------------------------------------
1 | # SKY130 DAY 5: Final Steps For RTL2GDS Using TritonRoute and OpenSTA
2 | ## Routing and Design Check [DRC]
3 | ### Introduction to Maze Routing and Lee's Algorithm
4 |
5 | Routing is to find the best possible connection [route] between two elements [clocks, flip-flops etc]. There have been many routing algorithms created like Steiner Tree algorithm, Line Search algorithm etc. and one such algorithm we will go into detail is **Maze Routing** - Lee's Algorithm (Lee 1961).
6 |
7 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
8 |
9 | 
10 |
11 | Consider connecting points 1 and 2 in the above picture, where in 1 is the source and 2 the target. The need is to find the best possible [shortest] path to connect 1 and 2. This route will aim to have very little or none routes with zig-zags, and mostly the routes are L-shaped. From an algorithmic standpoint, the software needs to search and connect the two poi+nts. From a physical design point of view, it is a physical/wire that allows signals to travel.
12 |
13 | Lee's Algorithm is popularly used in maze routing [type of problem where path from source to destination needs to found in grid similar to a maze]. This algorithm is especially effective for routing in grid or mesh-based structures, making it an excellent choice for integrated circuit design.
14 |
15 | Steps:
16 |
17 | 1. Initialisation - In this step, a routing grid/matrix is created in the area to be routed. It categorises each cell into one of various states - (i) obstacle ; (ii) empty ; (iii) visited ; (iv) source ; (v) target.
18 |
19 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
20 |
21 | 
22 |
23 | 2. Wave Expansion - The algorithm performs a wave expansion from the source [marked as 'S'] cell, spreading outwards in all directions. At each step, the algorithm examines neighboring cells (up, down, left, and right) and assigns them a value one greater than the minimum value of their neighboring cells (excluding obstacles and starts from 1). This process continues until the target [marked as T] cell is reached or until no more cells can be visited.
24 |
25 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
26 |
27 | 
28 |
29 | ### Lee's Algorithm Conclusion
30 |
31 | [Continuation of Steps]
32 |
33 | 3. Backtracking and Path Reconstruction - Once the target is reached, the algorithm backtracks the path to the source by following the cell values. Through this there might be multiple paths obtained but the tool will choose one with less bends i.e. a shorter route along the algorithm to give us the shortest route.
34 |
35 | > The route should not be diagonal and must not overlap any blockage/obstruction such as macros or HIPs.
36 |
37 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
38 |
39 | 
40 |
41 | ### Design Rule Check
42 |
43 | When we route, we do not just merely connect two points, we must also adhere to certain rules. For example, one rule mention how when constructing two wires there must be a minimum distance between them, they must have a minimum width and pitch etc. ence, DRC cleaning is done to ensure that the routes can be fabricated and printed in silicon properly.
44 |
45 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
46 |
47 | 
48 |
49 | Another critical issue is **signal short**, which causes functionality failure. This can be removed by moving the route to the next layer. This leads to more DRCs (via width, via spacing, higher metal layer must be wider than lower metal layer etc.).
50 |
51 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
52 |
53 | 
54 |
55 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
56 |
57 | 
58 |
59 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
60 |
61 | 
62 |
63 | ## Power Distribution Network and Routing
64 | ### Lab Steps To Build Power Distribution Network
65 |
66 | The lab steps to build a power distribution network are -:
67 |
68 | 1. Go to the openlane directory
69 |
70 | 2. Enter the command _docker_ and then **./flow.tcl -interactive** . To subsequently get the openlane package, type _package require openlane 0.9_.
71 |
72 | 3. Then prep the design using -: **prep -design picorv32a -tag [folder name of run where in cts had been done]
73 |
74 | 4. Then type **echo $::env(CURRENT_DEF) /openLANE_flow/designs/picorv32a/runs/[folder name of run where in cts had been done]/results/cts/picorv32a.cts.def**
75 |
76 | 5. Then, type this to generate the PDN -: **gen_pdn**
77 |
78 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
79 |
80 | 
81 |
82 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
83 |
84 | 
85 |
86 | ### Lab Steps From Power Straps To STD Cell Power
87 |
88 | The power and ground rails have a pitch of 2.72µm and hence the custom inverter cell also has a height of 2.72µm. This is as otherwise power and ground rails will not be able to power the cell. We also see that looking at the LEF file runs/[date]/tmp/merged.lef, all cells are have height of 2.72µm and only their width differs.
89 |
90 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
91 |
92 | 
93 |
94 | It is shown below how standard cells are powered up :- power/ground pads -> power/ground ring-> power/ground straps -> power/ground rails
95 |
96 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
97 |
98 | 
99 |
100 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
101 |
102 | 
103 |
104 | ### Basics of Global and Detail Routing and Configure TritonRoute
105 |
106 | **TritonRoute** is the engine that is used for routing through the **run_routing** command.
107 |
108 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
109 |
110 | 
111 |
112 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
113 |
114 | 
115 |
116 | In the VLSI flow, the routing stage is highly critical and can be executed using either open-source or commercial tools. This stage is divided into two phases:
117 |
118 | Global Route / Fast Route:
119 |
120 | This is accomplished using fast routing techniques where the area to be routed is partitioned into tiles or rectangles. Global routing establishes the initial framework for routing paths.
121 | Detail Route:
122 |
123 | This phase involves meticulous tracking routing techniques to complete the routing process. Detailed routing fine-tunes and finalizes the paths to ensure proper connectivity and compliance with design constraints.
124 |
125 | In VLSI, routing is extremely important and is either done through open-source/commericial tools. It has mainly two phases -:
126 | - Global Route - Also known as fast route, it uses fast routing techniques wherein we partition the area to routed into tiles/rectangles. It establishes the initial framework
127 | - Detailed Route - This process uses more meticulous routing techniques, and completes the process by fine-tuning and finalizing the paths to ensure connectivity and compliance with DRC.
128 |
129 | ## TritonRoute Features
130 | ### TritonRoute Feature 1 - Honors Pre-processed Route Guides
131 |
132 | The preferred direction for M1 and M2 respectively is vertical and horizontal. Whenever, a non-preferred direction route is found by the tool, the tool divides the route into unit width in a process called splitting. The sections that fall into the preferred directions are subsequently combined. Sections parallel to the preferred direction are bridged with upper layer [in bridging]. Non-preferred routes are converted into preferred routing guides of M2.
133 |
134 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
135 |
136 | 
137 |
138 |
139 | ### TritonRoute Feature 2 & 3 - Inter-Guide Connectivity and Intra & Inter Layer Routing
140 |
141 | The second feature is interguide connectivity:-
142 |
143 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
144 |
145 | 
146 |
147 | As mentioned earlier, the preferred direction of M1 is vertical - resulting in vertically oriented lines. Panels are the dashed lines with a routing guide for each panel. Intra layer panel routing is when routing occurs withing even-index panels. Initially, routing takes place simultaneously in all even-index panels, which is followed by routing in odd-index panels. This routing remains confined within a particular layer and then Routing progresses from lower to upper layers, ensuring the orderly flow of routing operations.
148 |
149 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
150 |
151 | 
152 |
153 | ### TritonRoute Method To Handle Connectivity
154 |
155 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
156 |
157 | 
158 |
159 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
160 |
161 | 
162 |
163 | The aim of MILP (Mixed Integer Linear Programming) is to find the optimal solution to connect two access point clusters.
164 |
165 | In the below algorithm, cost is found for each access point. Then, a minimum spanning tree between access points and cost is made. So, the algorithm says that the minimal and most optimal point is needed between two APCs.
166 |
167 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
168 |
169 | 
170 |
171 | ### Routing Topology Algorithm and Final Files List Post Route
172 |
173 | After running the _run_routing_ command, routing [both global and detail] is completed. Routing Strategy was set to 0, which meant that DRC violations must be brought down from a high value [25000 in this case] to 0. This takes multiple iterations [34] and nearly 20 minutes to half an hour.
174 |
175 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
176 |
177 | 
178 |
179 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
180 |
181 | 
182 |
183 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
184 |
185 | 
186 |
187 | After this, a def file will be formed in the location [runs/[date]/results/routing/picorv32.def], which has to opened in MAGIC -:
188 |
189 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
190 |
191 | 
192 |
193 | ##### Parasitic Extraction
194 |
195 | > NOTE: OpenLANE does not have any spef extraction tool, so we use a separate tool present in work/tools/ directory.
196 |
197 | The steps for extraction are -:
198 | 1. Go to /home/vsduser/Desktop/work/tools/SPEF_EXTRACTOR, where in there are a list of files, one of which is a python file called main.py. This file helps in generation of the SPEF provided. There are also lef & def files in the folder.
199 |
200 | 2. Now, to create the SPEF file **python3 main.py /home/vsduser/work/tools/openlane_working_dir/openlane/designs/picorv32a/runs/26-03_05-49/tmp/merged.lef /home/vsduser/work/tools/openlane_working_dir/openlane/designs/picorv32a/runs/26-03_05-49/tmp/routing/picorv32a.def**
201 |
202 | > NOTE: spef will be saved in the same location as def file. /home/vsduser/work/tools/openlane_working_dir/openlane/designs/picorv32a/runs/26-03_05-49/tmp/routing
203 |
204 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
205 |
206 | 
207 |
208 | The last stage will be to extract the GDSII file ready for fabrication run_magic
209 |
210 | This uses Magic to stream the GDSII file runs/26-03_05-49/results/magic/picorv32a.gds. This GDSII file can then be read by Magic:
211 |
212 |
213 | The last stage is to extract the GDSII file ready for fabrication through **run_magic**. This uses MAGIC to stream the GDSII file **runs/26-03_05-49/results/magic/picorv32a.gds**. The GDSII can now be ready by MAGIC -:
214 |
215 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
216 |
217 | 
218 |
--------------------------------------------------------------------------------
/DAY 2.md:
--------------------------------------------------------------------------------
1 | # SKY130 Day 2: Good vs Bad Floorplan and Introduction to Library Cells
2 | ## Chip Floor Planning Considerations
3 | ### Utilisation Factor and Aspect Ratio
4 |
5 | The first step in physical design is to **define the width and height of the core and die** : Beginning with a very simple netlist, that can extrapolated later we will first draw a basic diagram in the form of symbols that we will later convert into physical designs. We will take each cell (gates, specific cell like flip flop) and give it a standard (although rough for now) dimensions. As an example here, each unit will be 1 unit x 1 unit - i.e. 1 sq. unit in size, and since there are 4 gates/flip-flops here, the total size of the silicon wafer will 4 sq. units.
6 |
7 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
8 |
9 | 
10 |
11 |
12 | > NOTE : here, we are ignoring the wires
13 |
14 | All logical cells will be placed inside the core - which is part of the die. If the logical cells occupy the core fully, it is known as 100% utilisation. Utilisation factor = Area occupied by netlist / Total area of core. In this case, we see that utilisation factor is 100%, but practically it is usually 50%. Aspect Ratio is the ratio between height and width. If the chip is square - it is 1, else the chip is rectangular in shape.
15 |
16 | Example:
17 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
18 |
19 | 
20 |
21 | Utilisation factor = 50 %
22 |
23 | Aspect Ratio = 2 : 4 = 1 : 2 = .5
24 |
25 |
26 | ### Concept of Pre-Placed Cells
27 |
28 | Pre-Placed cells are complex logic blocks that can be reused. They are already implemented and cannot be touched by Auto Place and Route tools - and hence are required to be very well designed. Placement of such cells are user-based. A combinational logic - such as netlist shown does a particular function and is composed of various gates. We can divide this logic into blocks - while preserving the connectivity of the logic. By extending IO pins and making connections we can convert the logic into two parts - that are blackboxed and can be used as needed. If a design only requires a black box, it can be directly handed over to the designer with out much hassle. The various preplaced blocks available include memory, clock-gating cell, comparator, MUX. The arrangement of these IPs in a chip are known as floorplanning.
29 |
30 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
31 |
32 | 
33 |
34 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
35 |
36 | 
37 |
38 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
39 |
40 | 
41 |
42 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
43 |
44 | 
45 |
46 |
47 | ### De-Coupling Capacitors
48 |
49 | We surround pre-placed cells with de-coupling capacitors. If we think of a circuit to be part of a block, whenever it is switched on there is a demand for current, which is supplied by the Vdd. Upon switching the circuit off, there is a discharge, which the ground accepts. However, practically when voltage is supplied is passes through a wire which causes it to reduce slightly due the resistance, inductance and capacitance in the wire, and the reduced voltage is called Vdd'. The Vdd' always needs to stay in the noise margin - which ranges from Vih to Voh. If this is not true, the circuit is unstable. This is due to the large physical distance between the actual voltage supply and the circuit.
50 |
51 | Decoupling capacitors is a solution to this problem. Decoupling capacitors can be thought of as as a huge capacitor completely filled with charge. The equivalent voltage across the capacitor is same as across the main supply voltage. The capacitor decouples the circuit from the main supply. Hence, all the pre-placed cells get their power supply from the capacitors and hence are completely stable.
52 |
53 | ### Power Planning
54 |
55 | Consider a particular piece of logic to be a _macro_, that is repeated many times on a single chip. It requires a lot of voltage, so voltage must be supplied through a decoupling capacitor. However, it is not feasible to add the de-coupling capacitors on the entire circuit - only critical elements can be decoupled.
56 |
57 | If the 16 bit bus is connected to an inverter, then it means that all the capacitors will discharge the voltage at once. A lot of capacitors discharging at once cam cause **Ground Bounce** due to great amount of voltage needed to drained at the same time, and turning the capacitor on might cause **Voltage Drop** due to insufficient current. Ground bounce and voltage drop might cause the voltage to not be within the noise margin range. To solve this problem, we can have multiple powersource taps and sources ( known as a power mesh) where capacitors can source current from the nearest Vdd and sink current to the nearest Ground.
58 |
59 | ### Pin Placement and Logical Cell Placement Blockage
60 |
61 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
62 |
63 | 
64 |
65 | Take the above netlist as an example needing to be implemented. The information about the connections is coded through VERILOG (also known as VHDL).The input and output ports are placed left and right between the core and the die respectively. The placements of the ports is cell-specific. The clocks are continuously drive the cells and hence clock ports are bigger than data ports. Due to this, we also need the least resistance paths for the clocks. The size is inversely proportional to the resistance.
66 |
67 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
68 |
69 | 
70 |
71 | After the pin placement, we create Logical Cell Placement Blockage to ensure that the APR tool does not place any cell on the pin locations.
72 |
73 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
74 |
75 | 
76 |
77 |
78 | ### Steps to Run Floorplan Using OpenLANE
79 |
80 | 1. The first step is setting the configuration variables - Before running floorplan, the configuration variables or switches must be set. These are present in **openlane/configuration**
81 |
82 | {IMAGE CREDITS: AUTHOR ; SCREENSHOT TAKEN FROM DEVICE}
83 |
84 | 
85 |
86 | The _README.md_ contains all configuration variables, which are segregated based on stage and the **.tcl** files consists of the default OpenLANE settings.
87 |
88 | 2. All _configurations/switches_ accepted by the current run are from **openlane/designs/[design - date]/config.tcl**
89 |
90 | ***
91 |
92 | There is a order of priority -:
93 |
94 | - _openlane/designs/[design-date]/sky130A_sky130_fd_sc_hd_config.tcl_
95 | - _openlane/designs/[design]/config.tcl_
96 | - _openlane/configuration/floorplan.tcl_
97 |
98 | > In OpenLANE, it is important to note that the vertical and horizontal metals set one more than what we specify. For example, if the vertical metal is specified as 3, then it'll be 4.
99 |
100 | 3. Floorplan is to be run on OpenLANE through the command :- _run_floorplan_
101 |
102 | ### Review Floorplan Files and Steps to Review Floorplan
103 |
104 | 4. After running floorplan as above, it will produce a result that will be stored in the form of a design exchange format - and will contain the area of the Die as well as positions.The die area in this file is in database units and 1 micron is equivalent to 1000 database units. Area of die = (554570/1000) microns * (565290/1000) microns = 311829.1653 sq. µm.
105 |
106 | ### Review Floorplan Layout in Magic
107 |
108 | 5. The command _magic -T /home/vsduser/Desktop/work/tools/openlane_working_dir/pdks/sky130A/libs.tech/magic/sky130A.tech lef read ../../tmp/merged.lef def read picorv32a.floorplan.def &_ should be typed to view the file.
109 | 6. Subsequently, press the **S** key to select the entire die and then **V** to center the view, and then **Z** to zoom. You will observe that the IO pins are placed equidistant to one another in a random mode as based on the configuration **(FP_IO_MODE = 1)** set in _openlane/configuration/floorplan.tcl_
110 |
111 | {IMAGE CREDITS: AUTHOR ; SCREENSHOT TAKEN FROM DEVICE}
112 |
113 | 
114 |
115 | 7. After this, typing _what_ on the **tkcon** window will give the layer of the selection.
116 |
117 | {IMAGE CREDITS: AUTHOR ; SCREENSHOT TAKEN FROM DEVICE}
118 |
119 | 
120 |
121 | > Standard cells are not placed but can be viewed at the bottom left corner of the layout
122 | >
123 | >{IMAGE CREDITS: AUTHOR ; SCREENSHOT TAKEN FROM DEVICE}
124 | >
125 | > 
126 |
127 |
128 | ## Library Binding and Placement
129 | ### Netlist Binding and Initial Place Design
130 |
131 | + The first step is to bind the netlist with physical cells i.e. cells with real dimension. The netlist contains various gates, that while in the schematic are of a certain shape as depicted, are usually square/rectangular in shape in production. These gates are given a specific shape, and in the end look very different from the netlist.
132 |
133 | These blocks are sourced from a "_shelf_", known as a **library**. The library has cells with various shapes, dimensions and also contains information about the delay information. The library contains various sizes of cells with the same functionality too - since bigger cells have lesser resistance
134 |
135 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
136 |
137 | 
138 |
139 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
140 |
141 | 
142 |
143 | + The second step is **PLACEMENT**, which is done based on connectivity. As can be seen, flip flop 1 is close to the _Din1_ pin and flip flop 2 is close to _Dout1_ pin. Combinational cells are placed in close proximity to FF1 and FF2 as to reduce delay.
144 |
145 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
146 |
147 | 
148 |
149 |
150 | ### Optimise Placement Using Estimated Wire-Length and Capacitance
151 |
152 | Here, we will estimate wirelength needed to connect the components together. If the wirelength is too long, we would need to install repeaters, as the signal may change over a long distance. Repeaters essentially recondition the same signal to it's prior strength.
153 |
154 | ### Final Placement Optimization
155 |
156 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
157 |
158 | 
159 |
160 | ### Congestion Aware Placement Using RePLACE
161 |
162 | The command to run placement of OpenLANE - _run_placement_ is a wrapper which does three functions
163 | - Global Placement (by using the RePlace tool) - there is no legalisation and HPWL reduction model is used
164 | - Optimization (by Resier tool)
165 | - Detailed Placement (by OpenDP tool) - legalisation occurs - where standard cells are placed in rows and there will be no overlap of the cells.
166 |
167 | Placement aims to **converge the overflow value**.
168 |
169 | > NOTE: If placement will be sucessful and the designs will converge, the overflow value will progressively reduce during the placement.
170 |
171 | After running the placement, output is generated in this folder **_openlane/designs/picorv32a/runs/[design - date]/results/placement/picorv32a.placement.def_**
172 |
173 | Then, we can type the command : **_magic -T /home/vsduser/Desktop/work/tools/openlane_working_dir/pdks/sky130A/libs.tech/magic/sky130A.tech lef read ../../tmp/merged.lef def read picorv32a.placement.def &_** to view it in Magic:
174 |
175 | {IMAGE CREDITS: AUTHOR ; SCREENSHOT TAKEN FROM DEVICE}
176 |
177 | 
178 |
179 |
180 | ## Cell Design and Characterisation Flows
181 | ### Inputs for Cell Design Flow and Circuit and Layout Design Step
182 |
183 | Standard cells - for example AND gate, OR gate, BUFFER etc are stored in the _standard cell library_. There are various types of cells in the library with various variations as well - in drive strengths, functionality, and voltages. For a greater cell size, there is greater drive strength for longer wires. If there is high Vth, then it will take more time to switch than a lesser threshhold voltage cell.
184 |
185 | The standard cell design flow is as follows:-
186 |
187 | INPUTS (PDKS : DRC and LVS rules, SPICE models, library and user defined specs)
188 |
189 | PROCESSES (circuit, layout design and charecterisation)
190 |
191 | OUTPUTS (Circuit Description Language, GDSII, lef, timing, noise etc)
192 |
193 | > DRC & LVS Rules contain tech files and poly substrate parameters
194 | >
195 | > SPICE Models contain threshold, linear regions, saturation region equations with added foundry parameters, including NMOS and PMOS parameters
196 | >
197 | > User defined specifications include cell height and cell width, supply voltage, pin locations, and metal layer requirement
198 | >
199 | > IMPORTANT: The standard cell library developer must adhere to the rules given by the foundry so that when the cell can be used on a real design without any errors
200 | >
201 | > Circuit design is done by modeling the pmos and nmos to meet input library requirement
202 | >
203 | > Layout design is done using Euler's path and stick diagram on Magic layout tool
204 | >
205 | > {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
206 | >
207 | > 
208 |
209 | ### Typical Characterisation Flow
210 |
211 | Steps of Characterisation Flow:-
212 |
213 | 1) Reading of SPICE module files
214 | 2) Reading of netlist extracted by SPICE
215 | 3) Recognising buffer behaviour
216 | 4) Reading subcircuits
217 | 5) Attaching neccessary power sources
218 | 6) Applying stimulus
219 | 7) Provision of of neccessary output capacitance
220 | 8) Provision of simulation command
221 |
222 | These steps are given to the CHARECTERISATION SOFTWARE KNOWN AS **GUNA** in the form of a configuration file, which will generate timing, noise and power models in the form of _.libs_ files.
223 |
224 | ## General Timing Characterisation Parameters
225 | ### Timing Threshhold Definitions
226 |
227 | Here, we will talk about the semantics of the various _.libs_ files generated by GUNA. To do this, we will take this circuit as an example:
228 |
229 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
230 |
231 | 
232 |
233 | Here, the red line is output of first inverter and blue is output of second inverter.
234 |
235 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
236 |
237 | 
238 |
239 | {IMAGE CREDITS: DEEPTHY SANTHAKUMAR}
240 |
241 | 
242 |
243 | {IMAGE CREDITS: DEEPTHY SANTHANKUMAR}
244 |
245 | 
246 |
247 | ### Propogation Delay and Transition Time
248 |
249 | Propogation delay is calculated as = time(out_x_thr) - (time_x_thr). If the propogation delay is negative, it can cause quite unexpected results - as an output is generated before the input. Hence, threshhold values should be selected properly. Delay threshold is usually 50% and slew rate threshold is usually 20%-80%.
250 |
251 | Transition time is calculated as = time(slew_high_x_thr) - time(slew_low_x_thr)
252 |
253 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
254 |
255 | 
256 |
257 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah
2 |
3 | Course - [Advanced Physical Design Using OpenLANE/SKY130 offered by VSDIAT](https://vsdsquadron.vlsisystemdesign.com/digital-vlsi-soc-design-and-planning/)
4 |
5 | Author - Ojasvi Shah
6 |
7 | Contents -:
8 | * [SKY130 Day 1: Inception of OpenSource EDA, OpenLANE and SKY130 PDK](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md)
9 | - [How to Talk to Computers](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#how-to-talk-to-computers)
10 | + [Introduction to QFN - 48 package, chip, pads, core, die and IPs](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#introduction-to-qfn---48-package-chip-pads-core-die-and-ips)
11 | + [Introduction to RISC V](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#introduction-to-risc-v)
12 | + [From Software Applications to Hardware](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#from-software-applications-to-hardware)
13 | - [SoC Design and OpenLANE](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#soc-design-and-openlane)
14 | + [Introduction to Components of Opensource Digital ASIC Design](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#introduction-to-components-of-opensource-digital-asic-design)
15 | + [Simplified RTL to GDS flow](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#simplified-rtl-to-gds-flow)
16 | + [Introduction to OpenLANE and Strive Chipsets](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#introduction-to-openlane-and-strive-chipsets)
17 | + [Introduction to OpenLANE detailed ASIC Design Flow](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#introduction-to-openlane-detailed-asic-design-flow)
18 | - [Get Familiar to Opensource EDA tools](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#get-familiar-to-opensource-eda-tools)
19 | + [OpenLANE Directory Structure in Detail](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#openlane-directory-structure-in-detail)
20 | + [Design Preparation Step](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#design-preparation-step)
21 | + [Review Files After Design Prep and Run Synthesis](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#review-files-after-design-prep-and-run-synthesis)
22 | + [Steps to Characterise Synthesis Results](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%201.md#steps-to-charecterise-synthesis-results)
23 | * [SKY130 Day 2: Good vs Bad Floorplan and Introduction to Library Cells](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#sky130-day-2-good-vs-bad-floorplan-and-introduction-to-library-cells)
24 | - [Chip Floor Planning Considerations](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#chip-floor-planning-considerations)
25 | + [Utilisation Factor and Aspect Ratio](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#utilisation-factor-and-aspect-ratio)
26 | + [Concept of Pre-Placed Cells](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#concept-of-pre-placed-cells)
27 | + [De-Coupling Capacitors](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#de-coupling-capacitors)
28 | + [Power Planning](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#power-planning)
29 | + [Pin Placement and Logical Cell Placement Blockage](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#pin-placement-and-logical-cell-placement-blockage)
30 | + [Steps to Run Floorplan Using OpenLANE](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#steps-to-run-floorplan-using-openlane)
31 | + [Review Floorplan Files and Steps to Review Floorplan](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#review-floorplan-files-and-steps-to-review-floorplan)
32 | + [Review Floorplan Layout in Magic](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#review-floorplan-layout-in-magic)
33 | - [Library Binding and Placement](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#library-binding-and-placement)
34 | + [Netlist Binding and Initial Place Design](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#netlist-binding-and-initial-place-design)
35 | + [Optimise Placement Using Estimated Wire-Length and Capacitance](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#optimise-placement-using-estimated-wire-length-and-capacitance)
36 | + [Final Placement Optimization](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#final-placement-optimization)
37 | + [Need for Libraries and Characterisation](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#need-for-libraries-and-characterisation)
38 | + [Congestion Aware Placement Using RePLACE](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#congestion-aware-placement-using-replace)
39 | - [Cell Design and Characterisation Flows](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#cell-design-and-characterisation-flows)
40 | + [Inputs for Cell Design Flow](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#inputs-for-cell-design-flow-and-circuit-and-layout-design-step)
41 | + [Circuit Design Step](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#inputs-for-cell-design-flow-and-circuit-and-layout-design-step)
42 | + [Layout Design Step](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#inputs-for-cell-design-flow-and-circuit-and-layout-design-step)
43 | + [Typical Characterisation Flow](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#typical-characterisation-flow)
44 | - [General Timing Characterisation Parameters](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#general-timing-characterisation-parameters)
45 | + [Timing Threshhold Definitions](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#timing-threshhold-definitions)
46 | + [Propogation Delay and Transition Time](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%202.md#propogation-delay-and-transition-time)
47 | * [SKY130 DAY 3: Design Library Cell Using Magic Layout and NGSPICE characterisation](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#sky130-day-3-design-library-cell-using-magic-layout-and-ngspice-characterisation)
48 | - [Labs for CMOS Inverter NGSPICE Simulations](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#labs-for-cmos-inverter-ngspice-simulations)
49 | + [IO Placer Revision](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#io-placer-revision)
50 | + [SPICE Deck Creation For CMOS Inverter](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#spice-deck-creation-for-cmos-inverter)
51 | + [SPICE Simulation Lab for CMOS Inverter](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#spice-simulation-lab-for-cmos-inverter)
52 | + [Switching Threshhold Vm](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#switching-threshhold-vm)
53 | + [Static and Dynamic Simulation of CMOS Inverter](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#static-and-dynamic-simulation-of-cmos-inverter)
54 | + [Lab Steps to GitClone VSDSTD Cell Design](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-steps-to-gitclone-vsdstd-cell-design)
55 | - [Inception of Layout  CMOS Fabrication Process](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#inception-of-layout-%C3%A2-cmos-fabrication-process)
56 | + [Create Active Regions](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#create-active-regions)
57 | + [Formation of N and P well](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#formation-of-n-and-p-well)
58 | + [Formation of Gate Terminal](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#formation-of-gate-terminal)
59 | + [Lightly Doped Drain [LDD] Formation](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lightly-doped-drain-ldd-formation)
60 | + [Source  Drain Formation](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#source-%C3%A2-drain-formation)
61 | + [Local Interconnect Formation](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#local-interconnect-formation)
62 | + [Higher Level Metal Formation](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#higher-level-metal-formation)
63 | + [Lab Introduction to SKY130 Basic Layers Layout and LEF using Inverter](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-introduction-to-sky130-basic-layers-layout-and-lef-using-inverter)
64 | + [Lab Steps to Create STD Cell Layout and Extract SPICE Netlist](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-steps-to-create-std-cell-layout-and-extract-spice-netlist)
65 | - [SKY130 Tech File Labs](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#sky130-tech-file-labs)
66 | + [Lab Steps To Create Final SPICE deck using SKY130 tech](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-steps-to-create-final-spice-deak-using-sky130-tech)
67 | + [Lab Steps to Characterise Inverter using SKY130 Model Files](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-steps-to-characterise-inverter-using-sky130-model-files)
68 | + [Lab Introduction to SKY130 PDKs And Steps to Download Labs](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-introduction-to-sky130-pdks-and-steps-to-download-labs)
69 | + [Lab Introduction to Magic Tool Options and DRC Rules](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-introduction-to-magic-tool-options-and-drc-rules)
70 | + [Lab Introduction to Magic and Steps to Load SKY130 Tech Rules](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-introduction-to-magic-and-steps-to-load-sky130-tech-rules)
71 | + [Lab Excercise to Fix **poly.9** error in SKY130 Tech-File](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-excercise-to-fix-poly9-error-in-sky130-tech-file)
72 | + [Lab Excercise to Implement Poly-Resistor Spacing to Diff and Tap](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%203.md#lab-excercise-to-implement-poly-resistor-spacing-to-diff-and-tap)
73 | * [SKY130 DAY 4 : Pre-Layout Timing Analysis and Importance of Good Clock Tree](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#sky130-day-4--pre-layout-timing-analysis-and-importance-of-good-clock-tree)
74 | - [Timing Modelling Using Delay Tables](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#timing-modelling-using-delay-tables)
75 | + [Lab Steps To Convert Grid Information Into Track Information](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-convert-grid-information-into-track-information)
76 | + [Lab Steps to Convert Magic Layout to STD Cell LEF](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-convert-magic-layout-to-std-cell-lef)
77 | + [Introduction of Timing **libs** and Steps To Include New Cell in Synthesis](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#introduction-of-timing-libs-and-steps-to-include-new-cell-in-synthesis)
78 | + [Delay Tables](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#delay-tables)
79 | + [Lab Steps To Configure Synthesis Settings to Fix Slack and Include VSDINV](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-configure-synthesis-settings-to-fix-slack-and-include-vsdinv)
80 | - [Timing Analysis With Ideal Clocks Using Open STA](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#timing-analysis-with-ideal-clocks-using-open-sta)
81 | + [Setup Timing Analysis And Introduction to Flip-Flop Setup Time](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#setup-timing-analysis-and-introduction-to-flip-flop-setup-time)
82 | + [Introduction to Clock Jitter and Uncertainty](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#introduction-to-clock-jitter-and-uncertainty)
83 | + [Lab Steps to Configure OpenSTA for Post-Synth Timings Analysis](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-configure-opensta-for-post-synth-timings-analysis)
84 | + [Lab Steps to Optimize Synthesis to Reduce Setup Violations](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-optimize-synthesis-to-reduce-setup-violations)
85 | + [Lab Steps to do Basic Timing ECO](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-do-basic-timing-eco)
86 | - [Clock Tree Synthesis TritonCTS and Signal Integrity](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#clock-tree-synthesis-tritoncts-and-signal-integrity)
87 | + [Clock Tree Routing and Buffering Using H-Tree Algorithm](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#clock-tree-routing-and-buffering-using-h-tree-algorithm)
88 | + [Crosswalk and Clock Net Shielding](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#crosswalk-and-clock-net-shielding)
89 | + [Lab Steps to run CTS using TritonCTS](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-run-cts-using-tritoncts)
90 | + [Lab Steps to Verify CTS Runs](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-verify-cts-runs)
91 | - [Timing Analysis With Real Clocks Using Open STA](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#timing-analysis--with-real-clocks-using-open-sta)
92 | + [Setup Timing Analysis Using Real Clocks](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#setup-timing-analysis-using-real-clocks)
93 | + [Lab Steps to Analyse Timing With Real Clocks Using OpenSTA](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#setup-timing-analysis-using-real-clocks)
94 | + [Lab Steps to Excecute OpenSTA With Right Timing Libraries and CTS Assignment](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-excecute-opensta-with-right-timing-libraries-and-cts-assignment)
95 | + [Lab Steps to Observe Impact of Bigger CTS Buffers On Setup And Hold Timing](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%204.md#lab-steps-to-observe-impact-of-bigger-cts-buffers-on-setup-and-hold-timing)
96 | * [SKY130 DAY 5: Final Steps For RTL2GDS Using TritonRoute and OpenSTA](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#sky130-day-5-final-steps-for-rtl2gds-using-tritonroute-and-opensta)
97 | - [Routing and Design Check [DRC]](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#routing-and-design-check-drc)
98 | + [Introduction to Maze Routing and Lee's Algorithm](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#introduction-to-maze-routing-and-lees-algorithm)
99 | + [Lee's Algorithm Conclusion](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#lees-algorithm-conclusion)
100 | + [Design Rule Check](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#design-rule-check)
101 | - [Power Distribution Network and Routing](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#power-distribution-network-and-routing)
102 | + [Lab Steps To Build Power Distribution Network](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#lab-steps-to-build-power-distribution-network)
103 | + [Lab Steps From Power Straps To STD Cell Power](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#lab-steps-from-power-straps-to-std-cell-power)
104 | + [Basics of Global and Detail Routing and Configure TritonRoute](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#basics-of-global-and-detail-routing-and-configure-tritonroute)
105 | - [TritonRoute Features](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#tritonroute-features)
106 | + [TritonRoute Feature 1 - Honors Pre-processed Route Guides](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#tritonroute-feature-1---honors-pre-processed-route-guides)
107 | + [TritonRoute Feature 2 & 3 - Inter-Guide Connectivity and Intra & Inter Layer Routing](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#tritonroute-feature-2--3---inter-guide-connectivity-and-intra--inter-layer-routing)
108 | + [TritonRoute Method To Handle Connectivity](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#tritonroute-method-to-handle-connectivity)
109 | + [Routing Topology Algorithm and Final Files List Post Route](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/DAY%205.md#routing-topology-algorithm-and-final-files-list-post-route)
110 | * [Bibliography and Acknowledgements](https://github.com/ojasvi-shah/Advanced-Physical-Design-Using-OpenLANE--Ojasvi-Shah/blob/main/Bibliography%20and%20Acknowledgements.md)
111 |
--------------------------------------------------------------------------------
/DAY 3.md:
--------------------------------------------------------------------------------
1 | # SKY130 DAY 3: Design Library Cell Using Magic Layout and NGSPICE characterisation
2 | ## Labs for CMOS Inverter NGSPICE Simulations
3 | ### IO Placer Revision
4 |
5 | OpenLANE configurations can be changed inside the shell itself, on the fly. IO Mode is usually set to _random equidistant_. However, if we want to change this, we can do so through the following command typed after floorplan : **set ::env(FP_IO_MODE) 2**. After running this command, the IO [input - output] pins will not be equidistant in mode 2 (instead of the default - that is 1).
6 |
7 | After this, we may re-run floorplan, and then check by seeing that the pins are placed based on of Hungarian algorithms now i.e. stacked one over the other.
8 |
9 | > NOTE: changing the configuration on the fly will not change the runs/config.tcl, the configuration will only be available on the current session.
10 |
11 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
12 | 
13 |
14 | ### SPICE Deck Creation For CMOS Inverter
15 |
16 | The SPICE deck contains connectivity information about netlists, inputs to be provided, TAPS for the outputs etc. The component values are taken, that are usually -: for the PMOS it is .375u/.25u (i.e. the channel length is .25 micron and and the channel width is .375 micron). Ideally, the PMOS should be 2 to 3 times wider than the NMOS. This is as the PMOS hole carrier is slower than the NMOS carrier, and since the rise and fall time must be matched, to reduce the resistance, we increase the width of the PMOS. The next steps are to identify and name the nodes:
17 |
18 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
19 | 
20 |
21 | The syntax of the SPICE deck netlist PMOS and NMOS is _[component name] [drain] [gate] [source] [substrate] [transistor type] W=[width] L=[length]_. It is to be noted that all components in a netlist are described based on its node and values.
22 |
23 | > EXAMPLE SYNTAX - M1 OUT IN VDD VDD PMOS W=.375U L=.25u
24 |
25 | ### SPICE Simulation Lab for CMOS Inverter
26 |
27 | The start of SPICE simulation is _.op_ where in Vin will be swept from 0 to 2.5 with 0.05V steps. The model file is **tsmc_025um_model.mod** that has all the technological parameters for the 0.25µm NMOS and PMOS.
28 |
29 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
30 | .
31 |
32 | For SPICE simulation, there are various steps-:
33 |
34 | 1) Open the NGSPICE simulator
35 | 2) Source the Circuit File through _source_ command
36 | 3) Execute it by the command _run_ and then use _setplot_ which allows one to view any plots possible from the simulations specified in the spice deck and will give you a choice for which simulation to be run
37 | 4) Then, type _display_ which will give you a choice of nodes to be plotted which when _plot out vs in_ is typed will be plotted on a graph.
38 |
39 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
40 | 
41 |
42 | ### Switching Threshhold Vm
43 |
44 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
45 | 
46 |
47 | POINTS TO BE NOTED:
48 |
49 | - The shapes of the graphs are almost the same, through which we can derive the conclusion that CMOS is a robust device
50 | - The parameters that determine the robustness of the CMOS is the switching threshhold and the propogation delay
51 |
52 | The Switching Threshhold is the point where the the input voltage is equal to the output voltage and both PMOS & NMOS are in saturation region. When these are turned on, there is a high chances of leakage and that the current flows directly from VDD to GND. Due to this, short circuit can be seen.
53 |
54 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
55 | 
56 |
57 | ### Static and Dynamic Simulation of CMOS Inverter
58 |
59 | To find Vm, we use DC TRANSFER ANALYSIS. Simulation is essentially a sweep from 0V to 2.5V by taking 0.05V steps.
60 |
61 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
62 | 
63 |
64 | To find propogation delay, we use transient analysis when a pulse is applied to the CMOS.
65 |
66 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
67 | 
68 |
69 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
70 | 
71 |
72 | ### Lab Steps to GitClone VSDSTD Cell Design
73 |
74 | We have been provided with a github repository wherein inverter files lie. It is available at this link - https://github.com/nickson-jose/vsdstdcelldesign. Steps to clone and observe the layout are as follows:
75 | 1. Clone the custom inverter standard cell design from the github repository shared above
76 | 2. Clone the repository with the custom inverter design through the command _git clone https://github.com/nickson-jose/vsdstdcelldesign_
77 | 3. Subsequently, copy the tech file to the _vsdstdcelldesign_ directory (created through above step) by this command _cp /home/vsduser/Desktop/work/tools/openlane_working_dir/pdks/sky130A/libs.tech/magic/sky130A.tech /home/vsduser/Desktop/work/tools/openlane_working_dir/openlane/vsdstdcelldesign/_
78 | 4. Then, open the custom inverter layout in MAGIC through this command: _magic -T sky130A.tech sky130_inv.mag &_cp__
79 |
80 | {IMAGE CREDITS: AUTHOR ; SCREENSHOT TAKEN FROM DEVICE}
81 |
82 | 
83 |
84 | ## Inception of Layout and CMOS Fabrication Process
85 |
86 | The 16 MASK CMOS Fabrication process is as follows:
87 |
88 | ### Create Active Regions
89 |
90 | 1. The first step is to select a substrate - which is where the entirety of your design is fabricated. The most common substrate is a P doped Silicon Substrate. A substrate is ideally lesser doped than it's wells.
91 |
92 | 2. The next step is creating an active region for transistors. It is to be noted that it is necessary to have isolation between the pockets, which can be done through
93 | - Growing 40nm of Silicon Dioxide
94 | - Depositing 80nm of Silicon Nitride.
95 | - Depositing a layer of photoresist
96 | - Deposit mask-1 layer on top of photoresist. It covers the photoresist layer that must not be etched away (protects the two transistor active regions)
97 | - Applying UV light to remove the layers on the unmasked regions
98 | - Removing mask-1 and photoresist layers
99 | - Placing the chip in the furnace to grow the oxide in other areas
100 | - Removing the Si3N4 layer using hot phosphoric acid to have only p-substrate and SiO2 left
101 |
102 | ### Formation of N and P well
103 |
104 | 3. P well and N well formation
105 | + Deposition of photo resist layer and define the areas to protect by deposition of mask-2 and 3. Mask 2 protects the N-Well (PMOS side) while P-Well (NMOS side) is being fabricated and Mask 3 protects P-Well while N-Well is being formed
106 | + Application of UV Light to remove the exposed photoresist
107 | + Placing of chip in furnace to diffuse the boron and phosphorous to form wells. This process is called **Twintub** process.
108 |
109 | > Boron [B] is used to form P-Well and Phosporus [P] is used to form N-well
110 |
111 | ### Formation of Gate Terminal
112 |
113 | Gate Terminal is where Threshhold Voltage is controled - as seen below:
114 |
115 | {IMAGE CREDITS: VSDIAT ; SCREENSHOT TAKEN FROM LECTURE}
116 | 
117 |
118 | 4. Formation of Gate
119 | + Deposit photo resist layer to define the areas to be protected, and then subsequently deposit mask-4. Then, UV light is applied, and the exposed area of photoresist is removed
120 | + Then, implantation of low energy boron at the surface of p-well using mask-4 to control the threshold occurs
121 | + Similarly, implantation of phosphorous/arsenic for n-well using mask-5 occurs
122 | + Fixing the oxide which is damaged by implantation steps by removing extra SiO2 using the hydroflouric acid and re-grow high quality SiO2 on p-substrate to contol the oxide thickness occurs next
123 | + Addition of polysilicon film subsequently occurs
124 | + Then, mask-6 is added and etching using photolithography occurs
125 | + Then, mask 6 is etched off to form the gate terminal
126 |
127 | ### Lightly Doped Drain [LDD] Formation
128 |
129 | 5. LDD Formation - the reason LDDs are created is to prevent the hot electron which can eventually cause Si - Si bonds break or create voltage that passes the 3.2eV barrier leading to issues with doped regions. The second major need is to prevent another effect, known as the short channel effect which can cause gate malfunctioning due to the drain field penetrating the channel.
130 | + Mask 7 and 8 are created for NMOS (lightly doped N-type) and PMOS (lightly doped P-type) respectively.
131 | + Heavily doped impurity (N+ for NMOS and P+ for PMOS) are added for the actual source and drain but the lightly doped impurity which are also added help maintain spacing between the source and drain and prevent hot electron effect and short channel effect.
132 | + To protect the lightly doped regions, we also add SiO2 and create spacers using _plasma anisotropic_ etching
133 |
134 | ### Source and Drain Formation
135 |
136 | 6. Source and Drain Formation
137 | + Thin screen oxide is added to avoid channeling during. Channeling is when implantations dig too deep into substrate which is very problematic
138 | + We create Mask-9 is for N+ implantation and Mask-10 for P+ implantation
139 | + The side wall spacers maintain the N-/P- while implanting the N+/P+
140 | + High temperature annealing is done as well
141 |
142 | ### Local Interconnect Formation
143 |
144 | 7. Steps to Form Connects and Interconnects [LOCAL] - these are very important as they help in controlling the electrical charecteristics. These are also the only things accessible to the end user.
145 | + The thin screen oxide is removed for opening up the source, drain and gate for contact building. We use Titanium as it has less resistance.
146 | + Titanium Diselenide [Ti2Si2] is used for local interconnects
147 | + Mask 11 is formed and Titanium Nitride [Ti N] is etched off by RCA cleaning to create the first level contact
148 |
149 | ### Higher Level Metal Formation
150 |
151 | 8. Higher Level Metal Formation - These steps are very similar to the previous steps and are quite easy to understand.
152 | + The previous steps in the MASK process have created an uneven surface layer. A layer of Silicon Dioxide [SiO2] doped with phosphorous or boron -[boron reduces the temperature] [known as phosphosilicate glass and borophosphosilicate glass] is deposited on the wafer surface.
153 | + Then, the surface is polished using the CMP [Chemical Mechanical Polishing] technique to planarize the surface.
154 | + Contact holes are created through photolithography.
155 | + Various masks are used for the various processes after this:-
156 | - Mask 12 is created for the first contact holes
157 | - Mask 13 is used for the first Aluminum contact layer, which the contact holes are connected to.
158 | - Mask 14 creates the second contact holes
159 | - Mask 15 is similarly, for the second Aluminum contact layer
160 | - Finally, we use Mask 16 for making contact to topmost layer
161 |
162 | ### Lab Introduction to SKY130 Basic Layers Layout and LEF using Inverter
163 |
164 | {IMAGE CREDITS: DEEPTHY SANTHAKUMAR}
165 |
166 | 
167 |
168 | > In sky130A, the first layer is the LDD or local-i and then the m1, m2 layers and so on.
169 | > The power and ground lines are located in m1.
170 | > When polysilicon crosses ndiffusion then NMOS and if polysilicon crosses pdiffusion then PMOS is created.
171 | > The output of the layout is the _LEF_ file, which is used by the router in APR to get the location of standard cell pins for proper routing. So it is essentially an abstract form of the layout of a standard cell.
172 |
173 | ### Lab Steps to Create STD Cell Layout and Extract SPICE Netlist
174 |
175 | For the SPICE extraction of the custom inverter layout, we can enter the following commands in the TCKON -:
176 | 1. _**extract all**_
177 | 2. _**ext2spice cthresh 0 rthresh 0**_ --> This extracts the parasitic information
178 | 3. _**ext2spice**_
179 |
180 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
181 | 
182 |
183 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
184 | 
185 |
186 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
187 | 
188 |
189 | ## SKY130 Tech File Labs
190 | ### Lab Steps To Create Final SPICE deck using SKY130 tech
191 |
192 | The default SPICE deck file using Sky130 is seen in the previous section 👆. Now, we can modify the file to plot a transient response, which would then create a final SPICE deck file by editing as below.
193 |
194 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
195 |
196 | 
197 |
198 | To load the SPICE file for simulation in NGSPICE, type the following command : _**ngspice sky130A_inv.spice**_
199 |
200 | ### Lab Steps to Characterise Inverter using SKY130 Model Files
201 |
202 | After typing this command, you will get a result as follows:-
203 |
204 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
205 |
206 | 
207 |
208 | After this, to generate a graph, type the command _**plot y vs time a**_ to generate a plotted graph of the transient analysis through NGSPICE -:
209 |
210 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
211 |
212 | 
213 |
214 | Using this, we can characterise the cell through four parameters -
215 | 1. value of rise transition, which is the time taken for an output waveform to transit from a value of 20% of the maximum value to 80% of the maximum value = vdd = 3.3V. 20% of 3.3V is about .66V, and 80% is about 2.64V, and hence we will click on those points, whose x and y values will appear in the terminal as seen -:
216 |
217 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
218 |
219 | 
220 |
221 | Then, rise transition = 2.2457ns - 2.1819ns = 0.638
222 |
223 | 2. value of fall transition, which is the time taken for an output waveform to transit from a value of 80% to 20% of the maximum value. Similarly, 4.06818ns - 4.04073ns = 0.02745ns
224 |
225 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
226 |
227 | 
228 |
229 |
230 | 3. value of fall cell delay, which is the time difference {delay} between 50% of the input and 50% of the output which essentially means the time taken for output to fall to 50% and time taken for input to rise to 50%. Calculating fall delay => 4.05402ns - 4.0501ns = 0.00392ns
231 |
232 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
233 |
234 | 
235 |
236 |
237 | 4. value of rise cell delay, which is the time difference {delay} between 50% of the input and 50% of the output which essentially means the time taken for output to rise to 50% and time taken for input to fall to 50%. Calculating rise delay => 2.18381ns - 2.15003ns = 0.03378ns
238 |
239 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
240 |
241 | 
242 |
243 |
244 | Through this, we have charecterised a cell at 27 degrees Celsius successfully -:
245 | [cell was plotted with analysis occuring at 27 degrees Celsius]
246 |
247 |
248 | {IMAGE CREDITS: VSIDAT; SCREENSHOT TAKEN FROM LECTURE}
249 |
250 | 
251 |
252 | ### Lab Introduction to Magic Tool Options and DRC Rules
253 |
254 | A documentation shared by the instructor on how MAGIC performs DRC [Design Rule Check] and it's syntax for the rules is at [this link](http://opencircuitdesign.com/magic/)
255 |
256 | ### Lab Introduction to SKY130 PDKs And Steps to Download Labs
257 | Now, for the lab we need to download the lab files, which can be done through this command -: _**wget http://opencircuitdesign.com/open_pdks/archive/drc_tests.tgz**_
258 |
259 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
260 |
261 | 
262 |
263 | Then, to extract these files, we can type _**tar xfz drc_tests.tgz**_
264 |
265 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
266 |
267 | 
268 |
269 | Then we will go into the directory by **_cd drc_tests_** and then list the contents through _ls -al_. Then to open the magic tool, type _**magic -d XR**_
270 |
271 | ### Lab Introduction to Magic and Steps to Load SKY130 Tech Rules
272 |
273 | Then, in the empty magic prompt, click **"FILE"**, which is at the top and select _open_ and then _met3.mag_ under that, to obtain this screen view wherein we can see a number of independent layouts contain certain DRC errors
274 |
275 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
276 |
277 | 
278 |
279 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
280 |
281 | 
282 |
283 | > NOTE: the text in purple is the periphery rules broken
284 |
285 | ### Lab Excercise to Fix **poly.9** error in SKY130 Tech-File
286 |
287 | Type **_load poly_** in the tkcon window -:
288 |
289 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
290 |
291 | 
292 |
293 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
294 |
295 | 
296 |
297 | Now, to focus on the poly 9 rule as explained at [this link](https://skywater-pdk.readthedocs.io/en/main/rules/periphery.html#rules-periphery--page-root) which states that poly resistor spacing to poly or spacing (no overlap) to diff/tap should be atleast 0.48um! Now, we can look at the below screenshot to find that this is not true, here and hence must be fixed by changing the tech file to include this DRC -:
298 |
299 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
300 |
301 | 
302 |
303 | Firstly, open the **_sky130A.tech_** file from the directory _drc_tests_. The rules included for poly.9 are only for the spacing between the n-poly and p-poly resistor with diffusion. So, we will now add new rules for the spacing between the poly resistor with poly non-resistor. Highlighted in green below are the two newly added rules. First one is the rule for the spacing between the p-poly resistor with poly non-resistor and the next one is the rule for spacing between n-poly resistor with poly non-resistor. The allpolynonres is a macro under alias section of techfile -:
304 |
305 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
306 |
307 | 
308 |
309 | Then, enter commands as shown:
310 |
311 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
312 |
313 | 
314 |
315 | ### Lab Excercise to Implement Poly-Resistor Spacing to Diff and Tap
316 |
317 | In the below pic, we see an error which we can fix by modifying the tech file by not including only the spacing between npolyres with N-substrate diffusion in poly.9 but also between npolyres and all types of diffusion.
318 |
319 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
320 |
321 | 
322 |
323 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
324 |
325 | 
326 |
--------------------------------------------------------------------------------
/DAY 1.md:
--------------------------------------------------------------------------------
1 | # SKY130 Day 1: Inception of OpenSource EDA, OpenLANE and SKY130 PDK
2 |
3 | ## How to Talk to Computers
4 |
5 | ### Introduction to QFN - 48 package, chip, pads, core, die and IPs
6 | A commonly and extensively used arduino circuit board can be seen in the below picture. The board has a processer or SoC i.e. System on a Chip. This is a central part of the chip and is encircled as can be seen below:
7 |
8 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
9 |
10 | 
11 |
12 | The encircled region, however is only a high level view, which can be represented through a block diagram, as shown below:
13 |
14 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture and subsequently hand drawn by author}
15 |
16 | 
17 |
18 | In the picture, we are able to see a large box which represents, as written a SoC. In layman's terms, this often called a "CHIP". However, in technicality it is termed as a "PACKAGE". One kind of package, which is used in the arduino board is a QFN - 48 package (Quad Flat No-Leads). A package can be schematically represented as below:
19 |
20 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture and subsequently hand drawn by author}
21 |
22 | 
23 |
24 | As seen, a chip is actually inside a package, and is connected to various "PINS" or inputs/outputs. The locations of the pins and what they are are usually driven by the design of the PCB. A chip is also a very complex system, and has various components such as -:
25 |
26 | * PADS : They act as connectors between the integrated circuit and chip. Pads, simply are structures for sending electrical signals inside the chip. They are strategically placed and made with respect to the pins
27 | * CORE : This is the digital logic (i.e. the various gates such as AND, OR, XOR etc and the MUXes) is placed. It carries out all processor functions.
28 | * DIE : A die is a part of semiconductor wafer that can be used independently in various devices. It can contain more than one core.
29 |
30 | The core also has various components, which can mainly be segregated into -:
31 |
32 | * FOUNDRY IPs : These are components that are provided to the designer of the SoC by the foundry (i.e. a factory where chips are produced). These components are usually pre-designed and tested by the foundry. Foundry IPs can include PLLs, adc0, adc1, SRAMs and various other components.
33 | * MACROs : Macros are very similar to Foundry IPs, but consist of pure digital logic, that is pre-made for certain common use-cases and can be easily integrated into a SoC or Integrated Circuit (IC). Macros can be of various types such as a GPIO bank and SPI etc.
34 |
35 | Two schematics encompassing all of the above components can be seen below:
36 |
37 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture and subsequently hand drawn by author}
38 |
39 | 
40 |
41 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture and subsequently hand drawn by author}
42 |
43 | 
44 |
45 | ### Introduction to RISC V
46 | RISC-V Instruction Set Architechture, commonly called RISC V ISA, is the language of the computer. When a C program is to be run on a piece of hardware, it is first compiled in an assembly language program like RISC V. It is then converted to machine language i.e. binary and subsequently implemented in the form of a hardware description language such as picorv32 cpu core. A schematic is shown below, representing the same:
47 |
48 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
49 |
50 | 
51 |
52 |
53 | ### From Software Applications to Hardware
54 | Application Software, or apps. They run on hardware such as laptops, mobile phones, tablets etc that are powered by chips. However, apps are coded in complex application programs that require conversion into binary or machine language for running. This is done through system software, which majorly consists of
55 |
56 | * Operating systems - Operating Systems (OSs) perform a variety of functions such as I.O. operation, memory allocation and low level system function. They produce functions in languages such as C, C++, VB and Java, which are sent to the compiler.
57 | * Compilers - Compilers produce simple instructions (the format of which depends on the hardware) in the form of .exe documents, which are to the assemblers. These instructions are abstract interfaces between complex coding languages like C/C++ and hardware, and hence are called ISAs. They are known as the architechture of the computer.
58 | * Assemblers - Assemblers convert the instructions from the compilers into binary, and the function is implemented.
59 |
60 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
61 |
62 | 
63 |
64 |
65 | ## SoC Design and OpenLANE
66 |
67 | ### Introduction to Components of Opensource Digital ASIC Design
68 | ASIC requires mainly three components for design
69 | * RTL IPs - they are building blocks written in a hardware description language. These blocks describe the functioning of the circuit at a basic level and are pre designed and verified.
70 | * EDA Tools - EDA, which expands to Electronic Design Automation tools are used for design, simulation and verification and the analyzing of circuit designs. Common tools are OpenSTA, OpenRoad etc.
71 | * PDK data - Process Design Kit data is a collection of files used to model the fabrication process for EDA tools. It is usually provided by a foundry and include Process Design Rules, Device Models, Digital Standard Cell Libraries and IO libraries.
72 |
73 | However, until June of 2020, there was no OPENSOURCE available PDK data, making it impossible to do ASIC design on opensource platforms. Nonetheless, this changed when Google and Skywater released PDK data on 130 nm chips. There is a unfortunate common misconception that 130 nm is not up to the industrial mark, with chips reaching Armstrong sizes in today's date. This is debunked due to the following two reasons -:
74 | - several applications do not require such advanced nodes, and 130nm chips provide a good amount of power for those cases
75 | - fabrication costs are also much lesser for 130nm chips
76 |
77 | 130 nm chips are also not slow, as verified by intel and OSU-:
78 |
79 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
80 |
81 | 
82 |
83 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
84 |
85 | 
86 | ### Simplified RTL to GDS flow
87 | The RTL to GDSII ( Register Transfer Level to Graphic Design System II) design process takes many steps, that are -:
88 |
89 | - Synthesis - it converts hardware description languages such as VERILOG into gate-level representations part of a standard cell library. The cells part of this library have a regular layout. Each of these have different views/models such as Electrical, HDL, Spice etc.
90 |
91 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
92 | 
93 |
94 | - Floor Planning involves optimizing chip performance, area utilization, and connectivity through spatial arrangements (i.e. the layout and placement of various components)The three main purposes of floor planning are firstly, minimizing wire lengths, secondly, reducing signal delays, thirdly, optimizing power distribution, and fourthly, ensuring efficient chip utilization. Power Planning aims to ensure stable and reliable power delivery to all components by effective distribution and design of power supplies and power distribution networks (PDN). The main purposes of this are minimizing voltage drop and noise, reducing power distribution network (PDN) resistances and capacitances, and ensuring uniform power distribution throughout. Usually the chip is powered through VDD pads which are connected to various components through parallel rectangular strips causing lesser resistance.
95 |
96 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
97 | 
98 |
99 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
100 | 
101 |
102 | - Placement - it is the process of determing where a component will be placed on the chip. The components can include standard cells, macros, and I/O pads. The cells are usually placed on floorplan rows, and are aligned with the sites. There are majorly two steps - global and detailed.
103 |
104 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
105 | 
106 |
107 | - Clock Tree Synthesis - This step is done before routing, because the clock needs to be routed by delivering the clock to all sequential elements.
108 |
109 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
110 | 
111 |
112 | - Routing - The determination of the interconnections of the components throught the various metal layers, whose thickness, pitch etc is detailed by the PDK. The SKY130 has 6 layers.
113 |
114 | - Sign Off - this majorly has verification through three processes:
115 |
116 | + Design Rule Check (DRC) - this makes sure the design complies with manufacturing guidelines and is compatible for fabrication. It aims to detect and correct layout errors so that fabrication defects do not occur.
117 |
118 | + Layout vs. Schematic (LVS) - here the layout is contrasted against the schematic to ensure consistency. LVS tools extract netlists and compare them for differences, after which the design proceeds to physical design flow
119 |
120 | + Static Timing Analysis (STA) - it evaluates timing behaviour of a digital circuit to ensure design meets setup and hold time constraints, maximum clock frequency, and other timing requirements
121 |
122 | ### Introduction to OpenLANE and Strive Chipsets
123 | OpenLANE is an open-source digital ASIC jointly developed by efabless and Google, designed to automate the entire design process flow based on several components including OpenROAD, SPEF-Extractor, KLayout and a number of custom scripts for design exploration and optimization. It aims to create a clean GDSII (i.e. no LVS violations, no DRC violations, and no timing violations) with no human intervention. striVe is family of SoCs created by Efabless.
124 |
125 | {IMAGE CREDITS:VSDIAT ; shared as part of lecture}
126 | 
127 |
128 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
129 | 
130 |
131 | ### Introduction to OpenLANE detailed ASIC Design Flow
132 |
133 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
134 | 
135 |
136 | - Synthesis Exploration - it generates a delay vs area report
137 |
138 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
139 | 
140 |
141 | - Design Exploration - sweeps design configuration and subsequently find best configuration for any given design. It produces a report as shown:
142 |
143 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
144 | 
145 |
146 | - OpenLANE Regression Testing
147 |
148 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
149 | 
150 |
151 | - Design for Test (also k/a DFT)
152 |
153 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
154 | 
155 |
156 | - Physical verification (DRC & LVS) - Magic is used for DRC and Magic and Netgen for LVS.
157 |
158 | - Logic Equivalence Check (LEC) - checks that the physical implementation and the netlist have the same logic. It is performed each time netlist is modified and checks that changing netlist did not change function.
159 |
160 | - Dealing with Antenna Rules violations
161 |
162 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
163 | 
164 |
165 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
166 | 
167 |
168 | {IMAGE CREDITS - VSDIAT ; shared as part of lecture}
169 | 
170 |
171 | - Timing Analysis (STA) - Here, the input also contains a synthesized netlist along with other data.
172 |
173 | ## Get Familiar to Opensource EDA tools
174 |
175 | ### OpenLANE Directory Structure in Detail
176 | Openlane is more of a flow than a tool comprising of the various opensource EDA tools such as Yosys, OpenSTA. The aim of openlane is to automate the entire RTL to GSII flow and make it clean and opensource. It is very similar to commercial EDA tools.
177 |
178 | Exploring OpenSource directory through Linux terminal steps:-
179 |
180 | 1) Open the virtual machine (made as instructed through the document Kunal sir shared) and then open terminal on it.
181 |
182 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
183 | 
184 |
185 | 2) Type _cd Desktop_ and then _cd work/tools_ to change directory to Desktop/work/tools, as this is where all openlane files are stored.
186 |
187 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
188 | 
189 |
190 |
191 | 3) After changing directory, type _ls -ltr_ to list the contents of the directory.
192 |
193 | > Side note: **ltr** represents how the list of contents should be ordered . To find other ways, type _ls --help_.
194 |
195 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
196 | 
197 |
198 | 4) In this workshop, we are going to use **openlane_working_dir**, and hence we will change directory to it by typing _cd openlane_working_dir_. Afterwards, we list the contents using the same _ls -ltr_. In this workshop, we are going to use **pdks** and **openlane** directories and hence we will explore both in sequence.
199 |
200 | 5) Starting with **pdks**, type _cd pdks_ and then _ls -ltr_ to view the contents in **pdks**. Here, we will explore **sky130A**, so similarly change directory and then view contents. One will observe two directories - _libs.tech_ and _libs.rif_
201 |
202 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
203 | 
204 |
205 | 6) _libs.tech_ contains all tool specific files. As seen in the picture - tools like Qflow, netgen, magic etc have directories. Opening the **magic** directory in **libs.tech**, we can see the following files:
206 |
207 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
208 | 
209 |
210 | 7) _libs.ref_ contains all the technology/foundry related processes. Upon further exploration of **sky130_fd_sc_hd**, we see the following
211 |
212 | > **_cd .._** reverses the directory one step behind to the parent directory.cd
213 |
214 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
215 | 
216 |
217 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
218 | 
219 |
220 | 8) Next, we will open **openlane**
221 |
222 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
223 | c
224 |
225 | ### Design Preparation Step
226 |
227 | To open Openlane, we can use the _docker_ command using **interactive**. After invoking the docker command, the prompt changes to **bash-4.2$**, and then one must type _ls -lrth_, and subsequently _./flow.tcl -interactive_ _package require openlane 0.9_ retrives all the required information for openlane.
228 |
229 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
230 | 
231 |
232 | OpenLane has various designs and we are most interested in **picorv32a** Inside the _designs_ folder there is document named _config.tcl_ which overrides the default settings. These configurations are design specific.(e.g. clock period, clock port, verilog files).
233 |
234 | {IMAGE CREDITS: DEEPTHY SANTHAKUMAR}
235 | 
236 |
237 | To setup the design of OpenLANE, we first need to prepare the design ensures that the final product functions correctly and reliably through _prep -design picorv32a_, which gives the following result.
238 |
239 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
240 | 
241 |
242 | The command when run, sets up a filesystem where the OpenLANE can store the results. This creates a folder inside the **picorv32a** directory which contains the command log files, results, and the reports dumped of the various tool. The folder will be only have the lef files generated by this design setup stage. The cell LEF files *.lef* and technology LEF files *.tlef* merge to generate merged.lef inside **runs/tmp/**, wherein a a folder with today's date will be created, inside which a **tmp** folder will have contents, and the _merged.lef_ folder will contain the merged _lef_ files.
243 |
244 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
245 | 
246 |
247 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
248 | 
249 |
250 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
251 | 
252 |
253 |
254 | PROGRESS SO FAR:
255 |
256 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
257 | 
258 |
259 | ### Review Files After Design Prep and Run Synthesis
260 |
261 | Opening the **merged.lef** file through the _less_ command after design prep will give one a document as shown:
262 |
263 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
264 | 
265 |
266 | After this, type the command _run_synthesis_ to run synthesis which converts an abstract netlist into a program to run yosys RTL synthesis, ABC scripts (for technology mapping) and openSTA. This process will take about 5-6 minutes, depending on system speed.
267 |
268 | ### Steps to Charecterise Synthesis Results
269 |
270 | After synthesis, under point 20, there are printing statistics, which can be used to calculate flip-flop ratio.
271 |
272 | > FLIP FLOP RATIO = NO OF DFFs / NO OF CELLS * 100
273 |
274 | Solving this through our data, we get => 1613/18036*100 = 8.94%
275 |
276 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
277 | 
278 |
279 | After this, one may look at the results of the synthesis through hte **picorv32a.synthesis.v** file, which can be found as shown, and then viewed through the _less_ command.
280 |
281 | {IMAGE CREDITS: AUTHOR ; screenshot taken from device}
282 | 
283 |
284 | Also, to look at the clock timing report, we can go into **reports** folder by _cd_ command, and then view the report named **1-yosys_4.stat.rpt**, or the STA report named **2-opensta.timing.rpt** through the _less_ command, which can be exited by pressing the _Q_ key.
285 |
286 |
287 |
288 |
289 |
--------------------------------------------------------------------------------
/DAY 4.md:
--------------------------------------------------------------------------------
1 | # SKY130 DAY 4 : Pre-Layout Timing Analysis and Importance of Good Clock Tree
2 | ## Timing Modelling Using Delay Tables
3 | ### Lab Steps To Convert Grid Information Into Track Information
4 |
5 | _sky130_inv.mag_ located in _vsdstdcelldesign_ directory contains all information like PG and port information, logic etc. OpenLANE is a PnR tool and hence does not require the full information present in the _.mag_ file. The only information that we require are the boundary, power and ground rails, and the inputs & outputs information. This is the reason of we use **.lef** files. Hence, our next objective is to extract the LEF file from the MAGIC file and plug that into the picorv32a design. The guidelines to be followed while making a standard cell are -:
6 |
7 | 1. The input and output ports must lie at the intersection of the horizontal and vertical tracks (this is to ensure the routes can reach the ports).
8 | 2. The width and height of the standard cell must be odd multiples of the track's horizontal and vertical pitch respectively
9 |
10 | > Tracks refer to the horizontal and vertical metal layers on which routing occurs. The grid formed by the intersection of horizontal and vertical tracks creates a routing grid, also k/a a routing matrix.
11 |
12 | The ~/Desktop/work/tools/openlane_working_dir/pdks/sky130A/libs.tech/openlane/sky130_fd_sc_hd/tracks.info contains track information. Before and After changing the grid values -:
13 |
14 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
15 | 
16 |
17 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
18 | 
19 |
20 | Hence, we are able to satisfy the first guideline.
21 |
22 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
23 | 
24 |
25 | Then, we are able to satisfy the second guideline as follows -:
26 |
27 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
28 | 
29 |
30 | ### Lab Steps to Convert Magic Layout to STD Cell LEF
31 |
32 | LEF [Library Exchange Format] which contains information of the standard cell library used in the design. They contain detailed information about the geometric shapes, sizes, layers, and other physical properties of individual cells or macros within the library. The instructions to set the port definitions are available [here](https://github.com/nickson-jose/vsdstdcelldesign#create-port-definition). Next, save the _.mag_ file with a new filename by typing _**lef write**_ in the tkcon terminal, which will generate a new **lef** file with the new filename -:
33 |
34 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
35 | 
36 |
37 | ### Introduction of Timing **libs** and Steps To Include New Cell in Synthesis
38 |
39 | Inside this directory [_pdks/sky130A/libs.ref/sky130_fd_sc_hd/lib/_] are the liberty timing files for SKY130 PDK which have the timing and power parameters for each cell needed in STA. It can either be slow, typical, fast with different supply voltages (1v80, 1v65, 1v95), which are called PVT corners. The library named **sky130_fd_sc_hd__ss_025C_1v80** describes the PVT corner as slow-slow [ie. delay is maximum], 25° Celsius temperature, at 1.8V power supply. Timing and power parameter of a cell are obtained by simulating the cell in a variety of operating conditions [i.e. different corners] and this data is represented in the liberty file, which characterizes all cells and is used during ABC mapping during synthesis stage which maps the generic cells to the actual standard cells available in the liberty file.
40 |
41 | - Firstly, copy the extracted lef file - named _**sky130_vsdinv.lef**_ and the liberty files named _**sky130*.lib**_ from this repository - _**/openlane/vsdstdcelldesign/libs**_ to the **src** directory of **picorv32a**.
42 |
43 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
44 |
45 | 
46 |
47 | - Subsequently, add the following to the _**config.tcl**_ file inside the _picorv32a_ directory. Through this, we are setting the liberty file that will be used for ABC mapping of synthesis (LIB_SYNTH) and for STA (_FASTEST,_SLOWEST,_TYPICAL) and also the extra LEF files (EXTRA_LEFS) for the customized inverter cell.
48 |
49 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
50 |
51 | 
52 |
53 | - After this, invoke the _**docker**_ command and prepare the _**picorv32a**_ design. Plug the new _lef_ file to the OpenLANE flow through the following commands
54 |
55 | > docker
56 | >
57 | >
58 | > ./flow.tcl -interactive
59 | >
60 | >
61 | > package require openlane 0.9
62 | >
63 | >
64 | > prep -design picorv32a
65 | >
66 | >
67 | > set lefs [glob $::env(DESIGN_DIR)/src/*.lef]
68 | >
69 | >
70 | > add_lefs -src $lefs
71 | >
72 | >
73 | > This will generate the following picture -:
74 | >
75 | >
76 | > {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
77 | >
78 | > 
79 |
80 | - Then, run synthesis using the _run_synthesis_ command and check that sky130_vsdinv cell is successfully included in the design
81 |
82 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
83 |
84 | 
85 |
86 | > NOTE : here, timing is not fixed, which then needs to be fixed.
87 | >
88 | >
89 | > {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
90 | >
91 | 
92 |
93 | ### Delay Tables
94 |
95 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
96 |
97 | 
98 |
99 | The above image depicts to us how the enable pin affects the CLK propogation. In case of AND gate, ONLY when the enable pin is equal to 1, the CLK propogates to Y. Similarly, in case of OR gate, the CLK propogates to Y only when the enable pin is 0. Whenever the enable pin is equal to 1, the CLK does not propogate and there is no short circuit power consumption. Switching power consumption when such elemements are used is used in CLOCK TREE. This method is known as Clock Gating Technique.
100 |
101 | However, when we think of this, the question that arises is _**HOW DOES ONE USE THIS?**_ For this purpose, consider the below clock tree structure -:
102 |
103 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
104 |
105 | 
106 |
107 | We see through the above picture that buffers on different levels have different capacitive loads and buffer sizes but as long as they have the same loads and sizes in the same level, the total delay for each clock tree path will be the same and, so skew will remain zero. However, we can observe that practically, different levels can have varying input transition and output capacitive load and hence varying delay.
108 |
109 | We use delay tables to observe each cell's timing models that is included inside the _.lef_ files. The element that majorly impacts delay is _output slew_, which depends on capacitative load and the input slew [which is a function of previous stage buffer's output capacitive load and input slew and has its own transition delay table.]
110 |
111 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
112 | 
113 |
114 | We notice at level 2 that both buffers have identical delays due to equal transition times, load capacitances and buffers sizes. Subsequently, we see that the _skew_ is zero. However if this is not true, the skew will be negative, which will cause timing violations. On a small scale, these are often considered to be insignificant but we see their importance in large designs which millions of cells, where in if we fail to adhere to guidelines during clock tree creation, many timing-related complications can be caused.
115 |
116 | > CTS is the process of designing a clock distribution network to minimize skew and ensure synchronous operation of the circuit
117 | >
118 | > Skew refers to the variation in clock signal arrival times, and slew [rate] is the rate of change of signal's voltage on time
119 | >
120 | > Latency is the delay experienced by the clock signal
121 |
122 | ### Lab Steps To Configure Synthesis Settings to Fix Slack and Include VSDINV
123 |
124 | We can see through previous pictures that currently,
125 | - tns = -711.59
126 | - wns = -23.89
127 | - chip area for the module picorv32a = 147712.9184
128 |
129 | Hence, our next step is to try to make the synthesis more **timing driven**. This can be done as follows-:
130 |
131 | 1. Firstly, check synthesis strategy and other timing related variables and then modify accordingly
132 | - SYNTH_STRATEGY of delay 0 will mean that the tool will focus more on optimizing the delay
133 | - index can changed to be 0, 1, 2, or 3 where 3 is the most optimized for timing at the cost of area.
134 | - SYNTH_BUFFERING of 1 will ensure that the buffer will be used on high fanout cells to reduce wire delay.
135 | - SYNTH_SIZING of 1 will enable cell sizing where cell will be upsized or downsized as needed to meet timing.
136 | - SYNTH_DRIVING_CELL is the cell used to drive the input ports and is vital for cells with a lot of fan-outs since it needs higher drive strength.
137 |
138 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
139 |
140 | 
141 |
142 | 2. After this, run synthesis again. It is will be seen that area is increased but there is no negative slack
143 | + tns = 0
144 | + wns = 0
145 | + Chip area for module picorv32a = 209181.872
146 |
147 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
148 |
149 | 
150 |
151 | 3. Subsequently, we may run floorplan and placement
152 |
153 | > NOTE : If any error comes related to macro placement, temporary solution is to comment **basic_macro_placement** inside the file **OpenLane/scripts/tcl_commands/floorplan.tcl** (this is okay since we are not adding any macro to the design).
154 | >
155 | > We can also execute the following commands:-
156 | >
157 | > init_floorplan
158 | >
159 | > place_io
160 | >
161 | > global_placement_or
162 | >
163 | > detailed_placement
164 | >
165 | > tap_decap_or
166 | >
167 | > detailed_placement
168 |
169 | After successful run, **runs/[date]/results/placement/picorv32a.placement.def** will be created:-
170 |
171 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
172 |
173 | 
174 |
175 | 4. After this, search for instance of cell **sky130_vsdinv** inside the DEF file after the placement stage through this command **cat picorv32a.placement.def | grep sky130_vsdinv**
176 |
177 | 5. Then, select a single **sky130_vsdinv** cell instance from the list dumped by grep (e.g. 41096). On tkcon, command **select cell 41096** may be run. Press ctrl+z to zoom into that cell. As shown below, our customized inverter cell sky130_myinverter is sucessfully placed. Use the **expand** command on tkcon to show the footprint of the cell and notice how the power and ground of sky130_vsdinv overlaps the power and ground pins of its adjacent cells -:
178 |
179 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
180 |
181 | 
182 |
183 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
184 |
185 | 
186 |
187 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
188 |
189 | 
190 |
191 | ## Timing Analysis With Ideal Clocks Using Open STA
192 | ### Setup Timing Analysis And Introduction to Flip-Flop Setup Time
193 |
194 | Consider an ideal clock [i.e. the clock tree is not built yet] where perform timing analysis to understand the parameters [later the same can be done using real clocks]. Specifications are as mentioned in the picture [Clock frequncy (F) is 1GHz and clock period (T) is 1ns]. -:
195 |
196 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
197 |
198 | 
199 |
200 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
201 |
202 | 
203 |
204 | The setup timing analysis equation is = Θ < T - S
205 |
206 | > Θ = Combinational delay which includes clk to Q delay of launch flop and internal propagation delay of all gates between launch and capture flop
207 | >
208 | > T = Time period, also called the required time
209 | >
210 | > S = Setup time. As demonstrated below, signal must settle on the middle (input of Mux 2) before clock tansists to 1 so the delay due to Mux 1 must be considered, this delay is the setup time.
211 |
212 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
213 |
214 | 
215 |
216 | ### Introduction to Clock Jitter and Uncertainty
217 |
218 | CLK signals are sent to the device by the PLL (Phase Locked Loop). This clock source is expected to send clock signal at 0, T, 2T etc. However, even these clock sources might or might not be able to provide a clock **exactly** at Tns because of its own in-built variation known as jitter. Jitter can be thought of as short-term fluctuations in the timing of signal transitions, which can result in deviations from the expected clock or data timing.
219 |
220 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
221 |
222 | 
223 |
224 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
225 |
226 | 
227 |
228 | Hence, we see that a more realistic equation for setup time is = Θ < T - S - SU
229 |
230 | > SU = Setup uncertainty due to jitter which is temporary variation of clock period, which is due to non-idealities of PLL.
231 |
232 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
233 |
234 | 
235 |
236 | ### Lab Steps to Configure OpenSTA for Post-Synth Timings Analysis
237 |
238 | STA can either be -:
239 | + single corner - which only uses the LIB_TYPICAL library which is the one used in pre-layout(pos-synthesis) STA
240 | + multi corner - multicorner which uses LIB_SLOWEST(setup analysis, high temp low voltage),LIB_FASTEST(hold analysis, low temp high voltage), and LIB_TYPICAL libraries
241 |
242 | 1. In the location *Desktop/Work/tools/openlane_working_dir/openlane_ there is a file named *pre_sta.conf* on which we will be doing the prelayout analysis. The file contains the following contents-:
243 |
244 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE AND SUBSEQUENTLY MODIFIED FOR MORE CLARITY}
245 |
246 | 
247 |
248 | 2. This is the SDC file on which analysis will be done is located at *Desktop/Work/tools/openlane_working_dir/openlane/designs/picorv2a/src* and is named *my_base.src_. It contains the following contents -:
249 |
250 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE AND SUBSEQUENTLY MODIFIED FOR CLARITY}
251 |
252 | 
253 |
254 | 3. The various commands to be run and their functions are -:
255 |
256 | + _create_clock_ -it creates clock for the port with specified time period.
257 |
258 | + *set_input_delay* and *set_output_delay* - defines the arrival/exit time of an input/output signal relative to the input clock. [This is the delay of the signal coming from an external block and internal delay of the signal to be propagated to external ports] This adds a delay of Xns relative to clk to all signals going to input ports, and delay of Yns relative to CLK to all signals going to output ports.
259 |
260 | + *set_max_fanout* - specifies maximum fanout count for all output ports in the design.
261 |
262 | + *set_driving_cell* - models an external driver at the input port of the current design.
263 |
264 | + *set_load* sets a capacitive load to all output ports.
265 |
266 | 4. Execute *sta pre_sta.conf* and check timing.
267 |
268 | ### Lab Steps to Optimize Synthesis to Reduce Setup Violations
269 |
270 | To reduce negative slack, focus on large delays. Net with big fanout might cause delay increase. Use report_net -connections to display connections. First thing we can do is to go back to OpenLane and reduce fanouts by setting ::env(SYNTH_MAX_FANOUT) 4 then run_synthesis again.
271 |
272 | For reducing the negative slack obtained, we must focus on the large delays and try to reduce them. Increases in delays are majorly caused by nets with big fanouts, which result in high load cap which causes high delay. To display the connections of the nets, the commands **report_net -connections ** can be used. Now, looking upon this output, we realise that fanouts must be reduced. This can be done by going back to OpenLANE and reducing fanouts by typing **::env(SYNTH_MAX_FANOUT) 4**. After this, we can run_synthesis again and obtain a expected value for slack.
273 |
274 | ### Lab Steps to do Basic Timing ECO
275 |
276 | However, if we want to reduce the negative slack even more, we can upsize the cells with high fanouts so that bigger drivers will be used. Now, since we cannot change load capacitance but can change the cell size, we can increase the size of the cell for a large driver to drive large cap loads leading to lesser delay. This is often done in iterations until we reach the desired slack in a process known as Timing ECO [Engineering Change Order]
277 |
278 | ## Clock Tree Synthesis TritonCTS and Signal Integrity
279 | ### Clock Tree Routing and Buffering Using H-Tree Algorithm
280 |
281 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
282 |
283 | 
284 |
285 | Take into account the CLK port going to the various flip-flops in the above picture. It's purpose is to connect the port to the CLK pins of the many flip-flops based on the connectivity information given. In the above picture, we have blindly made connections and hence t2 is greater than t1. Skew is the difference between t2 and t1. CLK skew, as explained earlier, refers to the variation in arrival times of the clock signal at different points within a digital system. More simply, CLK skew is essentially the difference in propogation delay of the CLK signal as it moves along various paths. It can occur due to -:
286 | - differences in wire lengths
287 | - variations in signal routing paths
288 | - variations in buffer delays
289 | - other physical and environmental factors
290 |
291 | Due to this, some parts of the system can recieve CLK signals earlier than or after the rest of the system. Minimizing clock skew is essential as to -:
292 | - ensure proper synchronization of signals
293 | - reliable operation of the digital circuit.
294 |
295 | > NOTE : Ideally, the skew should be zero.
296 |
297 | Now, since the skew is not minimum, or even close to minimum in the above picture, we can call this tree a **_bad tree_**. To optimize this scenario, we can use H-Tree routing. It analyses the clock route by calculating the distance from the source to all the endpoints and deciding on a midpoint to start building tree. Subsequently, it finds another midpoint and creates divergents in the wire. Eventually, after repeating this process, the CLK reaches all the flip-flops at almost the same time, while splitting up at various midpoints.
298 |
299 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
300 |
301 | 
302 |
303 | It is expected that the input CLK signal is exactly reproduced at the output. However, this does not happen in H-Tree routing due to inherent resistance and capacitance in physical wires, which may cause the signal to experience distortion. We can solve this problem by inserting buffers/repeaters along the path for signal integrity. In the past, we have also talked about another kind of repeaters, used in data paths. The key differences between repeaters used in clock and data paths respectively lie in their **rise and fall times**. Clock buffers have **same rise and fall times**, to ensure uniform signal propagation throughout the clock distribution network. Contrastingly, data buffers exhibit **varying rise and fall times**, which may differ based on the characteristics of the data being transmitted and the components involved in processing it.
304 |
305 | ### Crosswalk and Clock Net Shielding
306 |
307 | Clock nets are critical nets in the design because clock tree is built is such a fashion that the skew is zero. There is a phenomenon called crosstalk where a signal transmitted on one channel interacts with or interferes with signals on adjacent channels leading to distortion, noise, timing errors etc, which can cause the clock tree structure will be deteriorated. To solve this, all the clock nets are shielded [protected]. If there is a wire adjacent to such shields, then there exists a huge coupling capacitance causing two issues - (i) glitch and (ii) delta delay.
308 |
309 | Whenever there is a switching activity happening in the aggressor, then the coupling capacitance is so strong that it directly affects the net close to it named _the victim net_, which is without any shielding. This causes a dip in the voltage, resulting in glitch. Due to a glitch, there can be incorrect data in memory, which can cause inaccurate functionality. To solve this, we do shielding which protects the victim nets by breaking the coupling capacitance between the aggressor and the victim. These shielding nets are either in the form of Vdd or Vss. The shields do not switch, and hence the victim will not switch as well.
310 |
311 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
312 |
313 | 
314 |
315 | ### Lab Steps to run CTS using TritonCTS
316 |
317 | After completion of Timing ECO, we see that the timing currently is still above 1. To reduce it, we can go through the results and switch the cells causing a lot of slack to buffers. After this the negative slack is reduced to below 1.
318 |
319 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
320 |
321 | 
322 |
323 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
324 |
325 | 
326 |
327 | After this, for OpenLANE to use the modified netlist, we can type **write_verilog [filename]** and then run floorplan and placement.
328 |
329 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
330 |
331 | 
332 |
333 | After running CTS, we can see that the clock buffers get added -:
334 |
335 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
336 |
337 | 
338 |
339 | ### Lab Steps to Verify CTS Runs
340 |
341 | After the previous step, OpenLANE will take the procedures from **/Desktop/work/tools/openlane_working_dir/openlane/scripts/tcl_commands** and eventually invoke OpenROAD to run the tool.
342 |
343 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
344 |
345 | 
346 |
347 | For example, the command **run_cts** is found in the location _/OpenLane/scripts/tcl_commands/cts.tcl_. This tcl process will invoke OpenROAD which will call the _cts.tcl_ which contains the OpenROAD commands for TritonCTS.
348 |
349 | > The file contains many configuration variables for CTS like-:
350 | >
351 | > - CTS_CLK_BUFFER_LIST -> which has the list of clock buffers used in clock tree branches (sky130_fd_sc_hd__clkbuf_1 sky130_fd_sc_hd__clkbuf_2 sky130_fd_sc_hd__clkbuf_4 sky130_fd_sc_hd__clkbuf_8)
352 | > - CTS_ROOT_BUFFER -> this is the clock buffer used for the root of the clock tree and is the biggest clock buffer to drive the clock tree of the whole chip (sky130_fd_sc_hd__clkbuf_16)
353 | > - CTS_MAX_CAP -> it is a numerical value for the maximum capacitance of the output port of the root clock buffer
354 |
355 | ## Timing Analysis With Real Clocks Using Open STA
356 | ### Setup Timing Analysis Using Real Clocks
357 |
358 | Now the clock tree is built and timing analysis is done on real clocks.
359 |
360 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
361 |
362 | 
363 |
364 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
365 |
366 | 
367 |
368 | > delta1 = launch flop clock network delay
369 | >
370 | >
371 | > delta2 = capture flop clock delay
372 |
373 | Any design satisfying Slack [i.e. Data required time - Data arrival time] is ready to work in the given frequency. However, if this equation is violated, then slack will become negative which is not expected. We expect slack to be either zero or positive.
374 |
375 | ### Hold Timing Analysis Using Real Clocks
376 |
377 | Hold Time is delay [time] needed by the MUX2 model within a flip-flop to transfer certain data outside. [i.e. how long it **holds** the data]. It is the time period during which the launch flop must retain dat before it reaches the capture flop. Unlike setup analysis, which has two rising clock edges, hold analysis occurs on the same rising clock edge for both the launch and capture flops.
378 |
379 | A hold violation occurs when the path is too fast, impacted by factors such as -:
380 | - combinational delay
381 | - clock buffer delays
382 | - hold time.
383 |
384 | > Notably, parameters such as time period and setup uncertainty hold no significance, as both launch and capture flops receive identical rising clock edges during hold analysis.
385 |
386 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
387 |
388 | 
389 |
390 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
391 |
392 | 
393 |
394 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
395 |
396 | 
397 |
398 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
399 |
400 | 
401 |
402 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
403 |
404 | 
405 |
406 | {IMAGE CREDITS: VSDIAT; SCREENSHOT TAKEN FROM LECTURE}
407 |
408 | 
409 |
410 |
411 | ### Lab Steps to Analyse Timing With Real Clocks Using OpenSTA
412 |
413 | The aim is to analyse the clock tree explained previously. The steps for analysis of timings with real clocks are -:
414 |
415 | 1. Enter into OpenROAD using the **openroad** command.
416 |
417 | > NOTE: In OpenROAD, timing is done slightly differently, where in a db is created from lef and def files and subsequently used
418 |
419 | 2. Subsequently create the db file through this command -: *read_lef [location of merged.lef]
420 |
421 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
422 |
423 | 
424 |
425 | 3. Then, we must read the def file from the CTS stage
426 |
427 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
428 |
429 | 
430 |
431 | 4. Subsequently create the db through this command -: _write_db pico_cts.db_
432 |
433 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
434 |
435 | 
436 |
437 | 5. Then, read the db, verilog files, library and sdc
438 |
439 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
440 |
441 | 
442 |
443 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
444 |
445 | 
446 |
447 | 6. After this, set the propogated clock to calculate the actual delay in the clock path through the command -: *set_propogated_clock [all_clocks]*
448 |
449 | 7. Subsequently check the timings -:
450 |
451 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
452 |
453 | 
454 |
455 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
456 |
457 | 
458 |
459 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
460 |
461 | 
462 |
463 | ### Lab Steps to Excecute OpenSTA With Right Timing Libraries and CTS Assignment
464 |
465 | TritonCTS is build to optimise only based on one corner. However, the libraries included previously that also take part in timing analysis optimise based on both min and max corners, which is not accurate. Hence, we need to exit and re-enter OpenROAD and then check timing only for typical corner.
466 |
467 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
468 |
469 | 
470 |
471 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
472 |
473 | 
474 |
475 | Here, we can see that slack is met for both setup and hold analysis in the typical scenario-:
476 |
477 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
478 |
479 | 
480 |
481 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
482 |
483 | 
484 |
485 | > NOTE: When the CTS is built, skew values are tried to be met by inserting buffers from **CTS_CLK_BUFFER_LIST**, which can be modified based on requirements.
486 | >
487 | > When TritonCTS builds the clock tree, it tries to use each buffer listed in *$::env(CTS_CLK_BUFFER_LIST) (sky130_fd_sc_hd__clkbuf_1 sky130_fd_sc_hd__clkbuf_2 sky130_fd_sc_hd__clkbuf_4 sky130_fd_sc_hd__clkbuf_8)* from smallest to largest until the target skew is met.
488 | >
489 | > It stores target skew in _$::env(CTS_TARGET_SKEW)_.
490 | >
491 | > The STA result also shows that **sky130_fd_sc_hd__clkbuf_1** is the most used buffer, and we can also change the **$::env(CTS_CLK_BUFFER_LIST)** to use other buffers and observe the effect on STA and area.
492 | >
493 | > We can also use tcl lreplace command to modify $::env(CTS_CLK_BUFFER_LIST)
494 |
495 | Example:
496 |
497 | {IMAGE CREDITS: AUTHOR; SCREENSHOT TAKEN FROM DEVICE}
498 |
499 | 
500 |
501 | The _$::env(CURRENT_DEF)_ used by CTS is the DEF file of the previously run CTS, but the DEF file we want for CTS is the placement's DEF file. So to implement this, change the **$::env(CURRENT_DEF)** to point to placement DEF file then *run_cts*.
502 |
503 | Now, observe the resulting post-CTS STA compared to previous run since we modified the clock buffer. Only buf_2 clock buffer is used now compared to buf_1 used in previous run, and hte WNS is better now since we have used bigger clock buffers.
504 |
505 |
--------------------------------------------------------------------------------