Slam Capacity
The slam system was designed to handle even very large designs.
The limits of the database are below.
Platform Capacity The following can be used as a general guide to
virtual memory requirements for slam with P&R type databases. All component
counts exclude filler cell placements, which can double or even triple
placement counts.
If your design does not contain connectivity information,
a substantially larger design will fit in the same memory footprint. Estimated
platform limits are
The above are only estimates as every design will be slightly
different. Some designs have more or less wiring per cell. Placement
counts are used as a guide because it is a more commonly available
parameter. Note the placement counts are all unique placements. For example
15 placements of a cell containing 50 placements counts as 65, not 750 placements.
Please note that for reasonable performance, you should
have physical memory of at least the size of the largest block. In the above
3M placement case, 4GB of physical memory is recommended as a minimum.
Slam Performance Example on a quad 16GB opteron
Example (on an Ultra 10 440MHz processor)
Resource Usage
**32 bit operating systems are limited by virtual memory. Because
most designs are hierarchical, the requirement for more than 4GB of
virtual memory is unlikely. Even very large designs would probably
not have 1 billion objects in any specific cell. Even some very large
graphic chips and DSP chips have not required more than 32 bit addressing.
Some of the latest processor and graphics do require 64 bit addressing
though. If the design requires more than 4GB of memory, you must use
either opteron or solaris 64 bit OS'es.
12GB stream file
5 minute conversion from stream to slam format
1 minute to open database with all hierarchical levels displayed
1.2 million instances
1.8 million rectangles
82 thousand paths
1.9 million wires
3.1 million port connections
400MB Virtual memory
230 seconds stream in conversion time
Move 500K instances in 120 seconds