Hi <@U016EM8L91B> and <@U0175T39732>, sorry to kee...
# openramm
Matt Venn
10/19/2021, 3:06 PMHi @User and @User, sorry to keep asking the same question. I still can't get a clean run with openram. I'm using sky130_sram_1kbyte_1rw1r_32x256_8.gds which is found in /home/matt/work/asic-workshop/shuttle3-mpw-3//pdk/open_pdks/sources/sky130_sram_macros/sky130_sram_1kbyte_1rw1r_32x256_8/sky130_sram_1kbyte_1rw1r_32x256_8.gds
t
Tim Edwards
10/19/2021, 4:17 PMAs far as I can tell some bug got into the precheck system and it is now not recognizing the SRAM macro names anymore. Please issue a helpdesk ticket on efabless, or else raise an issue in the github issue tracker for efabless/precheck, if that repository is public.
Tim Edwards
10/19/2021, 4:18 PMFYI, I got a similar report yesterday and I alerted the people maintaining precheck (I think @omla is the main contact).
m
Matt Venn
10/19/2021, 4:44 PMI'm not at precheck stage yet
Matt Venn
10/19/2021, 4:44 PMThis is happening while trying to harden user project wrapper
d
Dinesh A
10/19/2021, 5:36 PMDuring hardening of user_project_wrapper with SRAM integrated, regular Magic Flow hangs with large DRC violation.
I have disabled Magic DRC using interactive.tcl flow. As per Tim Suggestion i am using pre-check to cross-check the DRC. With pre-check also i see around 51 DRC around the SRAM.
Not sure where to replace maglef for SRAM to avoid magic DRC violation around SRAM.
m
Matt Venn
10/21/2021, 8:29 AM@Tim Edwards @Matthew Guthaus still blocked on this. This isn't precheck, this is just make user_project_wrapper with the sky130_sram_1kbyte_1rw1r_32x256_8 ram instantiated inside. https://github.com/embelon/caravel_wb_openram
Matt Venn
10/21/2021, 8:30 AMany ideas/suggestions would be great
t
Tim Edwards
10/22/2021, 1:50 PM"Hangs" and "large DRC violation" are different things---it may take a long time to run, but if left to complete, even with the "(full)" DRC deck in magic, it should not take more than, say, an hour to run a complete check on the SRAM layout (plus whatever it takes to run DRC on the rest of the design). If it seems to really be hanging indeterminately, then that is likely something else and I may need a to look at the project myself and see if I can reproduce the problem. Probably what you want to do, though, is make sure that the version of the cell that is instantiated in magic is the "maglef" view. If the view in magic shows the SRAM down to the transistor level, then the easiest thing to do is to just edit the user project .mag file, find where the SRAM is instantiated, and change the path name from "/mag/" to "/maglef/" (there are ways to do this from the command line, but text editing the .mag file is easier and faster).
m
Matt Venn
10/22/2021, 1:56 PMit's not hanging, sorry if I wrote that
Matt Venn
10/22/2021, 1:58 PMI'm not sure what you mean about instantiating things in magic. I'm running make user_project_wrapper, and a couple of macros. One macro is the sram block and the other is a thin wishbone shim for the sram
Matt Venn
10/22/2021, 1:58 PMI thought that the flow was meant to recognise the sram block and then not run DRC on it
Matt Venn
10/22/2021, 1:58 PMbut that isn't work
Matt Venn
10/22/2021, 1:58 PMing
t
Tim Edwards
10/22/2021, 6:07 PMThe tape-in precheck is designed to recognize the SRAM and not run DRC on it. Locally, it would be necessary to know that the SRAM should only be instantiated by the abstract view. Extraction requires the full view; DRC requires the abstract view. GDS needs the abstract view; LVS can work with either. What I need is a better method in magic for switching between abstract and full views, since that's needed a lot.