Hello David,

@Tim: I've added the specs for LibreSilicon in Magic: https://github.com/libresilicon/magic-8.2/commit/90ecfd589e0c05bc9a4dd5a2745... Please review and give feedback

Okay, now that I get that you are trying to make use of the SCMOS technology as a foundation for your process, only creating a new cifoutput section for the process, here are my comments:

(1) First, if you are doing an "intermediate layer", like wells_sti, then later recasting it to a GDS layer, I guess it works to do it the way you are doing, but it is preferable just to go directly to the GDS layer, e.g.,

layer STI nwell,pwell shrink 50 calma 4 0

unless you need the intermediate layer to generate more than one mask.

(2) GDS purpose 0 is more normally used for basic GDS mask layers. All other purpose numbers are generally used for slots, fill, text, verification, etc.

(3) In the SCMOS style, contacts are drawn as contact areas, where the drawn layer includes one or more contact cuts and the surrounding metal (much like a LEF "VIA" definition). If, e.g., layer "m2c" is translated directly to the GDS output as a contact cut, then all of the DRC rules for m2c will be incorrect. That is not the SCMOS style (that is, the DRC rules are going to insist that via layers are 4x4 lambda and will not require any additional metal surround).

Usually your cifoutput for a contact area would look like:

layer CCA pc,pdc,ndc,ppc,nnc squares 20 50 50 calma 10 0

(4) In the SCMOS style, implant and (sometimes) well layers are not drawn, but are generated in the output using grow or bloat operators. Normally, it would look something like this:

layer CSN ndiff,ndc,nsd,nsc,nfet grow 100 shrink 50 calma 7 0

Although you may have a different grow distance around the gate (nfet) compared to non-gate diffusion. For wells, you would want to make a "templayer" with the explicitly-drawn and auto-generated wells, since you want to both output this directly as CWN but also further manipulate it to generate STI.

The grow + shrink operators are typical for auto-generated layers. You grow by the amount you want to grow for the surround rule, then grow an extra distance equal to half of the spacing rule, then shrink by the same distance (half of the spacing rule). The net result is the expected grow distance, but any layers that are near enough to each other to violate the spacing rule will get merged together.

The grow + shrink method always has problems with layers that have corners placed diagonally from each other. I have considered trying to come up with a reasonable algorithm to cope with that issue. On the other hand, such errors (which tend to be little narrow strips of implant layers) are "false" errors which technically violate DRC rules but would not cause any circuit failure.

(5) You are missing substrate/well contacts in your OR list for CSN and CSP.

(6) I doubt "or pad" is what you want for any via layer, as this will create one giant contact cut over the entire pad surface. Normally you would want some "squares" rule for this, although the "slots" rule has more options that you can use to make via patterns across the area of the pad. Otherwise you will likely end up with delamination issues on your pads.

(7) Note that the whole point of the SCMOS style is that everything that is drawn must be a multiple of lambda (50 centimicrons). Have you checked/confirmed that all your layers are consistent with this, so minimum gate width = 2 * lambda = 1 um, minimum metal width = 3 * lambda = 1.5 um, minimum contact size (cut + surround) = 4 * lambda = 2.0 um, minimum well width = 10 * lambda = 5 um, etc. By slipping the LibreSilicon rules into the scmos.tech file, you are implicitly accepting all of the SCMOS DRC rules.

(8) You need to use the "labels" statement everywhere if you wish to be able to preserve labels through any re-import of the GDS. If you only wish to create masks for manufacture, then it's not an issue.

That seems to cover the basics.

---Tim

+--------------------------------+-------------------------------------+ | R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design | web: http://opencircuitdesign.com | | 19601 Jerusalem Road | phone: (240) 489-3255 | | Poolesville, MD 20837 | cell: (408) 828-8212 | +--------------------------------+-------------------------------------+