https://open-source-silicon.dev
Join Slack
Another DRC issue with the SONOS: "SONOS transistor must be in cell with abutment box" I've no ide...
# magic
u
Another DRC issue with the SONOS: "SONOS transistor must be in cell with abutment box" I've no idea what it means. Also, it wants me to draw an nwell around the transistor. Shouldn't this be also part of the device generator?
d
Hi @Uri Shaked. I typed that down below before thinking to ask this. Can a SONOS fet share body connections with other SONOS fets? I don't know if each SONOS transistor has to be fully isolated in it's own pwell. I doubt it does because that would make the FLASH array very inefficient (but I could be wrong here) and I don't recall the SONOS FLASH being a dominant block in the PSoCs. I think the SONOS fets are made to be placed in some sort of an array, then a nwell ring placed around that. Maybe worse case the devices in each page can share pwell connection.
✅ 1
h
The description of 
tunm.8
is a bit clearer in the Periphery Rules doc (https://skywater-pdk.readthedocs.io/en/main/rules/periphery.html): it says 
tunm
has to be enclosed by 
areaid.ce
. It seems (according to https://open-source-silicon.slack.com/archives/C01BPL3HECT/p1601488185004600) that we inherited some rules from Cypress that specify separate "memory core" and "periphery" (i.e. everything else) areas, and memory cells can only be in a memory core area.
u
Thanks! I still can't make sense of what 
areaid.ce
is?
it doesn't seem to be one of the layers in magic
h
Is there an 
areaid.core
? That's how it's called in klayout.
u
image.png
👍 1
h
Or GDS layer/datatype 81/2
u
image.png
👍 1
d
I don't think it's core. Let me look it up.
Where did you get that, @Uri Shaked?
u
h
Btw. this is the part of sky130.tech raising the DRC error:
Copy code
#------------------------------------
# nsonos
#------------------------------------
 
variants (full)
  cifmaxwidth bbox_missing 0 bend_illegal \
    "SONOS transistor must be in cell with abutment box (tunm.8)"
variants (fast),(full)
✅ 1
u
Copy code
# SONOS nFET devices must be in cell with abutment box
 templayer abutment_box
	boundary

 templayer bbox_missing nsonos
	and-not abutment_box
so that brings us back to the abutment box thing
d
CE is core. I suspect they cheated on the design rules in the FLASH macro and lumped the different rules in the core section.
h
This comment also seems relevant:
Copy code
#----------------------------------------------------------------
# Create a temp layer from the cell bounding box for use in
# generating ID layers.  Note that "boundary", unlike "bbox",
# requires the FIXED_BBOX property (abutment box) in the cell.
#----------------------------------------------------------------
u
looks like
property *FIXED_BBOX
can help*
however, looking at the .mag file that contains the SONOS:
Copy code
<< properties >>
string FIXED_BBOX -168 -202 168 202
string gencell sky130_fd_bs_flash__special_sonosfet_star
string library sky130
string parameters w 0.45 l 0.22 m 1 nf 1 diffcov 100 polycov 100 guard 1 glc 1 grc 1 gtc 1 gbc 1 tbcov 100 rlcov 100 topc 1 botc 1 poverlap 0 doverlap 1 lmin 0.15 wmin 0.42 class mosfet compatible {sky130_fd_pr__nfet_01v8 sky130_fd_pr__nfet_01v8_lvt  sky130_fd_bs_flash__special_sonosfet_star  sky130_fd_pr__nfet_g5v0d10v5 sky130_fd_pr__nfet_05v0_nvt  sky130_fd_pr__nfet_03v3_nvt} full_metal 1 viasrc 100 viadrn 100 viagate 100 viagb 0 viagr 0 viagl 0 viagt 0
<< end >>
it seems to have this FIXED_BBOX
perhaps this DRC issue can just be ignored? It seems like something that would have no effect on the final GDS
h
Is your SONOS fet entirely within the bounding box specified on the FIXED_BBOX line?
u
I guess it is - it was generated by the device manager. I tried playing around with the numbers (0 0 100 100), but DRC still wasn't happy
h
But you said you edited the cell manually to fix some DRC issues after it was generated by the device generator. Didn't that increase the size of the SONOS fet while keeping the original FIXED_BBOX entry? Also 0 0 100 100 doesn't look better than -168 -202 168 202.
Can you try something huge like -10000 -10000 10000 10000 and see if the issue goes away?
✅ 1
u
trying
👍 1
the box is definitely huge now:
image.png
but DRC ain't happy yet
🙁 1
I pushed the current state here, btw:
I guess Tim will know to point us at the right direction
👍 1
t
@Uri Shaked: Ignore the DRC rule for now. I don't think that it will be properly checked on the SkyWater side, anyway, at least not rules having to do with area identifiers.
👍 1
The nwell error has to be taken care of outside of the SONOS device; the expectation is that there will be an array of SONOS devices, and they will all be inside a deep nwell structure, and the entire deep nwell structure will need to be surrounded by an nwell ring tied to the power rail (see any of the analog circuit layouts from Chipalooza). The nwell can't be put inside the SONOS cell or else the transistors will have to have massive amounts of space between them. The error will always show up within the cell, or with a single cell standing alone, but once you put the nwell ring around the deep nwell structure at the top level (or at least the level above the individual SONOS cells), the DRC error will go away.
✅ 1
@Uri Shaked: I don't get the DRC error if I just create the SONOS cell. Is this happening because you read back the SONOS device from GDS? That might makes sense---It looks like the COREID layer (areaid.ce) is not being automatically generated around SONOS devices like it ought to. I think I need to revisit some of this in the tech file. . .
a
I did a SONOS tapeout a year ago. I think the error went away when I added 
FIXED_BBOX
to the SONOS cell and also its parent? I also had to manually fix 
tunm
in klayout, but only in an array
t
@Aidan Medcalf: Critical question: Were you able to observe any clear floating gate behavior from the device?
a
@Tim Edwards I have been able to shift the Vt and make I-V curves proving it (irrelevant nitpick: it's not a floating gate)
t
Isn't the "N" in "SONOS" the floating gate?
a
It's an oxide stack (SiO2-Si3N4-SiO2) which stores charge in trap sites. The charges aren't mobile because it's not conductive
SONOS should be in dnwell with the iso-pwell (body) and gate used for program/erase. The nwell should be biased high (highest voltage--so if the body (pwell) is at +6.7V, the nwell should be at least that high--in practice just tie the nwell to the high program voltage)
t
@Aidan Medcalf: Thanks for the explanation. I have not studied the technology at all, and I just assumed that the buried layer was conductive.
@Aidan Medcalf: I see that in your repository you have a 240x250x64 array with the last commit message "Big sonos array---maybe working?". Was there a conclusion to that "maybe working"?
a
@Tim Edwards "maybe working" was w.r.t. DRC, either tap spacing or the 
tunm
issue. At the time, magic generated inconsistent 
tunm
rectangle sizes, which had to be fixed in GDS with klayout. That giant array is not electrically functional (terminals are shorted). The isolated SONOS and 8x8 2T SONOS / npass array devices (a layout you sent around some time ago) in the test pad area are working
h
Apparently getting rid of the SONOS cell 
sky130_fd_bs_flash__special_sonosfet_star_EA7MKQ.mag
and pasting its contents directly in the parent cell makes the error disappear.
👍 1
✅ 1
t
If a hack is necessary, that's on me to fix. . .
👍 1
u
Tim, would you like me to open a GitHub issue? How to describe this?
t
@Uri Shaked: Yes, please post a github issue (to my 
open_pdks
repository, since the error apparently arises from the device generator in magic). Just post the error. I can figure it out from there.
u
t
Thanks.
20 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by