I loaded the nand2_1.mag file in Magic from the hd library and it has li spacing errors. Am I missing something?

This is what I see, and it's fine.

Hm. I had an older sky130A

I'm not aware that the cell ever changed. Did you run using

-rcfile

and

sky130A.magicrc

? If you don't apply the command

drc euclidean on

you will get that error, since the manhattan distance is in violation of the distance rule. The command is part of the

sky130A.magicrc

script.

Yes, it seems to be grabbing a wrong .magicrc somehwere. I'm not even sure how it is picking it up...

New windows will not have a border.
Repainting console in magic layout window colors
handling file entry mag/sky130_fd_sc_hd__nand2_1.mag extension .mag
File <mag/sky130_fd_sc_hd__nand2_1.mag> is already locked by pid 4028751.  Opening read-only.
Cell sky130_fd_sc_hd__nand2_1 has technology "sky130A", but current technology is "minimum"
Loading technology sky130A
Input style sky130(vendor): scaleFactor=2, multiplier=2
Cell path is now "/usr/local/lib/magic/sys/current /usr/local/lib/magic/tutorial /software/PDKs/sky130A/libs.ref/sky130_fd_pr/mag /software/PDKs/sky130A/libs.ref/sky130_fd_pr/maglef /software/PDKs/sky130A/libs.ref/sky130_ml_xx_hd/mag"
Input cell sky130_fd_sc_hd__nand2_1 scales magic internal geometry by factor of 2
Using technology "sky130A", version 1.0.258-0-g11fb930

I'm running this in another directory with no .magicrc, not in my home directory, and not in the system directories either. Where does it even get my PDK paths?

It probably isn't running any

.magicrc

file. It gets the technology from the

.mag

file and may be able to find everything if you have

PDK_PATH

set in your environment.

No $PDK_PATH set up

Is there a

.magicrc

file in the directory where the file you read in is, or is there a

.magicrc

file in your home directory?

Not with any config. Just some keymappings

Any

PDKROOT

or

PDK_ROOT

environment variable?

I did have PDK_ROOT set, but when I unset it I get the same behavior. I'm not sure how it would get searched..

The message

Cell path is now ...

above comes from some code that attempts to find a PDK that was installed by open_pdks. It will try a number of different things, including just a search on

/usr/share/pdk

.

Oh, that is built into magic?

It is now. That experience, though, suggests that as long as it is expecting an open_pdks-style PDK, it should probably be looking for the related

.magicrc

script and sourcing it first, before it tries to just load the tech file.

I see the oddness. It defines PDKPATH differently due to a .magicrc it picks up in the device models: $ diff /software/PDKs/sky130A/libs.ref/sky130_fd_pr/mag/.magicrc /software/PDKs/sky130A/libs.tech/magic/sky130A.magicrc 23c23 < set PDKPATH "/software/PDKs/open_pdks/sky130/sky130A" ---

set PDKPATH "/software/PDKs/sky130A

Either one of those should work. The path to

open_pdks/sky130/sky130A/

is a staging area where open_pdks builds the PDK. All of the paths there are self-consistent and valid, and you can run the whole think out of the staging area. But the intent is to follow that through with

make install

which will copy it to the final destination (and

make clean

so that you don't end up with two entire copies of the PDK).

Except that I think one was really old.

@User It looks like the openlane Makefile

build-pdk

target has a

make clean

. This will delete the staging area

open_pdks/sky130/sky130A

, correct?

build-pdk: $(PDK_ROOT)/open_pdks $(PDK_ROOT)/skywater-pdk
        [ -d $(PDK_ROOT)/sky130A ] && \
                (echo "Warning: A sky130A build already exists under $(PDK_ROOT). It will be deleted first!" && \
                sleep 5 && \
                rm -rf $(PDK_ROOT)/sky130A) || \
                true
        $(ENV_COMMAND) sh -c " cd $(PDK_ROOT)/open_pdks && \
                ./configure --enable-sky130-pdk=$(PDK_ROOT)/skywater-pdk/libraries $(OPEN_PDK_ARGS)"
        cd $(PDK_ROOT)/open_pdks/sky130 && \
                $(MAKE) veryclean && \
                $(MAKE) prerequisites
        $(ENV_COMMAND) sh -c " cd $(PDK_ROOT)/open_pdks/sky130 && \
                make && \
                make SHARED_PDKS_PATH=$(PDK_ROOT) install && \
                make clean"

This may be what's causing the bad links https://github.com/RTimothyEdwards/open_pdks/issues/204

@User: I don't think that's the issue here, but it's definitely an issue, and one that I dropped the ball on. I need to check the open items more often. . .