I got a SUBMODULE HOOKS CHECK FAILED in both my design and the default Caravel analog user example: SUBMODULE HOOKS CHECK FAILED: The user power port vccd1 is not connected to the correct power domain in the top level netlist. It is connected to mprj/vccd1 but it should be connected to vccd1_core. I don't have anything connect to vccd1. I found @Rana Muhammad Shahid Jamil mentioned about this same error in Dec. 2021, but no solution was provided . Does anyone know how to fix it?

I am also running into this error

The pre-check for analog designs uses the following settings. (From

checks/utils/utils.py

)

if analog_gds_path.exists() and not digital_gds_path.exists():
        project_config['type'] = 'analog'
        project_config['netlist_type'] = 'spice'
        project_config['top_module'] = 'caravan'
        project_config['user_module'] = 'user_analog_project_wrapper'
        project_config['golden_wrapper'] = 'user_analog_project_wrapper_empty'
        project_config['top_netlist'] = caravel_root / "spi/lvs/caravan.spice"
        project_config['user_netlist'] = project_path / "netgen/user_analog_project_wrapper.spice"

The pre-check expects the

user_analog_project_wrapper

power ports to be connected to

vccd1_core

etc. However, when it checks

caravel/spi/lvs/caravan.spice

it finds

mprj/vccd1

connected instead. I believe the cause is that

vccd1_core

text has been removed from

caravan

. Also the extracted result appears to be missing wiring at the top level. I'll log an issue. If you wanted to force fix, this might work

sed -i.bak 's,mprj/\(v...[12]\)\>,\1_core,g' caravel/spi/lvs/caravan.spice

I also got this error from the online check. I am trying your solution for the local pre-check.

I logged an issue here https://github.com/efabless/caravel/issues/105 You could follow/reply to that.

I tried the force fix as @Mitch Bailey mentioned, however I still get SUBMODULE HOOKS CHECK FAILED error. I see changes in line 1976 in caravan.spice file with vccd1_core, vccd2_core,.. , vssd2_core showing up

Do you get the error on both the local and efabless precheck?

I see it at both places..

I don't think you can do anything about the efabless precheck. Can you post your local precheck log? I want to verify the message.

sorry for the delay, here's the log -

The

caravan.spice

file that needs to be modified is inside the docker image. See https://open-source-silicon.slack.com/archives/D03PJ8S988M/p1657886097926969

Sorry, the link is not working..

You might be able to change your Makefile from

efabless/mpw_precheck:latest bash -c "cd $(PRECHECK_ROOT) ; python3 mpw_precheck.py --input_directory $(INPUT_DIRECTORY) --pdk_path $(PDK_ROOT)/$(PDK)"

to

efabless/mpw_precheck:latest bash -c "cd $(PRECHECK_ROOT) ; sed -i.bak 's,mprj/\(v...[12]\)\>,\1_core,g' /opt/caravel/spi/lvs/caravan.spice ; python3 mpw_precheck.py --input_directory $(INPUT_DIRECTORY) --pdk_path $(PDK_ROOT)/$(PDK)"

but changing the Makefile might cause the precheck to fail. You might try mounting the docker image and then editing the file.

the check is still failing, it gives a permission denied issue when trying to open a temporary file at

/opt/caravel/spi/lvs/sedeh8dUb

Yeah, my proposal was a kludge. It needs to be fixed at the efabless side. Just ignore it for now. Can you check your DRC errors.

Thank you so much, I'm seeing some klayout BEOL drc errors regarding the ReRAM layers. Klayout is not reading the reram layers correctly and is recognizing them as via1 rectangles. It then throws a drc error -

via.1a_b : maximum length of  via : 0.15um

In the figure below, the purple rectangle is supposed to be a reram layer and so I made it's dimensions much bigger than 0.15um x 0.15um (0.23um x0.23um). Is this something that needs to be fixed in the klayout layer properties file, at libs.tech/klayout/sky130B.lyp? #reram @Tim Edwards

In older versions of the magic tech file, the ReRAM layer may not have been output to GDS. Is your original design in magic and do you see the ReRAM layers there? After you create the GDS file, can you read it into magic (without overwriting your original data) to see if the ReRAM layers have been output correctly?

My original design is in magic and it works fine even after reading back the GDS, in magic. It seems to be only an issue in klayout. I remember @Tim Edwards made some updates back in December to help with reading and writing the reram layers correctly in a GDS format. https://open-source-silicon.slack.com/archives/C02Q2DE33QF/p1648002376682949

Does klayout show and unnamed layer/type pair 201/20 at the end of the layer list?

I'm looking at all the klayout .lyp files and I don't see "201" or "reram" in any of them---both the original files that I had in the open_pdks repository locally, or in the ones I'm pulling now from @Amro Tork's repo. If Amro could make that addition, that would be helpful. I'm pulling his repository when doing the build because it's better developed than the one I have locally, which I don't think anyone claims responsibility for.

@Mitch Bailey Without loading the klayout.lyp file from load layer properties, I do see a 201/20 layer in the layer list. But once I load the layer map, I don't see 201 or reram as Tim mentioned, the reram just shows up as a via drawing.

We're waiting on efabless to fix

SUBMODULE HOOKS CHECK

. The ReRAM layers show up correctly in magic, right? What version of tech file are you using? Should be in the magic log.

They show up in magic correctly. I was using 41c0908b47130d5675ff8484255b43f66463a7d6/sky130B

Looks like the tech file is about 4 days too old.

I can try to update it locally but still may be an issue on efabless side.

I'll ask. @jeffdi It looks like the open_pdks commit

41c0908b

used for mpw-7a does not have the fix for ReRAM layer from commit

d7faec2

This means that designs using ReRAM may be missing that layer in the gds streamed out from magic and will not work.

Thanks @Mitch Bailey@Tim Edwards, the updates made on efabless side to fix

SUBMODULE HOOKS CHECK

are working now. However, I'm still failing the

Klayout BEOL check

due to ReRAMs being seen as via1, which is the last precheck I'm failing. I uploaded the

precheck.log

from precheck I did locally, which shows 32 drc errors in the

Klayout BEOL check

, and the

klayout_beol_check.xml

marker file. The GDS is at the GitHub project repo (https://github.com/jainsoumil2/caravan_reram_crossbar.git),

gds/user_analog_project_wrapper.gds

. #analog-design #reram

The precheck was updated this week. Do you have the latest version locally?

I updated the local version and ran precheck again. The BEOL errors remain.

2022-09-06 22:46:48 - [INFO] - {{EXTRACTING FILES}} Extracting compressed files in: /Volumes/export/isn/soumil/caravel_analog_reram_crossbar
2022-09-06 22:46:51 - [INFO] - {{Project Type Info}} analog
2022-09-06 22:46:51 - [INFO] - {{Project GDS Info}} user_analog_project_wrapper: 9918f9e9cd4da5064e0bae3c5ca0de4aed84018a
2022-09-06 22:46:52 - [INFO] - {{Tools Info}} KLayout: v0.27.10 | Magic: v8.3.315
2022-09-06 22:46:52 - [ERROR] - MPW Precheck failed to get Open PDKs & Skywater PDK versions: Command '['git', '-C', '/Volumes/export/isn/soumil/open_pdks/volare/sky130/versions/41c0908b47130d5675ff8484255b43f66463a7d6/open_pdks', 'rev-parse', '--verify', 'HEAD']' returned non-zero exit status 128.
2022-09-06 22:46:52 - [INFO] - {{START}} Precheck Started, the full log 'precheck.log' will be located in '/Volumes/export/isn/soumil/caravel_analog_reram_crossbar/precheck_results/06_SEP_2022___22_46_48/logs'
2022-09-06 22:46:52 - [INFO] - {{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]
2022-09-06 22:46:52 - [INFO] - {{STEP UPDATE}} Executing Check 1 of 13: License
2022-09-06 22:46:53 - [INFO] - An approved LICENSE (Apache-2.0) was found in /Volumes/export/isn/soumil/caravel_analog_reram_crossbar.
2022-09-06 22:46:53 - [INFO] - {{MAIN LICENSE CHECK PASSED}} An approved LICENSE was found in project root.
2022-09-06 22:46:54 - [INFO] - An approved LICENSE (Apache-2.0) was found in /Volumes/export/isn/soumil/caravel_analog_reram_crossbar.
2022-09-06 22:46:55 - [INFO] - An approved LICENSE (Apache-2.0) was found in /Volumes/export/isn/soumil/caravel_analog_reram_crossbar.
2022-09-06 22:46:55 - [INFO] - {{SUBMODULES LICENSE CHECK PASSED}} No prohibited LICENSE file(s) was found in project submodules
2022-09-06 22:46:56 - [INFO] - {{SPDX COMPLIANCE CHECK PASSED}} Project is compliant with the SPDX Standard
2022-09-06 22:46:56 - [INFO] - {{STEP UPDATE}} Executing Check 2 of 13: Makefile
2022-09-06 22:46:56 - [INFO] - {{MAKEFILE CHECK PASSED}} Makefile valid.
2022-09-06 22:46:56 - [INFO] - {{STEP UPDATE}} Executing Check 3 of 13: Default
2022-09-06 22:46:56 - [INFO] - {{README DEFAULT CHECK PASSED}} Project 'README.md' was modified and is not identical to the default 'README.md'
2022-09-06 22:46:56 - [INFO] - {{CONTENT DEFAULT CHECK PASSED}} Project 'gds' was modified and is not identical to the default 'gds'
2022-09-06 22:46:56 - [INFO] - {{STEP UPDATE}} Executing Check 4 of 13: Documentation
2022-09-06 22:46:56 - [INFO] - {{DOCUMENTATION CHECK PASSED}} Project documentation is appropriate.
2022-09-06 22:46:56 - [INFO] - {{STEP UPDATE}} Executing Check 5 of 13: Consistency
2022-09-06 22:46:58 - [INFO] - HIERARCHY CHECK PASSED: Module user_analog_project_wrapper is instantiated in caravan.
2022-09-06 22:46:58 - [INFO] - COMPLEXITY CHECK PASSED: Netlist caravan contains at least 8 instances (68 instances).
2022-09-06 22:46:58 - [INFO] - MODELING CHECK PASSED: Netlist caravan is structural.
2022-09-06 22:46:58 - [INFO] - SUBMODULE HOOKS CHECK PASSED: All module ports for user_analog_project_wrapper are correctly connected in the top level netlist caravan.
2022-09-06 22:46:58 - [INFO] - {{NETLIST CONSISTENCY CHECK PASSED}} caravan netlist passed all consistency checks.
2022-09-06 22:46:58 - [INFO] - PORTS CHECK PASSED: Netlist user_analog_project_wrapper ports match the golden wrapper ports
2022-09-06 22:46:58 - [INFO] - COMPLEXITY CHECK PASSED: Netlist user_analog_project_wrapper contains at least 1 instances (1 instances).
2022-09-06 22:46:58 - [INFO] - MODELING CHECK PASSED: Netlist user_analog_project_wrapper is structural.
2022-09-06 22:46:58 - [INFO] - LAYOUT CHECK PASSED: The GDS layout for user_analog_project_wrapper matches the provided structural netlist.
2022-09-06 22:46:58 - [INFO] - {{NETLIST CONSISTENCY CHECK PASSED}} user_analog_project_wrapper netlist passed all consistency checks.
2022-09-06 22:46:58 - [INFO] - {{CONSISTENCY CHECK PASSED}} The user netlist and the top netlist are valid.
2022-09-06 22:46:58 - [INFO] - {{STEP UPDATE}} Executing Check 6 of 13: XOR
2022-09-06 22:47:07 - [INFO] - {{XOR CHECK UPDATE}} Total XOR differences: 0, for more details view /Volumes/export/isn/soumil/caravel_analog_reram_crossbar/precheck_results/06_SEP_2022___22_46_48/outputs/user_analog_project_wrapper.xor.gds
2022-09-06 22:47:07 - [INFO] - {{XOR CHECK PASSED}} The GDS file has no XOR violations.
2022-09-06 22:47:07 - [INFO] - {{STEP UPDATE}} Executing Check 7 of 13: Magic DRC
2022-09-06 22:47:08 - [INFO] - 0 DRC violations
2022-09-06 22:47:08 - [INFO] - {{MAGIC DRC CHECK PASSED}} The GDS file, user_analog_project_wrapper.gds, has no DRC violations.
2022-09-06 22:47:08 - [INFO] - {{STEP UPDATE}} Executing Check 8 of 13: Klayout FEOL
2022-09-06 22:47:26 - [INFO] - No DRC Violations found
2022-09-06 22:47:26 - [INFO] - {{Klayout FEOL CHECK PASSED}} The GDS file, user_analog_project_wrapper.gds, has no DRC violations.
2022-09-06 22:47:26 - [INFO] - {{STEP UPDATE}} Executing Check 9 of 13: Klayout BEOL
2022-09-06 23:09:40 - [ERROR] - Total # of DRC violations is 32 Please check /Volumes/export/isn/soumil/caravel_analog_reram_crossbar/precheck_results/06_SEP_2022___22_46_48/outputs/reports/klayout_beol_check.xml For more details
2022-09-06 23:09:40 - [WARNING] - {{Klayout BEOL CHECK FAILED}} The GDS file, user_analog_project_wrapper.gds, has DRC violations.
2022-09-06 23:09:40 - [INFO] - {{STEP UPDATE}} Executing Check 10 of 13: Klayout Offgrid
2022-09-06 23:09:49 - [INFO] - No DRC Violations found
2022-09-06 23:09:49 - [INFO] - {{Klayout Offgrid CHECK PASSED}} The GDS file, user_analog_project_wrapper.gds, has no DRC violations.
2022-09-06 23:09:49 - [INFO] - {{STEP UPDATE}} Executing Check 11 of 13: Klayout Metal Minimum Clear Area Density
2022-09-06 23:09:52 - [INFO] - No DRC Violations found
2022-09-06 23:09:52 - [INFO] - {{Klayout Metal Minimum Clear Area Density CHECK PASSED}} The GDS file, user_analog_project_wrapper.gds, has no DRC violations.
2022-09-06 23:09:52 - [INFO] - {{STEP UPDATE}} Executing Check 12 of 13: Klayout Pin Label Purposes Overlapping Drawing
2022-09-06 23:09:54 - [INFO] - No DRC Violations found
2022-09-06 23:09:54 - [INFO] - {{Klayout Pin Label Purposes Overlapping Drawing CHECK PASSED}} The GDS file, user_analog_project_wrapper.gds, has no DRC violations.
2022-09-06 23:09:54 - [INFO] - {{STEP UPDATE}} Executing Check 13 of 13: Klayout ZeroArea
2022-09-06 23:09:55 - [INFO] - No DRC Violations found
2022-09-06 23:09:55 - [INFO] - {{Klayout ZeroArea CHECK PASSED}} The GDS file, user_analog_project_wrapper.gds, has no DRC violations.
2022-09-06 23:09:55 - [INFO] - {{FINISH}} Executing Finished, the full log 'precheck.log' can be found in '/Volumes/export/isn/soumil/caravel_analog_reram_crossbar/precheck_results/06_SEP_2022___22_46_48/logs'
2022-09-06 23:09:55 - [CRITICAL] - {{FAILURE}} 1 Check(s) Failed: ['Klayout BEOL'] !!!

@Tim Edwards Could I get your input on this? The klayout drc rules flag vias larger that 0.15um. In this layout, the ReRAM layer is 0.23x0.23 with the via the same size so they all get flagged. Is this due to an older technology file being used? Looks like it was fixed around April 19, 2022. @Soumil Jain Please make sure that the magic technology file

$PDK_ROOT/sky130B/libs.tech/magic/sky130B.tech

that you create the gds with is later than

1.0.310

. If the technology file has been updated, you will need to recreate the gds for each openlane block from the lowest to the highest. If the technology version is older: 1. Check that you are on the latest commit of

caravel_user_project_analog

with the correct

caravel

commit. 2. If you are, please log an urgent issue on

caravel_user_project_analog

@jeffdi Who is in charge of version control on

caravel_user_project/caravel_user_project_analog

?

If the GDS of the user project is made with the PDK from open_pdks version 1.0.310, then it should be correct. . . Nothing on the Efabless side is going to change the layout. As Mitch notes, your layout has ReRAM and Via1 sizes both 0.23; 0.23um is the minimum width for the ReRAM layer; however, the Via1 needs to be 0.15um x 0.15um, and since there is a required 0.055um minimum enclosure of via1 by ReRAM, the ReRAM effective minimum size is 0.26um x 0.26um (in other words, the minimum width rule makes no sense in the context of the rest of the rules---there is no legal way for it to be less than 0.26 x 0.26). For the record, the reference layout made by SkyWater has a 0.32um x 0.32um ReRAM layer. I can make no recommendations about whether the 0.32um x 0.32um is preferred, or more reliable, or what. I just know that that's what the reference layout uses for size.

@Mitch Bailey @Tim Edwards I tried to reinstall open_pdks using volare (instructions from https://github.com/efabless/volare) but the latest volare gives me

1.0.291

. I also tried

make pdk_with_volare

command from caravel_analog_user_project documentation (https://github.com/efabless/caravel_user_project_analog/blob/main/docs/source/index.rst), which gives the same sky130B.tech version. Where can I find instructions to download

1.0.310

or later?

@donn: Can volare be updated to point to a PDK version that works for ReRAM (open_pdks version 1.0.310 or later, preferably latest)? Because otherwise nobody using volare is going to be able to produce a working ReRAM design.

Volare supports the latest open_pdks version. This is on the caravel team to update, not I. While they're at it, they can also update the OpenLane version as I've asked.

@Soumil Jain https://github.com/efabless/volare explains how to update your local version (for gds output).

@Mitch Bailey @Tim Edwards I updated my local version from volare to the one @donn mentioned but the updated tech file at

.volare/volare/sky130/versions/fa87f8f4bbcc7255b6f0c0fb506960f531ae2392/sky130B/libs.tech/magic/sky130B.tech

still shows the version as 1.0.291, unless I am looking at the wrong place. I did manage to pass the klayout BEOL precheck with this update, perhaps klayout’s layer properties (.lyp) file was updated. However, when I try to open my GDS in klayout with

.volare/volare/sky130/versions/fa87f8f4bbcc7255b6f0c0fb506960f531ae2392/sky130B/libs.tech/klayout/tech/sky130B.lyp

, I don’t see any reram layers (screenshot attached). The rerams are generated as via1 with the same dimensions as a standard via1 (0.15um x 0.15um) this time, which is probably why it does not throw a drc. The reram does show up when I import the gds in magic (screenshot attached) with dimensions 0.26um x 0.26um. Should I be concerned about this? GDS file at updated GitHub repo - https://github.com/jainsoumil2/caravan_reram_crossbar.git

@Soumil Jain Thanks for the detailed infomation. That should be enough for efabless to debug the situation. I'm not sure how volare creates the data for the pdks, but if it uses the

caravel/Makefile

, they need to be aware of the commit for

open_pdks

. It may not have been the most recent data.

ill take a look

@donn We didn't write reram cells.

Thanks for looking into this @donn @Soumil Jain The ReRAM layer may be at the bottom of the layer list. Is there an unnamed

201/20

there in klayout?

Anybody familiar with a way to get GitHub to also pull tags from upstream? Asking for a friend.

Maybe

git fetch --tags

@Mitch Bailey I see a 201/20 layer without having the layer properties file loaded. Not seeing an unnamed 201/20 layer after loading the tech file

sky130B.lyp

and it does not show up as an empty layer either.

So what you're saying is that if you load the gds and then load the layer file,

201/20

dissappears. If you then open in a new window with the layer file already loaded, what happens? This may be a klayout issue.

That seems to work and I see an unnamed 201/20. I'll try updating klayout as well