GF180mcu_fd_pr editing cell property (Ctrl+P) throws error and hangs viewport

[ollelogdahl]

When updating gf180mcu nfet parameter cells, Magic has a tendency to break (update not applied successfully, showing an error message, viewport rendering is broken). The issue is sporadic but deterministic and quickly occurs under normal working conditions.

To Reproduce
Its not very clear what exactly triggers this bug, and I think there are multiple bugs. If you fail to replicate using the steps below, try more combinations of copying cells and changing one of the older cells' properties. Doing this I can quickly get a crash with arbitrary steps. Simply changing the instance name seems to cause this sometimes.

Steps to reproduce the behavior:

1. Start up a fresh container from iic-osic-tools using ./iic-osic-tools/start_x.sh. (https://github.com/iic-jku/IIC-OSIC-TOOLS)
2. Run sak-pdk gf180mcuD
3. Run magic
4. Click Devices 1 > nMOS in the top menu.
5. Leave everything default and click Create & Close
6. While this cell is still selected, press c to copy it anywhere.
7. With the new copied cell selected, press ctrl+p to open properties. Change width to 1um. Press Okay

You now get a popup saying "Error" with nothing more. Clicking details gives:

    while executing
"instance list exists $newinstname"
    (procedure "magic::gencell_change" line 19)
    invoked from within
"magic::gencell_change nfet_03v3_K2E6BN_1 nfet_03v3 gf180mcu {} "
    invoked from within
".params.buttons.okay invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 22)
    invoked from within
"tk::ButtonUp .params.buttons.okay"
    (command bound to event)

Pressing OK and cancelling, the main viewport rendering is broken: the main viewport is filled with black and can only be restored with a restart.

Expected Behavior

• I want it to be easy to try changes without effectively needing to restart the application.
• Errors in the gencell script are OK but should maybe be caught with an error message and not crash the application?
• There should ideally not be issues when just trying to change name / simple properties.

Additional Information
This has additionally been filed to iic-osic-tools (iic-jku/IIC-OSIC-TOOLS#310) but feels like it is a PDK/magic issue.

• OS: Linux (windowing: wayland & hyprland)

Magic log:

loading history file ... 5 events added
Use openwrapper to create a new GUI-based layout window
Use closewrapper to remove a new GUI-based layout window

Magic 8.3 revision 664 - Compiled on Mon Jun 15 08:31:32 AM CEST 2026.
Starting magic under Tcl interpreter
Using Tk console window
Using TrueColor, VisualID 0x40 depth 24
Processing system .magicrc file
Switching to WIRING tool.
Switching to NETLIST tool.
Switching to PICK tool.
Switching to BOX tool.
Sourcing design .magicrc for technology gf180mcuD ...
10 Magic internal units = 1 Lambda
Input style import: scaleFactor=10, multiplier=2
The following types are not handled by extraction and will be treated as non-electrical types:
    obsactive mvobsactive filldiff fillpoly m1hole obsm1 fillm1 obsv1 m2hole obsm2 fillm2 obsv2 m3hole obsm3 fillm3 m4hole obsm4 fillm4 m5hole obsm5 fillm5 glass fillblock lvstext obscomment 
Scaled tech values by 10 / 1 to match internal grid scaling
Loading gf180mcuD Device Generator Menu ...
New windows will not have a title caption.
New windows will not have scroll bars.
New windows will not have a border.
Repainting console in magic layout window colors
Using technology "gf180mcuD", version 1.0.599-0-gb344c97
Root cell box:
           width x height  (   llx,  lly  ), (   urx,  ury  )  area (units^2)

microns:   0.050 x 0.050   ( 0.000,  0.000), ( 0.050,  0.050)  0.002     
lambda:     1.00 x 1.00    (  0.00,  0.00 ), (  1.00,  1.00 )  1.00      
internal:     10 x 10      (     0,  0    ), (    10,  10   )  100       
Main console display active (Tcl8.6.14 / Tk8.6.14)
Loading DRC CIF style.

[ollelogdahl]

To troubleshoot this, I have compiled & installed magic master on my machine. Using the exact same pdk distribution (installed via ciel and copied out of docker), I can run: magic -rcfile ~/pdks/gf180mcuD/libs.tech/magic/gf180mcuD.magicrc

This is maybe somewhat misconfigured, but these settings manage to recreate the same kind of error popup.

And after closing this add menu, the rendering is dead again:

Really this report is:

1. We should produce better error messages (OR, the nfet pcell shouldn't be broken? idk)
2. We shouldn't crash the rendering thread when this popup occurs.

[ollelogdahl]

gf180mcuD version (via ciel): b344c97eacc2aaf8e14ae7e43e2e9dc0871de2c0 (fossi-foundation/open-pdks@b344c97)

[RTimothyEdwards]

If the viewport hangs, run the command resumeall (which may be necessary to do several times, if it was called in a nested manner). There is presumably a way to handle errors such that an error in the middle of a suspendall call will automatically exit out of the graphics suspended state.

I am unable to reproduce the problem here, but as yet I have not tried the specific PDK version that you mentioned. However, I have not done any recent development on the gf180 PDK support for magic, so I doubt that there is any difference. I will keep trying to see if I can re-create the error response that you are seeing.

[ollelogdahl]

Thank you for the reply!

Regarding hangs, I think its fine to leave running resumeall to the user. One other idea that may be suitable is ensuring that all third-party code that does suspend (like this case PDKs) are always wrapped in a try catch with a resumeall guaranteed to run. This way, noobs like me don't get so confused! :^)

After playing around with it more, it feels like it doesn't occur if doing Apply then Close separately. I still had some cases when it occurs, where I assume the input is invalid. One example I found was resistors, but now I don't fully remember what I did... I'll update this when I know more, but I think maybe this is an issue with the PDK parameter cells.

[RTimothyEdwards]

There's a good chance that this has nothing at all to do with the PDK but is some issue with timing between Tk and the window manager regarding when windows are created and destroyed vs. being referenced. Especially since "Apply" then "Close" just executes the same sequence of commands as "Apply and Close", just with some delay in between. That is, the callback function is checking for an instance in the layout that ought to exist by the time the callback is executed, but maybe doesn't. But that's just a random theory off the top of my head. At any rate, it's a known fact that development work on the GF180MCU support for magic stopped when Efabless stopped running open MPW shuttle runs on GF180MCU, and needs to be taken up again and completed now that Wafer.Space has re-started the GF runs.

[tskaar]

FYI: I have seen this issue happen with the IHP PDK as well:

I always just assumed this was a Tk in XWayland bug/issue.
For reference I use Jay, which is a Wayland tiling window manager, same as Hyprland (as OP uses).

[ollelogdahl]

Yes, it does seem to be a bug related to windowing, we should probably rewrite and improve this issue. @tskaar Do you experience it working when only pressing "Apply"?

After using magic a lot more, and I don't know if this is PDK issues or not, it seems almost random when "Apply" (which leaves the window open) works. I often need to press it twice and then use resumeall.

[tskaar]

In the image I posted, that was when I clicked "apply", I did the following:

1. Create & close instance
2. CTRL+P
3. Modify fingers (1->2)
4. Click Apply

Note: I have been able to trigger this issue/error on both: "Create" and "Create & close" during instantiation as well.
I haven't seen anything particularly deterministic about it; sometimes it errors, sometimes it doesn't 🤷