Has anyone experienced Magic trying to save all ce...
# magic
b
Has anyone experienced Magic trying to save all cells in the layout when saving changes to the top-level .mag file? This includes PDK cells that are read-only. I just had my first seg fault and am thinking this new behavior might be related.
On a similar topic, I've accumulated .mag files in my directory from prior versions of cells that have been replaced. Is there a preferred way to remove all obsolete .mag files without corrupting the top-level layout?
m
Magic does
crashbackups
, unless you’ve stopped them. Check your
/tmp
directory - you may be able to recover some of your work. The
writeall modified
command will (should) prompt for saving modified cells on a cell by cell basis.
b
Thanks for the advice! In the circled filename format?
m
Yes, but I don’t know how to recover.
👍 1
b
So, I tried a
write modified
, apologies for the white background. At some point after I added the
tapvpwrvgnd_1
cells, Magic started treating the standard cells as if they had been modified. Not sure why. (It was the first time I created an instance directly from the
libs.ref
directory, so maybe I used the wrong technique.)
m
Looks like it didn’t overwrite the standard cells, but did save your top level - which is what you want, right?
t
@Brady Etz: Every so often I try to fix issues with magic and timestamps, which is a long-running battle that I have become quite tired of. At some point I want to get rid of the timestamps altogether and replace them with a git-like method of stamping designs with hash tags. Anyway, the bottom line is that there are situations where magic becomes convinced that the timestamps of read-only cells need to be updated and I'm not sure why. This is why it helps to have the PDK in a read-only directory tree, so they can't be modified regardless of what magic tries to do. Other questions above: (1) To recover from a /tmp file, use
magic -r
. Beware that magic needs to be called with the same arguments that were originally used (i.e.,
-rcfile ...
or else you may end up with recovered data corrupted beyond recognition. You can also just read the file in /tmp directly as a layout file. (2) I wrote a routine for cleaning up unused paramterized cells. See open_pdks
runtime/cleanup_unref.py
. Use
Copy code
cleanup_unref.py <path_to_layout>
to get a list of what the script thinks are unused layouts. Use
Copy code
cleanup_unref.py -remove <path_to_layout>
to actually delete those files. Be careful using this, as it assumes that all cells are local to the same project in the given root directory, so if there are layout files elsewhere that are referencing the same set of cells, you might end up deleting cells you don't want to delete. I usually use this script in a paranoid manner by never using the
-remove
option but just collecting the set of files it thinks aren't being used, moving them to a temporary directory somewhere, then attempting to load the project to make sure that I didn't get rid of something I shouldn't have. If all looks good, then I delete the temporary directory.
b
Thank you for the tip on the unused files script. Worked like a charm, and will help clean up the git repo.