<@U0175T39732> I was looking at the `sky130_sram_1...
# openram
m
@User I was looking at the
sky130_sram_1kbyte_1rw1r_32x256_8
layout and noticed that some of the large decoder inverters had transistors with only 1
licon
each on the source and drain. I'm thinking that that won't provide the drivability of the spice simulation. @User Do you know of a DRC rule that checks
licon
density inside diffusion?
m
These are definitely suboptimal and need to be improved. First, they are just too big. Second, the connection can be improved as you mention. It's on the list and we would welcome a PR.
t
@User: I'm not sure what you mean by the "drivability of the spice simulation". Only if you do a full R-C extraction would you see the effect of the approximately 170 ohm resistance of the contact stack. That's big, but it won't stop an inverter from working.
m
To be honest, I haven't done much simulation. My thinking is that basic spice simulation assumes that the diffusion is uniformly connected to low resistance metal. In this case, there is only one contact in the center of the diffusion. If the diffusion is coated with a low-resistance silicide, then maybe it's not that big of an issue. Otherwise, I'm not seeing the benefit (drivability - output strength) of having such a wide transistor because the current through the gate would be concentrated near the region of the contacts.
t
That's what full R-C extraction is for, but then that shows a fundamental issue with things like the SRAM circuit, which is so big that a full R-C extracted SPICE simulation is going to bog down the simulator completely (I tried this with the Caravel management SoC---it didn't go well. After a week, ngspice was still processing the input). The best bet for something like the SRAM block would be to treat it like a standard cell design, run full R-C extraction on single cells like the inverter, simulate the timing on each block, convert the netlist and timing into a liberty file, and then run it through a verilog simulator with annotated delays.
f
@User I don't think even full R-C extraction extract the R effect of the active and current crowding which would become important when not having enough contacts for a big w transistor. At least I have not seen such decks; what I have seen is rules telling the longest source/drain 'length' without a contact.
t
@User: Ideally you just use device generators that always contact the source and drain all the way across. OpenRAM uses its own device generators, though, so it would need to be addressed there.