Do you mean interfacing to external SDRAM chips? I don't think there are enough pins for that. Perhaps if you can accept an 8 bit data bus. In that case you can simply include the Verilog for some SDRAM controller (there are several available, though many are pretty bad - don't handle block transfers, for example) from the Internet in your project. If you mean using OpenRAM to implement an on chip SDRAM then sky130 doesn't have the capacitors needed. From a thread in #openram

Ok, so I think interfacing external SDRAMs should be the first priority. (But could we use off-chip MLCC capacitors or do we need on-chip capacitors?)

I can accept an 8 bit data bus, and I could also accept accessing only a part of the addressing space to save some IOs.

What about using a secondary Sky130 chip to work as a GPIO extender to act as a virtual memory paging controller, which would control the upper address bits? Most accesses are likely inside the same page, so we would only have to instruct the other controller to change the target page when we want to reach a different page.

I think a somewhat generic method for Sky130 projects to access an up to 4GB address space would be a good thing to have, even if not all of the 4GB are directly full speed.

Which other options do we have to get access to more RAM? PCIe and LPC (Low-Pin-Count) is coming to my mind.

About the capacitors, I meant that each DRAM memory cell includes one transistor and one capacitor. Very early DRAMs used regular capacitors that could be manufactured in a normal logic chip fabrication technology but very soon they split into their own thing with vertical capacitors and increasingly advanced technology. Some IP companies do sell you DRAM designs that can be integrated into something like sky130 but they are far less area efficient than DRAMs made in dedicated processes.

Take a look at the datasheet for a 64Mbit generation SDRAM. It comes in 4 bit, 8 bit and 16 bit versions. The 8 bit version requires 29 signals and can run faster than 100MHz. https://www.micron.com/-/media/client/global/documents/products/data-sheet/dram/64mb_x4x8x16_sdram.pdf

I found an interesting project: https://github.com/zrafa/30pin-simm-ram-arduino They need approximately 17 pins to address 4KB or RAM.

Ok, so we want 8 bit data bus chips. I think I can organize some.

Hmm, on the other hand I think we could also use chips with 16 bit data bus, and we just utilize 8 bits of them. Since we read the same 8 bits we have written, that shouldn't be a problem for us I think?

But one additional address bit will provide the same double memory size than the 8 additional data bits, so we prefer chips with 8 bit data bus.

To save on IO.

I found an old DRAM module with 3 Samsung KM41C1000AJ-8 chips on, I am quite sure the -8 at the end means that it's 8 bits.

Unfortunately i couldn't find a datasheet for it, but surprisingly I found a datasheet for a similar chip from Samsung with a 4 Bit databus. I don't remember having heard about 4 bit RAM chips before.

@Philipp Gühring We have a project to tape out a DDR controller on SKY130

@Philipp Gühring The University of Washington just tape out DDR3 compatible I/O cells

@Tim 'mithro' Ansell Sounds great! Can you invite those people here and provide references please?

Great news as from a performance standpoint IO speed was a bit of bottleneck, twas rated at 33MHz previously (and slow access to SDRAM ofc). Curious, are these IO cells special or are they using special circuits to drive IO cells?

We use the bare “analog” I/Os and then add some circuits to do impedance control so that we can do on-die termination and controlled drive strength and edge rate.

@Derek Hines-Mohrman can tell you more!

I did a short look through all the MPW projects and found the following RAM related projects:

GitHub - BrandonOng22/caravel_user_project: https://caravel-user-project.readthedocs.io Project Detail | Efabless GitHub - steve-aurifexlabs/mpw5: MPW5 - PSRAM interface with ACORN PRNG 66-67WVH16M8ALL-BLL.pdf Project Detail | Efabless Taylor's Bespoke Silicon Group at UW Project Detail | Efabless Project Detail | Efabless Project Detail | Efabless Project Detail | Efabless Project Detail | Efabless Project Detail | Efabless

On first sight, HyperRam seems like a potentially interesting option for us too, from my point of view. Any ideas pro/contra HyperRam?

@taylor-bsg Thanks! I talked to Derek a little last week and understood why it was organized like that. @Derek Hines-Mohrman So I did an in depth read of your circuitry this week, and everything panned out quite elegantly! I was wondering how you amplified the receiver side since SSTL 15 swings only +- 0.175 volts on the centered at 0.75V. If I'm understanding correctly, you're using 2x standard clock buffers to amplify that swing into rail to rail. The only concern I have is on PVT variations of those clock buffers (especially process), which could shift it off center and mess up the result amplification. Were there any simulations on that/measures deployed to calibrate? or we're hoping most of the chips should work 😅

oh nvm that's 11% swing, should be enough to withstand variations, if there was >11% probably should scrap the whole chip anyways

Hi Franklin, an SSTL receiver should use a differential comparator to a reference voltage. We did not implement that in this chip. However as you noticed the 1.8V cmos inverters are perhaps adequate in some situations…

@Derek Hines-Mohrman has left the channel

Hi everyone 👋