magic-tech vs klayout-drc consistency, re: 5LM + 9k: If 9k refers to "6th metal" metaltop (gds:53), why doesn't magic-tech support it?

[sto6]

Actual Behavior

magic-tech & klayout-drc appear almost consistent in: Treating gf180mcuC as: "5LM", where upper-most metal is metal5 (gds:81/0). And there is no: via5, metaltop (gds:82/0, 53/0). That is, klayout-drc has a primary METAL_LEVEL conditional that assigns meta-layers like top_via,top_metal, and only for "6LM" are top_via,top_metal assigned to via5,metaltop; for "5LM" they get via4,metal5. (Although it unconditionally connects metal5 thru via5 to metaltop; which I believe is a bug: #8).

The klayout-drc has thickness-specific (6k, 9k, 30k) rule sections. But 6k & 9k sections operate on metaltop (gds:53/0) (not meta-layer top_metal, i.e. metal5 for 5LM), which does not exist in gf180mcuC. Then why mention "+ 0.9um thick top metal" in gf180mcuC PDK .config/nodeinfo.json description, if C does not use the layer?

Expected Behavior

If for "5LM + 9k", the "9k" describes thickness of metal5 (gds:81/0) and there are no via5,metaltop: klayout-drc 9k section needs fix, and must not connect using via5,metaltop (#8) and more rules on these layers need to be disabled. If for "5LM + 9k", the "9k" means via5,metaltop (0.9um thick, gds:82/0, 53/0) ARE used for a "6th" metal (in addition to met1-5): magic-tech needs fix.

Specifications

github.com//efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr.git : rules/klayout/drc/{gf180mcu.drc,run_drc.py} 8cbf289 2022-12-01T00:12:24-08:00 (HEAD -> main, origin/main, origin/HEAD) Update run_drc_parallel.py

volare-pdk (2022.11.25): gf180mcu/versions/35c7265f51749ad8d9fdbb575af22c7c8fab974e/gf180mcuC/libs.tech/magic/gf180mcuC.tech

[atorkmabrains]

@jeffdi and @mkkassem Could you please send us the correct stack used for the variant C?

[jeffdi]

5LM 9KA. 26 layers. See attached.

-- Jeff

On Sun, Dec 4, 2022 at 7:30 AM Amro Tork @.***> wrote:

@jeffdi https://github.com/jeffdi and @mkkassem https://github.com/mkkassem Could you please send us the correct stack used for the variant C?

— Reply to this email directly, view it on GitHub https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/issues/11#issuecomment-1336440789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKAZZ5M46AFMPDU3ZDCVUPDWLS2JHANCNFSM6AAAAAASR3XGF4 . You are receiving this because you were mentioned.Message ID: <efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/issues/11/1336440789@ github.com>

[atorkmabrains]

@jeffdi Where the attachment?

[jeffdi]

-- Jeff

On Sun, Dec 4, 2022 at 10:42 AM Amro Tork @.***> wrote:

@jeffdi https://github.com/jeffdi Where the attachment?

— Reply to this email directly, view it on GitHub https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/issues/11#issuecomment-1336488214, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKAZZ5OA47HVR6G5MYIN5T3WLTQ2XANCNFSM6AAAAAASR3XGF4 . You are receiving this because you were mentioned.Message ID: <efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/issues/11/1336488214@ github.com>

[atorkmabrains]

@jeffdi Github doesn't take attachments.

[jeffdi]

Check you email.

On Sun, Dec 4, 2022, 10:58 AM Amro Tork @.***> wrote:

@jeffdi https://github.com/jeffdi Github doesn't take attachments.

— Reply to this email directly, view it on GitHub https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/issues/11#issuecomment-1336491353, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKAZZ5NRL243Y6ZQNCKXGDLWLTSVLANCNFSM6AAAAAASR3XGF4 . You are receiving this because you were mentioned.Message ID: <efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/issues/11/1336491353@ github.com>

[RTimothyEdwards]

@sto : The 9K refers to the top level metal, which is not GDS layer 53. I know this is confusing. Please see the GF DRC document section 2.8, as they have different nomenclature (but the same names!) for "INTERNAL REFERENCE ONLY" and "DESIGN ACTIVITIES". My conclusion (after a number of readings) is that the first one is used by the foundry internally, but all users and design software should use the 2nd. In the second, "MetalTop" (GDS layer 53) refers only to metal 6 in the 6-metal stack. For "DESIGN ACTIVITIES", the top metal layer in the 5LM stack is "Metal5" with a note that it "must comply with MetalTop rule[s]". They couldn' t have made it less clear if they had dipped the whole thing in mud.

[atorkmabrains]

@RTimothyEdwards I disagree with your comment above. I believe @sto6 is right. This is extremely weird for me. Usually, each metal has a unique identifier.

But here is why @sto6 is right, please refer to the document that Jeff has shared about the tape-out mask layer numbers of the BEOL:

• 92
• 95
• 80
• 85
• 88
• 91
• 93
• 94
• 96
• 97
• 98
• 99

and those map to the following layers in the stack according to the table found: Mask Layer Numbering :

• FuseTop
• Pad
• Metal1
• Via1
• Metal2
• Via2
• Metal3
• Via3
• Metal4
• Via4
• MetalTop
• PIB

Meaning that we should have all the routing on beyond Via4 on 53/0 layer.

Thanks @sto6 for catching this. My team are still new to this and didn't get it.

I have updated the rule deck to make sure that the correct metal stack selected based on the switches.

[RTimothyEdwards]

No, that is completely wrong. You can determine that simply by looking at the foundry GDS for the I/O cells from the 5LM set. Metal5 is the top layer of metal, and can be found in all the GDS files as layer 81. There is no layer 53 in these files.

[atorkmabrains]

@RTimothyEdwards Could you review the Tape-out agreement that efabless has with Globalfoundries? @jeffdi Could you please send @RTimothyEdwards that document? It provides the mask number as 98 which stands for gds number 53 as I mentioned above.

BTW @RTimothyEdwards, I had the same understanding at the beginning.

[RTimothyEdwards]

@atorkmabrains : A mask number is not a GDS layer number. Yes, the process will use mask layer 98. No, mask layer 98 is not equivalent to design layer GDS number 53.

[RTimothyEdwards]

"I have updated the rule deck to make sure that the correct metal stack selected based on the switches."

If you modified rule decks based on faulty assumptions which were not approved by me, then revert them immediately.

[atorkmabrains]

@FaragElsayed2 Please take a look

[atorkmabrains]

@RTimothyEdwards We have cleaned all of that. I'll close the issue.