ECE637 Integrated VLSI Systems Professor David Rennie University of Waterloo Department of Electrical and Computer Engineering

Transcription

1 ECE637 Integrated VLSI Systems Professor David Rennie University of Waterloo Department of Electrical and Computer Engineering Project: Winter nm Han-Carlson Adder By: Chris Beg (292646)

2 Table of Contents 1.Literature Review of Adder Architectures Architectures Analyzed Optimization and Implementation Flow Results and Conclusions Project Overview Hierarchy of Design HDL Model (Verilog) Schematic myINV Gate myNOR Gate myNAND Gate myXNOR Gate driverINV Gate pgBlock sumBlock genBlock & genwithpropblock adderPGLogic adderSumLogic adderGroupLogic Top Level Adder Test-Bench Simulations myINV Gate myNOR Gate myNAND Gate myXNOR Gate driverINV Gate Block Level Simulation Verification Top Level Adder myINV Gate myNOR Gate myNAND Gate myXNOR Gate driverINV Gate pgBlock sumBlock genBlock & genwithpropblock adderPGLogic adderGroupLogic adderSumLogic Top Level Adder Conclusions...32 Appendix A. Verilog Model - Top Level - adder.v...35 Appendix B. Verilog Model PG Logic - adderpglogic.v...36

3 Appendix C. Verilog Model Group Logic - addergrouplogic.v...37 Appendix D. Verilog Model Sum Logic addersumlogic.v...39 Appendix E. Verilog Model All Blocks...4 Appendix F. Verilog Model Test Bench...41 Appendix G. Verilog Model Random Vector Generator...42 Appendix H. LVS Report for myinv...43 Appendix I. LVS Report for mynor...44 Appendix J. LVS Report for mynand...45 Appendix K. LVS Report for myxnor...46 Appendix L. LVS Report for driverinv...47 Appendix M. LVS Report for pgblock...48 Appendix N. LVS Report for genblock...49 Appendix O. LVS Report for genwithpropblock...5 Appendix P. LVS Report for sumblock...51 Appendix Q. LVS Report for adderpglogic...52 Appendix R. LVS Report for addergrouplogic...53 Appendix S. LVS Report for addersumlogic...54 Appendix T. LVS Report for adder16 (Complete Project)...55

4 Table of Figures Figure 1: Han-Carlson Adder Architecture...8 Figure 2: Design Hierarchy Illustration...9 Figure 3: ModelSim Simulation Results...1 Figure 4: myinv Gate Schematic...11 Figure 5: mynor Gate Schematic...11 Figure 6: mynand Gate Schematic...12 Figure 7: myxnor Gate Schematic...12 Figure 8: driverinv Gate Schematic...13 Figure 9: pgblock Logic Schematic...13 Figure 1: sumblock Logic Schematic...14 Figure 11: genblock Logic Schematic...14 Figure 12: genwithpropblock Logic Schematic...14 Figure 13: adderpglogic Logic Schematic...15 Figure 14: addersumlogic Logic Schematic...15 Figure 15: addergrouplogic Logic Schematic...16 Figure 16: Top Level Adder Schematic...17 Figure 17: Adder Test-Bench Schematic...17 Figure 18: Standard Gate Simulation Testbench...18 Figure 19: myinv Gate Transient Simulation...18 Figure 2: mynor Gate Performance Optimization...19 Figure 21: mynor Gate Transient Simulation...19 Figure 22: mynand Gate Performance Optimization...2 Figure 23: mynand Gate Transient Simulation...2 Figure 24: myxnor Gate Performance Coarse Optimization...21 Figure 25: myxnor Gate Performance Fine Optimization...21 Figure 26: myxnor Gate Transient Simulation...22 Figure 27: driverinv Gate Transient Simulation...22 Figure 28: pgblock Transient Simulation...23 Figure 29: genwithpropblock Transient Simulation...23 Figure 3: Adder TT Functional Operation...24 Figure 31: Adder FF Functional Operation...24 Figure 32: Adder SS Functional Operation...24 Figure 33: Adder Delay Variability Analysis...25 Figure 34: Adder Power Consumption Variability Analysis...25 Figure 35: myinv Gate...26 Figure 36: mynor Gate...26 Figure 37: mynand Gate...27 Figure 38: myxnor Gate...27 Figure 39: driverinv Gate...28 Figure 4: pgblock Logic Schematic...28 Figure 41: genblock Logic...29 Figure 42: genwithpropblock Logic...29 Figure 43: adderpglogic Logic...3 Figure 44: addergrouplogic Logic...3 Figure 45: addersumlogic Logic...31

5 Figure 46: adder16 (Complete Project)...31 Index of Tables Table 5.1: myinv Final Performance Results...18 Table 5.2: mynor Final Performance Results...19 Table 5.3: mynand Final Performance Results...2 Table 5.4: myxnor Final Performance Results...22 Table 6.1: myinv Gate Properties...26 Table 6.2: mynor Gate Properties...26 Table 6.3: mynand Gate Properties...27 Table 6.4: myxnor Gate Properties...27 Table 6.5: driverinv Gate Properties...28 Table 6.6: pgblock Properties...28 Table 6.7: genblock Properties...29 Table 6.8: genwithpropblock Properties...29 Table 6.9: adderpglogic Properties...3 Table 6.1: addergrouplogic Properties...3 Table 6.11: addersumlogic Properties...31 Table 6.12: adder16 Properties...31 Table 7.1: myinv Component Count Summary...32 Table 7.2: mynor Component Count Summary...32 Table 7.3: mynand Component Count Summary...32 Table 7.4: myxnor Component Count Summary...32 Table 7.5: driverinv Component Count Summary...32 Table 7.6: pgblock Component Count Summary...33 Table 7.7: genblock Component Count Summary...33 Table 7.8: genwithpropblock Component Count Summary...33 Table 7.9: sumblock Component Count Summary...33 Table 7.1: adderpglogic Component Count Summary...33 Table 7.11: addergrouplogic Component Count Summary...33 Table 7.12: addersumlogic Component Count Summary...34

6 1. Literature Review of Adder Architectures Before entering the design phase of the adder, some background reading was done to ramp myself up on some of the concepts, terminology, trade offs and constraints involved with adder / ALU circuits. A very comprehensive I found on IEEE Xplore was Post- Comparison of High Performance 64b Static Adders in Energy-Delay Space 1. This paper provided really good background information, because its focus was to analyze the most energy efficient architecture, while examining different parameters such as delay, logic levels, fanout, and wiring complexity. Within the paper, the target adder size is a 64-bit design, which makes things like delay and complexity even more critical Architectures Analyzed A number of different adder architectures were analyzed and discussed. Below is a very brief summary of some of the advantages / disadvantages of various designs evaluated. Full Kogge-Stone: Advantages: Fanout of 2, and probably fastest at the schematic level Disadvantages: Large amount of logic redundancy makes design less power efficient Knowles: Advantages: Results in fewer long wires, which improves layout and reduces capacitance Disadvantages: Design has the same number of logic cells as Full Kogge-Stone design (large) Kogge-Stone Sparseness 2 and Han-Carlson: Advantages: Energy efficient and fast designs have only have logic cells as Kogge-Stone Disadvantages: Wiring and complexity is increased Kogge-Stone Sparseness: Advantages: Sparseness increases power efficiency Disadvantages: Increased fanout in some cases Sparse Knowles: Advantages: Reduced wires Disadvantages: Increased fanout 1.2. Optimization and Implementation Flow The paper described an optimization and implementation design flow which was used throughout the analysis. The design flow consisted of a seven step procedure which results in what is considered an optimized design. The procedure makes use of commercial tools such as Synopsis AMPS and Pathmill to aid the design. The seven step procedure is as follows: 1 Post- Comparison of High Performance 64b Static Adders in Energy-Delay Space by Sheng Sun and Carl Sechen

7 1. Gate sizing (AMPS) runs to determine Energy-Delay (E-D) plots (using a wire load model) 2. Select E, D points and execute itools placementand routing 3. Extract actual 3D wire loads (Assura RCX andstar-rcxt) and determine E, D 4. Re-run sizer for one or more of the layout points 5. itools ECO place and route 6. Extract 3D actual wire loads and determine E, D 7. If necessary, repeat 4-6 once This design flow is interesting to know, however it relies heavily on various tools rather than full hand designed logic. To implement a full 64-bit adder by hand would be a very tedious and time consuming task, so it is fair to say unless a highly optimized and highly customized design is required a design flow such as this is normally what is done Results and Conclusions The main analysis performed was the experimentation of adding things like buffering within various logic paths to tradeoff current consumption, area, delay, etc. Energy-Delay curves are used as a metric to evaluate the overall effectiveness of the design. By playing with the CLA (Carry-Look-Ahead) trees and buffering, the design can be optimized with respect to the Energy-Delay-Product. At the end of the day, it turns out that there is not a single best solution, and with most other things the best solution is dependent on the constraints of the problem. For some delay targets the modified CLA trees provide an optimal solution, however for other delay / power targets a traditional Brent-Kung architecture is better.

8 2. Project Overview The Han-Carlson adder is a logarithmic adder, with an overall CLA tree illustrated in the following figure. The implementation technology for this adder will be TSMC 65 nm. Figure 1: Han-Carlson Adder Architecture The implementation of the adder will be done by breaking the functionality into fundamental blocks which larger functions can be built from. A Verilog model was constructed which I found VERY useful when grouping the logic together. Ultimately there are 4 fundamental building blocks, plus a larger inverter used to drive the output signals. The 4 fundamental blocks are a INV, NAND, NOR, and XNOR. The blocks were named: myinv, mynand, mynor, and myxnor. Each of these blocks were tested and optimized separately (with some initial design criteria assumed more described below) before grouping them together to build larger blocks. Each of the fundamental blocks were designed with one or more tuning parameters which allow the tradeoff of Area / Power / Delay to be made.

9 2.1. Hierarchy of Design To maximize the amount of functionality that can be reused, the overall hierarchy of the adder is important. This also means the amount of testing / design effort / layout is reduced, however the tradeoff is flexibility. Optimizing a section of the circuit may be ideal when it is used for one situation, however it may be less ideal when used by a different part of the circuit. This tradeoff comes in the form of power, delay, area. The following figure illustrates the hierarchy that is implemented within the design. Note that at the most primitive level, only 5 logical operations are required (actually 4, however a seperate block has been created for a larger inverter to drive the output load. The following structure also represents how the project was structured throughout the design files. Figure 2: Design Hierarchy Illustration

10 3. HDL Model (Verilog) To aid with the logic optimization, a verilog model was built to allow quick and easy verification of the entire adder. A big part of the project's complexity can be reduced with well optimized logic, and rather than testing the logic at the transistor level, it makes much more sense to test it at the HDL level. My goal during the logic optimization was to design the logic to work with easily implementable CMOS logic blocks (ie: blocks with inverted outputs such as NOR, NAND, etc). Doing this avoids the need for placing inverters all throughout the design (larger power consumption, taking up area, requiring more layout effort). In addition, I chose to avoid placing inverters on all inputs, which means the logic will have to be designed with this into account. The advantage to not placing inverters on all inputs is less power, less area, and less layout effort. The disadvantage to not placing inverters on all inputs is potentially larger delay (as it is dependent on the circuit driving the inputs). Throughout the group logic, all propagate and generate blocks will work with inverted inputs and inverted outputs. This means that the PG logic block will have to take in non-inverted inputs, and generate inverted PG outputs for the group logic. In addition, it means that the SUM logic block will have to take inverted inputs, and generate non-inverted outputs. By having the SUM logic block take inverted inputs and generate non-inverted outputs works quite well from a design optimization point of view, as larger inverters can be placed on the output to satisfy the transformation requirement, and in addition serve as an output driver to drive the specified output load. Finally, to verify logic was properly designed and optimized, a random vector generator was created in verilog by using two LFSRs with different polynomials (maximum length). These vectors were fed into the adder model, and the adder output was compared with an ideal generated sum. If a difference between actual and expected output was detected, an additional signal (labeled Not Equal) was raised high. This allowed to quickly and easily test a HUGE number of different vectors to determine if any logic errors were present. The following figure illustrates the ModelSim output. The entire verilog model is presented in Appendix A to Appendix G. A good future modification for the Not Equal signal would be to turn it into a set-latch, where once it is set it remains set. This would allow for only checking the signal at the end of the simulation rather than scanning it throughout the entire simulation. Figure 3: ModelSim Simulation Results

11 4. Schematic The following sections describe the schematic design of all the functional gates and blocks as described by the verilog model. To allow for easier implementation and debugging, the schematic design will match the design described by the verilog model, and not deviate myinv Gate The myinv block implements a NOT function. It is a simple inverter. The sizes selected for the inverter are based primarily off the unit inverter used for previous assignments. The inverter has a tuning parameter which keeps the ratio between N and P devices constant, but allows to increase the size (to increase speed). The tuning parameter is called myinvfactor, and when set to 1. the resulting block will be a unit inverter. The following figure shows the circuit schematic of myinv. Figure 4: myinv Gate Schematic 4.2. mynor Gate The mynor block implements a logical NOT-OR function. The sizes selected for the devices are based primarily off the unit inverter used for previous assignments, and scaled such that worse-case delays are matched for rising and falling. The gate has a tuning parameter which keeps the ratio between N and P devices constant, but allows to increase the overall size trade off power/delay/area. The tuning parameter is called mynorfactor, and when set to 1. the resulting block will be of unit size. The following figure shows the circuit schematic of mynor. Figure 5: mynor Gate Schematic

12 4.3. mynand Gate The mynand block implements a logical NOT-AND function. The sizes selected for the devices are based primarily off the unit inverter used for previous assignments, and scaled such that worse-case delays are matched for rising and falling. The gate has a tuning parameter which keeps the ratio between N and P devices constant, but allows to increase the overall size to trade off power/delay/area. The tuning parameter is called mynandfactor, and when set to 1. the resulting block will be of unit size. The following figure shows the circuit schematic of mynand. Figure 6: mynand Gate Schematic 4.4. myxnor Gate The myxnor block implements a logical NOT-XOR function. This gate was designed using a sixtransistor pass transistor architecture. The advantage to using an architecture like this is overall transistor count is reduced (reducing area / layout complexity / power). The disadvantage to this kind of design is delay will be determined by the block driving the inputs. This is because all parasitic capacitance needs to be charged / discharged through the transmission gates, which are connected to the block inputs. This basically relates to the block having a potentially larger input capacitance (which will depend on what the output of the block is connected to. From an optimization standpoint, there are two tuning parameters which can be tweaked. The two parameters are called myxnorfactor1 and myxnorfactor2. The myxnorfactor1 variable controls the sizing of the inverter structure, and the variable myxnorfactor2 controls the sizing of the two transmission gates. The ratio between NMOS and PMOS is based on the unit inverter, and remains unchanged. The following figure shows the circuit schematic of myxnor. Figure 7: myxnor Gate Schematic

13 4.5. driverinv Gate The driverinv block was taken directly from the assignments. This block was designed specifically to drive a capacitive load equal to 4x an inverter of fixed width. The design was not modified for the purposes of this project. Optimization was not performed, as it was used as designed for the assignments. Figure 8: driverinv Gate Schematic 4.6. pgblock The pgblock performs the logic function: n_p = A XNOR B n_g = A NAND B This block is built up using the gate level logic (XNOR gate and NAND gate). No additional tuning parameters are added to this block, as for simplicity the tuning will be performed at the individual logic gate level. In an actual application, if every bit of performance needs to be squeezed out of the adder, then it may make sense to optimize this block. The following figure illustrates the schematic used. Figure 9: pgblock Logic Schematic

14 4.7. sumblock The sumblock performs the logic function: n_s = n_p XNOR n_g This block is built up using the gate level logic (XNOR gate). No additional tuning parameters are added to this block, as for simplicity the tuning will be performed at the individual logic gate level. In an actual application, if every bit of performance needs to be squeezed out of the adder, then it may make sense to optimize this block. The following figure illustrates the schematic used. Figure 1: sumblock Logic Schematic 4.8. genblock & genwithpropblock The genblock performs the logic function: n_g_i_j = (n_p_i_k NOR n_g_k_minus1_j) NOR (NOT n_g_i_k) n_p_i_j = NOT (n_p_i_k NOR n_g_k_minus1_j) This block is built up using the gate level logic (2 NOR gates, and 1 INV). No additional tuning parameters are added to this block, as for simplicity the tuning will be performed at the individual logic gate level. In an actual application, if every bit of performance needs to be squeezed out of the adder, then it may make sense to optimize this block. The following figures illustrate the schematic used. Figure 11: genblock Logic Schematic Figure 12: genwithpropblock Logic Schematic

15 4.9. adderpglogic The adderpglogic generates the initial P and G terms for the adder. This block is built from pgblocks and an inverter. The following figures illustrate the schematic used. Figure 13: adderpglogic Logic Schematic 4.1. addersumlogic The addersumlogic generates the final outputs of the adder given the resulting P and G terms. This block also contains inverters to drive the output loads. The following figures illustrate the schematic used. Figure 14: addersumlogic Logic Schematic

16 4.11. addergrouplogic The addergrouplogic generates final P and G terms. This block contains organization defined by the Han-Carleson architecture design. The following figures illustrate the schematic used. Figure 15: addergrouplogic Logic Schematic

17 4.12. Top Level Adder The top-level contains the connection of adderpglogic, addergrouplogic, and addersumlogic. This schematic implements the complete adder, and finalizes the design. The following figure shows the schematic used. Figure 16: Top Level Adder Schematic Test-Bench The following figure shows the schematic used to test the adder. All outputs are loaded with capacitive loads, and the inputs are generated using the veraloga model provided. Figure 17: Adder Test-Bench Schematic

18 5. Simulations The following sections describe the simulation and optimization of all the functional gates and blocks within the design. The focus of the optimization was on the individual logic gates, rather than the accumulated logic blocks. This simplification was made to reduce optimization complexity. The design is not done in a blind manner though. Given some rough hand calculations, a simulation frequency and a simulation load was selected for each of the logic gates, and the performance was tuned based on that criteria. After tuning based on these conditions is satisfied, some basic functional testing was performed at the block level using the same conditions (to verify functionality at the specified frequency is still valid). Finally, the entire design is simulated and spec compliance is verified. If it is, then the design is complete. If not, the initial simulation constraints are modified and the gates are re-optimized. This design results in an iterative process. After some rough ball-park estimations, the initial design criteria for optimization is a frequency of 3GHz, and a load of 4fF. The following figure shows an example testbench used. Figure 18: Standard Gate Simulation Testbench 5.1. myinv Gate The following figure illustrates the resulting transient response for the simulation with the specified load, at the specified frequency. Figure 19: myinv Gate Transient Simulation The following table summarizes the final characterization of myinv after tuning. Fclk myinvfactor tplh tphl risetime 3 GHz ps ps ps Table 5.1: myinv Final Performance Results falltime ps

19 5.2. mynor Gate The following figure illustrates the tradeoff of delay / power to gate area with respect to the tuning parameter mynorfactor. From the plots, a balance between area, power, and delay can be evaluated. Figure 2: mynor Gate Performance Optimization The following figure shows the resulting performance of the gate with the optimal tuning selected. Figure 21: mynor Gate Transient Simulation The following table summarizes the final characterization of mynor after tuning. Fclk mynorfactor tplh tphl risetime falltime rmspower 3 GHz ps ps ps ps uarms Table 5.2: mynor Final Performance Results

20 5.3. mynand Gate The following figure illustrates the tradeoff of delay / power to gate area with respect to the tuning parameter mynandfactor. From the plots, a balance between area, power, and delay can be evaluated. Figure 22: mynand Gate Performance Optimization The following figure shows the resulting performance of the gate with the optimal tuning selected. Figure 23: mynand Gate Transient Simulation The following table summarizes the final characterization of mynand after tuning. Fclk mynandfactor tplh tphl risetime falltime rmspower 3 GHz ps ps ps 32.4 ps uarms Table 5.3: mynand Final Performance Results

21 5.4. myxnor Gate The following two figures illustrate the tradeoff of delay / power to gate area with respect to the tuning parameters myxnorfactor1 and myxnorfactor2. From the plots, a balance between area, power, and delay can be evaluated. The tuning is split into two sections, a coarse tuning and a fine tuning. Figure 24: myxnor Gate Performance Coarse Optimization Figure 25: myxnor Gate Performance Fine Optimization

22 Figure 26: myxnor Gate Transient Simulation Fclk 3 GHz myxnorfactor1 myxnorfactor tplh tphl risetim falltim e e rmspower ps ps ps 25.6 ps uarms Table 5.4: myxnor Final Performance Results 5.5. driverinv Gate No additional tuning was performed on this block for the project. The block was designed for the assignments, and was used unmodified. The following figure shows the transient response of the driverinv block. Figure 27: driverinv Gate Transient Simulation

23 5.6. Block Level Simulation Verification As an intermediate verification, the pgblock and genwithpropblock were simulated to verify that the functionality and basic specifications can be met based on the tuning of the gate level circuits. The following figures show the transient response of both pgblock and genwithprop blocks. Figure 28: pgblock Transient Simulation Figure 29: genwithpropblock Transient Simulation

24 5.7. Top Level Adder The following three figures illustrate the functional behavior showing the adder operation meeting specification with a random input vector. Figure 3: Adder TT Functional Operation Figure 31: Adder FF Functional Operation Figure 32: Adder SS Functional Operation

25 A Monte-Carlo performance was performed on the adder across variability mismatch, and process mismatch. The input vector for the delay was defined as A=xFFFF, B= and A=x, B=x. For power consumption, the input vector was defined as a random vector, for 2us of run time. The following figure illustrates the expected delay variance due to variability. Figure 33: Adder Delay Variability Analysis The following figure illustrates the expected power consumption due to variability. Figure 34: Adder Power Consumption Variability Analysis

26 6. The following sections describe the layout design of all the functional gates and blocks as implemented within the schematic. All final design sizes were selected based on the optimization results from the previous section. All LVS reports are presented in the Appendix myinv Gate The following figure shows the layout of the myinv gate (rotated 9 degrees). Figure 35: myinv Gate X-Size.93 um Y-Size 2.4 um Device Connect Layers Used Poly, M1 Table 6.1: myinv Gate Properties 6.2. mynor Gate The following figure shows the layout of the mynor gate (rotated 9 degrees). Figure 36: mynor Gate X-Size 1.95 um Y-Size 3.9 um Device Connect Layers Used Poly, M1 Table 6.2: mynor Gate Properties

27 6.3. mynand Gate The following figure shows the layout of the mynand gate (rotated 9 degrees). Figure 37: mynand Gate X-Size 1.75 um Y-Size 3.22 um Device Connect Layers Used Poly, M1 Table 6.3: mynand Gate Properties 6.4. myxnor Gate The following figure shows the layout of the myxnor gate (rotated 9 degrees). Figure 38: myxnor Gate X-Size 3 um Y-Size 5.11 um Device Connect Layers Used Poly, M1, M2 Table 6.4: myxnor Gate Properties

28 6.5. driverinv Gate The following figure shows the layout of the driverinv gate (rotated 9 degrees). Figure 39: driverinv Gate X-Size 1. um Y-Size 2.57 um Device Connect Layers Used Poly, M1 Table 6.5: driverinv Gate Properties 6.6. pgblock The following figure shows the layout of the pgblock. Figure 4: pgblock Logic Schematic X-Size 4.98 um Y-Size 5.15 um Device Connect Layers Used Poly, M1, M2 Table 6.6: pgblock Properties

29 6.7. sumblock The sumblock layout is identical to the layout of myxnor. See the myxnor section genblock & genwithpropblock The following figure shows the layout of the genblock logic. Figure 41: genblock Logic X-Size 5.3 um Y-Size 3.92 um Device Connect Layers Used Poly, M1, M2 Table 6.7: genblock Properties Figure 42: genwithpropblock Logic X-Size 5.28 um Y-Size 6.1 um Device Connect Layers Used Poly, M1, M2 Table 6.8: genwithpropblock Properties

30 6.9. adderpglogic The following figure shows the layout of the adderpglogic block (rotated 9 degrees). Figure 43: adderpglogic Logic X-Size 11.5 um Y-Size 57.3 um Device Connect Layers Used Poly, M1, M2, M3 Table 6.9: adderpglogic Properties 6.1. addergrouplogic Figure 44: addergrouplogic Logic X-Size um Y-Size um Device Connect Layers Used Poly, M1, M2, M3, M4 Table 6.1: addergrouplogic Properties

31 6.11. addersumlogic Figure 45: addersumlogic Logic X-Size 8.5 um Y-Size um Device Connect Layers Used Poly, M1, M2, M3 Table 6.11: addersumlogic Properties Top Level Adder Figure 46: adder16 (Complete Project) X-Size um Y-Size um Device Connect Layers Used Poly, M1, M2, M3, M4, M5 Table 6.12: adder16 Properties

32 7. Conclusions myinv: Component Count NCH 1 PCH 1 Table 7.1: myinv Component Count Summary mynor: Component Count NCH 2 PCH 2 Table 7.2: mynor Component Count Summary mynand: Component Count NCH 2 PCH 2 Table 7.3: mynand Component Count Summary myxnor: Component Count NCH 3 PCH 3 Table 7.4: myxnor Component Count Summary driverinv: Component Count NCH 1 PCH 1 Table 7.5: driverinv Component Count Summary

33 pgblock: Component Count myxnor 1 mynand 1 Table 7.6: pgblock Component Count Summary genblock: Component Count myinv 1 mynor 2 Table 7.7: genblock Component Count Summary genwithpropblock: Component Count myinv 2 mynor 3 Table 7.8: genwithpropblock Component Count Summary sumblock: Component myxnor Count 1 Table 7.9: sumblock Component Count Summary adderpglogic: Component Count myinv 1 pgblock 16 Table 7.1: adderpglogic Component Count Summary addergrouplogic: Component Count genblock 15 genwithpropblock 17 Table 7.11: addergrouplogic Component Count Summary

34 addersumlogic: Component Count driverinv 17 sumblock 16 genblock 1 Table 7.12: addersumlogic Component Count Summary adder16: Total= = = = = 1*myINV+17*driverINV+16*sumBlock+16*pgBlock+16*genBlock+17*genWithPropBlock 1*myINV+17*driverINV+16*myXNOR+16*(myXNOR+myNAND)+16*(myINV+myNOR)+17*(2*myINV+3*myNOR) 17*driverINV + 51*myINV + 67*myNOR + 16*myNAND + 32*myXNOR 17*(PCH+NCH) + 51*(PCH+NCH) + 67*(2*PCH+2*NCH) + 16*(2*PCH+2*NCH) + 32*(3*NCH+3*PCH) 33*NCH + 33*PCH Total NMOS Devices: 33 Total PMOS Devices: Total Transistors: 66 Overall, the initial conditions for the design process described (a 3 GHz clock, and 4 pf loads) resulted in a circuit which is somewhat over designed to meet the specification of 1 GHz. That being said, further optimizations could be considered to reduce area and power consumption to achieve a closer match to the 1 GHz target.

35 Appendix A. Verilog Model - Top Level - adder.v // // // // // adder.v Programmed by: Chris Beg (292646) Course: ECE // // adder // module adder(a, B, Cin, Sum, Cout); input [15:] A; input [15:] B; input Cin; output [15:] Sum; output Cout; wire [16:] Ginitial; wire [16:] Pinitial; wire [16:] Gfinal; // PG logic adderpglogic pglogic(cin, A, B, Ginitial, Pinitial); // Group PG Logic addergrouplogic grouplogic( Ginitial[15:], Pinitial, Gfinal[15:]); // Sum Logic assign Gfinal[16] = Ginitial[16]; addersumlogic sumlogic(gfinal, Pinitial[16:1], Sum, Cout); endmodule

36 Appendix B. Verilog Model PG Logic - adderpglogic.v // // // // // adderpglogic.v Programmed by: Chris Beg (292646) Course: ECE // // adderpglogic // module adderpglogic(cin, A, B, n_g, n_p); input Cin; input [15:] A; input [15:] B; output [16:] n_g; output [16:] n_p; assign n_g[] =!Cin; assign n_p[] = 1; pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock pgblock endmodule bit(a[], B[], n_g[1], n_p[1]); bit1(a[1], B[1], n_g[2], n_p[2]); bit2(a[2], B[2], n_g[3], n_p[3]); bit3(a[3], B[3], n_g[4], n_p[4]); bit4(a[4], B[4], n_g[5], n_p[5]); bit5(a[5], B[5], n_g[6], n_p[6]); bit6(a[6], B[6], n_g[7], n_p[7]); bit7(a[7], B[7], n_g[8], n_p[8]); bit8(a[8], B[8], n_g[9], n_p[9]); bit9(a[9], B[9], n_g[1], n_p[1]); bit1(a[1], B[1], n_g[11], n_p[11]); bit11(a[11], B[11], n_g[12], n_p[12]); bit12(a[12], B[12], n_g[13], n_p[13]); bit13(a[13], B[13], n_g[14], n_p[14]); bit14(a[14], B[14], n_g[15], n_p[15]); bit15(a[15], B[15], n_g[16], n_p[16]);

37 Appendix C. Verilog Model Group Logic - addergrouplogic.v // // // // // addergrouplogic.v Programmed by: Chris Beg (292646) Course: ECE // // addergrouplogic // module addergrouplogic(gin, Pin, Gout); input [16:] Gin; input [16:] Pin; output [15:] Gout; // bit wire G ; // bit 1 wire G_1_; // bit 2 wire G_2_; // bit 3 wire G_3_2; wire P_3_2; wire G_3_; // bit 4 wire G_4_; // bit 5 wire G_5_4; wire P_5_4; wire G_5_2; wire P_5_2; wire G_5_; // bit 6 wire G_6_; // bit 7 wire G_7_6; wire P_7_6; wire G_7_4; wire P_7_4; wire G_7_; // bit 8 wire G_8_; // bit 9 wire G_9_8; wire P_9_8; wire G_9_6; wire P_9_6; wire G_9_2; wire P_9_2; wire G_9_; // bit 1 wire G_1_; // bit 11 wire G_11_1; wire P_11_1; wire G_11_8; wire P_11_8; wire G_11_4; wire P_11_4; wire G_11_; // bit 12 wire G_12_; // bit 13 wire G_13_12; wire P_13_12; wire G_13_1; wire P_13_1; wire G_13_6; wire P_13_6; wire G_13_; // bit 14 wire G_14_; // bit 15 wire G_15_14; wire P_15_14; wire G_15_12; wire P_15_12; wire G_15_8; wire P_15_8;

38 wire G_15_; // Bit assign G = Gin[]; assign Gout[] = G ; // Bit 1 genblock gate(gin[1], Pin[1], G, G_1_); assign Gout[1] = G_1_; // Bit 2 genblock gate1(gin[2], Pin[2], G_1_, G_2_); assign Gout[2] = G_2_; // Bit 3 genwithpropblock gate2( Gin[3], Pin[3], Gin[2], Pin[2], G_3_2, P_3_2); genblock gate3(g_3_2, P_3_2, G_1_, G_3_); assign Gout[3] = G_3_; // Bit 4 genblock gate4(gin[4], Pin[4], G_3_, G_4_); assign Gout[4] = G_4_; // Bit 5 genwithpropblock gate5( Gin[5], Pin[5], Gin[4], Pin[4], G_5_4, P_5_4); genwithpropblock gate6( G_5_4, P_5_4, G_3_2, P_3_2, G_5_2, P_5_2); genblock gate7(g_5_2, P_5_2, G_1_, G_5_); assign Gout[5] = G_5_; // Bit 6 genblock gate8(gin[6], Pin[6], G_5_, G_6_); assign Gout[6] = G_6_; // Bit 7 genwithpropblock gate9( Gin[7], Pin[7], Gin[6], Pin[6], G_7_6, P_7_6); genwithpropblock gate1( G_7_6, P_7_6, G_5_4, P_5_4, G_7_4, P_7_4); genblock gate11(g_7_4, P_7_4, G_3_, G_7_); assign Gout[7] = G_7_; // Bit 8 genblock gate12(gin[8], Pin[8], G_7_, G_8_); assign Gout[8] = G_8_; // Bit 9 genwithpropblock gate13( genwithpropblock gate14( genwithpropblock gate15( genblock gate16(g_9_2, P_9_2, assign Gout[9] = G_9_; Gin[9], Pin[9], Gin[8], Pin[8], G_9_8, P_9_8); G_9_8, P_9_8, G_7_6, P_7_6, G_9_6, P_9_6); G_9_6, P_9_6, G_5_2, P_5_2, G_9_2, P_9_2); G_1_, G_9_); // Bit 1 genblock gate17(gin[1], Pin[1], G_9_, G_1_); assign Gout[1] = G_1_; // Bit 11 genwithpropblock gate18( Gin[11], Pin[11], Gin[1], Pin[1], G_11_1, P_11_1); genwithpropblock gate19( G_11_1, P_11_1, G_9_8, P_9_8, G_11_8, P_11_8); genwithpropblock gate2( G_11_8, P_11_8, G_7_4, P_7_4, G_11_4, P_11_4); genblock gate21(g_11_4, P_11_4, G_3_, G_11_); assign Gout[11] = G_11_; // Bit 12 genblock gate22(gin[12], Pin[12], G_11_, G_12_); assign Gout[12] = G_12_; // Bit 13 genwithpropblock gate23( Gin[13], genwithpropblock gate24( G_13_12, genwithpropblock gate25( G_13_1, genblock gate26(g_13_6, P_13_6, G_5_, assign Gout[13] = G_13_; Pin[13], Gin[12], Pin[12], G_13_12, P_13_12); P_13_12, G_11_1, P_11_1, G_13_1, P_13_1); P_13_1, G_9_6, P_9_6, G_13_6, P_13_6); G_13_); // Bit 14 genblock gate27(gin[14], Pin[14], G_13_, G_14_); assign Gout[14] = G_14_; // Bit 15 genwithpropblock gate28( Gin[15], genwithpropblock gate29( G_15_14, genwithpropblock gate3( G_15_12, genblock gate31(g_15_8, P_15_8, G_7_, assign Gout[15] = G_15_; endmodule Pin[15], Gin[14], Pin[14], G_15_14, P_15_14); P_15_14, G_13_12, P_13_12, G_15_12, P_15_12); P_15_12, G_11_8, P_11_8, G_15_8, P_15_8); G_15_);

39 Appendix D. Verilog Model Sum Logic addersumlogic.v // // // // // addersumlogic.v Programmed by: Chris Beg (292646) Course: ECE // // addersumlogic // module addersumlogic(n_g, n_p, S, Cout); input [16:] n_g; input [15:] n_p; output [15:] S; output Cout; wire n_cout; wire n_s[15:]; sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock sumblock genblock // Add assign assign assign assign assign assign assign assign assign assign assign assign assign assign assign assign assign endmodule bit(n_g[], n_p[], n_s[]); bit1(n_g[1], n_p[1], n_s[1]); bit2(n_g[2], n_p[2], n_s[2]); bit3(n_g[3], n_p[3], n_s[3]); bit4(n_g[4], n_p[4], n_s[4]); bit5(n_g[5], n_p[5], n_s[5]); bit6(n_g[6], n_p[6], n_s[6]); bit7(n_g[7], n_p[7], n_s[7]); bit8(n_g[8], n_p[8], n_s[8]); bit9(n_g[9], n_p[9], n_s[9]); bit1(n_g[1], n_p[1], n_s[1]); bit11(n_g[11], n_p[11], n_s[11]); bit12(n_g[12], n_p[12], n_s[12]); bit13(n_g[13], n_p[13], n_s[13]); bit14(n_g[14], n_p[14], n_s[14]); bit15(n_g[15], n_p[15], n_s[15]); carryout(n_g[16], n_p[15], n_g[15], n_cout); inverters to drive output signal Cout =!n_cout; // driverinv S[] =!n_s[]; // driverinv S[1] =!n_s[1]; // driverinv S[2] =!n_s[2]; // driverinv S[3] =!n_s[3]; // driverinv S[4] =!n_s[4]; // driverinv S[5] =!n_s[5]; // driverinv S[6] =!n_s[6]; // driverinv S[7] =!n_s[7]; // driverinv S[8] =!n_s[8]; // driverinv S[9] =!n_s[9]; // driverinv S[1] =!n_s[1]; // driverinv S[11] =!n_s[11]; // driverinv S[12] =!n_s[12]; // driverinv S[13] =!n_s[13]; // driverinv S[14] =!n_s[14]; // driverinv S[15] =!n_s[15]; // driverinv

40 Appendix E. Verilog Model All Blocks // // pgblock.v // Programmed by: Chris Beg (292646) // Course: ECE637 // // // pgblock // module pgblock(a, B, n_g, n_p); // declare port signals input A, B; output n_g, n_p; // Define logic function assign n_g =!(A & B); assign n_p =!(A ^ B); endmodule // NAND // XNOR // // genblock.v // Programmed by: Chris Beg (292646) // Course: ECE637 // // // genblock // module genblock(n_g_i_k, n_p_i_k, n_g_k_minus1_j, n_g_i_j); input n_g_i_k, n_p_i_k, n_g_k_minus1_j; output n_g_i_j; wire G_i_j; wire g1; assign G_i_k =!n_g_i_k; assign g1 =!(n_p_i_k n_g_k_minus1_j); assign n_g_i_j =!(g1 G_i_k); endmodule // INV // NOR // NOR // // genwithpropblock.v // Programmed by: Chris Beg (292646) // Course: ECE637 // // // genwithpropblock // module genwithpropblock(n_g_i_k, n_p_i_k, n_g_k_minus1_j, n_p_k_minus1_j, n_g_i_j, n_p_i_j); input n_g_i_k, n_p_i_k, n_g_k_minus1_j, n_p_k_minus1_j; output n_g_i_j, n_p_i_j; wire g1; genblock pg1(n_g_i_k, n_p_i_k, n_g_k_minus1_j, n_g_i_j); assign g1 =!(n_p_i_k n_p_k_minus1_j); assign n_p_i_j =!g1; endmodule // // SumBlock.v // Programmed by: Chris Beg (292646) // Course: ECE637 // // // sumblock // module sumblock(n_p, n_g, n_s); // declare port signals input n_p, n_g; output n_s; // Define logic function assign n_s =!(n_p ^ n_g); endmodule // NOR // INV

41 Appendix F. Verilog Model Test Bench `timescale 1ps/1ps // // adder_tb // module adder_tb (); reg clk; reg reset; wire Cin; wire [15:] A; wire [15:] B; wire wire wire wire wire reg Cout; [15:] Sum; [16:] CheckResult; [15:] CheckSum; CheckCout; ErrorOccured; // Connect the inputs to the adder adder hancarlson(a, B, Cin, Sum, Cout); inputvectorgenerator vectorgen(reset, clk, A, B, Cin); assign CheckResult = A+B+Cin; assign CheckSum = CheckResult[15:]; assign CheckCout = CheckResult[16]; // Clock Generation Block initial begin clk = ; reset = 1; 5 clk = 1; 5 clk = ; reset = ; forever begin 5 clk = 1; 5 clk = ; if (CheckSum == Sum && CheckCout == Cout) assign ErrorOccured = ; else assign ErrorOccured = 1; end end endmodule

42 Appendix G. Verilog Model Random Vector Generator // // inputvectorgenerator // module inputvectorgenerator(reset, clk, A, B, Cin); input reset; input clk; output [15:] A; output [15:] B; output Cin; // Use the MSB of A_LFSR to generate Cin reg [16:] A_LFSR; reg [15:] B_LFSR; // Tie assign assign assign all Cin A = B = input signals together = A_LFSR[16]; A_LFSR[15:]; B_LFSR[15:]; // 4-tap LFSR (17-bit) Polynomial: G^17 + G^16 + G^15 + G^14 always@( posedge clk or posedge reset ) begin if (reset) begin // Initialize LFSR state to all 1's A_LFSR = 'b ; end else begin A_LFSR[] = A_LFSR[16]; A_LFSR[13:1] = A_LFSR[12:]; A_LFSR[14] = A_LFSR[13] ^ A_LFSR[16]; A_LFSR[15] = A_LFSR[14] ^ A_LFSR[16]; A_LFSR[16] = A_LFSR[15] ^ A_LFSR[16]; end end // 6-tap LFSR (16-bit) Polynomial: G^16 + G^15 + G^14 + G^9 + G^8 + G^3 always@( posedge clk or posedge reset ) begin if (reset) begin // Initialize LFSR state to all 1's B_LFSR = 'b ; end else begin B_LFSR[] = B_LFSR[15]; B_LFSR[2:1] = B_LFSR[1:]; B_LFSR[3] = B_LFSR[2] ^ B_LFSR[15]; B_LFSR[7:4] = B_LFSR[6:3]; B_LFSR[8] = B_LFSR[7] ^ B_LFSR[15]; B_LFSR[9] = B_LFSR[8] ^ B_LFSR[15]; B_LFSR[13:1] = B_LFSR[12:9]; B_LFSR[14] = B_LFSR[13] ^ B_LFSR[15]; B_LFSR[15] = B_LFSR[14] ^ B_LFSR[15]; end end endmodule

43 Appendix H. LVS Report for myinv C A L I B R E S Y S T E M L V S R E P O R T REPORT FILE NAME: LAYOUT NAME: SOURCE NAME: RULE FILE: LVS MODE: RULE FILE NAME: CREATION TIME: CURRENT DIRECTORY: USER NAME: CALIBRE VERSION: myinv.lvs.report myinv.calibre.db /u6/cbeg/ece637/myinv.src.net ('myinv') /u6/cbeg/ece637/_calibre.lvs_ Mask /u6/cbeg/ece637/_calibre.lvs_ Sun Mar 2 22:38: /u6/cbeg/ece637 cbeg v29.4_31.27 Wed Jan 6 11:23:33 PST 21 CORRECT _ * _ * \ / NUMBERS OF OBJECTS Nets: Instances: Total Inst: Component Type MN (4 pins) MP (4 pins) INFORMATION AND WARNINGS Nets: Instances: Total Inst: Matched Matched Unmatched Unmatched Component Type MN(nch) MP(pch) o Initial Correspondence Points: vdd vss A F **********************************************************************

44 Appendix I. LVS Report for mynor C A L I B R E S Y S T E M L V S R E P O R T REPORT FILE NAME: LAYOUT NAME: SOURCE NAME: RULE FILE: LVS MODE: RULE FILE NAME: CREATION TIME: CURRENT DIRECTORY: USER NAME: CALIBRE VERSION: mynor.lvs.report mynor.calibre.db /u6/cbeg/ece637/mynor.src.net ('mynor') /u6/cbeg/ece637/_calibre.lvs_ Mask /u6/cbeg/ece637/_calibre.lvs_ Mon Mar 21 :28:3 211 /u6/cbeg/ece637 cbeg v29.4_31.27 Wed Jan 6 11:23:33 PST 21 OVERALL COMPARISON RESULTS CORRECT _ * _ * \ / NUMBERS OF OBJECTS Nets: Instances: Total Inst: Component Type MN (4 pins) MP (4 pins) INFORMATION AND WARNINGS Nets: Instances: Total Inst: Matched Matched Unmatched Unmatched Component Type MN(nch) MP(pch) o Initial Correspondence Points: vdd vss F B A **********************************************************************

45 Appendix J. LVS Report for mynand C A L I B R E S Y S T E M L V S R E P O R T REPORT FILE NAME: LAYOUT NAME: SOURCE NAME: RULE FILE: LVS MODE: RULE FILE NAME: CREATION TIME: CURRENT DIRECTORY: USER NAME: CALIBRE VERSION: mynand.lvs.report mynand.calibre.db /u6/cbeg/ece637/mynand.src.net ('mynand') /u6/cbeg/ece637/_calibre.lvs_ Mask /u6/cbeg/ece637/_calibre.lvs_ Mon Mar 21 22:8: /u6/cbeg/ece637 cbeg v29.4_31.27 Wed Jan 6 11:23:33 PST 21 OVERALL COMPARISON RESULTS CORRECT _ * _ * \ / NUMBERS OF OBJECTS Nets: Instances: Total Inst: Component Type MN (4 pins) MP (4 pins) INFORMATION AND WARNINGS Nets: Instances: Total Inst: Matched Matched Unmatched Unmatched Component Type MN(nch) MP(pch) o Initial Correspondence Points: vdd vss B A F **********************************************************************

46 Appendix K. LVS Report for myxnor C A L I B R E S Y S T E M L V S R E P O R T REPORT FILE NAME: LAYOUT NAME: SOURCE NAME: RULE FILE: LVS MODE: RULE FILE NAME: CREATION TIME: CURRENT DIRECTORY: USER NAME: CALIBRE VERSION: myxnor.lvs.report myxnor.calibre.db /u6/cbeg/ece637/myxnor.src.net ('myxnor') /u6/cbeg/ece637/_calibre.lvs_ Mask /u6/cbeg/ece637/_calibre.lvs_ Thu Apr 14 21:36: /u6/cbeg/ece637 cbeg v29.4_31.27 Wed Jan 6 11:23:33 PST 21 OVERALL COMPARISON RESULTS CORRECT _ * _ * \ / NUMBERS OF OBJECTS Nets: Instances: Total Inst: Component Type MN (4 pins) MP (4 pins) INFORMATION AND WARNINGS Nets: Instances: Total Inst: Matched Matched Unmatched Unmatched Component Type MN(nch) MP(pch) o Initial Correspondence Points: vdd vss B A F **********************************************************************

47 Appendix L. LVS Report for driverinv C A L I B R E S Y S T E M L V S R E P O R T REPORT FILE NAME: LAYOUT NAME: SOURCE NAME: RULE FILE: LVS MODE: RULE FILE NAME: CREATION TIME: CURRENT DIRECTORY: USER NAME: CALIBRE VERSION: driverinv.lvs.report driverinv.calibre.db /u6/cbeg/ece637/driverinv.src.net ('driverinv') /u6/cbeg/ece637/_calibre.lvs_ Mask /u6/cbeg/ece637/_calibre.lvs_ Sun Mar 2 22:1: /u6/cbeg/ece637 cbeg v29.4_31.27 Wed Jan 6 11:23:33 PST 21 CORRECT _ * _ * \ / NUMBERS OF OBJECTS Nets: Instances: Total Inst: Component Type MN (4 pins) MP (4 pins) INFORMATION AND WARNINGS Nets: Instances: Total Inst: Matched Matched Unmatched Unmatched Component Type MN(nch) MP(pch) o Initial Correspondence Points: vdd vss n_a A **********************************************************************

48 Appendix M. LVS Report for pgblock C A L I B R E S Y S T E M L V S R E P O R T REPORT FILE NAME: LAYOUT NAME: SOURCE NAME: RULE FILE: LVS MODE: RULE FILE NAME: CREATION TIME: CURRENT DIRECTORY: USER NAME: CALIBRE VERSION: pgblock.lvs.report pgblock.calibre.db /u6/cbeg/ece637/pgblock.src.net ('pgblock') /u6/cbeg/ece637/_calibre.lvs_ Mask /u6/cbeg/ece637/_calibre.lvs_ Thu Apr 14 22:8: /u6/cbeg/ece637 cbeg v29.4_31.27 Wed Jan 6 11:23:33 PST 21 OVERALL COMPARISON RESULTS CORRECT _ * _ * \ / NUMBERS OF OBJECTS Nets: Instances: Total Inst: Component Type MN (4 pins) MP (4 pins) INFORMATION AND WARNINGS Nets: Instances: Total Inst: Matched Matched Unmatched Unmatched Component Type MN(nch) MP(pch) o Initial Correspondence Points: vdd vss n_p n_g A B **********************************************************************

49 Appendix N. LVS Report for genblock C A L I B R E S Y S T E M L V S R E P O R T REPORT FILE NAME: LAYOUT NAME: SOURCE NAME: RULE FILE: LVS MODE: RULE FILE NAME: CREATION TIME: CURRENT DIRECTORY: USER NAME: CALIBRE VERSION: genblock.lvs.report genblock.calibre.db /u6/cbeg/ece637/genblock.src.net ('genblock') /u6/cbeg/ece637/_calibre.lvs_ Mask /u6/cbeg/ece637/_calibre.lvs_ Mon Mar 21 21:21:3 211 /u6/cbeg/ece637 cbeg v29.4_31.27 Wed Jan 6 11:23:33 PST 21 OVERALL COMPARISON RESULTS CORRECT _ * _ * \ / NUMBERS OF OBJECTS Nets: Instances: Total Inst: Component Type MN (4 pins) MP (4 pins) INFORMATION AND WARNINGS Nets: Instances: Total Inst: Matched Matched Unmatched Unmatched Component Type MN(nch) MP(pch) o Initial Correspondence Points: vdd vss n_g_i_j n_g_k_minus1_j n_g_i_k n_p_i_k **********************************************************************

50 Appendix O. LVS Report for genwithpropblock C A L I B R E S Y S T E M L V S R E P O R T REPORT FILE NAME: LAYOUT NAME: SOURCE NAME: RULE FILE: LVS MODE: RULE FILE NAME: CREATION TIME: CURRENT DIRECTORY: USER NAME: CALIBRE VERSION: genwithpropblock.lvs.report genwithpropblock.calibre.db /u6/cbeg/ece637/genwithpropblock.src.net ('genwithpropblock') /u6/cbeg/ece637/_calibre.lvs_ Mask /u6/cbeg/ece637/_calibre.lvs_ Mon Mar 21 23:27: /u6/cbeg/ece637 cbeg v29.4_31.27 Wed Jan 6 11:23:33 PST 21 OVERALL COMPARISON RESULTS CORRECT _ * _ * \ / NUMBERS OF OBJECTS Nets: Instances: Total Inst: Component Type MN (4 pins) MP (4 pins) INFORMATION AND WARNINGS Nets: Instances: Total Inst: Matched Matched Unmatched Unmatched Component Type MN(nch) MP(pch) o Initial Correspondence Points: vdd vss n_p_k_minus1_j n_g_k_minus1_j n_p_i_k n_g_i_k n_p_i_j n_g_i_j **********************************************************************