https://open-source-silicon.dev logo
Join Slack
Powered by
<@U0175T39732>: What sort of automatic documentat...
# openram
t
@Matthew Guthaus: What sort of automatic documentation generation is OpenRAM currently capable of?
m
It generates a limited data sheet in html.
t
Yes, sorry to bother you with that. I found the HTML in the SRAM macro library repository, and don't know why I didn't see it before (I'm sure I've looked at it before, too, so I don't really have any excuse except to blame bad memory. . . wetware is so unreliable).
m
We still haven't updated better models yet so the data isn't very reliable
t
The reason that I wanted it is that we are trying to prepare a spec sheet for what we need in an SRAM. The existing values don't matter too much but at least give me something to fill in the blanks.
m
That would be useful, yeah.
t
Also: Can you share any SPICE testbenches you use to validate the SRAM? I have been checking extraction after making changes to parasitic capacitance extraction and fixes to the full R-C extraction; I can do a basic C-parasitic extraction in 1 hour on the 1kB SRAM, and I can do the full R-C extraction in 16 hours. I want to try running both through a transient simulation in Xyce and ngspice, but I need to make sure I'm setting up a useful test. It's easy enough to write one up, but if you already have one, that would be even easier.
m
Sorry for the delay. We have some unit tests that do these checks to determine if OpenRAM works, but they are just using spice netlist and not extracted due to run-time. If you generate the macros with characterization turned on, it will create the stimulus. @Bugra Onal has also been working on the stand-alone characterizer, but it needs a bit of hand-holding on the old memories since the hierarchy changed. Can you help him with the extraction and he can do some verification. This is actually his task right now.
We are also interested in extracting the OR1 test chip so we can run chip-level spice on the memory.
t
Do you have any "trivially simple" SRAM layouts and netlist that could be used to validate a simulation environment, something like a 4 bit x 4 word memory block? Yes, I can help @Bugra Onal with extraction. I just managed to do extraction of the 1k SRAM both for C-parasitics and also for R-C-parasitics. I wanted to see just how long they take to simulate. I just finished fixing a number of issues in magic related to full R-C extraction, and was pleased that although the extraction took 16 hours, it chugged through it at a steady rate and didn't cough up any error messages. (Although "chugged through it at a steady rate" means that there probably aren't any low-hanging fruit that could be plucked to speed it up considerably. Parallelization is a possibility, though).
Also: Have you run extracted SRAM blocks through ngspice or Xyce? I hit an error in ngspice with a subcircuit with (around) 12000 pins which overflowed a fixed array. I patched the ngspice code and am still going with that one. It has spent several days on the transient operating point and has not started the transient analysis yet. Meanwhile, I tried Xyce and I get obscure errors like 
Subcircuit SKY130_fd_PR__PFET_01V8 has not been defined for instance X0
and 
Duplicate device
(both of which must be false positives). I wasn't necessarily expecting simulation times to be reasonable, but I was looking for a baseline to determine if it's necessary to pare down the layout to make a simulation practical (the answer appears to be "yes", at least for ngspice).
m
We had not done much with extracted netlists, to be honest. I haven't gotten to your trivial example yet. Swamped... sorry.
@Bugra Onal can you provide a simple test case from one of the unit tests?
Or sky130_sram_tiny in the macros directory.
t
No problem. Mostly I wanted to make sure I wasn't wasting time treading ground that had already been covered.
b
Here is the tiny macro. This is a 8x16 1rw SRAM.
sky130_tiny.tar.gz
t
Thank you!
@Bugra Onal (@Matthew Guthaus): There's a testbench in 
sky130_tiny
called 
functional_stim.sp
. This file is full of PWL sources that must have been generated by a script. Is that script available?
m
@Tim Edwards we have it as a separate script in a branch but it hasn't been merged in yet. I lost track of that but bugra was working on that. Otherwise it's created when you run the complete compiler
t
Indeed, those exist in the sky130_sram_macros repository for each of the macros. I should have thought to look there!
FYI, I was tracking down an extraction issue and discovered that the cell 
sky130_fd_bd_sram__sram_sp_colenda
has a label 
vnb
that has been erroneously placed on layer 64:5 which is for n-well text, while the 
vnb
is placed in p-well. There is also a correct label 
vnb
on 64:59 (p-well/substrate text). The magic tech file assumes, based on the standard SkyWater rules, that any pin layer must be accompanied by the actual layer, and will drop the actual layer into the pin position automatically. So the 
vnb
pin ends up with n-well inside it when reading GDS from magic, and the n-well being incompatible with an nFET device, and with the pin in that cell slightly overlapping an nFET, part of the nFET gets chopped out. This is mainly an issue in magic due to the way the GDS read-in rules are constructed. But ultimately it is an error in the GDS (but not a mask data error, so non-fatal).
Open in Slack
PreviousNext
Powered by