<@U016EM8L91B> Layout of `dfrbp_2` std cell was in...
# magic
v
@Tim Edwards Layout of
dfrbp_2
std cell was instantiated in magic with drc error count =0. If i run
DRC complete
followed by
DRC update
then the error count increases to 27. Any suggestions why this is happening and how to approach this ?
m
@vks I think the interactive drc=0 is a subset of the full drc rules - it does not check every rule, especially avoiding the rules that will flag errors on incomplete layouts such as standard cells.
drc full
on the other hand, expects all the drc rules to be satisfied include rules that flag errors on standard cells because they are missing well and substrate taps. In summary, expect errors when using
drc full
with standalone standard cells.
v
@Mitch Bailey For tapeout submission if it ok to go ahead with DRC interactive results only and DRC full can be ignored? Does precheck take these facts into consideration.
m
precheck does the full drc. You should probably run full drc on your macro level designs, if you have any.
v
I ran full DRC on my macro containing layout of standard cell and found errors which were not visible earlier with DRC interactive. If so, what can be the solution, is it ok to correct these in standard cell layout, is it recommended?
m
Are you creating the layout in magic or klayout? There are somethings you can do to fix some drc related errors related to standard cells in magic, but I do not recommend editing the standard cells directly. Can you share the errors that you are seeing?
t
@vks: You should have watched my Chipalooza workshop #3 on physical verification, because I explained this. . . You cannot get meaningful results running full DRC on a standard cell by itself because the standard cell by itself contains DRC violations that are not resolved until the standard cell is placed in the proper context of a digital layout. If you want to resolve the errors then in this case you need to have a layout containing the standard cell and at least one tap cell to connect the well to power and substrate to ground, and to satisfy the tap distance rule.
1
v
@Tim Edwards @Mitch Bailey I am using standard cell as part of analog design and getting no DRC errors in interactive mode. I had also added dedicated tap connections to provide bulk connections to transistors used in these blocks for LVS clearing purpose and no DRC errors were generated there also. It was while submitting to tiny tapeout that during precheck these additional DRC errors were discovered. Can you suggest how can these errors be rectified ? And reason why they are appearing since tap has been added .
I had added a tap connection on one side of std. cell layout just for purpose of LVS clearing. Is it that it requires to be added in all directions surrounding digital cell ?
image.png
m
@vks Are you saying that the above design was used to pass LVS, but is not what is submitted to tinytapeout? Rather than adding hand-drawn taps, I think it would be easier to place a tap cell
sky130_fd_pr__tapvpwrvgnd_1
sky130_fd_sc_hd__tapvpwrvgnd_1
. For one cell, you probably only need one tap. If you have a row of cells, you’ll want to add the taps every 15um or so and offset rows above and below by 7.5um. (See openlane generated cell rows for examples). Can you share the gds you submitted to tinytapeout?
v
@Mitch Bailey Where can I get tap cell
sky130_fd_pr__tapvpwrvgnd_1
? Attaching LVS clean gds where DRC interactive errors are 0 but DRC complete shows 17 errors. Please suggest how to take care of these errors.
m
Do you have access to a sample standard cell output of openlane? Maybe download
caravel_user_project
and run
Copy code
make setup
make user_proj_example
and then take a look at
gds/user_proj_example.gds
. Your standard cells are placed with horizontal and vertical spacing that does not need to (should not) be there. Cells are generally placed so that the metal in the cells abuts (nwell overlaps) - you shouldn’t have to draw metal to connect the cells. Every other (vertical) cell row is generally flipped on the x-axis so that the pmos is on the bottom and the metal1 vdd coincides with the metal1 from the lower cell row. Tap cells, which should be in the mag or gds library, should be inserted at least every 15um. What errors are you getting with full drc errors?
You can also add
sky130_fd_sc_hd__fill_x
cells to make the cell rows the same length.
t
@vks:
tapvpwrvgnd
is in the standard cell library; the reference to
sky130_fd_pr
is a typo. Look in the HD library for
sky130_fd_sc_hd__tapvpwrvgnd_1
.
😱 1
v
@Mitch Bailey @Tim Edwards Please check attached steps for adding tap connection to digital std cell using
sky130_fd_sc_hd__tapvpwrvgnd_1
cell from HD library. Before adding this cell drc error count was 27 from 'DRC complete' run which later reduced to 0. Hope this is the correct approach for adding tap connection to std. cell layout and should clear tiny tapeout precheck following this approach ? Please confirm.
m
@vks move left until metal abuts. nwel overlaps.
v
@Mitch Bailey Is this correct? Do pwell also needs to be abutted ?
m
I don’t think pwell is actually used as a mask layer, so you can ignore it.
👍 1