Another peculiarity is that all of the PR boundaries in the SRAM IP are inflated and aren't actually PR boundaries (i.e. connections won't be made if you use them as is, they will need to be deflated by a factor). This isn't so in the std cells

What cell are you looking at? I don't see any issue with the boundary layer. For the cell I looked at, the boundary layer exactly matches the extents of the geometry.

The bitcell, for example. Not the standard cells.

I don't see a boundary layer on the bit cell. What layer number are you looking at?

0/0

Okay, I must have done something to disable that layer in my tech file. It looks like layer 0/0 is at the geometry extents, not really a scaling of the actual boundary. The GF documentation lists "63 0" as the boundary layer, and there are cells with "63 63" that is not documented (I haven't looked to see if those are marking boundaries). From what I've seen, it looks like "0 0" might actually be indended as an extent-of-data marker and not an abutment box, in which case the SRAM bitcell is just missing an abutment box.

Yes, I noticed that 63 63 as well. It also looks like the cell extent may be appropriate for placement. I'll check more tomorrow.. in Italy at ESSCIRC so time for dinner

Envious. . . : )

Here is the example of M1 in the bitcell and the boundary. You can see that there are actually TWO boundaries. One is correct, one is inflated.

Which layer number is the real bounding box and which is the outer one? (I still don't think it's "inflated". I think it coincides with the nwell and pwell and marks the bounds of all geometry). Magic is probably counting both layers as an "abutment box", and the larger one ends up overwriting the smaller one (probably with an error message about the boundary being redefined).

Yes, you are correct that the larger/second bbox is the content extent of the cell.