What Can Go Wrong?

Below are summarized the major operations required for SRAM_ID.

File Open

File opening (even very large files) is generally no longer a problem when the correct layers have been specified i.e. SRAM support and POLY.

Rasterizing

The current known limitation is the size of the raster bitmap which cannot exceed 2GB. Some combinations of pixel resolution and chip area are therefore not possible. However we have not found that this step requires small resolutions so this is generally not a show stopper.

Window Generation

This is a one time step and we have not received any reports where this would take a very long time or lock up a machine.

Window Extraction

This step involves taking the list of windows and extracting the SRAM block data and writing a GDSII file (caw_auto_extract.gds) to disk.

It is possible that this step can take a long time and generate a very large file. That would then cause problems for the next step. What might cause these problems?

a) OASIS compression methods that have no equivalent in GDSII. OASIS has several advanced ways of compressing data that have no GDSII equivalent. If we encounter such a file we might have to essentially "flatten" most of it to convert it to GDSII when extracting the SRAM regions.

You can see if this is happening by examining the size of the caw_auto_extract.gds file. For example, if you start with a 100MB OASIS file but the caw_auto_extract.gds file is 4GB then you can assume that this is the problem.

Fix?

A fix has been implemented as of 1/15/2011. This needs to be tested on very large files and on OASIS files but here is a summary of the fix:

OASIS input - even relatively small OASIS files can blow up when converted into GDSII. Therefore we have created a "threshold" for determining whether or not the OASIS file should be extracted into a large number of GDSII regions. The threshold is based on the ratio of window area to total chip area.




b) problems with Hierarchical Extraction of AREFs - The Hextract program has a limitation currently when the extraction window crosses the extents of an AREF. Instead of only exploding the placed cells that cross the window, it explodes all the cells in the entire AREF. So even if the input is GDSII, this might result in a giant caw_auto_extract file that clogs up the next steps. Again, compare the size of the caw_auto_extract.gds file to your input file. It should be much smaller than the input file.

How can I tell if this is possibly the problem?

Use Qckvu3's Cell Reference highlight function and highlight AREFs (say larger than 4x4) and see if these cross the windows defined by the bitmap analyzer.

Fix?

Artwork is working on a code fix that will eliminate this behavior.

SRAM Finder - Pattern Recognition

This is where a lot of computation is done and generally consumes the lion's share of the time required to complete a job. There are several potential bottlenecks that might occur in this stage:

a) Poorly Constructed Rule List

If the rule list is not appropriately set, the sram_finder might do a lot of unecessary work; coupled with a large number of polygons this could bring progress to a halt.

Fix?

The most important rule is the max_x_pitch and max_y_pitch. These should be set to be slightly larger than your expected pitch in X and Y. If you set these values too high, then the sram_finder might not group elements within a cell for recognition and the pattern recognition routines will take much longer.




b) Swapping

sram_finder works in parallel by loading multiple copies of the caw_auto_extract.gds file into memory. The number of copies is based on the number of CPUs available -- not the amount of memory.

If for some reason this file is unreasonably large and loading multiple copies into memory forces the system into a swapping state, then progress will greatly slow down.

Fix?

Reduce the number of sram_finder instances (can we do this?); increase RAM; find out why the caw_auto_extract.gds file is so large and reduce it.




c) Very Large SRAM Block

Some devices may have very large SRAM blocks - by this we mean both physically and also the number of flattened polygons in the POLY layer. The pattern recognition routines are not linear - so a single very large SRAM block could take much much longer than 4 smaller ones that sum up to the same area.

Fix?

woud require code changes to optimize or subdivide handling of large blocks.