I'm having troubles specifying distances on magic....
# magic
a
I'm having troubles specifying distances on magic. Almost always we use the
um
directive/command/string (what's
cm
?) but that's float point, so it's desirable to avoid doing arithmetic with that, using db coordinates instead. How could I do it? for example, turning
overlap=0.19um
into an integer. I want something tech agnostic,
tech lambda
just gives
1 2
@Tim Edwards I've found this way to make it tech agnostic. Basically, using the dimentions of a 1um x 1um box.
Copy code
box 0 0 1um 1um
set um2db [expr int ([box width] * [lindex [tech lambda] 0] / [lindex [tech lambda] 1])]
🙌 1
t
Yes, that's a reasonable way to do it. I used the same trick for the fill generation script.
a
I think there's a better way to convert values. did you know about this?
Copy code
expr int([magic::u2i 0.19]) ; $ 38
t
I tend to forget about those. They are left over from work done on the Efabless Open Galaxy platform and I append them to all of the device generator scripts for magic, but I rarely use them. Good find!
a
Found a weird problem. If I run
magic
and then source a file that uses
magic::u2i
or something similar, it works as expected, but if I run
magic <tclfile>
then it don't recognizes the command. Also, the graphical interfaces has a different format.
t
That's due to the fact that
magic::u2i
is defined inside the sky130 device generator script, which is sourced from the sky130 startup script for magic. If you run
magic <tclfile>
, then you should either load the device generator script from your
<tclfile>
script or else start magic with
magic -rcfile $PDK_ROOT/sky130A/libs.tech/magic/sky130.magicrc <tclfile>
.
a
Yep, I'm sourcing
sky130A.magicrc
. I think this problem could be related to not sourcing files on
usr/lib/magic/tcl/
t
I would not source the
.magicrc
file from a script. The problem is in the order in which things get read and executed. The
.magicrc
file is run before any of the GUI is set up. If you let magic start up and then source the
.magicrc
file, then many of the commands will not apply to the existing layout window. They might work if you closed the layout window and started a new one. The better option is to use the
-rcfile
option on the command line.
If you don't want to put all that in the command line, then you just need to have a file named (exactly)
.magicrc
in the directory where you launch magic, and it will get read just like passing
-rcfile .magicrc
on the command line.
a
I'm specifying magicrc with the
-rcfile
as follows
Copy code
$ magic -rcfile ../../magicrc  # Pointing to PDK_ROOT/sky130A/libs.tech/...
> source INV.tcl
< (it works)

$ magic -rcfile ../../magicrc INV.tcl
< Error parsing "INV.tcl": invalid command name "magic::u2l"
< Main console display active (Tcl8.6.13 / Tk8.6.13)
< (it don't works)
t
I can confirm the problem easily. Looks like reading the script file fails on an unknown array variable. Not sure why.
It seems that magic doesn't read the wrapper script that defines the whole GUI. I might have missed this problem by always testing the use of a script as an argument on the command line in batch mode.
So far I'm just looping in circles trying to track down the cause of this.
🫢 1
Okay, I finally tracked it down; it was as I suspected. I had only ever tested use of a script on the command line as a way of running a batch process, so I didn't notice that it causes an error with interactive use. The problem is that when using the Tcl/Tk GUI, the initialization script appended "-nowindow" to the end of the command line to assert that the window is provided by Tk. But the rule is that all command line arguments following a Tcl script name are considered to be arguments of the script, not arguments of magic. So the "-nowindow" argument got passed to the script, not to magic, causing all sorts of issues. I just fixed this in version 8.3.472 which I just pushed to opencircuitdesign.com and which will mirror to github in about 6 hours.
🔥 1
a
That's wild, thank you very much for the effort put into making
magic
a better tool.