https://open-source-silicon.dev
Join Slack
<@U0175T39732>: There is an issue that has come up with SkyWater, where they are missing rules for ...
# openram
t
@User: There is an issue that has come up with SkyWater, where they are missing rules for NSDM and PSDM basic width and spacing in the "manufacturing rules" deck. That means that such rules have not been checked, even in our Calibre checks. The SRAM designs have a number of such errors, in the corners. These errors appear to be caused by forcing magic not to run hierarchical generation of GDS. If you subvert the hierarchical GDS generation, then you need to make sure that such errors are not generated by the automated layout. In the screenshot below, you can see that the errors are caused by the tap stubs that are placed as branches off of the power or ground supply line. If the tap shapes were extended further away from the supply line, these errors should not occur. I expect that the length of those branches is just a variable in OpenRAM, and one change would correct all of these errors.
m
I see. Is this an issue on the current MPW2/3 and needs to be redone?
If so, that's going to be a pain.
t
Yes, unfortunately. I'm not sure how easy it will be to patch it up manually. It depends on just how many such errors there are. Mostly it involves just detecting the errors and adding some extra NSDM or PSDM at the corners to meet the width or spacing rule. I have updated the SkyWater manufacturing rule deck so that it will now detect those errors, and we will get the klayout DRC deck updated soon, so hopefully within the day we can get you a dump of the errors. I got the new deck to @User , who should be able to run a quick test and then get it installed on the system to run during precheck.
m
well, fuck.
I'm booked for the next 2 weeks, to be honest.
This will change pin placements and will require a rerun of P&R
t
Then patching up the errors is probably the best option for quick turnaround.
m
We already did a bunch of patches too which aren't put back in openram
That is on our MPW5 list of tasks
Where are these new rules at?
If we just move them into the cell further like you say, will that cause a spacing issue?
How did these pass on the OR1 tape out?
This seems like a fundamental change.
t
Whoa, rapid-fire questions. . . (1) We used an older version SRAM for the 1st tapeout. Apparently those errors just didn't exist? Depending on the arrangement of blocks, it might be that there wasn't any of the catecorner placement of cells on that one. (2) The new MR deck currently just needs to be transferred to our server and tested. I just took the manufacturing rule deck and spliced the extra rules into it from the full Calibre deck. (3) I think that moving the taps away from the power line will add enough space between them that they will all have sufficient space between them not to have the catecorner issues.
Also I think that if you just write GDS without doing 
cif *hier write disable
, the errors will be taken care of automatically. The problem with that is that the GDS write then takes ages, because the hierarchical checks are very inefficient when used with large, tightly-spaced arrays like the SRAM core. If it only needs to be done once, though, then the long run-time might be the easier solution.
Possibly if you use 
cif *array write disable
but not 
cif *hier write disable
, then the arrays will be ignored and the overall GDS write time might be about the same.
m
where in the SRAM is that screenshot from?
and which SRAM?
It may only happen in some of the new larger sizes
I don't write GDS from magic at all... so those options are not relevant.
t
Screenshot is from the 2kbyte SRAM, position isi around (650um, 364um)
m
ah, yes, this is just some of the drivers for the control logic which are sized differently and therefore cause those catecorner issues.
t
Yes, I don't think there are very many errors, but we need to run it through Calibre and get a count.
m
@User we might have a few more hand fixes to do on MPW2/3
we will need to get these checks in klayout too, we have been using that more than magic to edit the layout
but if they are standard spacing/width it shouldn't be hard to do
t
Because those rules were missing from the manufacturing rule deck, they weren't caught until SkyWater ran a full deck after compiling the reticle and running full DRC on everything. Fortunately since we've restricted everyone to using the three or four macros in the library, mostly we just need corrected GDS for those and substitute the SRAM cells in every design.
@User: I upadted the klayout MR rule deck in open_pdks to include nsd.1, nsd.2, psd.1, and psd.2 rules. Those were trivial to implement. I didn't add nwell.6, which is a bit more complicated and I'm not sure of the klayout syntax. See open_pdks on opencircuitdesign.com, commit ID 
2a198f76a873c7c7787cfdbb50fecce4cb23adf91
.
👍 1
@User: We're running DRC on the Calibre deck now, and should be able to get you an error report soon. Just eyeballing the 2kbyte SRAM, it looks like maybe fewer than ten errors total, so it may be fairly easy to hand-correct them all. I don't know what needs to be done in your test SRAM submissions, but for everybody else's projects and caravel/caravan itself, we just need the ones from the SRAM macro repository corrected.
@User: Calibre results are 7 errors total NSDM and PSDM, and the nwell overlap of dnwell counts as 1 error. The new klayout deck catches the same 7 errors (the dnwell rule has not yet been implemented in the klayout deck).
👍 1
m
Ok, we will do some hand edits on those then.
t
Big bonus points if you can resolve the DRC errors with only changes to the implant and well layers.
2 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by