Memory Compilers and Their Views

Lessons 4 to 6 built an SRAM from the bitcell upward. In practice, a chip team rarely does this for each memory. Instead, it runs a memory compiler – a generator supplied by the foundry or an IP vendor – which takes a short list of parameters and produces a complete macro with every view the flow needs. For a PD engineer, the compiler is where memory design meets implementation.

This lesson describes what a compiler takes in, what it produces, how to choose the configuration (especially the mux factor from lesson 5), and the rules that govern placing the resulting macro in a floorplan. Lesson 9 then looks inside one of the outputs, the Liberty file.

Reading time: about 8 minutes.

8.1 What a memory compiler does

A memory compiler contains a set of pre-drawn, pre-verified leaf cells: the bitcell, a column of precharge and sense circuitry, a row of decoder and wordline driver, control blocks, and edge and corner cells. Given a configuration, it tiles these leaf cells into an array of the right size, connects them, and generates the models by a combination of simulation and pre-characterized data. Because every leaf cell has been verified in silicon and every legal combination has been checked by the vendor, the generated macro can be trusted without redesign.

Thus, the compiler offers a large family of macros from one investment in custom design. The cost is flexibility: only the configurations and options the compiler supports are available, and each has a legal range.

8.2 Compiler inputs

The main inputs are common across vendors, although names and legal ranges differ.

• Words – the depth, for example 2048. Usually it must be a multiple of the mux factor times some step size.
• Bits – the width of each word, for example 64.
• Mux – the column multiplexing factor from lesson 5, often 4, 8 or 16 for SRAM and smaller for register files.
• Banks – the number of internal banks, where the compiler supports it.
• Port type – single-port (one read-or-write port), two-port (one read and one write port), or dual-port (two independent read-or-write ports).
• Options – a bit-write or byte-write mask, redundancy (spare rows or columns, lesson 10), low-power modes such as light sleep, deep sleep or shutdown, periphery threshold-voltage flavour, separate supplies for array and periphery, and test interfaces for built-in self-test.

8.3 Compiler outputs

For each configuration, the compiler writes the set of views shown in Fig. 8.1. Each view serves a different tool in the flow.

• Verilog model – a behavioural model for RTL and gate-level simulation, often with timing checks for setup and hold violations.
• Liberty files – timing, power and pin capacitance at each process, voltage and temperature corner, for synthesis and static timing analysis. Lesson 9 covers their content.
• LEF abstract – the macro size, pin shapes and layers, and obstructions, for place and route.
• GDS layout – the full layout, merged into the chip database at the end of the flow. Some vendors supply a placeholder and merge the real layout at the foundry.
• CDL or SPICE netlist – used for LVS. At the chip level, the macro is often treated as a black box whose pins are checked.
• Datasheet – area, dimensions, timing, power and pin descriptions in human-readable form.

Some compilers also produce power-grid models for IR-drop analysis and files describing the test interface for MBIST insertion. It is good practice to regenerate all views together and keep them under version control as a set, because a LEF from one compiler version and a Liberty from another may not agree.

A short excerpt shows what the LEF abstract contains. The dimensions here are illustrative:

MACRO sram_2048x64
  CLASS BLOCK ;
  ORIGIN 0 0 ;
  SIZE 130.0 BY 120.0 ;
  SYMMETRY X Y ;
  PIN CLK
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT
      LAYER M4 ;
        RECT 129.80 60.00 130.00 60.10 ;
    END
  END CLK
  # ... address, data, enable and power pins ...
  OBS
    LAYER M1 ;
      RECT 0.00 0.00 130.00 120.00 ;
    # ... further obstructions up to the highest layer used inside ...
  END
END sram_2048x64

The OBS section tells the router which layers are blocked over the macro. Layers above the highest obstruction are typically free for over-the-macro routing.

8.4 Choosing the configuration

The architect fixes words and bits. The designer chooses the mux factor, banking and options. As lesson 5 showed, the mux factor sets the shape and influences speed and power. Typically, the designer generates a few candidates and compares their datasheets.

## Array only; assuming periphery adds about 25 um to width and 25 um to height
mux 4 :  102.4 x 102.4  ->  about 127 x 127   (too tall for 90 um)
mux 8 :  204.8 x  51.2  ->  about 230 x  76   (fits)
mux 16:  409.6 x  25.6  ->  about 435 x  51   (too wide for 250 um)

Two other choices matter often. Splitting a deep memory into two macros of half the depth can give a better shape and faster access, at the cost of extra periphery area and a multiplexer in the logic. Conversely, combining two narrow memories into one wider macro saves periphery but couples their access patterns.

8.5 Macro placement rules for PD

Let us consider Fig. 8.2, which shows a macro placed against the core edge.

The common rules, with the reason for each, are:

1. Pins face the logic. Macro signal pins are usually on one edge. Orient the macro so that edge faces the cells that connect to it; otherwise every net detours around the macro.
2. Use legal orientations only. At advanced nodes the poly direction is fixed, so a macro may typically be mirrored but not rotated by 90 degrees. The compiler documentation states which orientations are allowed.
3. Snap to the grid. The macro origin must sit on the placement or manufacturing grid the vendor requires, which sometimes also aligns it with the power-grid pitch.
4. Add a halo. A keep-out margin around the macro leaves room to reach the pins and avoids placing cells in a region that cannot be routed. In IC Compiler II, for example, create_keepout_margin -type hard -outer {left bottom right top} [get_cells u_sram0] adds one; Innovus has an equivalent, whose argument order should be checked in its help.
5. Avoid thin channels. A narrow gap between a macro and the core edge, or between two macros, is hard to route and easy to congest. Either abut the macro to the edge, or leave a channel wide enough for its pins.
6. Connect power generously. Macro power pins are typically on one of the middle metal layers. The chip grid must drop vias onto them at many points to limit IR drop, and if the macro has separate array and periphery supplies, both must be connected to the correct domains.
7. Plan for timing. Address and data setup times are often large, and the clock-to-output delay is long. Placing the launching and capturing flops close to the macro pins leaves more of the cycle for logic.

8.6 Interview questions

What views does a memory compiler generate, and who uses each? Verilog for simulation, Liberty for synthesis and STA, LEF for place and route, GDS for the final merge, a netlist for LVS, and a datasheet for planning.

How does the mux factor affect a macro? It sets the aspect ratio and bitline length: higher mux gives a wider, shorter macro with shorter bitlines but longer wordlines and more half-select power.

Why add a halo around a macro? To keep standard cells away from the pins so that routes can reach them, and to avoid unroutable slivers next to the macro edge.

Why can a macro not be rotated by 90 degrees at advanced nodes? Gate poly must run in one fixed direction across the die, and a rotated macro would have its poly in the wrong direction.