Tutorial:Place & Route Tutorial3

From NCSU EDA Wiki
Jump to: navigation, search

Place & Route Tutorial #3: Creating Standard Cells

In PRTutorial #2, you should have noticed that a certain instance of the NAND2X1 cell in the addsub design had an excessive rise-time and delay due to loading. In this tutorial, you will create a new standard-cell that has a larger driving-capability than the NAND2X1 cell. This tutorial consists of the following steps:


Determine the transistor sizes

PR tutorial3 addsub32 sche.JPG

The figure to the above shows a simplified view of the schematic in the addsub32 module, showing only the fan-out path of the most heavily loaded NAND2X1 cell. Note that it fans out to the select inputs of 32 MUXes and the carry-in of one full-adder. Each of the inputs of the NAND are driven by a minimum-sized inverter.

We can use the method of logical effort to determine the size of the NAND gate. First, we need to determine the path fan-out, which can be done approximately by comparing the total transistor with connected to each node. The INVX1/A pin is connected to a total gate-width of 3μm (assuming a minimum size inverter), and by examining the schematics for the other cells, we see that the MUX2X1/S and FAX1/C pins have 9μm and 18.6μm of gate width, respectively. We can compute the size of the NAND gate as follows:

PRtutorial3 NAND2size.jpg

which indicates that we need to create a NAND gate with a drive-strength of 8.75. We’re free to make a cell with this drive-strength if we wish, but we typically restrict ourselves to sizes that are powers of two, because it makes management of the library easier. The IIT library uses the suffixes X1, X2, X4, and X8 to indicate the drive strength. So, to stay within the IIT library conventions, we should create a NAND2X8 cell.

Looking at the INVX1 cell, the NMOS with is 1μm, and the PMOS width is 2μm. A NAND2X8 cell would therefore have both NMOS and PMOS widths of 16μm.

Create the Layout and Schematic views

Now we need to create a layout and schematic views for our NAND2X8 cell. The easiest way to do that is to create a new library and copy the NAND2X1 cell into it. You can then modify this cell to suit your needs. Open up the NAND2X1 cell and look at the layout. There are a number of unwritten rules that you should follow to ensure that you cell tiles properly with the other cells (as illustrated below):

PR tutorial3 NAND2X1 lay.jpg

  1. The rectangle in the prBoundary-drawing layer indicates how this cell with tiled with other standard cells. In order to work with the IIT library, this shape must always be 100λ high and a multiple of 8λ wide. This basic 100λ-by-8λ shape is often called the site, and basically defines the placement grid. Also notice that the lower-left corner is the origin.
  2. The NTAP and PTAP well-contacts are centered on the prBoundary rectangle, starting with the left-most edge and repeating every 16λ.
  3. The vdd and gnd rails are 6λ wide and also centered on the prBoundary shape. These rails extend to the left and right of the prBoundary just enough to cover the NTAP and PTAP contacts.
  4. All active areas (nactive and pactive) are spaced 2λ from the prBoundary. This rule actually comes from the active-to-contact spacing rule (which is 5λ). Without this spacing, adjacent cells could cause a design-rule violation. To be safe, you should also make sure that no metal or poly shapes come within 2λ of these edges, either. Note also that the IIT cells tend to use the active layer, rather than nactive and pactive. You may use either. An active shape inside an nselect shape is equivalent to nactive, as is active/pselect to pactive.
  5. The nwell shape extends 52λ below the top-edge of the prBoundary shape. You don’t need to observe this throughout your entire cell, but it should at least be observed within several λ of the edges to make sure that the active-to-well spacing rules aren’t violated by adjacent cells.
  6. There are also naming conventions for the cells. You already know about the convention that the suffixes X1, X2, etc. indicate the driving capability. In addition, the outputs of all cells in the library begin with either the letter “Y” or the letter “Q”. This convention makes it easier for the later scripts to figure out which terminals are outputs.

At this point, you would modify the cell to suit your needs. To speed things up, however, copy the mycells.tar.gz file (provided with this tutorial) to your icfb run-directory and unpack it with the following commands:

	gunzip mycells.tar.gz
	tar xvf mycells.tar 

Next, edit your cds.lib file to include the following line:

	DEFINE mycells ./mycells

Choose View->Refresh in your Library Manager to see the new library. Open and examine the NAND2X8 cell. You should notice the following:

  1. The NMOS and PMOS transistors each have four “fingers” in order to fit them inside the standard-cell. The schematic, however, shows only one transistor for each set of four. Extraction tools can generally recognize these as being part of the same transistor and merge them.
  2. The NMOS widths are 14.4μm, rather than 16μm. This was done to save some area, since the cell would have needed to be 1.6μm wider to accommodate 16μm-wide NMOS transistors.
  3. Note that the labels for the pins are in the metal1-drawing layer. Without labels, we will not be able to generate the abstract views. Also, these labels MUST be in the metal1 layer (not text). Otherwise, the abstract generator will not recognize these pins.

Run DRC, Extract, and LVS checks on this cell to verify that it has been designed correctly.

Create the LEF file and abstract views

We will now generate the LEF file (for Cadence Encounter) and the abstract views (for Cadence DFII). Ideally, this would be done with another automated flow, but the process isn’t very well automated at the moment. We will generate these views with the following steps:

  1. Export a GDS2 file containing the layout for all cells in the “mycell” library
  2. Create a technology file for the abstract program.
  3. Import the GDS2 file into abstract, set some rules, and generate the LEF file.
  4. Import the LEF file into Cadence DFII.

First, copy the lefkit.tar file into your icfb run-directory and unpack it as you did with the mycells library. You should see a directory call run/abs that contains three files:

  • stream.map – This file defines how the layer/purpose names in Cadence DFII map to the layer/purpose numbers in the GDS2 file.
  • streamout.il – This file is a script to make the GDS2 “stream-out” process go faster. It sets the options we want, including the following:
    • Setting the “Layer Map Table” option to the stream.map file mentioned above.
    • Converting all P-Cells (such as contacts and transistors), to normal shapes
    • Setting the library name to “mycells”. You can change this to your own library name, if you want.
    • Setting the output file to run/abs/mycells.gds.
  • TSMC_CMOS020_iit.lef – This file defines the layers and design-rules as needed by place-and-route tools. It also defines specifics of the standard-cell library, such as the site, mentioned earlier. If you open this file, you’ll notice that it is identical to the first 300 lines of the LEF file referred to by the SSHAFT technology variable SimplePR::EncounterLefFile, which is used to run Cadence Encounter. The rest of the file contains a text-version of the abstract views for the standard-cells. We will now generate our own abstract views and store them in a new LEF file.

From the CIW in Cadence, choose File->Export->Stream…. In the “Template File” box, enter “run/abs/streamout.il” and click “Load”. You should see the following:

PR tutorial3 streamout.jpg

Click OK. After a few seconds, you should see the following message in the CIW.

PIPO STRMOUT (PID = ipc:1) completed successfully, see log file './PIPO.LOG' for more details.

You should also see the mycells.gds file in the run/abs directory. Next, change to the run/abs directory and create the technology-file for the abstract program file with the following command:

	lef2hld TSMC_CMOS020_iit.lef -lib mycells -libPath ./tech -l tech.dpux

This command imports the LEF file, defines the library name as “mylib”, dumps the cell definitions into the ./tech subdirectory, and saves the abstract technology-file in the file tech.dpux. The main thing that we want is the tech.dpux file.

Next, start the abstract program with the following command:

	abstract –tech . &

The “-tech .” arguments instruct the program to look in the current directory for the tech.dpux file. Without it, the program will not start correctly. You should see the abstract window appear:

Next, follow these steps:

  1. Choose File->Technology… in the Abstract window. You should see the Technology File Editor window appear:
    • Under “Categories” on the left, select “Layers”. Then, in the tabs on the upper right, click “Mapping”. Click the “Map…” button, select the stream.map file, and click “Open”. Then choose File->Save in the Technology File Editor. These steps tell abstract which layers in the GDS2 file correspond to the layers in the LEF file. When done you should see the following: Finally, choose File->Close to close the Technology File Editor.
  2. Choose File->Library… in the Abstract window to open the “mycells” library. Then chose File->Import->Stream (GDSII)… in the. In the pop-up window, browse to select the mycells.gds file and click “OK”. When done, you should see the following:
  3. On the right-hand-side of the window, select the names of the cells you want to process (in this case the NAND2X8 cell) and choose Flow->Pins…. Set the following options (as illustrated below):
    1. Under “Map text labels to pins”, set to “(metal1 (metal1 pin) (metal1 drawing))”. This option tells the abstract generator to look for labels in either the metal1-pin or the metal1-drawing layer-purpose to assign the pin-names.
    2. Under “Clock pin names”, enter “CLK”. This is not important for this cell, but it is necessary to generate the correct LEF file for flip-flops and latches.
    3. Under “Output pin names”, enter “^Y|Q”. This indicates that pin names beginning with either Y or Q will be output pins.
    4. There should be no need to change the “Power Pin Names” and “Ground Pin Names” fields, but note that with these regular expressions, the power and ground labels that we use (“vdd!” and “gnd!”) will be recognized.
  4. Next, click the “Text” tab. In order to be consistent with the other cells in the IIT library, we need to remove the “!” from the vdd! and gnd! pins. We can do this by clicking the “Add” button to enter a new Text Manipulation rule. Enter “!” in the “Remove Text…” column for the rule and leave the “Replace With…” column blank.
  5. Next, click the “Boundary” tab. Under “Using Geometry on Layers” enter “prBoundary”. This tells the program to use the prBoundary that you created to determine the boundary for the cell.
  6. Click “Run”. After a few seconds, you should see an exclamation point “!” appear in the main Abstract window in the “Pins” column next to the name of the “NAND2X8” cell. This indicates that the “pins” step is complete with some warnings. You can look in the “Abstract PCW” window to see the warning message:
    WARNING   (ABS-515): Cell NAND2X8: prBoundary does not enclose all cell view geometry.

This is to be expected, so we can ignore this warning.

  1. Next, choose Flow->Extract… in the Abstract window. We don’t need to change any of these options, so simply click “Run” on the window that pops up. After a few seconds, you should see a check-mark appear in the “Extract” column.
  2. Next, choose Flow->Abstract… in the Abstract window. Under the “Adjust” tab, set “Power geometry groups” to “overlap”
  3. Next, under the “Site” tab, enter “core” in the “Define new site name” box. When you run this program in the future, you won’t need to define the new name. Instead, you can select it from the “Site name” box.
  4. Click “Run”. Again, after a few seconds, you should see an exclamation point appear in the “Abstract” column. You can look in the “Abstract PCW” window to see the warning messages:
    WARNING   (ABS-1076): Cell NAND2X8: Terminal B has no pins on Metal1-Metal2 Routing grid
    WARNING   (ABS-1076): Cell NAND2X8: Terminal A has no pins on Metal1-Metal2 Routing grid
    These messages indicate that the pins are not on the routing grid. The routers will be more efficient if the pins are aligned to a consistent grid, but our router should still work OK in spite of this limitation. We can ignore this warning for now.
  5. Next, choose File->General Options… in the Abstract window. In the “General Options” popup window, click on the “General” tab and set the “LEF Units” to 100. Click OK.
  6. Next, choose File->Export->LEF… in the Abstract window. Set the LEF filename to “mycells.lef” and click “OK”. After a few seconds, you should see the following message in the “Abstract PCW” window:
    HLD-MESSAGE: 2005/11/16 15:13:30: Completed generating lefout file.
  7. We are done! You may now exit abstract by choosing choose File->Exit.

We can now import the LEF file into Cadence DFII. In the CIW, choose . In the “Read LEF File” popup window, enter “run/abs/mycells.lef” for the LEF File Name and “mycells” for the Target Library Name. The other options should be OK. Be sure that the “Overwrite Technology Information” box is UNCHECKED (as it should be by default). Checking this box can create problems by modifying the technology file for Cadence DFII.


Once complete, you should see the message “Done reading LEF file” in the CIW. You should see that an abstract view now exists for the NAND2X8 cell. You are now ready to perform place-and-route with Encounter or most any other tool.

Create the Timing (.lib) file

This portion of the tutorial will show you how to create the .lib Timing Library for your standard-cells using the Cadence SignalStorm Library Characterizer. It is currently under construction, but in the meantime, you can read the documentation for this tool in the following location: /ncsu/cadence/tsi41/doc/signalstormlc/signalstormlc.pdf

Re-run the flow with the new cell

In order to run the pr.py script with the new standard-cell library, you need to do the following:

  1. Modify the addsub.v file to reference your new cell.
  2. Modify several variables in your techfile.sshaft file to include the new library
  3. Modify the cds.lib file to include the path to your new library.
  4. Modify the .synopsys_dc.setup and .synopsys_pt.setup files to include the path to your new library

The first change can be made by opening the addsub.v file from the previous tutorial and looking for the following line in the addsub32 module definition:

NAND2X1 I32 ( .A(J), .B(K), .Y(sub) );

Change the mention of the NAND2X1 cell to the NAND2X8 cell as follows:

NAND2X8 I32 ( .A(J), .B(K), .Y(sub) );

The second change can be made by downloading the techfile.sshaft file (distributed with this tutorial). Open this file, and you should notice the following new variables:

  • CdsVerilogInRefLibs – This variable is a comma-separated list of the libraries to be reference when the Verilog file is read into Cadence DFII. This variable is in the main techfile.sshaft file for the technology. Its value here is changed, however, by adding “mycells” to the end of the list.
  • CdsEncounterGDSRefLibs – This variable is a space-separated list of the libraries to be reference when a GDS2 or DEF is read into Cadence DFII. This variable is also in the main techfile.sshaft file for the technology. Its value here is changed, however, by adding “mycells” to the end of the list.
  • MyStdCellDir – This is a new variable that has been defined for convenience. It is set to the path to the directory where you generated the .lef and .lib files. It is referenced by the last two techfile variables. You will need to change this variable in order for the flow to work for you.
  • EncounterLefFile – This variable is a space-separated list of the .lef files to be used in Encounter to define the timing values for each standard-cell. (Note that the “\” character at the end of the line is a line-continuation indicator) This variable is also in the main techfile.sshaft file for the technology. Its value here is changed, however, by adding the absolute path to the “mycells.lef” file, referencing the MyStdCellDir variable defined above.
  • EncounterTimingLibrary – This variable is a space-separated list of the .lib files to be used in Encounter to define the timing values for each standard-cell. (Note that the “\” character at the end of the line is a line-continuation indicator) This variable is also in the main techfile.sshaft file for the technology. Its value here is changed, however, by adding the absolute path to the “mycells.lib” file, referencing the MyStdCellDir variable defined above. NOTE: If you haven’t yet generated the .lib file and want to re-run the flow, simply remove the reference to mycells.lib from the end of this file.

Next, we need to change the cds.lib file for the SSHAFT flow. In the last tutorial, you modified your own version of the flow. Go to the dist/tech/TSMC_CMOS020/cds directory now. In that directory, you will find the cds.lib file that will be copied to the run/cds directory when you run the pr.py script. Modify this file to add the following line:

DEFINE mycells [absolute path to your mycells-DFII library]

Finally, change to the dist/tech/TSMC_CMOS020/dc directory. Here you will find a file called synopsys_dc.setup.tcl. This file will be copied to the run/pt directory when you run the pr.py script and will be read every time Synopsys DesignCompiler is invoked to estimate the power. In this file, you should see a line that reads:

set search_path [concat  /afs/eos.ncsu.edu/lockers/research/ece/wdavis/tech/
iit/iit_stdcells/tsmc018/signalstorm $search_path]

Add the absolute path to the directory that contains your .lib and .db files into the path list, just before the “$search_path]” characters. Also, notice the lines that read

set link_library [list * iit018_stdcells.db]
set target_library [list iit018_stdcells.db]
set symbol_library [list iit018_stdcells.db]

Insert the name mycells.db into each one of these lists, just before the “]” character, so that you get the following:

set link_library [list * iit018_stdcells.db mycells.db]
set target_library [list iit018_stdcells.db mycells.db]
set symbol_library [list iit018_stdcells.db mycells.db]

Next, apply the same changes to the synopsys_pt.setup file. This file will also be copied to the run/pt directory when you run the pr.py script and will be read every time Synopsys PrimeTimer is invoked to estimate the timing. Note that the “symbol_library” entry is omitted from this file, because it is not needed by PrimeTime.

These should be all of the changes needed to re-run the flow with your new library. Source the setup-script for your private version of the flow and re-run it. You should notice that the critical-path delay has significantly reduced from the previous tutorial.

NOTE: If you skipped the generation of the .lib and .db files, then the timing and power verification portion of the flow will not work. You can re-run the flow without Timing and Power Verification with the following commands:

pr.py –route –log flow.log
pr.py –import –single –log import.log

You can open the layout view in Cadence DFII and search for the cell using the menu options Tools->Virtuoso Preview followed by Edit->Search. In the “By” window, select “Cell Name” and enter “NAND2X8” to the right of the “==” symbol. Then click “Select” and you should see the cell highlighted in your layout.

Run DRC, Extract, and LVS checks to make sure that everything is working properly. Remember that you will need to create pins for the vdd! and gnd! shapes manually before LVS will work!


Congratulations! You have finished Place & Route Tutorial #3.