Previously precheck- and tapeout-clean design (October 26th) now (November 10th) throwing errors in the efabless platform

I have to defer to @Mitch Bailey for this one. Mitch: The end of the file

OEB_check.log

looks like this:

ERROR: No model match dac_top_cell/RX9 R sky130_fd_pr__res_xhigh_po_2p85 l=1.25
Missing models

sky130_fd_pr__res_xhigh_po_2p85 R

ERROR: Model file problem
** Stage 1/7: Enter command ?> c 6

> c 6
continuing for 6 step(s)
ERROR: skipped due to problems in model/power/fuse files
 gpio |   in   |   out  | analog |  oeb min/sim/max  | Message

Why is it complaining about the

res_xhigh_po_2p85

model?? (Also, as a nit-pick: Why do all of these checks and related output end up in the file "OEB_check.log" when they have nothing to do specifically with OEB checks?)

@Aleksandar Pajkanovic the precheck now includes the oeb check, which checks the connections for the gpio. Does the local precheck pass with the current tag

mpw-9f

? It may be that the platform is missing some updates. I’ll check. @Tim Edwards OEB check are done on the CVC results. In this case, CVC is complaining because it can’t find a model. I’ve added models for all the test cases but not for all devices in the pdk. This will continue to be an issue when new models are introduced.

Could you please add the model efabless platform precheck is complaining about?

Probably not within the next 24 hours.

Ok, thanks. However, is there any way we can be sure that the actual problem is on the side of the platform?

Have you run the local precheck with the latest tag?

Hi @Mitch Bailey, I ran the precheck with his design with the latest mpw-9f tag. I got the problem and I reported it to @Aleksandar Pajkanovic. with mpw-9e, the design pass the precheck and the tapeout job.

@Hieu Bui I suggest going ahead with the integration even though precheck is not passing yet.

We've done it, but we have to exclude the design to pass the precheck and tapeout job

hi @Mitch Bailey, please, could you update us on this issue? Prof. @Hieu Bui must close the design and we are just two days away from deadline. Five students worked on this circuit for over two months, so it is of great importance for us to deliver it in time to be integrated.

Looks like the changes went into the local precheck about 8 hours ago. I don’t know if they’ve created a tag yet.

Prof. @Hieu Bui, Could you please pull the latest changes @Mitch Bailey is referring to and run the precheck with our design included?

@jeffdi has been away but should be back today and hopefully we can give this high priority and get it figured out and fixed.

Thanks @Tim Edwards, for all the attention and support.

@Aleksandar Pajkanovic the platform precheck has been been updated. Can you verify?

Hi @Mitch Bailey it is still not working. I've just run it on efabless server:

CVC: Setting models ...
ERROR: No model match dac_top_cell/RX0 R sky130_fd_pr__res_xhigh_po_2p85 l=1.25
ERROR: No model match dac_top_cell/RX3 R sky130_fd_pr__res_xhigh_po_2p85 l=1.25
ERROR: No model match dac_top_cell/RX6 R sky130_fd_pr__res_xhigh_po_2p85 l=1.25
ERROR: No model match dac_top_cell/RX9 R sky130_fd_pr__res_xhigh_po_2p85 l=1.25
Missing models

Nathan is pushing us to submit the design but I don't know how can we do it without precheck passed.

Hi @Mitch Bailey and @Hieu Bui, As far as I could understand, @Tim Edwards is planning to pass the design manually through the precheck. Mr. Edwards, could you comment, please?

@Aleksandar Pajkanovic: I don't have the authority to do that; @jeffdi can do it, though (but also we need to understand why a git update that was supposed to have been captured yesterday is apparently still not on the platform).

Hi @Tim Edwards, thanks for the clarification. Well... I guess than it's up to @jeffdi - since, and please do correct me if I am wrong - since there is nothing I personally or we as a team can do, right?

Not that I'm aware of.

I see, thank you. I have nothing else then, but to point out that my students spent two months working on this. It's not going to change the world, this design, but it means a lot to us. Therefore, I ask you, Mr. DiCorpo, to take into consideration all the effort and good will these young people invested in the making of the FreeDAC <=== after all, that's what efabless is all about: kids making chips 🙂 I hope you can help us get the design through, as we really honored all the requests and our hands are now tied. Let us know.

@Aleksandar Pajkanovic: Don't worry; we'll get it in.

Thank you @Tim Edwards. However, if it comes to the "2b | ~2b", please inform prof. Bui so he can submit without us.

There is no issue with pushing the project manually past precheck. My only concern is that the CVC check is failing on some minor issue but it isn't running so you might not be getting the full report back. But we'll get this worked out properly.

@Aleksandar Pajkanovic just to be clear, does your design pass the local precheck but not the platform precheck?

no, It does not pass both

@Tim Edwards thanks for checking the PR. You are correct that it does not fix the problem. There are a couple values that are off by 10nm. I must have looked at the range values for the device definitions instead of the model names. Pushing a fix now. @Aleksandar Pajkanovic @Hieu Bui I apologize for the stress this has caused. Can you copy this to your local

$PRECHECK_ROOT/checks/be_checks/tech/sky130A/cvc.models

MN nfet_01v8 Vth=0.2 Vgs=1.8 Vds=1.8
MP pfet_01v8_hvt Vth=-0.2 Vgs=1.8 Vds=1.8

R short model=switch_on

D sky130_fd_pr__diode_pw2nd_05v5 
D sky130_fd_pr__diode_pw2nd_11v0 
D sky130_fd_pr__diode_pw2nd_05v5_lvt
D sky130_fd_pr__diode_pw2nd_05v5_nvt 
D sky130_fd_pr__diode_pd2nw_05v5
D sky130_fd_pr__diode_pd2nw_05v5_lvt
D sky130_fd_pr__diode_pd2nw_11v0
D sky130_fd_pr__model__parasitic__diode_ps2dn
D sky130_fd_pr__model__parasitic__diode_ps2nw
D sky130_fd_pr__model__parasitic__diode_pw2dn
D condiode


#R sky130_fd_pr__res_generic_m1 R=l/w*0.125
#R sky130_fd_pr__res_generic_m2 R=l/w*0.125
#R sky130_fd_pr__res_generic_m3 R=l/w*0.047
#R sky130_fd_pr__res_generic_m4 R=l/w*0.047
#R sky130_fd_pr__res_generic_nd R=l/w*0.029
R sky130_fd_pr__res_generic_l1 model=switch_on
R sky130_fd_pr__res_generic_m1 model=switch_on
R sky130_fd_pr__res_generic_m2 model=switch_on
R sky130_fd_pr__res_generic_m3 model=switch_on
R sky130_fd_pr__res_generic_m4 model=switch_on
R sky130_fd_pr__res_generic_m5 model=switch_on
R sky130_fd_pr__res_generic_nd R=l/w*120
R sky130_fd_pr__res_generic_pd R=l/w*197
R sky130_fd_pr__res_generic_nd__hv R=l/w*114
R sky130_fd_pr__res_generic_pd__hv R=l/w*191
R sky130_fd_pr__res_generic_po R=l/w*48
R sky130_fd_pr__res_xhigh_po R=l/w*2000
R sky130_fd_pr__res_xhigh_po_0p35 R=l/0.35*2000
R sky130_fd_pr__res_xhigh_po_0p69 R=l/0.69*2000
R sky130_fd_pr__res_xhigh_po_1p41 R=l/1.41*2000
R sky130_fd_pr__res_xhigh_po_2p85 R=l/2.85*2000
R sky130_fd_pr__res_xhigh_po_5p73 R=l/5.73*2000
R sky130_fd_pr__res_high_po R=l/w*300
R sky130_fd_pr__res_high_po_0p35 R=l/0.35*300
R sky130_fd_pr__res_high_po_0p69 R=l/0.69*300
R sky130_fd_pr__res_high_po_1p41 R=l/1.41*300
R sky130_fd_pr__res_high_po_2p85 R=l/2.85*300
R sky130_fd_pr__res_high_po_5p73 R=l/5.73*300
R sky130_fd_pr__res_iso_pw R=l/w*4400

MN sky130_fd_pr__nfet_01v8 Vth=0.2 Vgs=1.8 Vds=1.8
MN sky130_fd_pr__nfet_01v8_lvt Vth=0.1 Vgs=1.8 Vds=1.8
MN sky130_fd_pr__special_nfet_latch Vth=0.2 Vgs=1.8 Vds=1.8
MN sky130_fd_pr__special_nfet_pass Vth=0.2 Vgs=1.8 Vds=1.8
MN sky130_fd_pr__nfet_03v3_nvt Vth=0.2 Vgs=3.3 Vds=3.3
MN sky130_fd_pr__esd_nfet_g5v0d10v5 Vth=0.2
MN sky130_fd_pr__nfet_05v0_nvt Vth=0.2
MN sky130_fd_pr__nfet_g5v0d10v5 Vth=0.2
MN sky130_fd_bs_flash__special_sonosfet_star Vth=0.2

MP sky130_fd_pr__pfet_01v8 Vth=-0.2 Vgs=1.8 Vds=1.8
MP sky130_fd_pr__pfet_01v8_lvt Vth=-0.1 Vgs=1.8 Vds=1.8
MP sky130_fd_pr__pfet_01v8_hvt Vth=-0.3 Vgs=1.8 Vds=1.8
MP sky130_fd_pr__special_pfet_pass Vth=-0.2 Vgs=1.8 Vds=1.8
MP sky130_fd_pr__special_pfet_latch Vth=-0.2 Vgs=1.8 Vds=1.8
MP sky130_fd_pr__pfet_g5v0d10v5 Vth=-0.2

C sky130_fd_pr__cap_mim_m3_1
C sky130_fd_pr__cap_mim_m3_2
C sky130_fd_pr__cap_var
C sky130_fd_pr__cap_var_lvt

Q sky130_fd_pr__pnp_05v5
Q sky130_fd_pr__pnp_05v5_W0p68L0p68
Q sky130_fd_pr__pnp_05v5_W3p40L3p40
Q sky130_fd_pr__npn_11v0
Q sky130_fd_pr__npn_11v0_W1p00L1p00

And see if the local precheck will complete without errors?

we don't have this file, but I copy the part for xhigh_po_2p85 into cvc.sky130A.models. It still fails

@Hieu Bui thanks for checking. I suspect your precheck is out-of-date. I’ll look for your repo, run the checks, and let you know the results.

@Mitch Bailey this is the version:

Well it’s not that out of date. 😁 Latest version is

mpw-9g

. But that still won’t have the necessary fix. Should be able to

MPW_TAG=mpw-9g make precheck

and then replace

$PRECHECK_ROOT/checks/be_checks/tech/sky130A/cvc.models

(

PRECHECK_ROOT

defaults to the user home direcotry).

@Mitch Bailey Thanks for the explanation. We notice the DRC messages but I does not flags as errors. Therefore, we continue. I think these rules for the SRAM?

The drc errors have to do with well connections. If the well connections are too far from the mosfet source/drain, you may experience latch up conditions. After the following changes, LVS “passes” with a trivial size error. netgen reports the

l

and

w

of a mim_cap as reversed. Since the total area and perimeter are the same there is no physical difference. You could switch the schematic values to get a clean LVS result.

Circuit 1: opamp                                                                  |Circuit 2: opamp
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
sky130_fd_pr__pfet_01v8_lvt (19->6)                                               |sky130_fd_pr__pfet_01v8_lvt (6)
sky130_fd_pr__nfet_01v8_lvt (9->5)                                                |sky130_fd_pr__nfet_01v8_lvt (5)
sky130_fd_pr__cap_mim_m3_1 (2)                                                    |sky130_fd_pr__cap_mim_m3_1 (2)
Number of devices: 13                                                             |Number of devices: 13
Number of nets: 11                                                                |Number of nets: 11
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Netlists match uniquely with property errors.
sky130_fd_pr__cap_mim_m3_1:6 vs. sky130_fd_pr__cap_mim_m3_1:C1:
 w circuit1: 4   circuit2: 2   (delta=66.7%, cutoff=1%)
 l circuit1: 2   circuit2: 4   (delta=66.7%, cutoff=1%)
sky130_fd_pr__cap_mim_m3_1:3 vs. sky130_fd_pr__cap_mim_m3_1:C2:
 w circuit1: 4   circuit2: 2   (delta=66.7%, cutoff=1%)
 l circuit1: 2   circuit2: 4   (delta=66.7%, cutoff=1%)

In the lvs_config file, I moved the netlist from

LVS_SPICE_FILES_TO_FIX

to

LVS_SPICE_FILES

. Fixed spice files have generic poly resistors while the current extraction rules yield poly resistors with model names that contain the device width. The

esd_cell

has a device,

R1

that uses a generic

sky130_fd_pr__res_high_po

model with

W=0.35

. I changed this to

sky130_fd_pr__res_high_po_0p35

.

Hi @Mitch Bailey, Thanks for the coverage. I am not clear, do we do something in the design now or not? I am confused, because this design was passing both lvs and drc before all these changes, so does your fix mean it's good to go or we need to perform actions?

@Aleksandar Pajkanovic Older versions of the pdk did not differentiate between poly resistance models. The error shows up with the update to the extraction rules. For this time, I think we can override the error.

Thank you @Mitch Bailey for your understanding, and all the time and effort invested to get this through. Thank you @Hieu Bui for your patience and perseverance to keep us in the game. Please confirm once the design actually does pass through and goes off to the foundry.

@Mitch Bailey we got the drc but before it is success 😞

hi @Hieu Bui, is this regarding FreeDAC?

the problem is on our side, we are doing a fix

Thanks. Please keep us updated.

@Hieu Bui They drc error regarding the tap - diff spacing is not a required rule. It will not stop tapeout.