Guild icon
wafer.space Community
📐 - Designing / 💻-digital
Between 2025-11-30 11:59 p.m. and 2026-01-01 12:00 a.m.
Avatar
given how big GF's SRAM blocks are at the small end (64 words is half the size of 512!), do you think it'd end up being more area-efficient to just use registers/flip flops for small "sram-like" banks? say 16 words / 128 bits?
7:44 p.m.
just criminal 😄
Avatar
(suppose it's easy enough to try it out heh)
Avatar
You can just take the are of a FF and multiply it and see how close you are.
8:45 p.m.
For wide shallow mem, the muxing/addr decode won't be too bad so it's a good first rough estimate.
Avatar
aha ok. so with some generous assumptions on the overhead plumbing, a 16x8 might looks something like this (albeit witih flexibility to smoosh into odd corners due to being not a macro block)
Avatar
Have you seen: https://github.com/AUCOHL/DFFRAM Their approach is to create a macro block containing standard cells for different memory configurations. This can be more dense than just having a large FF based RAM along with your RTL, and in theory speeds up synth/PnR. I'd suspect the final QoR ends up slightly worse.
Standard Cell Library based Memory Compiler using FF/Latch cells - AUCOHL/DFFRAM
👀 1
4:26 a.m.
Might be handy for size comparisions
Avatar
oh awesome, I had not seen that. cheers for the link!
2:31 a.m.
@BreakingTaps - I believe @Tim Edwards's 3v3 SRAM is quite a bit smaller?
Avatar
@BreakingTaps : One reason the GF SRAMs don't scale well is that they all contain the same 10-bit address decoder and sense amps designed for a 128-row array.
💀 1
Avatar
oof 😄
Avatar
generated a few latch and dff banks using dffram, neat project! latches were consistently 10-15% smaller than dff, and as expected they are all quite a bit bigger than the foundry optimized banks. Not really a fair comparison, will probably run some tests comparing it against a dumb register array since that's a lot closer to the use case
Exported 14 message(s)
Timezone: UTC+0