@User I'm currently trying to explore the best ESD strategy. In the spice models and documentation there are ESD FETs which I assume are intended to be used as grounded gate NMOS devices. That's all good. But the documentation clearly states that the layout is different from a standard FET which makes sense but the layout is not included in the PDK as far as I can see. In

sky130_fd_pr.gds

there is 20v0 ESD FETs but the other voltages, particularly 1.8 V are not present. Do you think it's possible to include the

sky130_fd_pr__esd_nfet_01v8

layout in the PDK? Or maybe it already is in there and I've missed it? Thanks in advance

We did not get a

sky130_fd_pr__esd

library. Some of those devices can be found in the I/O cells. In particular, look at one of the power pads with clamps. There is an ESD device up in the corner of it. The base cell is named

sky130_fd_io__signal_5_sym_hv_local_5term

and you can find a layout of it in the open_pdks install under

libs.ref/sky130_fd_io/mag/

.

Thanks for the info. It's a bit unfortunate that there's not a 1V8 device available. I will try and adapt the 5V one and if not then I'll have to take a gamble with 5V protection, it's only for output devices in this shuttle

@yrrapt I have been in contact with @Tim 'mithro' Ansell and he put the public release of the ESD PMOS pcell documentation on his todo list.

@FatsieFS that's good to know, thanks

The best approach is what we're doing for the SRAM modules, which is to abstract the view of the cell that has errors. We're working on that in precheck---once we have that working for the SRAM cell, it's trivial to extend/duplicate it to handle the ESD cell above. If you want to avoid seeing the DRC errors yourself, then use "lef write" to create an abstract view of it, then read back the LEF file into a magic view, then set "gds noduplicates true" and read the GDS of the same cell so that it annotates the file with the pointers to the GDS data. If you can live with the GDS errors, then that's fine, too.

OK interesting, so essentially eFabless will do an IP merge at tape-in? I do my layout in klayout so I will instantiate a phantom cell with the correct boundary and cell name and you guys will populate it? Final question, will this be in place for the imminent shuttle run?

No, this is not an IP merge. It is simply a way of presenting an abstract view of a cell to magic that is DRC clean and keeps magic from coughing up errors on one of the cells with one-off specialty rules that magic doesn't implement in its DRC deck. The GDS will have the correct data, but the view in magic will be abstracted and DRC clean, but contain pointers to the GDS data so that the original data can be produced on "gds write" instead of the contents of the abstract view.

Good to know, thanks. I will give it a go, I might have more questions in a day or two but I'll see how far I can get first. Thanks again

This change won't go into efabless precheck until we have implemented the similar script for SRAM and tested it. Ping me again when you're ready to run the precheck.

@Tim Edwards I will need to start looking at the precheck stuff very soon, I was wondering if the abstract view stuff we discussed above is in place now? How would I signal to precheck I want to abstract a cell?

What we implemented was a check for any of the (five, I think) SRAM macros in the

sky130_sram_macros

library. If these are used, then the block will be abstracted and it will be DRC clean. I believe that this code is in place and working now.

@Tim Edwards Ok, but not for the ESD devices?

Sorry, I forgot about the ESD devices. Now that we have the technique working for the SRAM macros, it's just a matter of adding the cell name to the list of cell names to pre-load as abstract views before running pre-check DRC. I'll see to it.

That's great, thanks. Will this be in place by the submission deadline tomorrow?

Maybe. I have a question, though. I can't find any cell

sky130_fd_pr__esd_nfet_01v8

. In the

sky130_fd_pr

library there's

esd_rf_nfet_20v0_hbm_21vW60p00

and

32vW60p00

and in the I/O library there's

sky130_fd_io__signal_5_sym_hv_local_5term

. Are you using one of those?

This is the one I'm using

sky130_fd_pr__esd_nfet_g5v0d10v5

which is not ideal because I'm using 1.8 V devices but it's better than nothing

But again, that's a device name, not a cell name.

I can call the cell whatever you'd like

I do not have a way to exclude cells from DRC checks except by cell name, and for that the cell name needs to be hard-coded into our precheck system.

So if I call the cell

sky130_fd_pr__esd_nfet_g5v0d10v5

and you put that name in the precheck system then we're good?

No. Shadowing a device subcircuit name with another subcircuit name would break everything.

Ok, so is there anything we can do or we just go without ESD protection?

You could use the cell

sky130_fd_io__signal_5_sym_hv_local_5term

. How much does that differ from the device layout you have now?

That is the one I'm using. I can ensure that cell name remains the same then

Yes, please do. Then it becomes simple to handle.

Ok great, will do. Thanks

Hello, we also need to add ESD protection to some pads working with 1.8V for digital signals operating at frequencies >30MHz. Is the cell

sky130_fd_io__signal_5_sym_hv_local_5term

the most appropriate?

You would be looking for some kind of 1.8V IO cell which I'm not sure exist (or can exist at this point). The device you mention is a 5 V grounded gate NMOS ESD device but that isn't going to provide much protection to a 1.8 V input device. As a first port of call I would look in

/usr/share/pdk/sky130A/libs.ref/sky130_fd_io/spice/sky130_fd_io.spice

library to see what you can find.

It seems there is no ESD protection for 1.8V yet. So we will need to add the same cell you used in order to have at least some kind of protection