<@U0175T39732> <@U016EM8L91B> Came in here to ask ...
# openram
o
@User @User Came in here to ask a couple of questions about future OpenRAM macros for sky130 but seeing the recent discussion it looks like I won't get the answers I was hoping for. Anyway, gotta ask. 1. Is there a single-port (preferably 8-bit) OpenRAM of any size for sky130 somewhere that can be used already now? 2. If not, are there any plans to add this in the near future? 3. If not, is there a reasonable chance I can just create my own python config and generate my own working IP with OpenRAM?
m
1. We taped one out on mpw2/3. 2. Yes. 3. Yes!
o
Fantastic! What do you think? Should I use the existing one you used for MPW2/3 (if so, where can I find it?), wait for one to appear in the PDK or just go YOLO and generate a new one right away? If you think there's a reasonable chance of success with the third option I'm leaning towards giving that a shot, because I guess that's where we really want to end up eventually.
t
Hey @User, try running OpenRAM. Even I was able to do it. Don't forget to run make install. You can generate 1w1r SRAMs, not sure about 1wr SRAMs.
m
@User they are in the dev branch of the macro repo. I'd probably suggest waiting as we are doing some fixes right now and the ones in dev haven't been silicon verified yet
o
Hi @User. Specifically interested in 1rw. End goal is to squeeze as many SERV cores as possible into the user area and IIUC, the single-port RAM are noticably smaller. How mush smaller @User? ~70% or so of a dual-port?
🌎 1
@User Hoping to do something for MPW5. I guess we won't have MPW2 results back by then so what do you suggest for this tapeout?
m
@User You could use a dev version of the memory...
o
@User Got it. This one https://github.com/efabless/sky130_sram_macros/tree/dev/sky130_sram_1kbyte_1rw_32x256_8 seems like what I'm looking for. I'll go with that
@User I notice that ADDR_WIDTH is set to 9 in the verilog model of the sky130_sram_1kbyte_1rw_32x256_8 I'm intending to use. Shouldn't that be 8 for 256 words? Also, are there any versions without the 33rd (parity?) data bit? No biggie, but won't be hooking it up so it will just be a bit extra area in my case
m
No, there neeeds to be an even number of columns and we use a replica column. So that is the pair for the replica column to make an even number. You can not use it.
o
The 33rd bit, you mean? I set spare_wen0 to 1'b0
m
Yes, there needs to be an even number of columns so technically there are 34 bits. One is the replica bit, 32 are the data bits, and the extra spare bit.
The replica is used for self-timing
o
Got it. What about the address width?
m
There also needs to be an even number of rows...
For the same reason.
o
This I don't understand
m
It is due to a lithography constraint in the bitcells
They can't print an odd number of rows
Or rather, the odd row won't print
o
So how many rows are there in the 256x32 RAM?
(32x256)
m
I'd have to look and see what the column mux size is
o
As a user, you can only access 256 addresses, right?
m
257 actually. They could use the spare row or column.
The spare column is shared among all words in a row though.
o
Is that a spare in case of silicon defects?
m
That was originally the idea, but it is used in this case to balance the replica row for lithography.
We did a hack to use that feature to force there to be an even number of rows/columns
In the 32x256 SRAM, there is a column mux of 4. That means there are actually 4*32+1 columns
o
Ok, but if I intend to use address 257, I would need some logic to handle that, right? And if I'm not going to implement that logic and just treat it as a 256x32 RAM then I can keep MSB of addr0 stuck at 0 ?
m
Address 257 would be the spare, but 258 would be nothing
Yes the MSB of addr0 should be 0
o
I do feel bad about letting 256+32 bits of memory go to waste. It would be enough to store the entire state of two SERV cores, but I'll live with it
m
You would need to get Skywater to create a new bitcell for us to change this
o
I'll get to that as soon as I have cleared my back log πŸ™‚
m
We are working on an SRAM control logic variant that uses a non-self timing technique that will avoid this issue, but it will be more sensitive to process variation
We hope to test that out on MPW5
o
Cool. Need a small RISC-V core to go with that? πŸ™‚
Hooks straight up to an OpenRAM RW port
Very cheap
m
We have a test setup for 3 test modes... serial scan, parallel port, and wishbone...
o
All three in use at the same time or just alternatives?
m
alternatives
o
oh, another thing. I'm terrible with GDS and layout viewers. What would be the easiest way to see on which sides the different pins are located on an OpenRAM instance? I want to squeeze my SERV really tight onto the OpenRAM instance
🌏 1
I tried hiding and showing each individual layer in klayout but ended up none the wiser
m
addr0 is on the left, data0 is on the bottom, addr1 is on the right, data1 is on the top, in general. Though with a 4 way column mux, the top 2 addr0 bits are on the bottom
control logic bits will be on the lower left or upper right
for the two ports
o
So, for a single port would all pins be bottom left?
m
addr0 bits would be on the left except for the 2 most significant on the bottom for this particular memory
data0 is on the bottom
control bits are on the lower left
o
Great. Then should make things easier
btw, how does the test modes work, especially the serial one? Do they contain any self test logic or purely for reading/writing RAM data? Do they go through the caravel wb/la ports or directly to external I/O? I've been thinking of doing some kind of serial access when I add many SERV cores, so thinking yours is perhaps something I can reuse
🌍 1