https://open-source-silicon.dev logo
Join Slack
Powered by
<@U01TEMQ2TLM>: Too many issues running FaSOC, an...
# magic
t
@saicharan0112: Too many issues running FaSOC, and I am already overloaded on commitments. Can you provide a .mag file and an extract command recipe that shows the error?
m
I’ll create an issue with reproducible data, but it only shows up with a modified tech file (with my data).
t
That's fine, as long as it's reproducible.
s
I just downgraded the magic version to 8.3.327 and the open_pdk to this commit (https://github.com/RTimothyEdwards/open_pdks/commit/5becac138d0ab0c69c7e8b7a00a96f20474512ba) via conda-eda packages. I no longer see this issue
Let me share the .mag file.. I have the final gds. Is there any command to convert that into a .mag file?
t
Yes, but it might not produce the error after conversion. If the original was a GDS file, though, then just post the GDS file.
s
@Tim Edwards Sorry for the delay. I wanted to confirm the issue with the version combinations
bug_decap_20221006.tar.gz
Check the readme file for the {openroad,magic,open_pdks] version combinations and the corresponding gds file
I still think it is something to do with openroad
@mehdi FYI
m
why is that?
t
@saicharan0112 @Mitch Bailey: It appears to be system-dependent because I can't get magic to raise any error on extracting the layouts. It would be helpful if somebody could run magic under the debugger and break on 
freeMagic()
if 
cp == 0
, then do a 
bt
backtrace to figure out which routine tried to free a NULL value.
m
Copy code
#0  freeMagic (cp=0x0) at malloc.c:140
#1  0x00007ffff6d42860 in extUniqueCell (def=0x555556e4b940, option=0) at ExtUnique.c:166
#2  0x00007ffff6d21332 in ExtUnique (rootUse=0x5555556904f0, option=0) at ExtMain.c:409
#3  0x00007ffff6c97cad in CmdExtract (w=0x55555564a080, cmd=0x555555b155e0) at CmdE.c:1038
#4  0x00007ffff6d7787b in WindExecute (w=0x55555564a080, rc=93824993286608, cmd=0x555555b155e0) at windMain.c:415
#5  0x00007ffff6cecee5 in DBWcommands (w=0x55555564a080, cmd=0x555555b155e0) at DBWprocs.c:632
#6  0x00007ffff6d74426 in WindSendCommand (w=0x55555564a080, cmd=0x555555b155e0, quiet=1 '\001') at windSend.c:263
#7  0x00007ffff6d6c9c0 in TxTclDispatch (clientData=0x0, argc=2, argv=0x555555573fd0, quiet=1 '\001') at txCommands.c:1180
#8  0x00007ffff6e897ee in _tcl_dispatch (clientData=0x0, interp=0x555555566120, argc=2, argv=0x555555573fd0) at tclmagic.c:400
#9  0x00007ffff7e221eb in TclInvokeStringCommand () from /lib/x86_64-linux-gnu/libtcl8.6.so
#10 0x00007ffff7e23fb7 in TclNRRunCallbacks () from /lib/x86_64-linux-gnu/libtcl8.6.so
#11 0x00007ffff7e253af in ?? () from /lib/x86_64-linux-gnu/libtcl8.6.so
#12 0x00007ffff7ede3f8 in Tcl_FSEvalFileEx () from /lib/x86_64-linux-gnu/libtcl8.6.so
#13 0x00007ffff7edcd57 in Tcl_EvalFile () from /lib/x86_64-linux-gnu/libtcl8.6.so
#14 0x00007ffff6dbb55f in mainInitFinal () at main.c:1181
#15 0x00007ffff6e8a2ac in _magic_startup (clientData=0x0, interp=0x555555566120, argc=1, argv=0x555555573b90) at tclmagic.c:740
#16 0x00007ffff7e221eb in TclInvokeStringCommand () from /lib/x86_64-linux-gnu/libtcl8.6.so
#17 0x00007ffff7e23fb7 in TclNRRunCallbacks () from /lib/x86_64-linux-gnu/libtcl8.6.so
#18 0x00007ffff7e253af in ?? () from /lib/x86_64-linux-gnu/libtcl8.6.so
#19 0x00007ffff7ede3f8 in Tcl_FSEvalFileEx () from /lib/x86_64-linux-gnu/libtcl8.6.so
#20 0x00007ffff7edcd57 in Tcl_EvalFile () from /lib/x86_64-linux-gnu/libtcl8.6.so
#21 0x00007ffff7ee5f6e in Tcl_SourceRCFile () from /lib/x86_64-linux-gnu/libtcl8.6.so
#22 0x00007ffff7ee64bd in Tcl_MainEx () from /lib/x86_64-linux-gnu/libtcl8.6.so
#23 0x000055555555522d in main (argc=6, argv=0x7fffffffe2f8) at magicdnull.c:49
In 
extUniqueCell
, 
nodeList
is null. I don’t know if this is the same thing @saicharan0112 is seeing or not. It doesn’t appear to be effecting my LVS results.
@saicharan0112 Can you post your extraction log and extraction commands? I’m having trouble duplicating the error with your data.
s
@Mitch Bailey It has the script which contains the instructions to extract the netlist. It also contains the .magicrc and the .tech file which are used here. Check the readme file for open_pdks and magic version that are used for this process
bug_decap_20221007.tar.gz
👍 1
@Tim Edwards, @Mitch Bailey - Regarding the lvs, for the first evaluation, the cell 
sky130_fd_sc_hd__decap_4
matches but after the parallel/series device merging, they don't.
@mehdi I am not sure but just with the change in openroad version, this issue shows up.
t
@saicharan0112: It sounds like the error in magic is both non-fatal and unrelated to the LVS error. The LVS error sounds like it may have to do with running LVS on two netlists where one of them has altered the number of decap cells. This would show up as a property error (different number of decap cells in each netlist) and most likely reflects that LVS is being done against the wrong netlist.
@Mitch Bailey: Thanks for the backtrace. The error is easy to fix, and was clearly having no effect other than printing a mysterious warning to the terminal.
👍 1
s
@Tim Edwards - I think you are right. Its with the netlist that is generated from the openroad. So, the freeMagic() message with the decap cells has nothing to do with Magic? Is it a harmless bug or something inside Magic?
t
@saicharan0112: It is a harmless bug in magic which I just fixed and pushed.
🙌 1
2 Views
Open in Slack
PreviousNext
Powered by