Inputs for ispatial

1. Tech lef and standard cell (.lef) files (tlef will have all layer/via properties, standard cell lef will have each stdcell details like pins , pins layers, antenna gate area)
2. Liberty (.lib) files — standard cell files (.lib will have max cap, max tran, leakage, lookup table, more attributes like dont touch, dont use, area)
3. Floorplan (.def) file
4. QRC techfile— required for good R/C correlation (Contains the process-dependent model files and manufacturing effects used by the extractor to calculate resistance and capacitance.)
5. MMMC configuration file

QRC technology files contains the same type of parasitic information as the LEF files but the resistance and capacitance information in these files have a finer granularity.

The capacitance in a LEF comes from a foundry and is generated by whatever process it sees as appropriate. The capacitance information in QRC technology file comes from the same process definition files that drive sign off extraction as well as the various other extractors used in Cadence tools. The process definition files define layer thicknesses, compositions, and spacing.

After you load both your LEF and parasitic files, tool will perform consistency checks between the two files. This happens automatically, much like the check between the LEF and timing library files.

For best results, the corner for the parasitic file used should match the corner for the timing library. That is typically max or worst.

Things to watch out for while doing synthesis

• Tool can mark a library cell as avoid (dont_use) when the cell exists in the timing library but does not exist in the physical library (LEF file).
• Besides the obvious HDL syntax errors that might occur during reading HDL, you need to pay attention to the blackboxes and latch inference during elaboration. If tool does not find the HDL module or a library cell for an instance referenced in the HDL, it will issue the following warning message and treat the instance as a blackbox.
• There is a slight difference between a logic abstract and a blackbox. A logic abstract has port definitions, which is not the case with blackboxes. All ports are treated as inout ports in a blackbox. During optimization, the logic connecting to the blackbox or logic abstract instance will not be optimized or deleted.
• Another thing that you might want to check after elaboration is unintentional latch inference. This normally occurs when coding case logic with the missing default condition or a missing else block in an if-else statement.
• check_design is a useful command that can provide information on undriven and multi-driven ports and pins, unloaded sequential elements and ports, unresolved references, constants-connected ports and pins, and any assign statements and preserved instances in the given design. In addition, the command can report any cells that are not in both .lib and the physical libraries (LEF files).
• If the design has hand-instantiated gates for functional or ECO purpose, these must be preserved before synthesis to avoid being removed by the tool. After elaborating the design, the preserve attribute must be applied to these instances.

Wireload Model Vs. PLE Vs. Spatial Vs. Ispatial

During synthesis (not post-placement), the wire capacitance and resistance are traditionally estimated from the wireload model (WLM). These WLMs are often provided with the technology libraries, which are statistical parasitic values obtained from the past designs. These are lookup tables of wire capacitance, resistance, and area based on the number of net fanouts. A more accurate form of WLM is a custom WLM, which is derived after the design is placed. However, to place the design, the initial netlist needs to be synthesized with the WLM supplied with the library or zero WLM. Another issue with the custom WLM is that it represents a static view of the design placement when the model is extracted. As the RTL and constraints are modified during the course of the design, the WLM becomes less accurate.

The PLE, on the other hand, dynamically models the effects of placement based on the current state of the design and constraints. It requires at the minimum the LEF library. The addition of the captable file and the DEF floorplan will add more accuracy to the PLE model. If the LEF library is read in, tool will automatically be in the PLE mode for synthesis. This can be verified with the root attribute ‘interconnect_mode’. In this mode, the ‘report -ple’ command would show the values of the estimated wire parasitic in each metal layer.

In the PLE flow, the PPA is low but the turnaround time (TAT) is very fast. TAT is the time which the tool takes to execute the flow or the runtime of the flow. The PLE flow can be used when the design is not complex and needs to be analyzed quickly.

The tool-Spatial flow uses a rapid placement to better estimate long wires in the design. This helps deliver more accuracy to the core synthesis optimization engine during RTL-to-gate synthesis.

In the Spatial flow, the PPA and prediction of design is medium post tool synthesis, but it comes at a cost of runtime. The Spatial flow can be used when there is a need of correlation between the Synthesis and Place and Route (PnR) flows.

The tool-iSpatial flow is targeted to deliver best-in-class PPA as part of a full RTL2GDS implementation flow, as well as excellent prediction of preCTS QoR for the RTL designers and synthesis engineers. It replaces all previous physically aware tool flows such as Hybrid, Spatial, etc. The new flow utilizes the GigaPlace and GigaOpt technologies from Innovus to create a placed and physically optimized layout of a design at the end of tool synthesis. The resulting layout can be directly taken into Innovus for further incremental preCTS optimization.

Tool will optimize the design to satisfy timing constraints first, and then consider area, power, and design rules violations (DRC) later in the process. The following are some ideas to fine-tune optimization for timing improvement.

Timing optimizations

• Datapath optimization, should select the ‘very_fast’ architecture if the datapath component is in a critical path.
• path grouping, During optimization, tool works on one cost group at a time until there is no improvement on the critical path of the cost group.

TNS optimization works on the critical path (WNS) of each cost group until there is no more improvement. The non-critical paths can be downsized for area saving. In the TNS optimization mode, all endpoints of the cost group are optimized. Optimizing for TNS reduces the number of violating paths and might reduce WNS in some cases. However, there is a drawback on runtime and possible area increase.

• Incremental optimization.
• Path adjust, Tightening the constraint on a selective path will make the path become more critical and force Genus to work harder on it.

Power optimizations

By default, power optimizations are off. We can tell tool to use multi vt libraries for leakage power reduction.

• When optimizing for dynamic power, you need to have the switching activities annotated to increase the accuracy of the dynamic power goal. Genus uses a default switching activity of 0.02 toggle/ns for every non-clock net. This switching activity might not be close to the actual switching activity obtained when the design is in an operational mode. Therefore, the dynamic power that Genus optimizes for will not reflect the switching power during actual operation.
• clock gating for dynamic power reduction.

Area optimization

Tool by default will optimize for smallest area for a given timing constraint. The logic in non critical paths is automatically downsized to save area. The unused sequentials are removed from the design .

• Tool supports multibit swapping. This helps in both reducing area and power.