<@U016EM8L91B> I got a new crash for you. Sorry :...
# magict
tnt
11/18/2020, 11:08 AM@User I got a new crash for you. Sorry 😕
Copy code
Program terminated with signal SIGSEGV, Segmentation fault.
#0 CIFPaintCurrent (filetype=1 '\001') at CIFrdcl.c:630
630 newplane = parray[pNum];
(gdb) bt
#0 CIFPaintCurrent (filetype=1 '\001') at CIFrdcl.c:630
#1 0x00007fbc55c8ffbf in calmaParseStructure (
filename=0x7fbc55da6120 <realName.14544> "/home/tnt/sky130/openlane_workspace/openlane/designs/pyfive_no2usb/runs/test_diode/results/magic/usb_sky130.gds") at CalmaRdcl.c:450
#2 0x00007fbc55c8ec54 in CalmaReadFile (file=0x565291a1b3a0,
filename=0x7fbc55da6120 <realName.14544> "/home/tnt/sky130/openlane_workspace/openlane/designs/pyfive_no2usb/runs/test_diode/results/magic/usb_sky130.gds") at CalmaRead.c:207
#3 0x00007fbc55b487d9 in CmdCalma (w=0x565291582ca0, cmd=0x565291a4ce40) at CmdCD.c:571
#4 0x00007fbc55c2fca7 in WindExecute (w=0x565291582ca0, rc=94912625829376, cmd=0x565291a4ce40) at windMain.c:414
#5 0x00007fbc55ba5d16 in DBWcommands (w=0x565291582ca0, cmd=0x565291a4ce40) at DBWprocs.c:598
#6 0x00007fbc55c2c559 in WindSendCommand (w=0x565291582ca0, cmd=0x565291a4ce40, quiet=1 '\001') at windSend.c:263
#7 0x00007fbc55c2460a in TxTclDispatch (clientData=0x0, argc=3, argv=0x565291496230, quiet=1 '\001') at txCommands.c:1180
#8 0x00007fbc55d3a2ec in _tcl_dispatch (clientData=0x0, interp=0x565291488380, argc=3, argv=0x565291496230) at tclmagic.c:400
#9 0x00007fbc56ff59ab in TclInvokeStringCommand () from /lib/x86_64-linux-gnu/libtcl8.6.so
#10 0x00007fbc56ff7777 in TclNRRunCallbacks () from /lib/x86_64-linux-gnu/libtcl8.6.so
#11 0x00007fbc56ff8b6f in ?? () from /lib/x86_64-linux-gnu/libtcl8.6.so
#12 0x00007fbc570b1bb8 in Tcl_FSEvalFileEx () from /lib/x86_64-linux-gnu/libtcl8.6.so
#13 0x00007fbc570b0517 in Tcl_EvalFile () from /lib/x86_64-linux-gnu/libtcl8.6.so
#14 0x00007fbc55c762c2 in mainInitFinal () at main.c:1164
#15 0x00007fbc55d3ae17 in _magic_startup (clientData=0x0, interp=0x565291488380, argc=1, argv=0x565291495df0) at tclmagic.c:725
#16 0x00007fbc56ff59ab in TclInvokeStringCommand () from /lib/x86_64-linux-gnu/libtcl8.6.so
#17 0x00007fbc56ff7777 in TclNRRunCallbacks () from /lib/x86_64-linux-gnu/libtcl8.6.so
#18 0x00007fbc56ff8b6f in ?? () from /lib/x86_64-linux-gnu/libtcl8.6.so
#19 0x00007fbc570b1bb8 in Tcl_FSEvalFileEx () from /lib/x86_64-linux-gnu/libtcl8.6.so
#20 0x00007fbc570b0517 in Tcl_EvalFile () from /lib/x86_64-linux-gnu/libtcl8.6.so
#21 0x00007fbc570b972e in Tcl_SourceRCFile () from /lib/x86_64-linux-gnu/libtcl8.6.so
#22 0x00007fbc570b9c7d in Tcl_MainEx () from /lib/x86_64-linux-gnu/libtcl8.6.so
#23 0x00005652900d7289 in main (argc=7, argv=0x7ffd267b15b8) at magicdnull.c:49tnt
11/18/2020, 11:17 AM Copy code
(gdb) print parray
$1 = (Plane **) 0x2d
(gdb) print cifReadCellDef->cd_client
$3 = (ClientData) 0x2dtnt
11/18/2020, 2:49 PMIf that helps the changes I had since last time is I updated OpenLane frm
d03377b84212527a269dfc58bb637a9e921af150t
Tim Edwards
11/18/2020, 3:00 PMNot an obvious error, and looks related to a comment I have in the code of the "this should not happen" variety. Can you get me the GDS file that causes the segfault so that I can use it to debug?
t
tnt
11/18/2020, 3:19 PMSure, as soon as I get back to that point in the flow (ATM it's not even getting through routing anymore) I'll post it.
tnt
11/18/2020, 3:38 PM@Tim Edwards there you go :
tnt
11/18/2020, 3:54 PMOh yeah, I forgot say say but this happen when doing
[INFO]: Saving .mag view With BBox Values: 0 0 248400 111790tnt
11/18/2020, 4:07 PMInterestingly I can load that gds just fine 😕 So that only happens when doing this script : https://github.com/efabless/openlane/blob/develop/scripts/magic.tcl
tnt
11/18/2020, 6:35 PM@Tim Edwards So after trying a bunch of stuff it seems the crash only happens if I write a GDS. Then load one. (doesn't need to be the exact one I just wrote)
For instance running this script crashes :
Copy code
drc off
lef read /home/tnt/sky130/openlane_workspace/pdks/sky130A/libs.ref/sky130_fd_sc_hd/techlef/sky130_fd_sc_hd.tlef
lef read /home/tnt/sky130/openlane_workspace/openlane/designs/pyfive_no2usb/macros/lef/sram_1rw1r_32_256_8_sky130_lp1.lef
def read /home/tnt/sky130/openlane_workspace/openlane/designs/pyfive_no2usb/runs/test_diode/tmp/routing/usb_sky130.powered.def
gds readonly true
gds rescale false
gds read /home/tnt/sky130/openlane_workspace/openlane/designs/pyfive_no2usb/macros/gds/sram_1rw1r_32_256_8_sky130_lp1.gds
load usb_sky130
select top cell
cif *hier write disable
gds write usb_sk130_bis.gds
gds read usb_sky130.gdst
Tim Edwards
11/20/2020, 10:48 PMI can confirm a crash condition by reading/writing/reading the GDS you posted. Undoubtedly it has something to do with reading back a GDS after writing one; still, I wonder why the script is doing this. . . Magic does not read the same thing back that it writes out (ideally it would, but that's almost never the case) so generally speaking, writing GDS is considered a one-way street.
t
tnt
11/20/2020, 10:49 PMThe "why" you'd have to ask @Ahmed Ghazy I guess
t
Tim Edwards
11/21/2020, 1:03 AM@tnt: I have tracked down and fixed the crash condition. _However_: The underlying problem seems to be that the GDS read just overwrites existing cells of the same name, and I would call this behavior "undefined". @Ahmed Ghazy: The referenced "scripts/magic.tcl" routine really should be broken into two parts, so that you do not read back the GDS data that you just wrote without exiting and re-entering magic first. So: write gds, quit, restart, read gds, and save. That should be safe.
t
tnt
11/21/2020, 7:16 AM@Tim Edwards 👍
tnt
11/21/2020, 7:18 AM@Ahmed Ghazy I already have a patch doing that, I'll open a PR this morning (gotta wake up and double check it first :p).
I also have a patch to add a conf variable to add obstructions, will open a PR for that too (just need to add it to the documentation)
tnt
11/21/2020, 11:29 AMtnt
11/21/2020, 11:30 AMAlthough as Tim said, why is re-reading the GDS needed before writing the MAG ? Can't that just be written from the DEF/LEF like the GDS ? Or maybe it's to ensure the MAG matches exactly what magic gets from reading the GDS ?
t
Tim Edwards
11/21/2020, 4:09 PM@tnt: Oh, I do know the answer to that one, which is that when the "gds readonly true" option is set, magic records the start and end positions of the data it reads and stores those as a property of the cell along with the location of the GDS file. Then the cell becomes an "abstract view", in effect, where magic does not attempt to rewrite the GDS data itself when writing the file, but copies the data from the source file to the destination file unchanged (except possibly to prefix the cell names to ensure no collisions with cells in the database). So to get those pointers, the GDS has to be read back, then the .mag file saved. Once again, I need a new command/option in magic like "gds annotate" which would do only the part where it finds the data positions and sets the properties, but doesn't actually read any data.
t
tnt
11/21/2020, 4:11 PMOh, ok, I see !
2 Views