Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative path change #1014

Open
aolofsson opened this issue May 5, 2022 · 1 comment
Open

Relative path change #1014

aolofsson opened this issue May 5, 2022 · 1 comment

Comments

@aolofsson
Copy link
Member

In some places like the libs and pdks, we are setting relative paths. (for historical reasons..)The current system is working, but it means it's not clear what the root is. I can guess at the root path based on knowing where the third_party is placed in the repo, but explicit is better than implicit and I don't think we should expose that part of our implementation to the user, especially now that we have the find function.

dict set sc_cfg model timing nldm typical [list ../third_party/pdks/virtual/freepdk45/libs/nangate45/r1p0/lib/NangateOpenCellLibrary_typical.lib]
dict set sc_cfg model layout lef 10M [list ../third_party/pdks/virtual/freepdk45/libs/nangate45/r1p0/lef/NangateOpenCellLibrary.macro.mod.lef]
dict set sc_cfg model layout gds 10M [list ../third_party/pdks/virtual/freepdk45/libs/nangate45/r1p0/gds/NangateOpenCellLibrary.gds]

New:

dict set sc_cfg model timing nldm typical [list third_party/pdks/virtual/freepdk45/libs/nangate45/r1p0/lib/NangateOpenCellLibrary_typical.lib]
dict set sc_cfg model layout lef 10M [list third_party/pdks/virtual/freepdk45/libs/nangate45/r1p0/lef/NangateOpenCellLibrary.macro.mod.lef]
dict set sc_cfg model layout gds 10M [list third_party/pdks/virtual/freepdk45/libs/nangate45/r1p0/gds/NangateOpenCellLibrary.gds]
@nmoroze
Copy link
Contributor

nmoroze commented Jun 30, 2022

We did it this way to make sure these files can be found during an editable install w/o having to set SCPATH (since the root of the Python package, aka siliconcompiler/, gets automatically added to our file search path). I don't think find_files() should be changed to somehow support just this specific case, that seems a little hacky.

An alternative could be to finally bundle the PDK data w/ the SiliconCompiler Pip package. Then these files would be under siliconcompiler/, and it might make the relative directory seem more clear in the manifest (although, they should be resolved to absolute paths in sc_manifest.tcl anyways?) This could be useful since it seems to trip people up a lot: #1068, #901, #788, #856.

I think the final long-term solution will be to package the libraries using sup :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants