care area web page logo


Profiling Large Layout Files

Steve DiBartolomeo, Applications Manager
last revised: December 16, 2010

Large ASICs can be profiled prior to running the complete SRAM_ID on them. This will identify any potential problems so that a user does not end up waiting hours for the SRAM_ID to complete and then find that there is no output.

Collecting Information

Information can be collected from various sources:

  • a) Qckvu3

  • b) system tools such as TOP

  • c) analysis of intermediate files

File Size, Contents and Memory Requirements

File size can be obtained by doing an ls -l command on the file under consideration.

[stevedb@asmsc37 caw_test1]$ ls -l
total 1524330
-rw-r--r-- 1 stevedb users 1524334592 Sep  3  2009 caw_test1.gds

You can see that this file is about 1.5 GB in size.

File internals can be seen after loading the file into Qckvu3 (using a layer filter does not change this report since the scan is done prior to layer filtering). The report is accessed from Qkcvu3's File menu.

qkcvu3's report details the internals of the GDSII/OASIS file.

Unfortunately this report does not tell you much about the hierarchy or how many polygons are actually in the exploded file.




Testing on a Small Section of the Chip

Prior to running the entire chip, it is helpful to test the SRAM_ID on a small portion of the chip in order to verify that your rule set is appropriate.


Zooming into a Single SRAM Block

To do this, start the Care Area Wizard Highlight, select Auto SRAM_ID and define your SRAM Support Layer and Poly layer.

Using the SRAM support layer as a guideline, zoom into a single region leaving sufficient margin around it so that the window that will be generated does not come close to the edge of the display.

qkcvu3's report details the internals of the GDSII/OASIS file.

Set your feature size to 1000nm and click on Find Bitmap Regions.

This initiates two operations:

    a) rasterizes the SRAM support layer (in your display window) using the given pixel size.

    b) uses the raster data to determine the "edge" of the SRAM blocks and creates windows to be analyzed.

Depending on file size and complexity theses two steps should take anywhere from a minute to 10 minutes for the full chip and much less for a single SRAM block. For our standard simple example, caw_test1.gds, these two steps take only about 10 seconds even when generating the full 141 windows for the entire chip. Record the number of areas that you get.


Examining the Windows

You can see the windows generated by the bitmap as an outline. View these outlines over the POLY layer and insure that they make sense - i.e. that they full enclose the SRAM blocks.

make sure the window generated by the bitmap analyzer is away from the display margins ...

Rule Set

Now check your rule set to verify that you are using the desired parameters. Make sure that the max_x_pitch and max_y_pitch are set to reasonable values.

A sample rule set suitable for caw_test1.gds is shown below. Because caw_test1 has an unusual memory cell that is very tall you will notice that the max_ref_height = 22 and the max_y_pitch = 22. Most of the other memory cells in caw_test have a max pitch of 5.65 um.

min_ref_width ANY
max_ref_width 6
min_ref_height ANY
max_ref_height 22
min_x_pitch ANY
max_x_pitch 14
min_y_pitch ANY
max_y_pitch 22
min_rows 2
max_rows ANY
min_cols 2
max_cols ANY
min_percent_coverage 40
max_percent_coverage ANY
min_element_cnt 14
max_element_cnt ANY

Run the Single Block

Click on the button Find Sram and Create Selections. This launches two separate operations.

    a) creates a new GDSII file (caw_auto_extract.gds) by using the windows from the previous step and cutting out any data within the window. In principle this file ought to be much much smaller than the original layout file since we are only pulling data in the SRAM regions and only from one layer.

    b) starts one (or more) instances of sram_finder. This program loads a copy of auto_extract.gds into memory and works on one of the SRAM blocks trying to recognize the repeating elements.

    The number of instances of sram_finder that are launched depends on how many CPU's you have available.


Expected Timing?

If you are running a single SRAM block then you would expect these two steps to take anywhere from one minute up to several minutes. Extracting the caw_auto_extract.gds file is only done once ... The sram_finder has to process one or more windows.


Results

Assuming it does complete quickly you should see a care area (or multiple care areas) for your block that contain the repetitive geometries.

care area generated for a single memory block

Potential Problems

Assume you have run a single block successfully and in what appears to be a reasonable amount of time. You then go to run the entire chip and after an hour you don't see much progress.

What should you look for?       Continued ...




  Download   Revision History   Installation   On Line Manual   Video Tutorials