@User: In magic, interactively, if you run the command "path", does the search path include

<_path_to_sky130A_>/libs.ref/sky130_fd_pr/mag/

? When you attempt to instantiate the BJT, does it say

Cell sky130_fd_pr__pnp_05v5_W3p40L3p40 couldn't be read

?

Hi @Tim Edwards, this is what I get when I run path and then generate a device:

% path
Search path for cells is ". /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_pr /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_io /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_sc_hd /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_sc_hdll /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_sc_hs /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_sc_hvl /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_sc_lp /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_sc_ls /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_sc_ms /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_osu_sc /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_osu_sc_t18 /media/tom/Storage/Linux/repos/sky130pdk/sky130A/libs.ref/mag/sky130_ml_xx_hd"
Cell library search path is "/usr/local/lib/magic/sys/current /usr/local/lib/magic/tutorial"
System search path is ". /usr/local/lib/magic/sys /usr/local/lib/magic/sys/current"
Scaled magic input cell sky130_fd_pr__pnp_05v5_W3p40L3p40 geometry by factor of 2
Loading DRC CIF style.
select cell: sky130_fd_pr__pnp_05v5_W3p40L3p40_0
%

The generated device is empty as before but the correct location seems to be included in the path variable. Here is an

ls

on that location:

tom@tom-workstation:~$ ls repos/sky130pdk/sky130A/libs.ref/mag/sky130_fd_pr/
sky130_fd_pr__cap_vpp_04p4x04p6_m1m2_lishield.mag
sky130_fd_pr__cap_vpp_08p6x07p8_m1m2_lishield.mag
sky130_fd_pr__cap_vpp_11p5x11p7_m1m2m3m4_shieldl1m5.mag
sky130_fd_pr__cap_vpp_11p5x11p7_m1m2_noshield.mag
sky130_fd_pr__pnp_05v5_W3p40L3p40.mag
sky130_fd_pr__rf_npn_05v5_W1p00L1p00.mag
sky130_fd_pr__rf_npn_05v5_W1p00L2p00.mag
sky130_fd_pr__rf_test_coil1.mag
sky130_fd_pr__rf_test_coil2.mag
sky130_fd_pr__rf_test_coil3.mag
tom@tom-workstation:~$

One difference is that I have gone for the default non-efabless folder structure. I noticed that you have

sky130_fd_pr/mag

whereas I have

mag/sky130_fd_pr

.

Not sure. There is a way to specify the style in the configure script for open_pdks, but you would have to specifically give it the option to make it use the EF style. I don't know of a way that could happen accidentally.

Should I be using EF style instead/is that the preferred option? I went for non-EF because I thought I read something that suggested it was being deprecated.

EF style is what we had set up previously on the efabless "open galaxy" platforms. I preferred the other format, so I wrote that into open_pdks as the default. I consider it preferred. I would rather figure out how you managed to accidentally set it to EF style---maybe the configuration script is wrong?

So I'm pretty sure that the first time I ran the install in december I changed it to EF style in the make script since I assumed (before I realized it didn't matter) that since the tapeout is through EF it would be preferred somehow. Then when I ran the install the second time around I chose non-EF since I too prefer that structure and was under the impression that it would become the de facto standard in due course. I don't know though why magic would still think I'm using the other style. Should I delete the sky130a folder and run the install again?