Hi guys - wanted to quickly check on the state of pre-check DRC runs, re: SRAMs. Understand this has been actively evolving - appreciate the work on it. My impression of the intent is that the pre-check DRC runs will abstract-out the OpenRam SRAMs, at least until final clean versions are ready. Is that still correct? And if so - should this abstract’ing should now be up and running? As of yesterday and today’s runs, much of our pre-check DRC report appears to come from within the SRAM boundaries, so it doesn’t seem to be meeting that (presumed) intent.

There seems to be a bug in TritonRoute that it routes too close to the SRAM blockages. Specifically, it violates the wide metal spacing rules (e.g. 4.5b) that interpret the blockage as a wide metal. I've also learned that this happens with commercial routers, so maybe it is actually an issue with the tech lef not specifying these rules to the router? @Manar Abdelatty

I'm pretty sure that the tech lef does specify the wide spacing rules.

Ok, then Innovus and TritonRoute just ignore it.

FWIW, while we have encountered and worked around (what I believe are) the wide-metal/router deficiencies you’re referring to, I am asking about DRC results inside the SRAM cell boundaries. Does eFabless expect the pre-checks should be filtering these out at this point?

I believe people have been hacking the flow to use the LEF view...

@Matthew Guthaus precheck does abstract the sram blocks. we are also seeing spacing violations on projects with SRAM blocks due to routing near blockages in the lef views.

OK interesting. Perhaps you are right and that applies to our block as well, and the violations are just outside the SRAM blocks instead.

We have been reading the project GDS and the error database into klayout, which allows us to see the errors but then doesn't show the abstract view, so it's hard to tell where the errors are relative to which abstracted cell. We didn't see any obvious real errors, but that's expected, as we were only spot-checking. That can't guarantee that there aren't real errors somewhere.