Hi, is it possible to have an nmos (nfet_01v8) wit...
# sky130
d
Hi, is it possible to have an nmos (nfet_01v8) with 0.36um width & 0.15um length? When I was designing and simulating my schematic, I looked up the minimum width & length from the models (looked at the model bins in
/usr/local/share/pdk/sky130A/libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_01v8.pm3.spice
), and from there I gathered minimum width & length for the nfet_01v8 were 0.36um/0.15um. My circuit needs small devices to minimize capacitance on certain nodes for high speed, so I set some devices in my schematic to that size, and it simulated without issues. I designed & verified (pre-layout) my circuit with those dimensions, but then when I get to the layout stage, Magic says that "Mos width must be >= 0.42 um" for that device... And it won't let me draw a 0.36um wide device. Why is there this inconsistency between Magic and the Sky130 model files? Which one is correct/to be trusted? Thanks
🌏 1
t
The
0.15um
length is only approved by SkyWater for use in the SRAM cells, where the density and regularity of the array allow for considerably smaller devices. Magic's device generator follows the guidelines for devices outside a standard cell or SRAM core cell. If you use such a device you will be adding risk to your design, as the device behavior is likely to be considerably off from the model. However, such a device does not violate any manufacturing rules, so you are free to experiment with it. In magic, you would need to draw the layers by hand rather than use the parameterized device generator, since the parameterized device generator will enforce the regular DRC rules.
s
@User, i always thought the SRAM-only gate length was 0.13. 0.15 is used in almost all stdcells. Or are there some changes i am not aware of between drawn dimensions and mask dimensions?
t
No, even the SRAM device minimum length is 0.15um, if you don't consider some weird parasitic transistors that are created by partial overlaps of poly over diffusion that have an effective length of 0.08um or something, but those are MOScaps, not true transistors. But yes, it is true that the standard cells have 0.15 length devices, so I should not have said that the 0.15um length was "only" approved for use in the SRAM cells.
👍 2
s
Thank you.I think @User question was more about the minimum width (together with minimum length). He is using W/L=0.36/0.15 in schematic and simulations with no errors, while getting a DRC violation in the layout (Wmin=0.42). May be Wmin and Lmin are mutually exclusive. Not sure.
d
That's right @User, my question is can I use a 0.36um/0.15um nfet_01v8 in my high speed circuit, in layout? Since there is a valid model bin in the PDK for that pair of W/L and it simulates fine. And @User how do I get around that
"Mos width must be >= 0.42 um"
notice from Magic? I don't think it's even a DRC, it's a message that appears on Magic's command console as soon as I click "Apply" on the params window for that device when trying to enter 0.36um width. And Magic won't even draw the 0.36um device, it just closes the form and sets the device back to 0.42um width.
t
@User: Yes, it is a SkyWater DRC rule that transistor gate width must be >= 0.42um except in standard cells, where it is allowed to be 0.36um, and SRAM macros, where it is allowed to be 0.15um. You can work around this in magic in one of two ways: (1) draw your own transistor by hand (poly + diffusion) instead of using the parameterized cell, or (2) edit the parameterized cell after it is created and reduce the transistor width by, for example, selecting the top half of the layout and compressing it downward. The result will always have a DRC error. But you should not be breaking any "manufacturing rules" and so the project won't be rejected by SkyWater. If you do option (2), then just be aware that any attempt to change parameters in the parameterized cell will result in the cell being redrawn with a 0.42um width. As long as you don't touch the parameterized cell through the GUI window, any edits you make to the cell will remain.
d
Thanks for the clear answer. I will try that