If you add all the package construction layers and their
"connects", and same for the bond wire, then you can
do an end-end / top-bottom verification.
Most IC CAD PDKs are single-process and nothing for
packaging besides (if you're lucky…
If you have the data but it's not hooked up:
Tools>Manage Technologies
If you don't have the library data then hit up Skywater
or one of the open source fan clubs that surround the
foundry.
The way I see it, this is about making the parameter comparison
for a topoloy-matched device incorporate an "error band" rather
than demanding strict numerical equality.
Now if PCell:symbol properties 1:1 enforces that matchup,
then the…
That is a peculiar looking Java file and I wonder if it's a
"legacy" from a GloFo kit.
Might go to the root of the PDK and search for *.json,
see what -does- turn up where, maybe there's really a
sky130.json that's just waiting for an inv…
klayout does have the PCells and I believe your problem
lies with the scripts which turn properties into polygons -
evidently either absent, or someplace that klayout has not
been told to look.
Scripts have "paths-to". I'd first pore over…
I would go to the source and pull all the setup info you
can find. There should be orderly docs for that as it
purports to be a fully capable PDK. But expect "some
assembly required", for which there ought to be
instructions (or maybe th…
Yes, I often see subcircuits "wrapping" a MOSFET core
element - RF CMOS, see Rg, Ls, Ld added external to
the intrinsic FET; ESD GGNMOS clamps work a lot more
realistically when you add a breakdown element that
BSIM lacks (trivial D mode…
In my opinion a "parametric" circuit is not verifiable because
it's not "done" - it's subject to change until all variables have
become fixed. I don't know that this is something worth
trying to support. Maybe just as far as co…
Could you perhaps post a little write-up on your findings,
similar to other recent LVS-fail and -solution threads? I think
collecting "syndromes" and "cures" is valuable (worthy of
collection to the examples-pile, even. Maybe wi…
I don't know about netlist import here, but if you use
ngspice there are args to the 'listing' command which
can put you out a fully expanded netlist, even as far
as turning any variables into numerical values (like in
case you left a FET's W as a …
Not knowing anything, I'd ask whether there is a pattern of
highlighting the "not full ortho width" regions of the via
(width done on Cartesian basis, maybe doesn't play with
round objects?) but calling the cardinal "flat edges"…
Well, let's dial it back to the most basic - what about "just"
making a "masked select" (point, area, all) function which
could sit alongside the existing, but do that one thing?
While leaving the as-was selection code and what …
But still, I believe we do not know why the symmetric-MOS
version fails to match? Seems like if force-assigning terminals
(DMOS) works then one of the MOS permutes should have
satisfied similarly, and been accepted.
Am I missing some resolution t…
I'm thinking that this goes to the "selection process" and any
old layer/purpose pair would do (although for general Brand X
compatibility I'd default to named "instance/drawing" absent
any overriding declaration of "select…
I would still like to get to a "masked selectability" behavior /
feature similar to how Brand X used the instance/drawing layer
(until recently - I have been seeing PDKs where this is damaged
by the instance/drawing layer being inactivate…
Yes, they should be but evidently are not, and I am wanting
to get to the bottom of "why?".
I figure maybe removing known "not-right" from input netlists
might help expose the unknown.
Which thus far, remains unknown.
Let me …
I disagree that "the schematic netlist is correct". I would go
along as far as "it works". But if you inspect the symbols'
wiring and the netlist, there is the fact that (for example)
M_m6 drain and source are swapped in the net…
That's good to know.
I'm trying to understand why what should work, does not.
Because there's a lot of use for symmetric MOS. Provided
it's verifiable. Need to know why this is failing, so as not to.
Given this, I would again suggest that the MOS schematic
elements be flipped so that D (symbol) is D (SPICE) and
see what results. If the compare "gets right" then the D-S
swapping must be somehow compromised. If it makes no
difference t…
(Quote)
This concerns me. I've been bitten by this when using asymmetric
MOS devices (e.g. drain-extended, no LDD on source). This
behavior (IMO) should be configurable, or an asymmetric MOS
extractor needed.
And then -if- it is configurable, com…
Not sure why you'd do this or how realistic you think it'll be
(much of CD variation will be systematic, and some more of
it involving proximity / edge-of-array effects). But if it were my
problem, I think I'd first make a PCell for the square objec…
I don't think the devices want or can be combined because they
are not fully parallel. What this situation lacks is enablement of
specific pin swapping (S=D).
Now "combining" could be done -to- the netlist or by bookkeeping
during the …
I'm wondering whether this is "algorithmic" (and a bug) due to the
high vertex count and long shrink dimension, causing "spurious
projection" as the vertices might cross over each other when projected
orthogonal to their flat?…
I would bet that the netlisting "template" can be found, probably
as a property of the PSPICE symbol itself (but I am no PSPICE
expert). Try pushing down the hierarchy looking for pin and
property passing. The PSPICE output log may show …
What is missing, is a compare rule that says S, D are swappable
in searching for topology-match. I know I've seen this discussed
but can't remember more.
Or you could go change the schematic so it matches what's naturally
found, but is there &quo…
How about making a "cutter" object (say, by subtracting
a circle of desired radius, from a square) and then using
that "cutter" on the target object? Both using the "Subtract,
Others from First" operation? All straig…
I'll mention that I've seen multiple times, that what you get
from a distro's package repository can be badly out of date,
or subject to an installer which sets you up to fail (like if it
wants to install via "snap", you get stuck into a…
It might be useful for the proponents of various simulator
netlist formats, to dig into their simulator's documentation
and see about options. There may be SPICE compatibility
settings that enforce more-standard formatting. If there are
no good op…
I don't know from "conda" but I've encountered problems with
applications "built inside environment", then having serious
limitations. In my case it was "snap" installations, which carry
a constraint (aka "sandbox…