@mehdi At last night’s meeting, we discussed the status of each group and issues they were facing. We did not touch on the description of the pad rings, so that is something that needs to be done. Is there a format or is a power point slide sufficient? Do you need the coordinates and size and names of each pad? On the sign up sheet, LTC1 and LTC3 have repo’s posted, but LTC2 is doing PR’s against your repo. Would it be ok to post that link on the shared sign up sheet too? There was an issue that programming all of the io cells separately would take time, but there was a suggestion made to instantiate the programming for one i/o cell and then just reuse that. The usage of deep nwell was clarified. There is no need for an nwell guard ring in the gf180mcu process. There are also issues of substrate connections that are causing LVS problems. To run LVS with klayout using xschem netlists, it’s necessary to modify the capacitor and resistor instances in spice. Flat drc takes too much time, so deep (hierarchical) drc was recommended. Full flat drc was left to Calibre. There were some false drc errors in the deep mode between wells in the pad ring. The check was flagging nwell based on the different node rule, but the nwell was actually on the same net. In order to discover any problems with the Calibre LVS/DRC flows, teams will send test data to Juan Maya by May 1st. I think Calibre LVS requires CDL. We’ll need a verilog to spice converter (I think qflow has one), or just substitute the openlane verified extracted layout (actually, the pin order in the openlane extracted layout does not match the spice library). This may be a large issue.

Hi @Mitch Bailey Thank you so much! I can add you to GCP. Are you available on Monday?

👍 Monday is ok.

I am sorry.. I just landed in Japan. Let's do this before the tcose meeting?

Welcome! Sounds good. Around 12:45am tonight then? (Thursday night, Friday morning).

Oh Gosh.. I am very jetlagged but yes!

The tcose meeting is at 1am. I’ll just sign in 15 min early.