I have integrated 2KB SRAM hardmacro available from PDK path : sky130A/libs.ref/sky130_sram_macros. I see high number of DRC violation reported by magic tool with "Local interconnect spacing < 0.17um (li.3)" Any suggestion on how to manage this ?

maybe ask in the #openram channel?

@Dinesh A: Magic does not implement the SRAM-specific DRC rules (which are many). The solution is to keep the SRAM as an abstract view by loading from the sky130_sram_macros/maglef/ directory. There are commands in magic to swap out the full view for the abstract view using "cellname filepath" and "flush", but the easiest way is just to find the SRAM entry in the .mag file of the top level cell and change "mag" to "maglef" in the path name.

@Tim Edwards In the .mag files under /mag folder I see only module + instance definition and i don't see any file path definition use wb_host u_wb_host timestamp 1634135732 transform 1 0 60000 0 1 60000 box -800 -800 98808 40800 use uart_i2c_usb_spi_top u_uart_i2c_usb_spi timestamp 1634135732 transform 1 0 200000 0 1 540000 box 14 -800 118864 137680 use sky130_sram_2kbyte_1rw1r_32x512_8 u_sram_2kb timestamp 1634135732 transform 1 0 440000 0 1 240000 box 0 0 136620 83308 use scr1_top_wb u_riscv_top timestamp 1634135732 transform 1 0 60000 0 1 160000 box -800 -800 320800 240800 use qspim_top u_qspi_master timestamp 1634135732 transform 1 0 60000 0 1 540000 box -800 -800 80800 127344 use pinmux u_pinmux timestamp 1634135732 transform 1 0 440000 0 1 60000 box -800 -800 100800 100800 use wb_interconnect u_intercon timestamp 1634135732 transform 1 0 60000 0 1 460000 box 105 -800 440800 30800 use sar_adc u_adc timestamp 1634135732 transform 1 0 400000 0 1 520000 box 106 0 98808 60000

@Dinesh A: Sorry, I wasn't thinking that

use

statement would assume a default and not add a path. There is a syntax option that is newer than the man page document which is "*use* _filename use-id path_". The statement should look like this:

use sky130_sram_2kbyte_1rw1r_32x512_8 u_sram_2kb $PDKPATH/libs.ref/sky130_sram_macros/maglef

Tried to point to maglef directory, then found out that $PDKPATH/libs.ref/sky130_sram_macros/maglef is empty. Is there anything obvious I'm missing?

You're probably missing the installation of the SRAM macros in open_pdks, which might be at the root of the problem. The SRAM macro installation has to be called out when doing "configure" because it takes a really long time to install, and so I try to avoid that unless someone specifically needs to use the SRAM macros.

@Tim Edwards Is this correct Step 1. In user_project_wrapper.mag replace the SRAM entry use sky130_sram_2kbyte_1rw1r_32x512_8  u_sram_2kb with

use sky130_sram_2kbyte_1rw1r_32x512_8 u_sram_2kb $PDKPATH/libs.ref/sky130_sram_macros/maglef

2. Load the modified user_project_wrapper.mag file into magic. 3. Write out user_project_wrapper.gds and use this gds for precheck ?

@Tim Edwards I tried to "*export INSTALL_SRAM = enabled*" before make pdk - no macros for sram, I even tried to go manually go step by step through recipe for build-pdk in openlane Makefile, calling "*./configure --enable-sky130-pdk=$(PDK_ROOT)/skywater-pdk/libraries --enable-sram-sky130=$(INSTALL_SRAM)*", but I got (under libs.ref/sky130_sram_macros/gds/sources.txt) file with this one line ".../*mpw3a/pdk/open_pdks/scripts/enabled/../sky130_sram_macros/*/*.gds*".

@Paweł Sitarz: I do not know now the

make pdk

is set up in openlane. I always just build open_pdks independently. From the above, I'm not sure what you're doing with

INSTALL_SRAM

. As an argument to

--enable-sram-sky130

, it should be the path to the SRAM macro library git repository, or if you have not cloned the SRAM macro library already, you can just use

--enable-sram-sky130

without any

=

argument, and open_pdks will clone it for you.

@Tim Edwards Thanks! You're right, it's weird that INSTALL_SRAM is set by default to "disabled" in openlane Makefile and then provided to open_pdks make where path should be... What's more interesting, when I did set INSTALL_SRAM to "yes" 10 minutes ago then I was able to finally get gds, lef, maglef and more file inside sram_macros.

@Paweł Sitarz: Sorry, I guess it should be expected that "enabled" is the opposite of "disabled". The workings of Makefiles are sometimes incomprehensible to me, too.

@Tim Edwards Np, I should have look through Slack history earlier and then spent less time trying to solve it on my own. That's a lesson on its own and on the other hand - I had a chance to learn more while tracking Makefiles chain :)

@Paweł Sitarz I did following changes in openlane makefile to install the SRAM in libref area -INSTALL_SRAM ?= disabled +INSTALL_SRAM ?= $PDK_ROOT/open_pdks/sources/sky130_sram_macros Then Run the make pdk command This will install the SRAM under $PDK_ROOT/sky130A/libs.ref/sky130_sram_macros/

@Dinesh A Thank you! I noticed that if you do "export INSTALL_SRAM = yes" then SRAM be also installed under the same path you mentioned. It took only something like 10 minutes, which surprised me, as I was expecting hours on my machine... BTW, Have you been able to get precheck with 0 violations? I'm asking because last night I went from 3M+ violations down to 16 violations.

@Paweł Sitarz For me also local pre-check still showing 25+ violation around the SRAM .. Expect Efabless team to suggest how to manage it .. But the Efabless website Site Pre-check Magic DRC fails with exception .. waiting for efabless team to close the issue

@Dinesh A: The problem appears to be that the PDK isntallation on the platform is missing the SRAM macro library, so it is unable to find the abstract view to use in the DRC. They should be able to get this fixed quickly now that the issue has been identified.

@Tim Edwards If I installed succesfuly sram macros on my machine, should I still get violations in sram precheck (after maglef substitution)? Is there anything I can do besides waiting for a fix in PDK installation? Is there a way to fix 3M+ DRC violations seen during hardening user_project_wrapper (probably by doing maglef substitution before magic DRC check) by altering scripts / Makefiles? - is that a good idea?

It's not clear to me how all the environments are set up, or even what exactly the issue is; aparently there are projects that use SRAM and pass precheck, and yours apparently still faults when the platform precheck is updated to install the SRAM macro library. If you run DRC locally, you would need to make sure you use the abstract view of the SRAM macro in your design. The precheck is supposed to make the substitution automatically based on the cell name. But this problem is actively being worked on. Don't get too much angst over it. We have about ten projects that have issues that are preventing tapeout from completing, and we will make sure all of those are resolved and make it to tapeout.

@Tim Edwards Thank you! I'm a newbie here and just trying to understand things, maybe asking too much questions

I tested @Paweł Sitarz caravel repo to find out about the local precheck DRC errors after maglef substitution. It seems that all the 16 errors, all of type

Metal4 > 3um spacing to unrelated m4 < 0.4um (met4.5b)

are caused by the project connections to the sram pins being too close to an

obsm4

layer in the maglef. But those errors don't happen when using the gds, as there is no metal4 that close to the pins on the sram. It would be safe to assume that those wont be real drc errors?

@Maximo Balestrini: It is likely that they are not real errors, but passing precheck will require that they are resolved anyway. This is easier than finding out that it actually is an error by getting it kicked back from SkyWater.

@Tim Edwards Could it be caused by offsetting placement of macro in this way: "wb_openram_wrapper 2000.07 1000.27 N"? We needed to add offset (0.07, 0.27) to get hardening done, otherwise it was failing with 7 or 8 violations.

@Paweł Sitarz probably

I removed this offset and so far so good... hardening finished with 0 violations, but still DRC reports 3M+ violations. I'll run precheck in few minutes to see if this is the case. On the other hand - I'm wondering what was changed so I don't need to offset placement by (0.07, 0.27) anymore. I installed pdk few times from scratch (to get sram macros), but haven't noticed changes/fixes.

@Paweł Sitarz Where you are adding obstruction on met4 around sram macro to resolve precheck DRC issue ? Is this just local pre-check fix OR works in efabless website pre-checks also ?

I haven't tried efabless website precheck yet, but for local precheck it resolved all 16 violations

Do you mean local pre-check passed with adding set ::env(GLB_RT_OBS) on met4 around SRAM in user_project_wrapper config.tcl ?

@Dinesh A: Is that method documented somewhere?

I doubt it, we are working this out very slowly

I don't know what these environment variables do, but I don't understand why the tools don't just see the obstructions placed in the LEF view of the macro and route around them with sufficient clearance. Something is not being handled right, and I don't know which tool is at fault.

GLB_RT_OBS just lets you define a box on a given layer where the router isn't allowed to use any routing

@Dinesh A You were right, I added only met4 obstruction around sram. Good to hear you were able to pass online precheck. Did you need to add obstruction on met1/2/3 to pass precheck? Wasn't met4 obstruction enough for you?

@Paweł Sitarz for me i had failure in Met2/Met3 around SRAM. I have used same SRAM instantiated in two different project and each are showing different number of failures, Both local/remote precheck passed in both the project after adding blockage around MET1/MET2/MET3 .. I have not added any Blockage in MET4. Thanks for your input

Hmm, so violations are showing on random layer(s).

@Tim Edwards I see similar MAGIC DRC failure with LEF/DEF based flow with pure digital logic using caravel_user_project .. Same one works with GDS flow.

---------------------------------------

Magic DRC Summary:
Violation Message "Metal2 > 3um spacing to unrelated m2 < 0.28um (met2.3b) "found 74 Times.
Total Magic DRC violations is 74
----------------------------------------

I have raised the issue tracking with example at https://github.com/The-OpenROAD-Project/OpenLane/issues/695 @Paweł Sitarz When I move the SRAM Macro location, I see once again Magic DRC failure which does not even fixes with Blockage around SRAM .. Did to you had change to move the SRAM offset location and check pre-check DRC

@Dinesh A No, I wasn't trying to move macro. I'll try today

@Paweł Sitarz I have made mistake in blockage offset computation after SRAM movement .. After correction Magic DRC is clean .. Sorry for the confusion ..

@Dinesh A NP. Good to know.

I got Magic DRC errors in pre-check I simply add GRT_OBS for 2 2K OpenRAM macros for li, metal1/2/3 for the area of RAMs Still got the error for met3 and met4 I will add met4 also for OBS but why am I getting met3 error ? macro cfg axi_interconnect_i 300 150 Ncore_region_i 240 1000 Nperipherals_i 2050 1200 Ninstr_ram 170 2960 Ndata_ram 1030 2960 N config tcl GRT_OBS set ::env(GRT_OBS) "\ li1 170 2960 853.1 3376.54,\ met1 170 2960 853.1 3376.54,\ met2 170 2960 853.1 3376.54,\ met3 170 2960 853.1 3376.54,\ li1 1030 2960 1713.1 3376.54,\ met1 1030 2960 1713.1 3376.54,\ met2 1030 2960 1713.1 3376.54,\ met3 1030 2960 1713.1 3376.54,\ met5 0 0 2920 3520" repo link: https://github.com/mbaykenar/mpw7_yonga_soc

The coordinates are no use without seeing your layout or where the problems actually are

image.png

Can you do an image with more context? Is this close or inside a macro? Next to sram?

these are the connection points to OpenRAM macros

This is exactly what i had

let me check: this is the macro.cfg: instr_ram 240 2950 N data_ram 1100 2950 N config.tcl set ::env(GRT_OBS) "\ li1 240 2950 923.1 3366.54,\ met1 240 2950 923.1 3366.54,\ met2 240 2950 923.1 3366.54,\ met3 240 2950 923.1 3366.54,\ met4 240 2950 923.1 3366.54,\ li1 1100 2950 1783.1 3366.54,\ met1 1100 2950 1783.1 3366.54,\ met2 1100 2950 1783.1 3366.54,\ met3 1100 2950 1783.1 3366.54,\ met4 1100 2950 1783.1 3366.54,\ met5 0 0 2920 3520" openram lef: MACRO sky130_sram_2kbyte_1rw1r_32x512_8 CLASS BLOCK ; SIZE 683.1 BY 416.54 ;

I'm stumped, sorry . Looks totally fine to me.

yes, only violation positions are at the edges of 2 openrams, stange thing, when I change the position and rerun error numbers change I will go with ram channel thanks

My project have met same failure. I generated my SRAM from OpenRAM, and it failed at DRC with

Local interconnect spacing < 0.17um (li.3)

when harden the top wrapper. I have add

GLB_RT_OBS

, but it seems not working. Precheck also failed at Check 8 Klayout FEOL

@Ruige Lee: I think you have a different issue. If you generated SRAM using OpenRAM instead of using the pre-built SRAM macros from the SRAM macro library, then you will run into the problem that magic does not implement the SRAM rule exceptions (there are many), and so these are handled in the Caravel pre-check by detecting the use of one of these macros in the design, and subsituting an abstract view of the SRAM so that it will pass DRC in magic. If you have your own SRAM build from OpenRAM and it doesn't match the name of the one of the pre-built macros, then DRC will be run directly on the SRAM layout, and you will get millions of errors reported. A DRC failure in magic is advisory for the precheck, not mandatory, and will not cause a failure of submission for tapeout. However, if you want to check DRC yourself and make sure that SRAM errors are not hiding other real errors, then you should create a LEF view of the SRAM macro and use that abstract view in magic when running DRC, which is how the precheck works with the pre-built SRAM macros.

@Tim Edwards Thanks for replying. But I did fail at precheck and can not submit for MPW-7 tapeout, looks like it causes a mandatory failure? --------------------- How can I hack into the flow and use the

abstract view of SRAM

to pass the DRC and pre-check, is there any tutorial that I can follow? --------------------- By the way, can we have more different types and different sizes of

pre-built SRAM macros

, like single port, two port, dual port, small SRAM for L1, large SRAM for L2 and so on?

@Ruige Lee: Are you sure that it was the DRC check that caused the actual submission failure? I'm not sure if there is a way to work around the issue; the cell name exceptions are the four cell names in the pre-built SRAM library. You can ask Jeff DiCorpo to bypass the precheck, but we'll need to make sure that the SRAM is the one and only cause of failure. There should be ways to generalize the replacement of abstractions, because we need to support users who spin their own SRAMs, but we don't have such a method in place at the moment. If you want different sizes and configurations of SRAM, you would need to contact Matt Guthaus. But we have been trying to get more configurations out of him and his team. I would prefer that users be able to spin their own.

the DRC failure from Klayout, not magic

[09/13/22 05:49:33 PDT] FAILURE
2 Check(s) Failed: ['Klayout FEOL', 'Klayout BEOL'] !!!






[09/13/22 05:49:33 PDT] FAILED
STDOUT: Loading Job # de2424ad-7615-4aa0-8973-b9a418b27696 ...
STDOUT: Open Source Shuttle MPW Precheck | Starting Job # de2424ad-7615-4aa0-8973-b9a418b27696 ...
STDOUT: {{Project Git Info}} Repository: <https://github.com/whutddk/Rift2Go_2301.git> | Branch: main | Commit: 374ce85ba02ea8b38484aa30f9f224ecba9d094f
STDOUT: {{EXTRACTING FILES}} Extracting compressed files in: rift2core_2301
STDOUT: {{Project Type Info}} digital
STDOUT: {{Project GDS Info}} user_project_wrapper: e5273b31757f88ee258567e9cd92b468fd666597
STDOUT: {{Tools Info}} KLayout: v0.27.10 | Magic: v8.3.315
STDOUT: {{PDKs Info}} PDK: sky130B | Open PDKs: 05af1d05227419f0955cd98610351f4680575b95 | Skywater PDK: c094b6e83a4f9298e47f696ec5a7fd53535ec5eb
STDOUT: {{START}} Precheck Started, the full log 'precheck.log' will be located in 'rift2core_2301/jobs/mpw_precheck/de2424ad-7615-4aa0-8973-b9a418b27696/logs'
STDOUT: {{PRECHECK SEQUENCE}} Precheck will run the following checks: [License, Makefile, Default, Documentation, Consistency, XOR, Magic DRC, Klayout FEOL, Klayout BEOL, Klayout Offgrid, Klayout Metal Minimum Clear Area Density, Klayout Pin Label Purposes Overlapping Drawing, Klayout ZeroArea]
STDOUT: {{STEP UPDATE}} Executing Check 1 of 13: License
STDOUT: An approved LICENSE (Apache-2.0) was found in rift2core_2301.
STDOUT: {{MAIN LICENSE CHECK PASSED}} An approved LICENSE was found in project root.
STDOUT: An approved LICENSE (Apache-2.0) was found in rift2core_2301.
STDOUT: {{SUBMODULES LICENSE CHECK PASSED}} No prohibited LICENSE file(s) was found in project submodules
STDOUT: {{SPDX COMPLIANCE CHECK FAILED}} Found 130 non-compliant file(s) with the SPDX Standard.
STDOUT: SPDX COMPLIANCE: NON-COMPLIANT FILE(S) PREVIEW: ['rift2core_2301/Makefile', 'rift2core_2301/customRAM/.magicrc', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/.magicrc', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/functional_stim.sp', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/run_drc.sh', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/run_ext.sh', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/run_lvs.sh', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/setup.tcl', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/sky130_sram_1rw_128x16.html', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/sky130_sram_1rw_128x16.lvs.sp', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/sky130_sram_1rw_128x16.py', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/sky130_sram_1rw_128x16.sp', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/sky130_sram_1rw_128x16.v', 'rift2core_2301/customRAM/sky130_sram_1rw_128x16/sky130_sram_1rw_128x16_TT_1p8V_25C.lib', 'rift2core_2301/customRAM/sky130_sram_1rw_24x16/.magicrc']
STDOUT: For the full SPDX compliance report check: rift2core_2301/jobs/mpw_precheck/de2424ad-7615-4aa0-8973-b9a418b27696/logs/spdx_compliance_report.log
STDOUT: {{STEP UPDATE}} Executing Check 2 of 13: Makefile
STDOUT: {{MAKEFILE CHECK PASSED}} Makefile valid.
STDOUT: {{STEP UPDATE}} Executing Check 3 of 13: Default
STDOUT: {{README DEFAULT CHECK PASSED}} Project 'README.md' was modified and is not identical to the default 'README.md'
STDOUT: {{CONTENT DEFAULT CHECK PASSED}} Project 'gds' was modified and is not identical to the default 'gds'
STDOUT: {{STEP UPDATE}} Executing Check 4 of 13: Documentation
STDOUT: {{DOCUMENTATION CHECK PASSED}} Project documentation is appropriate.
STDOUT: {{STEP UPDATE}} Executing Check 5 of 13: Consistency
STDOUT: HIERARCHY CHECK PASSED: Module user_project_wrapper is instantiated in caravel.
STDOUT: COMPLEXITY CHECK PASSED: Netlist caravel contains at least 8 instances (90 instances).
STDOUT: MODELING CHECK PASSED: Netlist caravel is structural.
STDOUT: SUBMODULE HOOKS CHECK PASSED: All module ports for user_project_wrapper are correctly connected in the top level netlist caravel.
STDOUT: POWER CONNECTIONS CHECK PASSED: All instances in caravel are connected to power
STDOUT: {{NETLIST CONSISTENCY CHECK PASSED}} caravel netlist passed all consistency checks.
STDOUT: PORTS CHECK PASSED: Netlist user_project_wrapper ports match the golden wrapper ports
STDOUT: COMPLEXITY CHECK PASSED: Netlist user_project_wrapper contains at least 1 instances (9 instances).
STDOUT: MODELING CHECK PASSED: Netlist user_project_wrapper is structural.
STDOUT: LAYOUT CHECK PASSED: The GDS layout for user_project_wrapper matches the provided structural netlist.
STDOUT: POWER CONNECTIONS CHECK PASSED: All instances in user_project_wrapper are connected to power
STDOUT: PORT TYPES CHECK PASSED: Netlist user_project_wrapper port types match the golden wrapper port types.
STDOUT: {{NETLIST CONSISTENCY CHECK PASSED}} user_project_wrapper netlist passed all consistency checks.
STDOUT: {{CONSISTENCY CHECK PASSED}} The user netlist and the top netlist are valid.
STDOUT: {{STEP UPDATE}} Executing Check 6 of 13: XOR
STDOUT: {{XOR CHECK UPDATE}} Total XOR differences: 0, for more details view rift2core_2301/jobs/mpw_precheck/de2424ad-7615-4aa0-8973-b9a418b27696/outputs/user_project_wrapper.xor.gds
STDOUT: {{XOR CHECK PASSED}} The GDS file has no XOR violations.
STDOUT: {{STEP UPDATE}} Executing Check 7 of 13: Magic DRC
STDOUT: Found 0 violations
STDOUT: 0 DRC violations
STDOUT: {{MAGIC DRC CHECK PASSED}} The GDS file, user_project_wrapper.gds, has no DRC violations.
STDOUT: {{STEP UPDATE}} Executing Check 8 of 13: Klayout FEOL
STDOUT: Total # of DRC violations is 8 Please check rift2core_2301/jobs/mpw_precheck/de2424ad-7615-4aa0-8973-b9a418b27696/outputs/reports/klayout_feol_check.xml For more details
STDOUT: {{Klayout FEOL CHECK FAILED}} The GDS file, user_project_wrapper.gds, has DRC violations.
STDOUT: {{STEP UPDATE}} Executing Check 9 of 13: Klayout BEOL
STDOUT: Total # of DRC violations is 40 Please check rift2core_2301/jobs/mpw_precheck/de2424ad-7615-4aa0-8973-b9a418b27696/outputs/reports/klayout_beol_check.xml For more details
STDOUT: {{Klayout BEOL CHECK FAILED}} The GDS file, user_project_wrapper.gds, has DRC violations.
STDOUT: {{STEP UPDATE}} Executing Check 10 of 13: Klayout Offgrid
STDOUT: No DRC Violations found
STDOUT: {{Klayout Offgrid CHECK PASSED}} The GDS file, user_project_wrapper.gds, has no DRC violations.
STDOUT: {{STEP UPDATE}} Executing Check 11 of 13: Klayout Metal Minimum Clear Area Density
STDOUT: No DRC Violations found
STDOUT: {{Klayout Metal Minimum Clear Area Density CHECK PASSED}} The GDS file, user_project_wrapper.gds, has no DRC violations.
STDOUT: {{STEP UPDATE}} Executing Check 12 of 13: Klayout Pin Label Purposes Overlapping Drawing
STDOUT: No DRC Violations found
STDOUT: {{Klayout Pin Label Purposes Overlapping Drawing CHECK PASSED}} The GDS file, user_project_wrapper.gds, has no DRC violations.
STDOUT: {{STEP UPDATE}} Executing Check 13 of 13: Klayout ZeroArea
STDOUT: No DRC Violations found
STDOUT: {{Klayout ZeroArea CHECK PASSED}} The GDS file, user_project_wrapper.gds, has no DRC violations.
STDOUT: {{FINISH}} Executing Finished, the full log 'precheck.log' can be found in 'rift2core_2301/jobs/mpw_precheck/de2424ad-7615-4aa0-8973-b9a418b27696/logs'
STDOUT: {{FAILURE}} 2 Check(s) Failed: ['Klayout FEOL', 'Klayout BEOL'] !!!

@Ruige Lee :

{{Klayout FEOL CHECK FAILED}} The GDS file, user_project_wrapper.gds, has DRC violations.

It fails FEOL density, which is a common issue with the SRAM designs. The problem is that SkyWater tightened the density rules, and their own SRAM core cell does not have enough diffusion in it to pass the tighter density rules. Depending on the size of the SRAM block, you might be able to make the error go away by adding large blocks of the

tap

layer in the empty areas around the SRAM outside of the core array to counter the lack of density inside the core array. In the worst case, the SRAM core is under-density by only a small amount, and if the overall density is within a few percent of the limit, we can probably get SkyWater to accept it. In that case, you can just ask Jeff DiCorpo to bypass the precheck and accept the design for tapeout.