magic
magic copied to clipboard
MSubcircuit Extraction Method inconsistency
Hello! I'm trying to get deeper into Magic's codebase, but I'm just at the beginning. As some newer features are undocumented, I'm not sure about the exact construct usages or implementation decisions - so I'm sorry for silly or redundant issue, as my understanding of the code is still strongly limited.
However, I recently experimented with "msubcircuit" extraction method in ext2spice and I found an inconsistency with the "mosfet" method.
For "mosfet", the terminal ordering is "d g s", which is correct for SPICE models, however, for "msubcircuit", the ordering is different: "s g d". It seems to me, that it might be confusing (when I use hand-written subcircuits, I prefer the same ordering for mosfet models as well as for subcircuits) - is there any reason behind?
Why are the mosfet attributes like drain/source area not available for "msubcircuit"? Those may be valuable for custom models.
Generally a MOSFET drain and source will be indistinguishable, so it doesn't matter what order they are in. Unless the device is an asymmetric MOSFET (like an extended drain device), which is a different extraction type, then magic's choice of which side of the device is the source and which is the drain is arbitrary.
That is, for a regular MOSFET, magic only distinguishes between "gate" and "other terminals", so you might get "d g s" or "s g d" for any device regardless of whether you are using the "device mosfet" or "device msubcircuit" methods.
The drain/source area are specific parameters to the M device in SPICE. For subcircuits (X device in SPICE), you need to declare parameters that are recognized by the subcircuit, which is what the parameters in the extraction statement are for.
This is all documented; see http://www.opencircuitdesign.com/magic/techref/maint2.html (documented but not well organized or indexed).
Oh, thank you for pointing me to the right document, probably I used the older version referenced here http://www.opencircuitdesign.com/magic/magic_docs.html :-(
D/S are indistinguishable in general, however, this is not the correct behaviour in the annotated case. In my case drain/source are annotated by using D$/S$ labels and I expect correct and consistent ordering - my point was just related to consistent ordering, especialy when Drain/source are explicitly defined. I know, that this feature was added several years ago, but stil ... it seems to me inconsistent.
I belive, that "msubcircuit" (or anything) with annotated D/S should be equal to asymmetric MOSFET in the D/S uniqueness.
To be honest, I tried "blind" parameter setting, but I got strange results, so I expected I did something wrong in my code understanding/definition; I redefined extract section in SCN6M_SUBM.10.tech from:
device mosfet pmos pfet pdiff,pdc nwell ERROR 70 81
device mosfet nmos nfet ndiff,ndc pwell,space/w ERROR 73 83
to
device msubcircuit pmos pfet *pdiff *pdiff nwell error l=l w=w ad=ad as=as
device msubcircuit nmos nfet *ndiff *ndiff pwell,space/w error l=l w=w ad=ad as=as
But I got different values of as/ad for both cases, e.g.:
X10 VDD Y O VDD pmos as=2p ad=0p w=4u l=0.2u
X11 GND Y O GND nmos as=1p ad=0p w=2u l=0.2u
M1010 O Y VDD VDD pmos w=4u l=0.2u ad=2p pd=9u as=0p ps=0u
M1011 O Y GND GND nmos w=2u l=0.2u ad=1p pd=5u as=0p ps=0u
For msubcircuit, ad is missing at all and as has the original ad value (taking mosfet extract as an reference).
Okay, I get the issue now---failure to handle the D$/S$ attributes correctly in the "device msubcircuit" model. That is almost certainly an unintended oversight, and should be trivial to fix.
I have fixed the ext2spice code and pushed to the repo on opencircuitdesign.com. The tarball will be created and the github repo mirrored overnight tonight. Please check and confirm the fix.
@RTimothyEdwards -- Is this related to the other instability in #29 ?
@mithro : It shouldn't be. Besides, there seems to be a lot more going on there, especially with devices going missing completely, and the technology name showing up as (null). This particular error has gone unnoticed for years because it doesn't show up unless you try to tag (with labels) a device's source and drain.
@RTimothyEdwards It seems, that I caused some confusion, I'm sorry! The issue is still there but in a different form.
(Currently, I tested the latest commit in the master branch)
My point was, that the ordering is confusing, but the semantics was correct - drain was drain and source was source (in the annotated case). Now it is incorrect.
Originally (before applying your patch), I got:
X10 VDD Y O VDD pmos as=2p ad=0p w=4u l=0.2u
X11 GND Y O GND nmos as=1p ad=0p w=2u l=0.2u
And here, the semantics was correct - the ordering was different than for mosfet (as I pointed, that it is confusing) but the semantics is correct, as GND and VDD are annotated as sources and O as drain - from source code:
/* MOS-like subcircuit is "Xnnn source gate [drain [sub]]" */
Now the semantics changed:
/* MOS-like subcircuit is "Xnnn drain gate [source [sub]]" */
but the output is the same - that means, that VDD and GND are considered drains:
X10 VDD Y O VDD pmos as=2p ad=0p w=4u l=0.2u
X11 GND Y O GND nmos as=1p ad=0p w=2u l=0.2u
Here -in the patched version, the semantics is incorrect.
And compared to the mosfet export output, the as and ad values are still swaped:
M1010 O Y VDD VDD pmos w=4u l=0.2u ad=2p pd=9u as=0p ps=0u
**devattr s=S d=D
M1011 O Y GND GND nmos w=2u l=0.2u ad=1p pd=5u as=0p ps=0u
**devattr s=S d=D
And actually, all the "ad" values in the whole SPICE netlist file are "0p", compared to the "mosfet" export generating correct ad and as values across the netlist. It seems, that magic drops ad value completely in the "msubcircuit" case.
Do you want to share my annotated testcircuit and modified techfile?
@belohoub : Sorry, just getting back to responding to this. There was clearly an error in the code with the identified source being written before the identified drain in the case of the "msubckt" type. The code fix corrects that. Any remaining problems are probably due to the lack of clear documentation on the subject of terminal attributes. The attached file:
has a layout (for SkyWater sky130A) that uses attribute labels to identify the source and drain. This file also correctly outputs the transistors as marked. What I found, though, was that I specifically had to set the label to layer "nmos" when I created it, and the label has to be exactly on the boundary between the gate and terminal. The default action seems to be to connect the label to the terminal type, not the gate type, which then prevents it from being seen. So for each gate, I set the cursor box size to zero, placed it on the edge between gate and terminal, and then did either label S$ c nmos
or label D$ c nmos
.
@RTimothyEdwards It's OK, I was also bussy, but we are nicely synchronized :-) : tomorow - before you submitted your comment - I also returned to it.
I tested the updated master branch, but it was still problematic. But I found the problem and I've a patch - I'll try to create a pull-request. :-)
The problem with attribute labels is known to me - although it is undocumented, I noticed the bad behaviour during my experiments with attributes and I compared the label layers with the example .mag files supplied with magic docs and I originally found the solution intuitively, thus my testcircuit was correct from the beginning (before I opened this issue). In the docs, only the note about "on the boundary" is present, however, the layer issue was not so tricky.
The alternative way to place the attribute, I found, was: I set the cursor box size to zero, then I placed the label to the middle of the terminal and then I moved the label to the gate edge - this is less explicit than your command, but it also ensures connecting the attribute to the correct layer.
I created a pull-request: there was an error: node parameters (e.g. as/ad) were not swapped when attributes were used leading to attribute swap. And I also originally misused the techfile parameter type/name setting - I found it during my work on the patch, as I decoded the techfile values meaning :-)
With techfile SCN6M_SUBM.10.tech containing the following definition:
device msubcircuit PMOS_MAGIC pfet *pdiff *pdiff nwell error l=l w=w a1=as p1=ps a2=ad p2=pd
device msubcircuit NMOS_MAGIC nfet *ndiff *ndiff pwell,space/w error l=l w=w a1=as p1=ps a2=ad p2=pd
it works as expected.
ext2spice now also generates attribute-related comments also for MBSubcircuits.
Note, that there are still some "TxPrintf()" calls I used for debugging, those should be maybee removed ...
I hope, that theis fix is OK.
But there is still some confusion - I'm sorry for silly question/comment, but the codebase is huge and I'm still not able to fully understand all the aspects and relationships in the code.
The confusing part is: I (and also you) originally edited the spcdevVisit() function in the ext2spice.c file, but it looks, that this function is never executed. Instead, function spcdevHierVisit() from ext2hier.c is executed. Those files contain a lot of redundant code. Is there any purpose behind? Or e.g spcdevVisit() is simply deprecated? In my patch, I modified both functions, but maybee, some ext2spice.c parts should be removed to make the code more readable and maintainable... ? I don't know.