How to specify space between cells in SoC Encounter

Hi,

I have specific pair of cell instances in my design that should not be placed very close to each other? Is there any way to specify the spacing between specific cells?

I'm not a synthesized-layout kind of guy, but I can
suggest you have a look at standard library cell construction
for features like a "prBoundary" polygon. This shows the
cell extents for butting (but, whether this is used directly
or is somehow massaged into tabular data elsewhere, I
couldn't say). I would suggest widening out that feature
so that the cell asserts the clearance it needs, and see
if this alone suffices (or if some sort of "compile" has to
be done after).

Now if these are not special cells, but special constraint,
maybe you want to design and lay out a "hard macro"
that embodies those constraints and is placed / routed
in that way?

You can specify cell padding to those cells. The padding will keep some space between the specified cells and others, not only just between the specified cells.

But, I wonder why those cells can not be placed close to each other.

Thanks for your replies.

Let me clarify the question with an example. Let assume that there are 10K gates in my design. I analyzed them and I find those that if placed close to each other, they increase circuit failure probability (due to soft errors). Now, I want to have at least 10um distance between these vulnerable pairs.

This is a common concern among designers of space grade
digital ICs (memory and Big Digital particularly) and you may
find more useful guidance out of IEEE TNS, NASA and other
radiation-effects conference publications. You could Google
for "multi-bit upset" and so on. I do not recall ever seeing
the low level details of routing, only people presenting that
they did enforce distributed layout styles in critical blocks.

My recommendation is that you determine a "leaf cell" (if
this is a memory design) that contains some plurality of bits
laid out at your desired bit spacing - maybe it's 2x2, maybe
it's 16x16, maybe it's orthogonal to the word, whatever)
and make that your buttable unit cell and lay out the array
with that, not single bits in linear orthogonal arrangement
and waiting for an unfortunate angle of incidence.

Well, in our design, we analyze what could stop the software (under reset, no clock, no power) and we duplicate the flops which involve for these "stop" conditions + a majority logic.
With this we reduce the probability of x-ray radiation impact, and we are in safer side if the software is properly coded.
We also track the reset source, to help the software to understood what cause the reset.