What sort of automatic documentation gene

Question

< Matthew Guthaus> What sort of automatic documentation generation is OpenRAM currently capable of

Matthew Guthaus · Answer

It generates a limited data sheet in html

Tim Edwards · Answer

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

Matthew Guthaus · Answer

We still haven t updated better models yet so the data isn t very reliable

Tim Edwards · Answer

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

Matthew Guthaus · Answer

That would be useful yeah

Tim Edwards · Answer

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

Matthew Guthaus · Answer

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

Matthew Guthaus · Answer

We are also interested in extracting the OR1 test chip so we can run chip level spice on the memory

Tim Edwards · Answer

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

Tim Edwards · Answer

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

Matthew Guthaus · Answer

We had not done much with extracted netlists to be honest I haven t gotten to your trivial example yet Swamped sorry

Matthew Guthaus · Answer

< Bugra Onal> can you provide a simple test case from one of the unit tests

Matthew Guthaus · Answer

Or sky130 sram tiny in the macros directory

Tim Edwards · Answer

No problem Mostly I wanted to make sure I wasn t wasting time treading ground that had already been covered

Bugra Onal · Answer

Here is the tiny macro This is a 8x16 1rw SRAM

Tim Edwards · Answer

Thank you

Tim Edwards · Answer

< 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

Matthew Guthaus · Answer

< 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

Tim Edwards · Answer

Indeed those exist in the sky130 sram macros repository for each of the macros I should have thought to look there

Tim Edwards · Answer

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