Filler cells placed outside EndCap

I did a test where I recreated similar to what you're describing, and I see the end cap cells placed right up against the placement blockage.  If I had to guess, 1 of 2 things is happening in your case:

1. The placement blockage is somehow not in sync with the placement grid.  Not likely that it would be off by so much that it would allow a filler cell to get in however.
2. addEndCap and addFiller are respecting power stripe differently for some reason.  Do you have a power stripe in the vicinity?  If so, does the same happen if you temporarily remove the power stripe?  You might want to check what layers of power striping are currently set to be treated as placement obstructions (under Place->Specify->Placement Blockage).  The default is that stripes on M1 and M2 are treated as if they're placement blockages, but you might want to check whether that's affecting things and/or addEndCap/addStripe are treating this differently.

If these suggestions don't help, I wonder if you could post a picture of what you're seeing -or- file a service request with your AE or on http://sourcelink.cadence.com

Hope this is helpful,
Bob

 Hi Bob,

Thanks for looking at it. Here is a quick screen shot.

Thanks for the picture!

Boy- it sure looks like the end cap is stopping coincident with where that red horizontal power wire is coming over, doesn't it?  Was the horizontal power in red created with addStripe or sroute?

I'll be trying each here to see if I can reproduce, but if you let me know it would be helpful.

 yeah, it sure seems that way. That's what I've been primarily messing with. Unfortunately for me, someone else wrote the tcl, and I'm not too familiar with the subtleties of the commands. What I have now is an addStripe followed by an sroute, so I'm not sure what it's doing.

           addHorzStripe GND M2 M2 M2 M2 M3 0.36 5.76 $YMIN
          addHorzStripe Vdd M2 M2 M2 M2 M3 0.36 5.76 [expr $YMIN + 2.88]
          # extend M2 strip to close to macro boundray
          sroute \
            -corePinLayer 2 \
            -layerChangeBotLayer 2 \
        -connect { corePin floatingStripe } \
            -straightConnections { straightWithDrcClean } \
        -stopStripeSCPin { boundaryWithPin }

  # Draw a horizontal power stripe
proc addHorzStripe {NET LAYER BLOCK_BOT BLOCK_TOP VIA_BOT VIA_TOP \
                    WIDTH PITCH YOFFSET} {
    global YMAX
    addStripe \
        -nets $NET \
        -layer $LAYER \
        -direction horizontal \
        -width $WIDTH \
        -spacing 0.24 \
        -set_to_set_distance $PITCH \
        -start_y [expr $YOFFSET-$WIDTH/2] \
        -stop_y  [expr $YMAX+$WIDTH/2] \
        -allow_jog_block_ring 0 \
        -allow_jog_padcore_ring 0 \
        -max_same_layer_jog_length 0.0 \
        -merge_stripes_value 0.0 \
        -block_ring_bottom_layer_limit $BLOCK_BOT \
        -block_ring_top_layer_limit $BLOCK_TOP \
        -stacked_via_bottom_layer $VIA_BOT \
        -stacked_via_top_layer $VIA_TOP \
        -create_pins 0 \
        -extend_to design_boundary
}

No luck reproducing it with a simple placement blockage.

I'm wondering- what's stopping the power stripes from going over the placement blockage?  The reason I'm wondering is because I'm wondering if there might be a hard macro in the vicinity with either obstructions or power striping or a block halo that's not visible.  Or perhaps a routing blockage present that's not visible.  Or perhaps the block is rectilinear and the cutout is being modeled with a placement blockage?

Tough to debug without the design.  If it's too cumbersome for you to go back and forth on the forum we could take this off-line and work it through the regular channels and summarize what we find for the benefit of others.

 It is indeed trying to do a cutout in the corner of the block. We represented that as a placement blockage plus routing blockage on all layers. So that's why the stripes don't extend. I did experiment with manually changing those routing blockages to a thin ring (thinking that maybe it was a wide-metal spacing rule), and that didn't help.

 How much of the design do you need? Could I just send you the .enc* or would you need all of the libraries and stuff?

Hi Steve,

Nice to connect with you on the phone just now. For the benefit of others that might come across this issue, here's what we found:

First, the placement blockage in the image above (along with a routing blockage that's not visible) is modeling a cutout within a rectilinear block.  We discussed modeling the block as a true rectilinear instead of with a placement and routing obstruction (which the tool supports via the GUI and with the setObjFPlanBoxList command).

Second, we did some testing and noticed that addEndCap is placing the end cap instances a few microns away from the routing blockage to avoid a drc violation between the metal in the end cap cell and the routing blockage.  However, addFiller does *not* do this, even with "-doDRC true".  This was made particularly obvious because the large routing blockage triggered wider spacing due to width-dependant spacing rules in the tech lef.  This is why filler cells were able to sneak between the placement blockage and the end cap.  I'll look into the inconsistency and report back.

Further, we noticed a slight difference in terms of how far from the routing blockage addStripe stopped and where addEndCap placed the instance.  I'll also look into this and report back.

Issue related to wide swaths of routing obstructions are good examples why modeling a block as a true rectilnear.  Steve, if you could report back on how that works out for, that would be great.

Another approach might be to edit the LEF to remove the larger spacing requirements for wider wires, but it seemed preferrable (to me) to go the rectilinear route because that would enable the horizontal stripes and the end cap cells to be abutted with the rectilinear edge.

Thanks for raising this issue- it's a great example to learn from.  I'll be following up as I have more information on the points I mentioned.

Let me know if you have any more related questions, and thanks for using the forums. I appreciate it.

Oh, one more thing...

Not that we needed it in this situation, but if anyone ever needs to send a self-contained testcase- here's a blog entry that describes how to do that easily:

/blogs/di/archive/2009/07/16/how-to-create-a-self-contained-testcase-in-encounter.aspx

 Anurag actually found an option that fixes the issue. The filler cells now always stay inside the endcap.

  setFillerMode -honorPrerouteAsObs true

Hi Steve,

Thanks for following up with that information.  I see that effective as well, though I think we could improve the documentation for that option since it doesn't state that routing blockages are considered as if they're equivilent to prerouted nets in terms of how addFiller avoids placing filler cells nearby.  I'll file an enhancement request for the documentation.

It sounds like this will work well for your situation as long as you're okay with having these end caps and filler cells a few microns away from the routing blockage.  If you (or anyone else) wants the end caps to be right next to the routing blockage, I wouldn't know how to make that happen since addEndCap doesn't have a similar option for arbitrating whether preroutes (or routing blockages in this case) should be treated as placement blockages. I'll file a CCR asking for an improvement in this area as well-addEndCap and addFiller should be aligned in their behavior as your scenario points out.

Thanks for raising the issues- every interaction we have with users is a chance to improve our solution.

-Bob