https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016EM8L91B> When using `addpath` in magic to ad...
# magic
m
@Tim Edwards When using 
addpath
in magic to add search paths for cells, does the first path added have priority or the last path? I couldn’t find anything in the documentation here. I’m wondering what happens when cells exist in multiple directories.
t
They will be searched by order of directories in 
addpath
.
👍 1
m
So if the addpath’s are in the order
Copy code
addpath $(CARAVEL_ROOT)/mag; \
                addpath $(UPRJ_ROOT)/mag; \
and the same cell exists in both directories and the parent cell is loaded with 
-dereference
, the cells in 
CARAVEL_ROOT
will have precedence over those in 
UPRJ_ROOT
, correct?
t
Yes, that's correct.
👍 1
m
One more question. 
mag
files can have absolute or relative paths to instances, correct? When the paths are relative, is that relative to the run directory or relative to the 
mag
data being loaded?
t
It's relative to the 
mag
being loaded. That's the only interpretation that makes sense; if you instance cell 
A
from an absolute path, and cell 
A
instantiates cell 
B
from a relative path, then that relative path must always be interpreted as being relative to cell `A`'s location.
m
In magic, if the same cell exists in different locations on the file system and is accessed by different parent cells, does the data from the first cell loaded have precedence (with dereference) or the data from the last cell.
@Tim Edwards Just a couple more scenarios. Related to the previous question. Does magic keep multiple versions of an open cell in memory or just one? If it’s just one, is it the first one loaded or the last? If magic opens a layout and can’t find the cell at the absolute or relative path, will it check the search path and load from there? My (current) assumptions are: 1. when magic loads a mag file, it checks to see if the sub cell is already loaded. a. if the sub cell has already been loaded, no further processing - the previously loaded cell is used b. if the sub cell hasn’t been loaded, magic attempts to open cell at the absolute/relative location in the mag file c. if the sub cell is not at the expected location, the search path is examined, in order, for a matching cell and the first cell found is opened d. otherwise an error is thrown 2. loading a cell that has already been loaded, will cause the new data to replace the old. Is this correct? So let’s say I have two hierarchical layouts A-B-C and a modified B’-C’ 1. Loading B’ followed by A, would magic see A-B’-C’? 2. Loading A followed by B’, would magic see A-B’-C (because C was loaded first?) Is this correct? If I now save (just) A, does the reference to B’ get stored? Meaning, the next time I open A, I get A-B’-C’ whether or not I opened with 1. or 2. above (references inside B’ have not been updated). This would seem to cause a situation where running verification on 2 (A-B’-C) may be clean, but the saved data (A-B’-C’) could point to something else giving a different result the next time the data is opened. If I save with writeall, does the reference in B’ get updated also? Meaning the next time I open A, I get A-B’-C’ if I opened with 1 or A-B’-C if I opened with 2. If B’ has a 
GDS_FILE
pointer (where that gds includes C’), is there a situation where opening with 2 gives a magic view of A-B’-C but the gds output is A-B’-C’?
t
Yikes, I need some time to parse through all that. There are multiple behaviors and when you get that deep into the possibilities, it can get complicated. Dealing with the location of cells according to the path was problematic enough that I changed it a few years back to keep the actual path to each cell in the .mag file of the parent cell, and allow the use of "-dereference" to override the hard-coded location and revert back to the original behavior of searching through the path. When a cell exists in memory, when it is requested to be loaded, the version in memory will be used. However, you could be requesting to load a cell with an exact path name that is different from the one in memory, and without dereferencing, in which case I would have to look up what the exact behavior is, because I'm not sure. A cell read from GDS is considered different from any cell in memory, but behavior depends on the "gds noduplicates" option setting, and again, I'd want to look up the exact behavior to make sure I'm telling you the right thing. I have been toying with the idea of giving every cell a random hash value like a git commit number and using that instead of names to differentiate cells. That method comes with its own problems.
Open in Slack
PreviousNext
Powered by