i want to have this gds locally

You don't get the full chip until about halfway through the tapeout process, just before the tapeout DRCs. user_project_wrapper is just that, the user core.

Sorry, what is halfway tapeout process mean? could u kindly point me to the step in this link to create full gds ? https://github.com/efabless/caravel_user_project/blob/main/docs/source/index.md#checklist-for-open-mpw-submission

In the Efabless flow you ran the online mpw_precheck to create the user project wrapper. Then you ran the online tapeout flow. The tapeout flow ran through sanity checks on the user project wrapper such as pin placement. Tapeout then inserted the user project wrapper into whichever harness chip you were using (caravel, caravan, openframe) to create the full chip with the necessary configurations. It then ran fill, inserted the fill and scribe into the full chip. It then ran the DRC flow. That's the basic order. I'm afraid I don't remember all the individual steps. But, you could see the steps in the log output.

@samarth jain To integrate the

user_project_wrapper

block into the caravel framework locally, run

make ship

. Be aware that in order to set the device id, you’ll first need to

export USER_ID=<the 8 hex characters for the user id>
make set_user_id

and to set up the gpio defaults, after configuring

verilog/rtl/user_defines.v

, you’ll need to

make gpio_defaults

got this error error came during mpu precheck @Tim Edwards @Mitch Bailey, not the ship command. these are MPW pre check log files https://drive.google.com/file/d/12-b2I5KHXBamTz2n0D1V6LChrWc180oi/view?usp=drive_link

@samarth jain This is the local mpw_precheck, right? The

Default

checks that you are not submitting the default design. Some people in the past, created a unique

user_proj_example

block, but did not integrate that into the final

user_project_wrapper

. If you are attempting to submit the default design, you can ignore this error. The

Documentation

check was required for the open mpw shuttles sponsored by Google. It checks that the

README.md

does not match over 70% of the default. Again, you can ignore this for private shuttles.

Thanks for the reply! I also got the make ship to run, but now it says that the "make ship" completes successfully, but it is not able to open a gds file in the gds folder. I checked if the permissions are proper and the shell has access to the directory, I also tried placing a caravel.gds file from the caravel repo in the hopes it will be able to overwrite it, but still getting the same error. I have exported the user project, mcw and caravel directories. Any ideas to what is happening? Appreciate your help! ~Anubhav

@samarth jain maybe too many files open. Check

ulimit -n

. If it’s 1024, try bumping to 2048.

@samarth jain @Mitch Bailey @Tim Edwards My make final output looks like this, what could cause this to happen? I tried with the original files before replacing the user_project_wrapper.gds in the /gds folder with a cadence generated file and it was fine. After I placed the cadence file, this happened. Thanks!

@Anubhav Mukherjee Not sure of all the problems that are occurring here. Looks like the origin may be different. Can you open the

user_project_wrapper

cell from the layout that looks correct and compare that to the origin of the Cadence

user_project_wrapper

cell?

Hi @Mitch Bailey! I am not sure how, but I got it to align. The mistake I was doing was exporting PROJECT=user_project_wrapper instead of PROJECT=caravel. Or so I think. The make fill pattern looks correct now. But the new issue is that magic is exiting with a PDK tech rule issue and the gds file 0 bytes now. Any idea how can I make it work? I feel like I am really close! Thanks for your help!

Cell sky130_fd_pr__cap_mim_m3_2_W5U4AW read from path primitives
Cell sky130_fd_pr__cap_mim_m3_1_WRT4AW read from path primitives
Cell sky130_fd_sc_hvl__decap_8 read from path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hvl/mag
Cell sky130_fd_sc_hvl__decap_4 read from path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hvl/mag
Cell sky130_fd_sc_hvl__diode_2 read from path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hvl/mag
Error message output from magic:
Cell RAM128 couldn't be read
Warning:  Parent cell lists instance of "EF_fill_4_8" at bad file path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hd/mag/EF_fill_4_8.mag.
The cell exists in the search paths at EF_fill_4_8.mag.
The discovered version will be used.
/home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.tech/magic/sky130A.tech: line 6087: section (none):
	Unrecognized layer (type) name "res0p69"
ERROR:  Magic exited with status -11
Done!

@Anubhav Mukherjee what version of the pdk are you using?

ciel ls

or

volare ls

Hi! I am using this one, I think I pulled it from the latest caravel-user-project repo. Although, I did make setup after changing the caravel-lite --> caravel, not sure if that makes an impact.

vboxuser@Ubuntu-rv5-tci-BMServer:~/Documents/GitHub/samj-user-project$ volare ls
In /home/vboxuser/.volare/volare/sky130/versions:
âââ 78b7bc32ddb4b6f14f76883c2e2dc5b5de9d1cbc (2023.07.10) (enabled)

@Anubhav Mukherjee That’s very old. Try

volare ls-remote

to list the available versions and the

volare enable <newer_commit>

to activate one of the more recent versions.

Hi @Mitch Bailey!

Cell sky130_fd_sc_hvl__decap_4 read from path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hvl/mag
Cell sky130_fd_sc_hvl__diode_2 read from path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hvl/mag
Error message output from magic:
Cell RAM128 couldn't be read
Warning:  Parent cell lists instance of "EF_fill_4_8" at bad file path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hd/mag/EF_fill_4_8.mag.
The cell exists in the search paths at EF_fill_4_8.mag.
The discovered version will be used.
/home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.tech/magic/sky130A.tech: line 6087: section (none):
	Unrecognized layer (type) name "res0p69"
ERROR:  Magic exited with status -11
Done!

Still facing the same issue. Loaded the latest pre release and stable versions and tried. tried versions: 0fe599b2afb6708d281543108caf8310912f54af & f2e289da6753f26157a308c492cf990fdcd4932d

@Anubhav Mukherjee The pdk being used in

make ship

appears here

/home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.tech/magic/sky130A.tech: line 6087: section (none):

while your volare installation appears to be here

In /home/vboxuser/.volare/volare/sky130/versions:

Are these the same file? You can try looking at the

caravel/Makefile

to see if there’s place to override the

OPEN_PDK_COMMIT

@Mitch Bailey I missed the PDK_ROOT step. Now it looks correct.

vboxuser@Ubuntu-rv5-tci-BMServer:~/Documents/GitHub/samj-user-project$ volare enable 0fe599b2afb6708d281543108caf8310912f54af
Version 0fe599b2afb6708d281543108caf8310912f54af enabled for the sky130 PDK.
vboxuser@Ubuntu-rv5-tci-BMServer:~/Documents/GitHub/samj-user-project$ volare ls
In /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/volare/sky130/versions:
------ 0fe599b2afb6708d281543108caf8310912f54af (2024.08.17) (enabled)
------6d4d11780c40b20ee63cc98e645307a9bf2b2ab8 (2024.02.11)
------ 78b7bc32ddb4b6f14f76883c2e2dc5b5de9d1cbc (2023.07.10)

But unfortunately, still having the same issue...

Cell sky130_fd_sc_hvl__decap_4 read from path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hvl/mag
Cell sky130_fd_sc_hvl__diode_2 read from path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hvl/mag
Error message output from magic:
Cell RAM128 couldn't be read
Warning:  Parent cell lists instance of "EF_fill_4_8" at bad file path /home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.ref/sky130_fd_sc_hd/mag/EF_fill_4_8.mag.
The cell exists in the search paths at EF_fill_4_8.mag.
The discovered version will be used.
/home/vboxuser/Documents/GitHub/samj-user-project/dependencies/pdks/sky130A/libs.tech/magic/sky130A.tech: line 6185: section (none):
	Unrecognized layer (type) name "res0p69"
ERROR:  Magic exited with status -11
Done!
#mv /home/vboxuser/Documents/GitHub/samj-user-project/caravel/mag/caravel_C0CA4A7F.mag ./mag/
make[2]: Leaving directory '/home/vboxuser/Documents/GitHub/samj-user-project'
Final build completed.
make[1]: Leaving directory '/home/vboxuser/Documents/GitHub/samj-user-project'

So, I thought, lemme see what is that line 6185 in the tech file and there are only 6184 lines (6184 is blank) in the file... I am so confused....😢

#-----------------------------------------------------------------
# No special plot layers defined (use default PNM color choices)
#-----------------------------------------------------------------

plot
  style pnm
     default
     draw fillblock no_color_at_all
     draw obsactive no_color_at_all
     draw obsm1 no_color_at_all
     draw obsm2 no_color_at_all
     draw obsm3 no_color_at_all
     draw obsm4 no_color_at_all
     draw obsm5 no_color_at_all
     draw fomfill no_color_at_all
     draw polyfill no_color_at_all
     draw m1fill no_color_at_all
     draw m2fill no_color_at_all
     draw m3fill no_color_at_all
     draw m4fill no_color_at_all
     draw m5fill no_color_at_all
     draw isosub no_color_at_all
     draw nwell cwell
end

Does the "res0p69" layer need to be defined here? Edit: Found out that its a ReRAM cell from the layout team and not part of PDK. Is there a way to ignore it and move forward?

@Anubhav Mukherjee there a old mag file somewhere that has

res0p69

defined. That was an old layer used to define resistors of width 0.69um. The magic program was changed to extract devices based on width without the recognition layer. The mag file may be part of an older repo besides the pdk. Check the commit id (and date) for the caravel repo, etc.

I see something of this metion by @Tim Edwards over here https://github.com/efabless/caravel/blob/main/mag/primitives/sky130_fd_pr__res_xhigh_po_0p69_S5N9F3.mag ,looks like a pull up or pull down res

@Anubhav Mukherjee Unfortunately, the magic output may all be irrelevant errors. What commit of caravel are you using? Can you attach the

caravel/Makefile

?

Hi @Mitch Bailey! PFA. I managed to solve the res0p69 issue by using a super old version of the PDK. But it still segfaults and crashes.

@Anubhav Mukherjee What version of magic is installed?

magic -dnull -noc --version

@Mitch Bailey 8.3.500

@Anubhav Mukherjee That’s from last November, but I don’t remember any major problems with that version. The Makefile invocation of magic sometimes hides the actual error message. Can you try running this script from the project directory and send me the resulting screen output? Be sure to check that the

CARAVEL_ROOT

and

MCW_ROOT

directories exist and that

PDK_ROOT

and

PDK

are set.

#! /usr/bin/env bash
export UPRJ_ROOT=$PWD
export CARAVEL_ROOT=$PWD/caravel
export MCW_ROOT=$PWD/mgmt_core_wrapper

cat >$UPRJ_ROOT/mag/mag2gds_caravel.tcl <<-EOF
		random seed `$CARAVEL_ROOT/scripts/set_user_id.py -report`;
		drc off;
		crashbackups stop;
		addpath hexdigits;
		addpath $MCW_ROOT/mag;
		addpath $UPRJ_ROOT/mag;
		load user_project_wrapper;
		property LEFview true;
		property GDS_FILE $UPRJ_ROOT/gds/user_project_wrapper.gds;
		property GDS_START 0;
		load $UPRJ_ROOT/mag/user_id_programming;
		load $UPRJ_ROOT/mag/user_id_textblock;
		load $CARAVEL_ROOT/maglef/simple_por;
		load $UPRJ_ROOT/mag/caravel_core -dereference;
		load caravel -dereference;
		select top cell;
		expand;
		cif *hier write disable;
		cif *array write disable;
		gds write $UPRJ_ROOT/gds/caravel.gds;
		quit -noprompt;
EOF

cd $CARAVEL_ROOT/mag && PDKPATH=$PDK_ROOT/$PDK MAGTYPE=mag magic -noc -dnull -rcfile ./.magicrc $UPRJ_ROOT/mag/mag2gds_caravel.tcl

Late to the game here. I don't check the slack workspace much. "Unrecognized layer (type) name "res0p69"" is a harmless message. I once used ID layers to recognize the different resistor widths, but then I upgraded magic to be able to specify width ranges in the extraction definitions, so it now automatically determines the right device to extract. The ID layer is no longer used, but some of the old layouts still reference it. When magic reads in the file it will issue a warning, but it will ignore the layer, and that's fine.

@Tim Edwards thanks for the clarification. Do you have any idea why the local

make ship

would not produce gds given the above error messages?