I can install tech files globally on a computer and have them referenced correctly from a .mag file, but I cannot do the same with magicrc files

Ok, I get the idea behind it. But if the magicrc always goes down to a 5nm grid, it's not much use that the tech file was more compromising

So my suggestion would be to always go down to the manufacturing grid in the tech file, and not fiddle arouns with the grid in the magicrc

I am slightly afraid that we can't change the gf18mcuC tech file anymore without breaking lots of stuff

I implemented a modification that requires adding this line to the cifoutput section of the tech file:

options set-minimum-grid

. That will force the database scaling to be set to the minimum manufacturing grid when the tech file is read in. It does seem like a useful feature.

If I remove the magscale 1 10 line and use a tech file with scalefactor 5, I get the results I expect, the widths are correct.

The set-minium-grid didn't had an effect.

With the magscale 1 10 and a scalefactor of 50 in the techfile I get an interesting bug effect when I measure the strips, the measurement is scaled up and not connected to the thing it should actually measure:

So I think magscale in the .mag files is causing too much troubles and since magic does not allow floating point coordinates in the tech file, the only real solution is to set the scalefactor to 5 nanometers in the .tech file.

Can we get the scalefactor fixed to 5 nanometers in the gf180mcu* PDK tech files?

@Tim Edwards I did a comprehensive test now, the rcfile does not help, the only solution I see is fixing the tech-file to 5 nanometers. (Or did I do anything wrong? Feel free to replicate my tests in the Makefile)

Values in a .mag file are never in physical dimensions. Magic is fundamentally based on scalable dimensions, meaning the dimensions are all relative. The only thing that determines physical dimensions is the choice of GDS (CIF) output and input styles. Since it gets increasingly difficult to properly define scalable dimensions as the feature size goes down, processes are generally not scalable, and so there is only one meaningful cifoutput or cifinput scale. Nevertheless, the database is still scalable. The "scalefactor" in the cifoutput and cifinput sections is defining the scale factor from values in the .mag file to physical dimensions. So when you change the scalefactor by a factor of 10 and then read the same .mag file, you have implicitly scaled the contents of the file by a factor of 10. That's exactly what you would do in scalable CMOS to take a design and output it for a 1um process, and a 0.8um process, and a 0.5um process, etc.; you would just change the cifoutput style, and the output will be scaled correctly for the chosen process.

The

scalegrid

command, however, changes the underlying integer grid without changing the scalefactor. But the

.mag

file output is defined to be in lambda (undimensioned) units, and so the

magscale

line is there to change the meaning of the units in the

.mag

file to match the difference between lambda units and whatever internal units have been defined by using the

scalegrid

command. If you make no other changes to tech file or .mag file but add a line

magscale 1 10

, then you have just declared that all units in the

.mag

file are 1/10 lambda, and so you have implicitly shrunk the entire design by a factor of 10.

So at the moment I see 3 potential solutions: Using .gds instead of .mag, changing gf180mcuC to a 5nm scalefactor, or trying to use magscale and fixing any bugs that we find there.

BTW, I never measure things with the "measure" command; I just type "box", which gives dimensions in microns, lambda, and internal units, and includes area as well as width and height.