@Stephen Sigdox has left the channel

Is there an easy way to have magic error out if there is geometry outside the defined cell area ? Like we provide a DEF template to users (for size / pin position / ...), but seems that if the user put meta outside the area, and then write the LEF, the LEF will still ahve the size we defined in the template but will have OBS outside of it. We'd like to see that as an error.

Everyone, I'm trying to move a subcell on magic, but i cant't, it moves the entire cell and tkcon says "You select on or more subcells that aren´t children of the edit cell. Only those in the edit cell were modified."

Can you show a full height / width cross hair following the mouse (to ease aligning things) ?

Hi, I am trying to run the LVS but after extracting the layout I get some big floating capacitors, is there any way to get rid of them without using shorter connections? thanks

Hi, although I labeled the pins, after the extraction for LVS I get the pin mismatch error.

Hi, I connected the layout to wrapper pads, ran LVS, I got: Circuits match uniquely with port errors. The undriven pads could be the reason? everything looks fine in the log

Hello, running the pre-check locally on our full Analog macro now. Getting hundreds of these errors - is there any way to tell Magic to merge the transistors in the layout on extraction?

Hello everyone, we are getting conflicts in LVS between resistors we have drawn in Magic and the .spice netlist extracted from Xschem. Here's an example:

message has been deleted

In the left column (from the layout), Magic is not extracting my resistors with the suffix

_0p35

. These were generated by the device generator in Magic, and in the layout it definitely looks like the suffix is present on these cells:

message has been deleted

In the schematic, the resistor devices have the

_0p35

suffix:

Just wondering the best way to resolve the conflict. There are resistor symbols in the Xschem PDK which don't contain the suffix - should I be including these instead? Or, is Magic extracting the layout incorrectly? Any advice appreciated 🙂

Hello, a further Magic related LVS question. Magic seems to be recognising a large piece of Deep N Well as a parasitic device. All of the cells in the hierarchy that reference the cell containing the Deep N Well have an added subcircuit pin in their subcircuit definitions in

user_project_wrapper.gds.spice.

In both layout and schematic, the net associated with the Deep N Well is labelled (

TXRX_B_POS_via_R

), but not ported out, so the .spice file from Xschem doesn't show it. Therefore we have LVS mismatches because every cell in the Layout has one extra pin in their pin list than in reality. The behavior is similar to what we've seen when the parasitic extraction is on in Magic. Is there any way to stop this happening please? 🙂

Heres the net in Magic and the same nets appearing through the hierarchy as pins in `user_project_wrapper.gds.spice`:

Here's the error in the LVS report (the long name of the port has been cut down in the left column)

Adding a resistor to pull the Well up to VDD or down to VSS makes no difference

@Ellen Wood: Try drawing layer "pwell" under the nFETs, connecting both the transistor and the tap. The "pwell" is not a physical mask layer, but it should help magic figure out that there's a pwell in the middle of the deep nwell structure.

Hello everyone, does the Magic version which is now used in the updates Mpw9f shuttle precheck have updated DRC rules? We were previously getting no DRC errors during the Magic DRC stage of the precheck, and now over 1000 have appeared!

Does the extraction of parasitic capacitances take into account the increase in capacitance by the metal fill? It seems to me the metal fill can substantially alter the extracted capacitances. Given the large fill in M1 to M3 the capacitances might be increased by almost 50% for the upper metal layers due to the fill. Is the fact that metal fill will be added taken into account? For example: Between M2 and M4 there is M3. If there is no metal on M3, but a delectric, the dielectric thickness between M2 and M4 is 1.65µm. If there is metal on M3, the dielectric thickness is reduced to 0.8 µm. This is substantial!

Hi, I do not know why I'm getting port errors running LVS. I labeled them like label port_name and the label was properly attached to the metal. I have them on the extracted netlist also but I get port errors. Netlists match uniquely with port errors.

@Tim Edwards I suspect I might have ran into a typo on the latest magic commit. I've put a comment in here: https://github.com/RTimothyEdwards/magic/commit/8445f3eb5d2c873313c4044e55e08e2f0e3f2c89

Hello, I have a few questions I'd like to ask: • 1. While trying to align LVS, it seems that the layout's SPICE recognizes four more devices compared to the SPICE from the schematic. I used 4 MOSFETs in the layout, and I'm wondering if it's possible for additional devices to be recognized due to interconnections. When examining the layout's SPICE file, it appears that the subcircuit of the MOSFETs I used might have generated these extra instances. I attempted to remove them, but it seems that the circuit doesn't match. Is there a way to prevent these from being created, or could the issue stem from another aspect? ** I've attached two SPICE files and the first figure showing the comp.out results. • 2. In the schematic's netlist, it seems that the order of pins following the MOSFET name indicates drain, gate, source, and body. However, in the layout's netlist, there are more pins generated. How can I understand the sequence here? Could the multiple pins be attributed to finger connections? **I've attached second figure • 3. After performing extraction to generate the SPICE file, I see diagonal white lines appearing in the layout, similar to the attached picture. It seems to signify an issue within my layout, yet I'm uncertain about the specific problem. When using 'feedback find,' errors like 'label attached to more than one unconnected node' or 'device missing 1 terminal' often appear. Clicking with 's' for the port seems to indicate proper connections, but I can't identify why these errors persist. **I've attached third figure I apologize for the scattered nature of my questions. If anyone has relevant information or helpful insights, I'd be tremendously grateful for any guidance provided.

@권미정 The 4 devices you’re seeing in the extracted layout are pcells. For example, this subckt

sky130_fd_pr__nfet_01v8_YCY3T5

is not a mosfet, but a subckt containing 4 mosfets. At the parent hierarchy, these are probably connected in parallel, but at this level, there are separate ports for each source/drain. I suspect the problem might come from a missing setup file when executing netgen. I suggest

netgen "tah.mag.spice.txt tah" "tah.sch.spice.txt tah" $PDK_ROOT/$PDK/libs.tech/netgen/${PDK}_setup.tcl

If you can share your

comp.out

file, I might be able to offer more suggestions.

@Tim Edwards Here is a tough one, I think there should be a solution for cases like this: We assembled the PEX netlist (created by Magic) of two blocks manually into one (PEX) SPICE netlist, each one containing standard cells. Strangely, simulation delivered weird results, while individual blocks were OK. @Patrick Fath debugged this over the weekend, and turns out: Port order on standard cells can change?!? Q1: Is that even possible? Q2: How can we make sure that cells (standard cells and otherwise) have a consistent pin order on extraction? Maybe the PEX should give cells a (random) name extension (like top cell name of extraction, or date/time code), so when adding two PEX netlists together, cells are kept unique, if there is no “guaranteed” port order on extraction.

Hi. When i use netgen to compare netlists, if the top-level file has a subckt wrapper netgen complains that the netlist contains no devices. Is there a way to fix this?

Does anyone know why magic puts the line

.option scale=5n

at the top of a paracitic extracted netlist for GF180mcu

Happy Thanksgiving! (if applicable) I'm having trouble with the extresist part of my PEX flow. It seems that when I turn it on parts of my circuit just disappear or are left unconnected, yet when I turn it off I don't have the issue. I have a 10-bit DAC and when i follow the path from "din[0]" for example in the version with extresist on I only manage to get to the gate of the nFET in the first buffer but not the pFET. This explains why in the simulation waveform the drain never goes high. If on the other hand I turn off extresist, I can get to both the pFET and the nFET of the first buffer, and as expected, the simulation works. I have attached both netlists incase anyone would be able to taka a look for me. I'f be grateful for some insight as to what's going on. The net

din[0].t0

in the resistor extracted netlist goes to the gate of the nFET but I can'd find an equivalent path to the pFET, which aligns with the failing simulation. My extraction procedure is as follows:

load $MAG_CELL
flatten ${CELL_NAME}_pex
load ${CELL_NAME}_pex
box values 0 0 0 0
extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist all
ext2spice lvs
ext2spice cthresh 0
ext2spice extresist on
ext2spice -o $OUTPUT_FILE_NAME
exit

Thanks in advance!

I extracted the data (full RC) as follows and created a .spice file. However, I noticed that there is information for capacitance but no information for resistance. I'm not sure what the problem is. Could you please let me know? https://open-source-silicon.slack.com/archives/C016YSAP6TZ/p1658077663367089?thread_ts=1657882815.583849&cid=C016YSAP6TZ