Memories, macros, and blocks

Large memories are cheaper and faster as SRAM macros than as flip-flops. Tapeo maps an RTL memory to a macro only when the macro does exactly what the RTL does, and proves it before using it.

RTL memories to SRAM#

• Synthesis finds every memory in the RTL (an array written in a clocked block and read through an index).
• A memory maps when an installed macro has the same behavior: one read/write port, a read registered on the rising clock edge, and write enables at a width the macro's mask can express.
• A memory larger than one macro is split across several: banks for depth, slices for width. The generated wrapper registers the bank select, enables only the macro being read or written, and never writes the unused bits.
• Each wrapper is proven equal to the RTL memory with SymbiYosys before it is used. If the proof fails, the memory stays in flip-flops.
• Memories with initial contents, several ports, an unregistered read, an asynchronous reset, or fewer than 2048 bits stay in flip-flops, each with its reason.

The memory plan#

The Workflow tab shows each memory: its size, the macros it uses and their bank and slice arrangement, the wrapper proof, the other arrangements compared, and why other macros do not fit. The plan is saved as generated/memory/plan.json; tapeo memories and Tapeo: Show Memory Plan print it.

Memory settings#

Create analysis/memory_settings.json to change the defaults:

{
  "mapping": "auto",
  "minimumBits": 2048,
  "maximumMacrosPerMemory": 16,
  "allowedMacros": ["sram22_1024x32m8w8"],
  "keepInRegisters": ["top.small_fifo"]
}

"mapping": "off" keeps every memory in flip-flops. Settings never force a mapping the checks refuse.

Where macros come from#

Each macro is imported at a pinned upstream revision with its views, timing corners, and checksums, and its behavior is checked against the provider's own model. Power: the process's macro grid reaches each macro's supply pins; signals are kept off the layers where that grid's vias land. Shuttles accept only macros their own template integrates (Tiny Tapeout none, wafer.space the 512 x 8 SRAM).

Hardened blocks#

A large repeated module can be implemented once and placed as a macro. List it in tapeo.json:

{ "sources": ["rtl/*.sv"], "top": "dual_mac", "blocks": ["mac_unit"] }

• Tapeo synthesizes, places, and routes the block on its own, with its own power grid whose supply pins the top's grid connects to, and saves its abstract, timing model, netlist, and layout under generated/blocks/<module>/.
• The top is synthesized with the block as a black box and places every instance of it.
• The block is rebuilt only when the files that define it, the process, the physical settings, the constraints, or the block flow change. Editing only the top reuses it.
• On SkyWater 130 a block may contain blocks (two levels: the inner one routes up to met3, the outer to met4, the chip uses met5). Each block gets a timing model per signoff corner.
• After synthesis, AI repairs may change constraints, settings, scripts, and process configuration only; an RTL change they propose waits for your review.

Process capabilities#

tapeo capabilities, Tapeo: Show Process Capabilities, and /api/capabilities list, for every process, whether each check is supported, experimental, needs your inputs, or unavailable, with the reason, plus its installed corners, rule decks, macro families, and shuttles. Signal-net electromigration, package IR drop, signal integrity, thermal analysis, and a processor in a generated SoC are listed as not available yet, each with what it needs. Workload-based ASIC power is available when a current simulation waveform, mapped netlist, and compatible Liberty are present.

Loading the capability matrix…

Limits#