You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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]
The text was updated successfully, but these errors were encountered:
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 :)
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.
New:
The text was updated successfully, but these errors were encountered: