hdl-tools/digital-chip-design-agents/memory-ip-design

Skill: Memory IP Design (SRAM / Register File / ROM)

Invocation

When this skill is loaded and a user presents a memory IP design task, do not execute stages directly. Immediately spawn the digital-chip-design-agents:memory-ip-orchestrator agent and pass the full user request and any available context to it. The orchestrator enforces the stage sequence, loop-back rules, and sign-off criteria defined below.

Use the domain rules in this file only when the orchestrator reads this skill mid-flow for stage-specific guidance, or when the user asks a targeted reference question rather than requesting a full flow execution.

Pre-run Context

Before executing or advising on any stage, read the following files if they exist:

1. memory/memory-ip/knowledge.md — known failure patterns, successful tool flags, PDK/tool quirks.

Incorporate its guidance into every stage decision. If absent, proceed without it.

1. memory/memory-ip/run_state.md — current run identity (run_id, design_name, tool,

last_stage). Use this to resume correctly after interruption. If absent, a new run is starting; the orchestrator will create this file before the first stage.

This pre-run read applies whether this skill is loaded by a user or called by the orchestrator mid-flow. It ensures the fix database is consulted before any diagnosis step.

Purpose

Guide embedded memory IP development from requirements capture through macro selection, array architecture, repair allocation, and view qualification. Produces a signed-off memory IP package: an instance inventory, a selected macro per instance, a QA-clean view set across all PVT corners, a repair architecture, and placement/timing constraints for downstream handoff.

Scope boundary — what this domain does NOT do

This domain treats the memory as the product. It stops at the handoff and does not duplicate work owned elsewhere:

This domain produces the inputs those domains consume: memory inventory and repair-register map for DFT, placement constraints for PD, .lib set and derates for STA, behavioural models for verification.

Supported EDA Tools

Open-Source

• OpenRAM (openram) — open-source memory compiler; generates GDS, LEF, Liberty, and Verilog for SRAM
• CACTI (cacti) — early access-time, area, and power estimation before a compiler run
• sky130 / gf180mcu SRAM macros — PDK-provided pre-hardened macro sets with fixed configurations
• Magic (magic) — DRC and LVS on generated macro layout
• KLayout (klayout) — GDS QA, layer/obstruction inspection, boundary checks
• OpenSTA (sta) — .lib load sanity check and macro timing arc inspection

Proprietary

• ARM Artisan memory compilers (artisan, dialect arm) — production SRAM/register-file/ROM compilers
• Synopsys memory compilers + SiliconSmart (siliconsmart, dialect synopsys) — compilation and Liberty characterisation
• Cadence Liberate (liberate, dialect cadence) — Liberty characterisation across PVT corners
• Siemens Tessent MBIST/BISR (tessent, dialect siemens) — repair-register and BISR architecture reference (insertion owned by DFT)

Stage: memory_requirements

Domain Rules

1. Capture depth × width × port count for every memory instance in the design; source from design_state.architecture and design_state.rtl where available
2. Establish memory type and port requirements by this precedence, and record which source supplied each instance:
3. `design_state.rtl` — the implementation is authoritative for port count, widths, and depth, because that is what must actually be instantiated
4. `design_state.architecture` — authoritative for type intent and sizing where RTL is silent (typically pre-RTL runs)
5. Inference — only when both are silent. Infer from the whole picture, not depth alone: port count and concurrency (multi-port and bypass-heavy structures are register files regardless of depth), access-latency budget, and what the target PDK actually offers. Depth is a weak tiebreaker (~256 words) that misclassifies both shallow SRAMs and deep register files, so record any inferred type as an assumption to confirm, not a fact

On conflict, do not silently pick a winner. If rtl and architecture disagree on type, port arrangement, depth, or width for the same instance, halt with a constraint_gap escalation naming the instance and both values. A mismatch here selects the wrong macro interface and is not recoverable after view_generation

1. Compute required read/write bandwidth per instance and check it against the target constraints.clock.clk_mhz — bandwidth shortfalls must be resolved here, not by over-selecting macros later
2. Decide the ECC scheme per instance with this deterministic policy, so two runs on the same inputs resolve identically. Compute budgeted_FIT = fit_target_fit_per_mb × instance_Mb (constraints.memory_ip.fit_target_fit_per_mb, default 100) and raw_FIT from the PDK's SER rate for the chosen bitcell:

Record raw_FIT, budgeted_FIT, the PDK SER source, and the resolved scheme per instance into memory_ip.ecc. An unaudited ECC choice is not reproducible on a re-spin

1. Enumerate required power modes per instance — active, light sleep (periphery off, array retained), deep sleep (retained at reduced voltage), shutdown (contents lost) — and resolve retention with an explicit precedence: a per-instance retention requirement from the spec/architecture always wins; constraints.memory_ip.retention_required is the default applied only to instances that state nothing. The global flag never overrides an explicit per-instance value in either direction — forcing retention onto an instance declared non-retained over-constrains macro selection and costs area, while dropping it from one declared retained is a functional bug. Where the global is true and an instance is explicitly non-retained, record the resolved value and the rationale rather than silently reconciling. Write the resolved per-instance value into memory_ip.power_modes
2. Record the dual-rail requirement: whether array and periphery supplies are separate, since this constrains both the macro choice and the UPF power intent
3. Flag any instance needing multi-port behaviour and whether it can be met by banking instead of a true multi-port bitcell (much larger)

QoR Metrics to Evaluate

• Total memory bit count and instance count
• Aggregate bandwidth required (GB/s) vs. available at target frequency
• Fraction of total die area budget provisionally allocated to memory

Output Required

• Memory instance inventory (name, type, depth, width, ports, retention requirement)
• Bandwidth and ECC decision table with rationale
• Power-mode requirement per instance

Stage: macro_selection

Domain Rules

1. Confirm compiler family and macro availability in the target PDK before evaluating options; a configuration the compiler cannot generate is not a candidate
2. Column mux factor (4/8/16) trades aspect ratio against access time: higher mux gives a squarer, shorter macro but a longer bitline-to-sense path. Sweep it rather than accepting the default
3. Evaluate bank count against single-array access time — splitting a deep array into banks shortens bitlines and improves access time at the cost of periphery area duplication
4. Compare every candidate on access-time margin at the slow corner (not typical), area, and leakage. A candidate with no slow-corner margin is a fail regardless of typical-corner numbers
5. Prefer fewer, larger instances to amortise periphery (decoders, sense amps, control) overhead — bounded by constraints.memory_ip.max_aspect_ratio (default 4.0), beyond which placement and routing become impractical
6. Verify the bitcell type against the Vmin requirement: 6T is denser, 8T gives better read stability and lower Vmin for low-voltage or dual-rail operation
7. Record why each rejected candidate lost — this is the single most reusable artefact for later re-spins and belongs in knowledge.md

QoR Metrics to Evaluate

• Access-time margin at slow corner (ns) per instance — must be > 0
• Area per instance and total (µm²)
• Leakage (µW) and active power (mW) per instance
• Aspect ratio per instance vs. constraints.memory_ip.max_aspect_ratio

Output Required

• Selected macro/compiler configuration per instance
• Candidate comparison table with the rejection rationale for each loser
• Slow-corner access-time margin report

Stage: array_architecture

Domain Rules

1. Choose banking for bandwidth before reaching for a true multi-port bitcell — independent banks with address interleaving serve most concurrent-access needs at far lower area cost
2. Fix the port arrangement per instance (1RW, 1R1W, 2RW) and define the write-during-read collision policy explicitly: read-old-data, read-new-data, or X/undefined. This policy must match the behavioural model written in view_generation
3. Define wrapper responsibilities: byte-enable decode, output pipelining/registering, and clock gating of the macro enable. Keep the wrapper thin — logic that belongs in the consuming RTL should not migrate into the memory wrapper
4. Place the ECC wrapper on the correct side of the pipeline boundary and account for its latency: SECDED check-bit count is the smallest c satisfying 2^c ≥ data_bits + c + 1 (8 data bits → 5, 32 → 7, 64 → 8). Record encode and decode latency separately — decode is on the critical read path
5. Define the scrubbing policy where ECC is used: background scrub interval must be short enough that the probability of a second bit flip accumulating in one word stays below the FIT-rate target
6. Determine Vmin and assist-circuit requirements per bitcell type — read assist (wordline underdrive, negative bitline) and write assist (boosted wordline, collapsed cell supply) are what make low-Vmin operation viable, and they cost area and complexity
7. Verify the resulting architecture still meets the bandwidth figure computed at memory_requirements; loop back rather than compensating downstream
8. Where the wrapper is delivered as RTL rather than only specified (byte-enable decode, pipelining, ECC encode/decode), it is synthesisable RTL: it follows the rtl-design skill's coding rules and must pass lint with 0 errors. The macro it instantiates is a stub in that lint run — undriven-net findings on the macro's outputs are not wrapper bugs

QoR Metrics to Evaluate

• Bandwidth achieved (GB/s) vs. target
• Total memory area (µm²) vs. budget — fail above 120%
• ECC decode latency added to the read path (ns or cycles)
• Vmin margin (mV) vs. constraints.memory_ip.vmin_margin_mv (default 50)