<@U01CZH7JG2G>: The inability to generate the SON...
# sky130
t
@User: The inability to generate the SONOS transistor without a guard ring appears to be a bug in the PDK Tcl script; I'll investigate. You can also just draw these layers manually, but I should be able to get that fixed soon enough for you. However: There are specific SkyWater DRC rules prohibiting the use of SONOS in all but "approved" cells, so if you or anyone is planning to do anything with SONOS, I would like to have a heads-up about it, and we should make sure we can push some partial layouts from you through an early DRC run to see what it coughs up, so we'll know what we will have to waive when we submit to SkyWater.
j
I think this was directed to @Md Munir Hasan, right?
t
Drat that auto-complete for names that has a laggy response. . .
m
@Tim Edwards You wanted to have a head up about anything with SONOS. I have a 2x2 array of nfet SONOS cells along with some other analog circuits. The analog circuits have power supply of 1V and below. But the SONOS devices will need about 7V. 1. Should we submit the GDS file to you before submitting to efabless? 2. If we do need to submit to you first do we need to embed the design in side the caravel frame? 3.
t
(1) Yes, please, and (2) no, just the inside design. I am going to pass it through Calibre so I can get a count of the DRC errors that are going to be raised by the use of cells with "unauthorized" names containing SONOS devices, and make sure there are no other errors related to the PDK.
m
@Tim Edwards I am attaching the single gds here. Not sure if I need to include other files as well. Let me know if you would prefer email for these.
t
I'm looking at a cell called "testing" but I don't see any SONOS transistors in it.
m
@Tim Edwards If you look on the left side of the tesing cell, there should be a small area with sonos cells.
t
Is that outside of "testing"? I could not read any top level cell from the GDS. The top level seems to have a name that is a full absolute file path, and it is not showing up in magic.
m
@Tim Edwards It is outside the cell testing. This is what I see on my end. Should I zip the whole magic files you?
t
It's okay, I just needed to know that the cell name was "2x2-cell". However, the GDS is bad and I'd like to know how you generated it.
m
From file->write gds
Can you guide me to the proper way?
t
Seemed like the right way to me. . . I will have to check what command is being run by the menu option. Instead, try the command from the command line "gds write <filename>".
I get a bunch of DRC errors on GDS read-back, but I understand what they are (they are false errors and I need to fix something in the PDK; doesn't affect your design). One thing I do see is that my rule set for magic apparently allows a deep nwell without the surrounding nwell ring, which is not legal. You wil need a ring of nwell around the deep nwell layer (and I need to fix the tech file to flag a deep nwell without an nwell connection).
m
@Tim Edwards used nwell around deep nwell and generated gds with gds write command. Here is the new gds.
t
Okay, one more round while I go fix those issues I was mentioning. The GDS looks good this time. For analog layout like this, though, you want to run the command "drc style drc(full)" so that you can see every error. That would show errors where a certain overlap of nwell is required on both the inside and outside of the deep nwell boundary. The best way to generate a correct deep nwell structure is the PDK menu "Devices 1 --> deep n-well region". There is another obscure error that all tap regions must have a contact, so each guard ring around each SONOS must have at least one contact (or you can remove the guard rings, if you have updated the PDK with my correction). One additional note: Local interconnect is very high resistance; it is called "local" for a reason. It is not good for long route wires. A better layout is to bump up all contacts to at least metal1, and route metal1 vertically, and metal2 horizontally (or vice versa). The most recent PDK update from open_pdks has not only the correction for the SONOS without the guard ring, but it also has an option on every device to contact each pin up to metal1. Nevertheless, for my purposes in running a quick DRC check on the SONOS devices themselves, your layout above is good for now.
Finally, SONOS transistors are considered part of core memory cells, and for obscure DRC reasons, I have had to create a special type of local interconnect called "coreli". For other obscure reasons, you cannot overlap "coreli" and "li" in different cells, but they can touch.
m
Ok. Thanks!
t
Sorry about all the trouble. I really want somebody to play around with the SONOS, but I have not spent much time checking the DRC rules around it. You are the beta tester here (more like alpha tester).
m
Glad to be around. With the new installation of open-pdk I see that when I uncheck the guard ring on the sonos, pwell does not appear in the layout. Is that the correct behavior? I should I draw one manually?
t
It should be correct without the pwell layer; pwell should be equivalent to nothing, either over substrate or over deep nwell. Usually pwell is just drawn to make it more like the functional opposite of nwell, but it has no mask layer and therefore no physical meaning.
m
@Tim Edwards We have finalized our design. I am attaching the gds file here in case you want to run that through your DRC checker for the SONOS cell and give us additional direction. The cell name is 2x2-array and connected to analog_io[0:5].
t
Thanks; I'll take a look at it.
@Md Munir Hasan: I have not run Calibre DRC yet, but I do see one small problem, which is that the nwell around your deep nwell in the 2x2 SONOS array isn't tied to anything. It should be tied to VDD.
m
Ok. Thanks