Re: Digest for electricvlsi@googlegroups.com - 2 updates in 2 topics

[Alexandre Rusev]

Re: About "Poly cap incorrect node distribution"

1. In the latest SVN version Steven fixed short cut in poly1-poly2 capacitor 2. Currently the 3D view of poly1-poly2 capacitor shows that metal-to-poly contact perforates poly2 layers,     which looks a bit amusing;), thought it's what we have for now. 3. To fix the issue using current approach we need to create (in mocmos.xml techdesc file) two different layers:      metal-to-poly1-cut and metal-to-poly2-cut and assign appropriate geometry sizes and locations for them,      as well as assign different connectivity rules. 4. Because metal-to-poly1-cut and metal-to-poly2-cut are NOT independent one from another we also have to     add DRC rules to force them to be far enough one from another. Also a rule preventing from placing     metal-to-poly1-cut  over poly2 is to be added. Looks like this will produces quite alot new rules for DRC 5. The layer metal-to-poly-cut is NOT creating connectivety rules itself. Connectivety rules  are created by node     "metal-to-poly contact" which consists of layers: poly, metal-to-poly-cut, metal + information which of these     layers can accept arc of the same layer connected to it 6. The same story as "4" is for metal-to-metal caps. I'm thinking on a patch to mocmos.xml, which provide     extra layers described above and DRC rules for them. BUT I'm NOT sure that it will not result in to exponential     groth of DRC rules number!    Look: metal-to-poly1-cut and metal-to-poly2-cut  (and m1-to-active in some technologies) are actually the same layer from the point of view of GDS file    and photomask production process.  This is just because metal-to-poly contact is connecting m1 to any silicon    above it, either it's poly2, poly1 or active.      I ask a question: may be we need a spectial porcessing of such layers in Electric instead of constraining them    with multiple "nonenatural" DRC rules?  I don't know the answer at this moment! Going to ask Steven! 7. Here is a helper project of Adam, designed to technology description files generation, currently it's devoted     to SkyWater130nm tech, lets' take a look how this  toolkit could help our purpose to fix caps   https://gitlab.com/westernsemico/com.westernsemico.vlsi And ... I'm going to use this capacitor as lon as metal5cap-metal5 capacitor in SkyWater130 tech ;)

On Mon, Feb 15, 2021 at 9:30 AM <electr...@googlegroups.com> wrote:

electr...@googlegroups.com

Google Groups

Topic digest
View all topics

• Why does aren't parasitics extracted for the Active-Cut? - 1 Update
• Poly cap incorrect node distribution - 1 Update

Why does aren't parasitics extracted for the Active-Cut?

Raphael Cardoso <cardosod...@gmail.com>: Feb 14 10:08PM -0800 In your spice extraction, did you select Conservative RC?   [image: cons_rc.png]   Em segunda-feira, 23 de novembro de 2020 às 03:11:55 UTC-3,

Back to top

Poly cap incorrect node distribution

Raphael Cardoso <cardosod...@gmail.com>: Feb 14 09:19PM -0800 Hi all,   When laying out a Poly1-Poly2 cap primitive (analog checkbox in technology preferences), Electric generates two nodes connecting to Poly1, and no nodes connecting to Poly2. This way, the capacitor will not work properly and fail NCC with poly-poly capacitors in schematics.   Here's a print of the layout with the properties window.   [image: poly_1.png]   I have tried many different workarounds to use the primitive without success. I believe the correct behavior would be either: - Generate 2 metal contacts: one corresponding to Poly2 and one for Poly1; - Make the user able to connect an external Poly2 node to the capacitor.   Another incorrect behavior is in the 3d view of this cell.   [image: 3dpoly.png]   Again, since the contact is over Poly2 in the layout, it is expected to be between the orange and blue layers, but the contact is actually between the pink and blue layers, passing through Poly2.   I have tried to mess around with the technology file for a few hours, again with no success.   I don't intend to use this cap, but a bug is a bug.   Best regards, Raphael.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to electricvlsi...@googlegroups.com.