How should we deal with DRC errors due to core mem...
# shuttlem
Matthew Guthaus
05/28/2021, 7:18 PMHow should we deal with DRC errors due to core memory rules? Right now, the sky130 tech doesn't support these (and there's no plan to support them). Should there be an option to over-ride and use the LEF for memory macros?
t
Tim Edwards
05/28/2021, 7:52 PMYes, exactly. I suggested that to Jeff, and we will implement this for precheck. The way it works is that you can pre-load the abstract view of the core cells, then read GDS with the "gds noduplicates true" option set, so that if those cells are found in the GDS, then the abstract view will take precedence, and the layout should be able to pass DRC. With the caveat that the method does not have any kind of version control checking, which I need to think about for the long term.
m
Matthew Guthaus
05/28/2021, 7:58 PMWould this just be the core cells or the whole memory macro?
Matthew Guthaus
05/28/2021, 7:58 PMWe have the core cells which is how we do checking now.
m
Matt Venn
05/28/2021, 8:22 PMIt will be great to have a working config we can use as a reference. 👍
m
Matthew Guthaus
05/28/2021, 9:48 PMI updated openram_test_project so that it works through DRC/LVS now
t
Tim Edwards
05/28/2021, 9:49 PMIt's clean with just the core cells abstracted?
m
Matthew Guthaus
05/28/2021, 9:50 PMThere are occasional supply errors (<10) due to the supply router. But I think my recent update gets rid of most of those
Matthew Guthaus
05/28/2021, 9:50 PMRight now, I'm planning to hand fix those
Matthew Guthaus
05/28/2021, 9:50 PMIt's dealing with off-grid pins
Matthew Guthaus
05/30/2021, 4:34 PM@jeffdi How can we do sign-off with these? Can we do something like what Tim says? Or use the entire memory LEF?
t
Tim Edwards
05/30/2021, 5:17 PMThis needs to be taken care of on our end (efabless) so that is handled automatically on pre-check. We are working on the issue and I hope should have it done in a few days.
m
Matthew Guthaus
05/30/2021, 11:50 PMManually doing this using the SRAM LEF files seems to work ok. I get a few errors of wires being routed too close to the SRAM macro blockages through. Not sure why TritonRoute is doing that.
Copy code
Metal2 > 3um spacing to unrelated m2 < 0.28um (met2.3b)
Metal1 > 3um spacing to unrelated m1 < 0.28um (met1.3b)Matthew Guthaus
05/30/2021, 11:51 PM@Tim Edwards If you want to use the memory cell LEF files (or maglef), you will need to pull them from the sky130_fd_bd_sram build space.
t
Tim Edwards
05/31/2021, 12:08 AMYou mean they should be copied from
sky130_fd_bd_sramsky130_sram_macrosTim Edwards
05/31/2021, 12:13 AMI don't know the general convention on obstruction layers. Since an obstruction hides all details, then maybe the convention is to only route minimum spacing to an obstruction, and if there is any large metal where the obstruction is, then the obstruction should be expanded outward by the difference in the spacing rule to compensate (this is something that just occurred to me, and makes sense, but I still have no idea if this is the convention or not). In that case, I could revise the "lef write" routine to (with an optional argument) make that extra expansion of obstruction around large metal areas, and then modify the metal-to-obstruction DRC rule to only check for minimum spacing. It's either do something like that, or convince the OpenROAD team that TritonRoute's behavior is an error and needs to be fixed.
m
Matthew Guthaus
05/31/2021, 2:03 AMI'm actually not using lef write. It was easier for me to create my own. I just block the entire area and carve out the pins. I think the router actually ignored the blockage because met1 and met2 should be completely blocked and there is nothing near the perimeter due to the m4/m5 power rings.
Regarding the maglef or lef files, I have just the memory cells (maglef) in sky130_fd_bd_sram or the full memories (lef) in sky130_sram_macros.
t
Tim Edwards
05/31/2021, 2:52 PMOh, okay, I see.
2 Views