<@U03H5SD02TY>: I have no idea about the cause of...
# magic
t
@Jake Ke: I have no idea about the cause of the error, although offhand it looks like there may be a stray piece of metal in the top level that is on top of one of the macros. The "can't overlap" error usually means that real metal layers are colliding with obstruction metal layers in an abstract view. The purpose of obstruction layers is to enforce that no (other) layout should exist in that area, and that's what magic is enforcing. It is not necessarily a "true" error, because the metal may be in a place where it does not cause any DRC or LVS issues. Klayout does not look at the abstract views; it just reads GDS and runs DRC on that, so it would not flag such an error unless the stray piece of metal was forming an actual DRC error with shapes inside the subcell. We do not fail designs in precheck based on magic's DRC check. There are numerous rules that can be purposefully broken if the designer knows what they're doing, and since we want to encourage experimentation, that's why we will only reject a design based on "manufacturing rules", which are run in klayout, and which are rules that, if violated, will cause SkyWater to reject the design. In the report you cite above, the precheck failure is from the klayout manufacturing rule check, so you need to fix that one.
1
j
Hi @Tim Edwards, following our discussion, please see this repo to debug that m5 error when you get time. The
gds/
lef/
def
folders have the up-to-date user project wrapper for you run precheck. Thanks! https://github.com/jake-ke/caravel_fast_ann_fieldious
t
@Jake Ke: What was the bounding box of the error?
And in what coordinate system (the whole caravel chip, I assume)?
j
Hi Tim, the bounding box is
box 675.370um 2645.385um 678.390um 2645.390; feedback add "Can't overlap those layers" medium
. It is in the caravel user project wrapper coordinate.
t
@Jake Ke: Thanks! This is indeed an issue. In that position there is a cell
sky130_fd_sc_hd__probe_p_8
. Now the probe cells are special-purpose cells that are designed to buffer a signal and take it all the way to the top metal where it can be probed on a probe station. Under no circumstances should a synthesis tool be allowed to use this cell as a buffer! By having it placed under a power bus, it is shorting its output to the power rail, which is bad. It is the pin on top metal in the cell that is being flagged as an error, since the whole digital block is abstracted and this probe position won't be designated as a subcircuit pin. This is exactly what the magic overlap check is designed to catch.
This could also be construed as an openlane/OpenROAD error, since it appears that the power network generator does not respect obstructions in the standard cells that are on the layers used for the power network. Probably an assumption has been made that the power supply metal layers are not used in the standard cells, without any check to see if that's true or not.
j
Thank you Tim! I am really glad that we found this issue. In fact, I think many of the dont use cells we defined in the constraint file still showed up in signoff
lvs.v
netlist. Somehow, those constraints are not preserved by DC and they got lost when sent to Innovus. Innovus probably did some optimizations so many dont use cells showed up again. I think I am going to try defining those dont use cells again in an Innovus tcl file and see if that helps. Could this be the same issue as https://skywater-pdk.slack.com/archives/C016H8WJMBR/p1654903152821919? I found that the cell under metal5 is also`sky130_fd_sc_hd__probe_p_8` .
t
@Jake Ke: Yes, I think it's exactly the same issue.
👍 1