https://open-source-silicon.dev
Join Slack
`sky130_fd_sc_hvl_lsbufhv2lv_1` is showing some DRC errors when I instantiate it (see picture). Com...
# chipalooza
r
sky130_fd_sc_hvl_lsbufhv2lv_1
is showing some DRC errors when I instantiate it (see picture). Complaining about MV diffusion being too close to low-voltage nwell. Anyone come across similar issues with the sky130 hvl library?
t
This is a rather weird rule in which the HVI layer may abut the nwell, so that it is illegal to have the nwell less than 0.825 away from the diffusion inside HVI unless it is at the exact distance at which HVI abuts nwell, which is how this cell is drawn. Since magic wants to draw its own HVI layer, it does not draw it in the same area as was done in the original standard cell layout. To maintain the precisely and intentionally placed HVI layer, the .mag cell for this layout has a property called MASKHINTS_HVI that specifies where the layout has the HVI layer drawn. This appears (or is supposed to) at the end of 
$PDK_ROOT/sky130A/libs.ref/sky130_fd_sc_hvl/mag/sky130_fd_sc_hvl__lsbufhv2lv_1.mag
. If you read the cell from GDS and then pass it through magic, this error will show up. Two ways to resolve the problem: (1) after reading GDS, edit the 
lsbufhv2lv_1
cell and run the command 
property MASKHINTS_HVI 22 34 706 1316
to restore the position of the HVI layer in the layout. (2) try the GDS option 
gds maskhints on
. This is pretty experimental, but is supposed to restore the mask hint automatically.
r
Hi Tim, thank you, would've never figured that out. Following your instructions by entering 
property MASKHINTS_HVI 22 34 706 1316
, the DRC errors are gone, but I noticed the coordinates actually extend beyond the cell (see box in picture). Is this the intended size and location of the HVI layer? Thanks.
Please ignore my last post, I found out the coordinates were magnified by 2x, making the rectangle twice as big.
After issuing the command 
property MASKHINTS_HVI 22 34 706 1316
, saving, and re-inserting the cell 
sky130_fd_sc_hvl_lsbufhv2lv_1
, I am still seeing the DRC error in the parent cell. Further, a second DRC error (see picture) related to min. width of HVNTM has appeared. Just to be clear, I made a local copy of 
sky130_fd_sc_hvl_lsbufhv2lv_1.mag
from the sky130 pdk and did the modification and saving and re-inserting of it in the parent cell. And I did check and verify that 
property MASKHINTS_HVI 22 34 706 1316
is located at the bottom of the file 
sky130_fd_sc_hvl_lsbufhv2lv_1.mag
.
t
I see that the error returns when anything is painted over the cell, like the metal 1 stripes. For now, treat these as false positive errors, and I will need to track down why they occur. I do not see the HVNTM error, which I think has something to do with the presence of the cell to the left. What cell is on the left of the level shifter?
r
This is the cell to the left: 
sky130_fd_sc_hvl__lsbuflv2hv_1
t
As I suspected, the HVNTM error appears as soon as I add the other level shifter to the left. So I can confirm all these errors and will see what I can do about making them go away.
🙌 1
The HVNTM error is "real" in the sense that I am missing an output rule for ensuring the minimum width of 0.7um; this is also a "false positive" error in the sense that the actual layout has HVNTM running from edge to edge of the cell. But I am correcting the HVNTM output rule so that that particular error will disappear in the future. The other error is more problematic, because it indicates that magic is ignoring the mask hints when computing hierarchical DRC, which probably means that the mask hints are not getting copied into the flattened cell that is generated to do the hierarchical checks.
🙌 1
I just fixed the error with the HVI layer (the 
HV diffusion to LV nwell spacing
error) in magic (version 8.3.470). I fixed the error in the PDK that generated the HVNTM layer error, and confirmed that the HVNTM no longer violates a design rule. But magic's DRC engine is still flagging it as an error, which I don't understand, so I'm still investigating that one.
👏 1
r
Awesome! Go Tim
t
And, okay, I figured out the other problem, too, which is that due to the way that magic implements boolean operators for DRC, the GDS generation rule has to be duplicated in the DRC section, which I forgot to do.
Except that wasn't the end of the story, and now several hours later I've finally tracked down all the bits and pieces leading to the last false positive DRC error and eliminated them all.
🙌 1
r
Yay!! Thanks for solving these problems so expediently, and in real-time, really helping me move along. Much is appreciated.
👍 1
42 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