Apple Pseudo RAM Design Project
The main idea behind the Pseudo SRAM/DRAM project is to build a parameterized SystemVerilog generator for pseudo-SRAM and DRAM macros, assembled from standard cells, that future course projects can drop into the shared project die. The current challenge with the Cadence flowtool used in the CSE 30342 course is that the TSMC PDK / Cadence flow does not have an SRAM generator. As a result, the students must use flip-flop storage, which is the most expensive way to hold a bit on the die. Compared to dynamic storage (BUFTD0+INVD0), flip-flop storage has four drawbacks:
- Area. A DFQD0 bit is 41.8 µm², compared with 28.6 µm² for BUFTD0+INVD0. A 128x32 b array in DFFs takes 47.5% of the die versus 32.5%. A 256x32 b DFF array takes 95.0%, which leaves essentially no room for the rest of the design.
- Clock load and power. Every bit has a clock pin, so the clock tree must drive all 4,096 flops of a 128x32 b array. Each flop's internal clock nodes toggle every cycle even when its data does not change. Clock power therefore grows with memory size unless students add clock gating.
- Routing and timing closure. Thousands of clocked sinks congest routing and make clock-tree synthesis, skew, and hold fixing harder in place-and-route.
- Leakage. A flip-flop has more transistors per bit than BUFTD0+INVD0, so it leaks more per stored bit.
Dynamic storage avoids these costs but forgets its data unless it is refreshed.The circuit design is the easy part. The hard part is developing a refresh strategy that is performant, and the RTL that implements it while keeping addressing and controller overhead low.
---------- -------------- -------------- -------------- ------------------------- ---------------
1 b 28.6 30.8 41.8 0.00793% 0.0116%
32 b 914 984 1340 0.254% 0.371%
128x32 b 117000 126000 171000 32.5% 47.5%
256x32 b 234000 252000 342000 65.0% 95.0%
* die_size = 600µm x 600µm (active area of a 1mm x 1mm die)
Refresh Feasibility
At a 10MHz clock, a row needs to be refreshed approximately every 256 cycles. That is very doable for a 128-word DRAM. This is feasible for a 128-word DRAM, and 128 assembly instructions is actually a lot. The TSMC liberty only gives total cell leakage power at 1.8V, and its noise margins aren't useful here. The estimate therefore uses two conservative assumptions:
- All cell leakage flows into the storage node, and it is constructive (worst case).
- Noise margin NM = 0.1*VDD.
Scope and deliverables
The core deliverable is a working 128 x 32b DRAM on the shared project die, plus a generator that can produce other sizes.
- Bit cell and array generator. Parameterized SystemVerilog that instantiates the BUFTD0+INVD0 storage cell plus the row/column decode and sense/write paths as a structural netlist.
- Behavioral model with retention. A simulation model that corrupts a row's data if it isn't refreshed in time. This lets students verify their refresh logic.
- Refresh controller. RTL for at least two strategies (for example burst vs. distributed refresh, or refresh hidden in idle cycles). Each is measured for stall cycles and for controller and addressing area.
- Pseudo-SRAM wrapper. An SRAM-style interface that hides refresh from the user, with a ready/stall handshake when a refresh collides with an access.
- Published IP black box. The packaged macro (abstract view, timing model, behavioral model, integration notes) that future course projects instantiate without seeing its internals.
- Characterization report. Area against the table above, refresh overhead per strategy, and the remaining assumptions.
Skills demonstrated
Upon completion of the project, students will demonstrate understanding of:
- Publishing and consuming IP black boxes. This means separating a macro's interface and views from its implementation, which is critical in industry.
- Architecture trade-offs. Refresh strategy versus performance, measured rather than argued.
- Area-efficient control RTL. Keeping addressing and controller overhead small next to the array it serves.
- Parameterized, generator-style SystemVerilog. One codebase produces many memory sizes.
- Verifying against a physical failure mode. Retention-aware models and tests that check whether the data survives refresh.
- Working from imperfect vendor data. Bounding behavior with conservative assumptions when the liberty lacks the needed numbers.