Tapcells placed on top of macros when they are closely placed

[joaomai]

Describe the bug

When macros are placed very close to each other tapcells may end up on top of macros.

Expected Behavior

Tapcells shouldn't be placed on top of macros.

Environment

-

To Reproduce

Relevant log output

Screenshots

Additional Context

The error lies in the cutRows function from the ODB module. The start_origin_x can be moved to a smaller x value if two macros share a row on their vertical boundary.

[codinghardware]

Hi,
I came across this issue and out of interest I looked into it, as I have previously worked on tap cell insertion on complex shield shapes. The proposed fix, using maximum start_x and adding the validation seg_end > start_origin_x seems to solve the issue.

However, while going through the cutRows() function, I noticed a potential concern. Looks like the code is iterating over the row and deleting it simultaneously if its empty. This might cause an undefined behavior such as rows being skipped or being processed more than once or potentially crash. This can be easily solved by separating the empty row identification and deletion.

// PASS 1: Identify rows that need cutting (read-only)
std::vector<std::pair<dbRow*, std::vector<dbBox*>>> rows_to_cut;

for (dbRow* row : block->getRows()) {
std::vector<dbBox*> row_blockages;
for (dbBox* blockage : blockages) {
if (overlaps(blockage, row, halo_x, halo_y)) {
row_blockages.push_back(blockage);
}
}

if (!row_blockages.empty()) {
    if (placed_row_insts.find(row) == placed_row_insts.end()) {
        // No placed instances - safe to cut
        rows_to_cut.emplace_back(row, row_blockages);
    } else {
        logger->warn(utl::ODB, 386, 
            "{} contains {} placed instances and will not be cut.",
            row->getName(), placed_row_insts[row]);
    }
}

}

// PASS 2: Now safe to modify the collection
for (auto& [row, row_blockages] : rows_to_cut) {
cutRow(block, row, row_blockages, min_row_width, halo_x, halo_y);
}

Happy to submit a PR with the fix if this approach seems valid.