search

RTimothyEdwards / magic

Magic VLSI Layout Tool
Other
447 stars 100 forks source link

"Types are not handled by extraction and will be treated as non-electrical types" message in Arm MacOS Magic built from source #285

Open gmejiamtz opened 6 months ago

gmejiamtz commented 6 months ago

With a Magic built from source, console displays the message:

The following types are not handled by extraction and will be treated as non-electrical types: n_field_implant p_field_implant nselect pselect glass filln filla fillb xp m1p m2p m3p comment bb

Upon making a simple inverter and extracting it to spice, vdd, gnd and the output label Z are floating. When installing magic on an x86 vm and making the same inverter spice extraction works fine and no nodes are floating. Both inverters are using SCME_SUBM.30 as the technology. On ARM MacOS, the tech files are in /usr/local/lib/magic/sys/current adn in x86 Linux they are at /usr/lib/x86_64-linux-gnu/magic/currnet`.

inverter_in_arm_macos_magic inverter_in_x86_linix_magic macos_spice_top_and_linux_spice_bottom magic_console_in_arm_macos magic_console_on_x86_linux
RTimothyEdwards commented 6 months ago

The message about "Types are not handled by extraction" is merely a diagnostic message. . . I added it relatively recently so it may look new to somebody used to the behavior with respect to the old SCMOS tech files. However, it is not describing any new behavior and should not be related to the issue at hand.

The issue you show is that some extracted parasitic capacitances are marked as "floating". This is most likely due to more sophisticated handling of substrates in magic, and the substrate handling is no longer strictly backwards-compatible with the SCMOS tech files. Adding a "substrate" line to the extract section of the tech file should fix the issue. You can take a look at the technology files that are distributed with "qflow"; these are old SCMOS tech files with a few modifications to make them better compatible with recent versions of magic (note that where nodes are marked as "floating", the substrate has been identified as node "0" and not "gnd"). I normally try to maintain backwards compatibility with the old SCMOS tech files and it looks like the treatment of parasitics may have unintentionally broken the backwards compatibility.

Otherwise, the difference between the file produced by extraction on the two systems appears to be that one was done with parasitic extraction (ext2spice cthresh 0) and the other without (ext2spice cthresh infinite). It's possible that there is an obscure bug causing a system-dependent default setting of the cthresh parameter (such as an uninitialized variable somewhere). If you repeat the procedure but run the command "ext2spice cthresh" at the end (no other arguments), then it will return the value that it thinks the cthresh parameter is set to. If it is different on the two different systems, and it was not intentionally set that way, then I will need to check for system-dependent behavior.

Meanwhile, the (presumed) workaround would be to specifically set "ext2spice cthresh" ("0" or "infinite") before running "ext2spice", so that the behavior is predicatable (please confirm that that is true).

gmejiamtz commented 6 months ago

For now I reverted back to version 8.3.105 since that is the one the Linux machine installed via APT. Following the MacOS install instructions this version worked properly.