search

RTimothyEdwards / open_pdks

PDK installer for open-source EDA tools and toolchains. Distributed with setups for the SkyWater 130nm and Global Foundries 180nm open processes.
http://opencircuitdesign.com/open_pdks
Apache License 2.0
292 stars 86 forks source link

sky130: generic poly resistor to diffusion spacing rule may not be necessary #467

Closed d-mitch-bailey closed 6 days ago

d-mitch-bailey commented 6 days ago

A generic poly resistor is just normal poly with a resistor recognition layer, right? Is there a reason why a generic poly resistor to diffusion spacing would need to be the same as the high resistance poly resistors?

In the tech file

  spacing xhrpoly,uhrpoly,xpc alldiff 480 touching_illegal \
    "xhrpoly/uhrpoly resistor spacing to diffusion < %d (poly.9)"

  spacing mrp1,xhrpoly,uhrpoly,xpc allfets 480 touching_illegal \
    "Poly resistor spacing to poly < %d (poly.9)"

  spacing xhrpoly,uhrpoly,xpc *poly 480 touching_illegal \
    "Poly resistor spacing to poly < %d (poly.9)"

  spacing mrp1 *poly 480 touching_ok \
    "Poly resistor spacing to poly < %d (poly.9)"

  spacing mrp1,xhrpoly,uhrpoly,xpc alldiff 480 touching_illegal \
    "Poly resistor spacing to diffusion < %d (poly.9)"

The last rule is the same as the first but with mrp1 added. I'm thinking that the last rule may not be necessary. It results in false errors like this. image (15)

RTimothyEdwards commented 6 days ago

Well, for one, this poly is a net divider and should be implemented with poly:short (66:15) and not poly:res (66:13).

The SkyWater documentation is not clear on this point, as poly.9 refers to "poly resistors" while the definitions do not define "poly resistors" (the definitions only define "prec resistors" as meaning the xhr and uhr devices). Since the rule does not state "prec resistors", it is implied that the rule applies to all poly resistors, and exists to ensure that the poly resistor model remains accurate.

Magic distinguishes between "rmp1" (poly used as a resistor) and "rpm" (poly used as a net divider) as a layer, although in both cases the extracted model is the same.

d-mitch-bailey commented 6 days ago

@RTimothyEdwards Thanks for the explanation. That makes perfect sense and offers a resolution to the problem

RTimothyEdwards commented 6 days ago

On the other hand, if this is in a standard cell and poly:res (66:13) is being used and as a vendor-supplied cell it can be assumed to be DRC clean, then the rule would need to be changed to conform to the vendor data.

d-mitch-bailey commented 5 days ago

The user stated that the PnR tool was adding it, but I don't know what tool they are referring to.

On Mon, Nov 18, 2024 at 7:12 AM R. Timothy Edwards @.***> wrote:

On the other hand, if this is in a standard cell and poly:res (66:13) is being used and as a vendor-supplied cell it can be assumed to be DRC clean, then the rule would need to be changed to conform to the vendor data.

— Reply to this email directly, view it on GitHub https://github.com/RTimothyEdwards/open_pdks/issues/467#issuecomment-2481626615, or unsubscribe https://github.com/notifications/unsubscribe-auth/A45UYNJBKUSYLT7UMH6GDJL2BEIFBAVCNFSM6AAAAABR6DXDUCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBRGYZDMNRRGU . You are receiving this because you modified the open/close state.Message ID: @.***>